

Show HN: Imgix Sandbox – Explore on-demand image processing - zacman85
https://sandbox.imgix.com

======
notduncansmith
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 manage. A killer feature for us was allowing us to source images
from an S3 bucket (a feature Cloudinary only exposes to Enterprise customers).

~~~
tortilla
I'm on Cloudinary and looking to migrate out. How difficult was it to switch?

I'm at the Enterprise level at Cloudinary

~~~
notduncansmith
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.

~~~
tortilla
Thanks! Yeah, we're storing IDs and we're already using a bucket. Thinking
about it now, it doesn't seem so daunting. :)

------
mmastrac
I was skeptical about imgix, but I recently plugged it into a CMS for a
startup I was helping out as a simple image editor + transcoding service. It
did pretty much all the work: all I did was add a few buttons to alter the
bri/con/vib parameters, and hook the crop up to simple jQuery cropper plugin.

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.

------
cscharenberg
Looks very similar to Cloudinary
([http://cloudinary.com](http://cloudinary.com)) which I use for my startup.
The pricing at lower end of images looks better for Imgix but doesn't scale as
well. Still, I think cloud-hosted image processing is a great service and I'm
glad there is competition in it. It let us skip huge amounts of dev work
related to constructing image pipelines and organizing assets: we pay $40
(plus more for some addons) and get a massive image layer. Imgix, Cloudinary,
and others let you focus on the unique parts of your own software at a really
good price.

------
choonkeat
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](https://github.com/choonkeat/attache_rails)

being able to host it yourself solves the last 20%
[https://github.com/choonkeat/attache](https://github.com/choonkeat/attache)

~~~
skuhn
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](https://www.imgix.com/docs/reference)

Client libraries are at
[https://www.imgix.com/docs/libraries](https://www.imgix.com/docs/libraries)

(also, I think your percentages may overflow)

~~~
n0thing
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?

~~~
kellysutton
(Employee of imgix here.)

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](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 :)

~~~
mc74
Rather than ImageMagick, how do your benchmarks compare against libvips?

[http://sharp.dimens.io/en/stable/](http://sharp.dimens.io/en/stable/)

~~~
kellysutton
Not sure. We'll have to run some on our end and get back to you.

------
biturd
as per the notes, I am forwarding this error message on:

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

------
monksy
So this is imagmagik as a service?

~~~
chrislloyd
From their homepage: "This is not ImageMagick running on EC2"

~~~
monksy
Oh, ok I didn't see that from the link provided.

