11–20 of 22 posts
404 Not Found The server can not find the requested page:
www.texturequalitypro.com/assets/files/content_files/TextureQualityPro_Large_Sample.jpg?w=250&border=5&txt=this+is+a+test&vib=20 (port 443) Please forward this error screen to www.texturequalitypro.com's WebMaster.
Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4 Server at www.texturequalitypro.com Port 443
I'd like to give a big shout-out to Imgix, they've built a truly useful service. Their landing page copy features lines like "You can't build this in a weekend" and "This isn't ImageMagick running on EC2" - and from what I've seen using them, they live up to it. Kudos on a great product, Imgix team (and congrats on the recent funding)! P.S. We tried using Cloudinary at first, but Imgix turned out to be much easier to…
I'm at the Enterprise level at Cloudinary
having a client counterpart lib to ease you in solves the other 80% https://github.com/choonkeat/attache_rails
being able to host it yourself solves the last 20% https://github.com/choonkeat/attache
having an image server with apis solves 80% of the problem. having a client counterpart lib to ease you in solves the other 80% https://github.com/choonkeat/attache_rails being able to host it yourself solves the last 20% https://github.com/choonkeat/attache
Behind the scenes it uses imgix's production infrastructure via the published API. We think it's really helpful to be able to quickly iterate over ideas, and we plan to use it ourselves within our API documentation.
The imgix API is documented over at https://www.imgix.com/docs/reference
Client libraries are at https://www.imgix.com/docs/libraries
(also, I think your percentages may overflow)
I'd like to give a big shout-out to Imgix, they've built a truly useful service. Their landing page copy features lines like "You can't build this in a weekend" and "This isn't ImageMagick running on EC2" - and from what I've seen using them, they live up to it. Kudos on a great product, Imgix team (and congrats on the recent funding)! P.S. We tried using Cloudinary at first, but Imgix turned out to be much easier to…
I'm on Cloudinary and looking to migrate out. How difficult was it to switch? I'm at the Enterprise level at Cloudinary
having an image server with apis solves 80% of the problem. having a client counterpart lib to ease you in solves the other 80% https://github.com/choonkeat/attache_rails being able to host it yourself solves the last 20% https://github.com/choonkeat/attache
The imgix sandbox is meant as a tool to experiment and try things out. Behind the scenes it uses imgix's production infrastructure via the published API. We think it's really helpful to be able to quickly iterate over ideas, and we plan to use it ourselves within our API documentation. The imgix API is documented over at https://www.imgix.com/docs/reference Client libraries are at https://www.imgix.com/docs/libraries…
Earlier quoted context omitted.
I'm on Cloudinary and looking to migrate out. How difficult was it to switch? I'm at the Enterprise level at Cloudinary
I have no idea how hard it would be for you, we're still young so it was quite painless for us. The biggest thing is to move from storing image URLs to storing image IDs (which, if you're on Cloudinary, you may already be doing). If you're already uploading to your own S3 bucket, you're most of the way there.
Earlier quoted context omitted.
The imgix sandbox is meant as a tool to experiment and try things out. Behind the scenes it uses imgix's production infrastructure via the published API. We think it's really helpful to be able to quickly iterate over ideas, and we plan to use it ourselves within our API documentation. The imgix API is documented over at https://www.imgix.com/docs/reference Client libraries are at https://www.imgix.com/docs/libraries…
Assuming you're not using ImageMagick, what are you using and what makes your solution superior? Do you have any benchmarks comparing against ImageMagick/GraphicsMagick?
Most of our feature benefits are derived from being a "full-stack" imaging solution. Because we know a lot more about the request and the client, we're able to perform operations to deliver the best image possible. One of the ways we do this is our automatic content negotiation strategy, which will serve up WebP images for Chrome, JPEG XR for IE 10+, etc. These more modern file formats tend to be much smaller, with some of our customers seeing a 40% reduction in their CDN bills as a result.
We're also able to push all of the work to our GPUs on our servers without worrying about noisy neighbors. This means our mean render time is 80ms, with the 90th percentile being 150ms. We wrote about our solution of racking Mac Pros: http://photos.imgix.com/racking-mac-pros
Sure, you can configure your own ImageMagick setup to do all of this. As you build this out, whether as an internal or external service, the economic realities of running ImageMagick in a virtualized environment catch up with you. It’s difficult to do this affordably and in a set-it-and-forget-it manner.
When explaining the benefits of imgix, I'm often reminded of the old jwz quote, "Linux is only free if your time has no value." Having stood up a few ImageMagick instances at previous jobs, I was happy to see imgix come along. Fast-forward a few years, and now I work there :)
Earlier quoted context omitted.
The imgix sandbox is meant as a tool to experiment and try things out. Behind the scenes it uses imgix's production infrastructure via the published API. We think it's really helpful to be able to quickly iterate over ideas, and we plan to use it ourselves within our API documentation. The imgix API is documented over at https://www.imgix.com/docs/reference Client libraries are at https://www.imgix.com/docs/libraries…
Assuming you're not using ImageMagick, what are you using and what makes your solution superior? Do you have any benchmarks comparing against ImageMagick/GraphicsMagick?