It can be easily implemented as a filter[1][2]. If you need to use it via command-line you can save the current buffer as a tempfile[3], call your CLI with the tempfile path and read the tempfile to use as the new buffer.
It's even simpler if your CLI can take a stdin argument, since you can just pass the buffer as a stdin parameter.
Thumbor's filter infrastructure allows you to change the image incrementally.
Yes. Sometimes thumborize.me will get the image sizes weirdly. It's there mainly to give you an idea. The settings are the standard ones that come with thumbor. If you tinker with the settings you always get best results. I highly encourage you to try it on your site with different quality settings. Setting up thumbor in your machine takes like 2 minutes. Have a look at the getting started page. If you need any further help please do not hesitate to create an issue and we'll most definitely help you.
Not sure how it compares, but thumbor is fully extensible. There are people using it with HBase, others with Amazon's S3 and Cloudfront, others with filesystem based solutions and yet others with redis or mongo backed images.
Other than storage, you can extend loading images from different places, as well as changing the imaging library thumbor uses.
You can also extend the filters or the detection mechanisms.
Anyway, good to know about magickly.
Definitely... We get around 50M page views/day in our website. And since we are a media company we need to have a storage of images from celebrities, sports and news in general.
At globo.com we have near a billion images (we are a big portal). Can you imagine pre-generating that many images every time a new format gets added?
We serve everything with thumbor with a Varnish cache in front of it and we're very happy with it. It has enabled our designers to work with any image size they can think of.
I agree, but one of the next features we'll implement is for you to be able to write stream processors, mappers and reducers in any language you want. Stay tuned!
We do horizontally scale redis as a farm. I'll try to get more details on how we do it as I'm not the one responsible.
We thought of parallel reducers and it does make a lot of sense. The reason they are sequential is to get a first release out so we can juggle ideas with people. If you care to contribute we'd love it. Even if you just create an issue.
The reason I wrote r³ is because I was a little overwhelmed by how complex disco is to administer and scale.
r³ was designed from the ground up to adhere to HTTP. That means it's pretty easy to scale using our old and well-proven techniques: caching and load-balancing.