4 ms·
I use http://github.com/markevans/dragonfly http://github.com/markevans/dragonfly for this purpose, using rack/cache to hold on to the generated images (also wi
by blasdel 16y ago
I use http://github.com/markevans/dragonfly http://github.com/markevans/dragonfly for this purpose, using rack/cache to hold on to the generated images (also with no expiration necessary).
Right now I'm working on doing streaming intermediate resizes that never load the full decompressed image into memory, because I need to be able to take uploads of 50 megapixel images and be able to respond with new versions based on user input in a timely manner. RMagick may be an extremely shitty implementation, but even a more solid one is stymied by the algorithm.
The solution is to just do something else -- for JPEGs, libjpeg has the capability to do a cheap streaming resize to 1/2, 1/4, or 1/8 by partially sampling the 8x8 DCT blocks and for PNGs MediaWiki's image server includes a utility for doing streaming resizes, though it's finicky about the exact scale factors it'll allow: http://svn.wikimedia.org/viewvc/mediawiki/trunk/pngds/ http://svn.wikimedia.org/viewvc/mediawiki/trunk/pngds/
- swindsor 16y agoDragonfly looks pretty cool. I like the approach of using rack (our app was written pre-rack, but it's been upgraded to newer versions of rails, so we could make it rack-enabled). Have people written different datastores (like S3?). I love the idea of a modular, pluggable image server that can choose different backends based on business need/scaling. Luckily, we deal with pretty small pictures since they are just pictures of our users & their classes. We don't really have any need for handling larger sizes, and our biggest use cases surround generating thumbnails (similar to many social networking web apps).
- elektronaut 16y agoThanks for the link, I haven't seen that plugin before. We use a plugin I wrote (http://github.com/elektronaut/dynamic_image/ http://github.com/elektronaut/dynamic_image/), which seems to be based on similar ideas on syntax. For caching we just do regular page caching, with no expiration. Since the request doesn't have to hit the backend at all (except for the first view), this is pretty damn fast.