What? Processing a thumbnail is insignificant compared to processing a video - in fact it's on the same magnitude as making a single frame of video... Maybe Google uses a lot of hardware encoders for YouTube?

In any case, I can't believe this is a reason. A billion images? Is nothing for Google. Google was offering a billion hours of cpu time to scientists for free in 2011. Don't tell me that a thumbnail takes an hour... http://googleblog.blogspot.com/2011/04/1-billion-computing-c...

Google App Engine now offers the Image Service, but perhaps that was launched after this. https://developers.google.com/appengine/docs/java/images/ove...

Being a premium CDN seems a bit like being a premium credit card processor -- as customers grow, they have more and more incentive to switch to a commodity alternative.

- Be competitive on price and performance for the basic CDN use case

- Amazon's strategy is to pass on their own costs with a very small margin. If you are serving each Zillow thumbnail by resizing it once in a while on a GPU and caching it in RAM, your costs should be tiny. Then you are just over-charging for bandwidth.

Biggest take-away is think hard about the pricing model. Maybe have big tiers with flat prices and pass on the bandwidth at cost.

I store about 300GBs of images. The resized versions take up about 100GBs of the 300.

If I were to then to add retina versions (2x) of each thumbnail, I might be running at 70%+ disk space being used up by thumbnails.

imgix is very interesting, as it would cut my storage costs, decrease my user image upload times ( because I wouldn't have to resize after uploading ). Also I would be free to create 2x retina images, or even new thumbnail sizes as desired.

Only things to justify, are the lock-in with using imgix ( re-writing my site to use it ) and the monthly cost.

Nice marketing though.

http://littleutils.sourceforge.net/

Also what does this has to do with being "graphics card for the entire internet"?

Resizing or optimizing images, in isolation, is not a hard problem. I've solved subsets of this problem a handful of times before, and I could do it again, but I gladly pay for imgix. The time and headaches saved are easily worth it. The next time I have to rely on ImageMagick will be too soon.

I must be misunderstanding because resizing an image, rotating it or many other basic operations consists of about 5 lines of .NET code and very little processing power. I imagine it's not any more difficult in other frameworks. I couldn't conceive of offloading that to an external service under just about any use case.

It seems like they plan to offer video editing via SaaS as well which is more valuable, but I would think the transfer time and bandwidth would kill any speed improvement over a massively parallel SaaS video editor as opposed to using a local open source library.

Yep.

> very little processing power

Not really. Those 5 lines are hiding a pretty big chunk of smarts. Simple scale/rotate transformations are an O(n) operation. That's not so bad. However image encoding/decoding is a bit more expensive.

JPEG encoding, for instance, utilizes an O(n*log(n)) frequency analysis algorithm called a Discrete Cosine Transform. Good JPEG encoders will also do some expensive analysis to maximize precision while minimizing size during quantization (edit: though most just use a set of standard quantization matrices). And then there's I/O. It seems fast when you're only processing one image at a time, but to do this as a real-time service for a number of high-traffic websites is very nontrivial.

Scuse me?

JPEG's frequency transform is a set of fixed linear transforms and is always 8x8, so this step is just O(n) of the area of the image. Also, it's not really "a DCT", just any approximation that will look good when run through the approximation of the opposite transform at the other side.

See http://multimedia.cx/eggs/dct-pr/.

The compression steps after are the most difficult, since they have poor ILP and can involve division. But JPEG is really simple, it's not a burden these days.

One interesting part of it is minimizing the memory use of your application, by using the smallest possible ring buffer for pixels rather than keeping the whole image in memory at once.

I didn't see any documentation about this on their site. Can they deliver, via a single URL, differently sized images for mobile vs desktop? This is one of the biggest headaches when trying to do responsive design.

I guess the imgix guys do something similar.

Serving different images with exactly the same URL is tricky because it will confuse the cache.

So your original may be 1000x1000px, you use a 128x128 thumbnail on your regular (non-retina) site, and you serve 256x256 thumbnail to your retina users.

If your original image is small then there is nothing to do.

  https://github.com/adamdbradley/foresight.js/wiki/Server-Resizing-Images

  http://www.vips.ecs.soton.ac.uk/index.php?title=Speed_and_Memory_Use

Apple has good terms for business purchases. Spend more than $2k and get 18 months interest-free financing. No need to drive around to all the stores (unless you just want the airline points on your credit card)

I am pretty sure they could have come up with a basic MoBo+GPU+CPU+RAM combo to buy from a large distributor, assemble them in series in no-time and get a vastly cheaper and more powerful farm.

Walking around buying mac minis a dozen a time to build a data center is just silly in my opinion, whatever the reasoning.

Its rated around 100 megahashes. A 6990 gets you 800MH.

¹A lot of data centers these days bill you based on the power + bandwidth you consume, not the # of U's you use in a rack.

But well, Ex-YouTube? They have way more money to throw at this. I'll have to put that idea aside.