I don't think littleutils does much more than optimize images, which is pretty different from: http://www.imgix.com/docs/urlapi

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.

>Is this really such a hard problem to solve?

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.

> 5 lines of .NET code

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.

> JPEG encoding, for instance, utilizes an O(n*log(n)) frequency analysis algorithm called a Discrete Cosine Transform.

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 thought the same thing. I think this would be hard to do at scale and they offer quite a lot more features than most would need (sepia tone filter). I couldn't personally see paying for re service, but obviously it must be useful to others.