P.S. We tried using Cloudinary at first, but Imgix turned out to be much easier to manage. A killer feature for us was allowing us to source images from an S3 bucket (a feature Cloudinary only exposes to Enterprise customers).
I'm at the Enterprise level at Cloudinary
We're also using it as a way to upload jpeg2000 files from iOS devices to save on bandwidth, which will then appear properly on Android and desktop.
I'd say it saved me a fair bit of infrastructure work.
EDIT: They had an outage the other day where new images weren't being cached that was fixed within a few hours (that sucked), but were awesome enough to provide a root cause for me.
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)
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
However, after doing so, you may find that it's terrible code, slow, leaky, and a giant pain to use in production at any real scale.