

Show HN: Imgix.js, a JavaScript library for responsive imaging - zacman85
http://www.imgix.com/imgix-js

======
fimdomeio
I wonder why are there so many services that work with this kind of business
model. while I would be willing to pay for code I can own, I would never
invest in something in something where I can't predict it's future.

~~~
latch
I can't speak specifically about this responsive image feature, but as for
imgix's core business, I have mixed feelings.

It's pretty trivial to write on-the-fly image processing using an existing
graphics library. And given that the image can be cached and served from disk
and a CDN, it can scale incredibly well.

Having said that, the features that they support is impressive, the API is
intuitive, the speed is great, and you can stick your own CDN infront of it
(or use theirs, which is actually Fastly, I believe). The founder, Chris, is
wicked smart...this is really more than just a wrapper around GM.

~~~
egonschiele
I just had to write an image server for work and found it incredibly hard.
What's your on-the-fly image processing setup look like?

~~~
latch
I'd break it down into two parts. The first is the image transformation. For
this we use graphics magic, and based on the params in the querystring, we'd
crop, resize, alter the quality, anchor the image to a focus point and so on.
Not copy and pastable, but [1] should give you a rough idea. Also [2] is code
we use to get the file type and size of the image (gm identify can be
painfully slow).

The second part was a bit more "fancy". There were two really slow parts to
this (a) fetching the origin (from S3) and (b) applying lossless compression
(for a large image, it can take 10+ seconds). Fetching from origin is easily
solved by caching the origin to disk. So if you ask for
goku.png?w=90001&h=9001 and then goku.png?w=2393&h=43433 it's only going to be
1 origin fetch. For the lossless compression, we just used the filesystem as a
queue. We'll serve up the umcompressed image with a short cache header (maybe
10 minutes) and store it in /storage/uncompressed. The filesystem is monitored
and when a file is added, we compress it and them move it to
/storage/compressed.

So, when you serve an image, the flow is:

\- check for the file in /storage/compressed/ and serve that with a long cache
header (this is a fully transformed image (hash the querystring parameters))

\- check for the file in /storage/uncompressed/ and serve that with a short
cache header (this is a fully transformed image (hash the querystring
parameters))

\- Check if we at least have the original in /storage/original

    
    
      - if not, fetch the original, put it in /storage/original
    

\- Transform the image, store it at /storage/uncompressed and serve it up

\- In the background, compress images and move them from /storage/uncompressed
to /storage/compressed

It might seem like overkill when you consider that, despite serving thousands
of images per second, the CDN handles almost every request. The problem is
with the lossless compression. We found it impossible to do it on-the-fly for
too many of our images, so you absolutely need that available and ready to go
for the 5% CDN miss.

[1]
[https://gist.github.com/anonymous/8f328359f07f6c5d142e](https://gist.github.com/anonymous/8f328359f07f6c5d142e)

[2] [http://openmymind.net/Getting-An-Images-Type-And-
Size/](http://openmymind.net/Getting-An-Images-Type-And-Size/)

~~~
egonschiele
I have heard anecdotally that graphicsmagick and imagemagick both have awful
memory leaks. Did you run into this? We serve ~400 reqs/sec from our image
server _after_ putting a CDN in front of it, so we couldn't work with memory
leaks.

File size was a problem for us too, as was file format. We needed a solution
that would work with pngs, jpegs, gifs and tiffs.

~~~
skuhn
I worked for a company that used ImageMagick for compositing images together
and resizing them to one of ~60 sizes (different page locations, device types,
etc.). While it worked, and it was at the core of the company's technology, it
was truly the worst software I have ever had to wrangle into a production
service.

You name it and ImageMagick could do it:

    
    
      - Leak memory
      - Perform terribly until you find the magic incantation that is 10x faster
      - Output wildly different images after a minor patch release
      - Remove / change options after a minor patch release
      - Enormously degrade performance after a minor patch release
      - Have numerous security vulnerabilities all the time, which require frequent upgrades
      - Dump core more often than you might like
    

It took us upwards of 3 months to simply move from one ImageMagick release to
another (a few minor versions ahead), and we had to do all sorts of
workarounds and A/B tests to ensure the images would look right.

I heard that GraphicsMagick was superior in that it maintained some
consistency of behavior between versions, but it doesn't have all of the
functionality of ImageMagick. So we couldn't switch to it.

Another company that I worked for had a fleet of several thousand servers
running constantly just to thumbnail user uploaded images, and it was not
unheard of for it to fall behind.

IM / GM are the stock answer to process images, but from my experiences they
have no place in a production system. I think this is an area that is pretty
poorly served by open source software; there are lots of libraries to handle
different image formats, but no good infrastructure exists to tie it all
together (that I'm aware of).

~~~
egonschiele
Eep. Thanks for the writeup. I'm really glad we didn't go with imagemagick.

------
justinph
This is nice, but it does not put a valid img tag in the document source
without javascript execution. That might be fine for things that don't face
the public internet, but if you do any type of public publishing, you should
care about having markup that describes your content independent of scripts or
css.

This is why standard markup-based responsive images (picture and srcset) are
such a big deal.

~~~
miggi
There is nothing stopping you from setting the src tag. But you are just
adding another request. Our base service works perfectly with src set and
picturefill. This library is for cases where a different result is desired.

~~~
sleepyhead
Why isn't there an img-tag in the default example? Why are you promoting bad
practice by not having images in img-tags? You solved one problem but created
a much bigger problem. Bots, screen readers and non-javascript client should
see an image, not a div with some attributes.

~~~
sim0n
They're welcome to target whichever type of users they want to - it's 2014,
most average internet users have javascript enabled. Besides, you can add a
title/aria-* attribute for bots and screenreaders (perhaps not semantically
correct but gets the job done).

~~~
sleepyhead
Yes it is 2014 and we should be able to follow simple standards that has been
around for quite some time.

------
kingzain
What would the advantage of this be versus using the picture tag with your own
image sources hosted on a CDN? (Let's assume picture tag is widely supported
for now)

~~~
miggi
It is possible to easily target thr picture element using imgix's URL API
directly. However, with picture you are limited to a set of image sizes and
predefined dprs. This library allows the containing element to recieve an
image at any size necessary with any DPR multiplier (up to 5, I believe) with
the added bonus of conditional image manipulation overrides. In the example,
we are baking in textual image information. Other edits like image quality and
sharpening or midtone adjustments could be conditionally set as the image
crops larger or smaller.

------
tantalor
Title is "for responsive images", not "imaging".

Imaging is completely different!

~~~
miggi
What is your definition of imaging? Our use of imaging is in reference to
imaging in technology. "The production of graphic images from digitally
generated data." Our service processes images on our servers and produces new
image data with each request when necessary (if not cached already.) The
Javascript library is just a way to interface with our infrastructure and
generate these requests.

------
crapiola
where did they get the yeti image in the demo?

~~~
miggi
I'm not sure what "yeti" image you are referring to. All images were purchased
royalty free images from iStockPhoto.

