At first I thought OpenRoss was a new competitor to GraphicsMagick and ImageMagick, but it's just a Twisted plugin. The title should be changed.
OpenRoss – fast, scalable, on-demand image resizer
21–30 of 34 posts
Re: OpenRoss – fast, scalable, on-demand image resizer
#22At first I thought OpenRoss was a new competitor to GraphicsMagick and ImageMagick, but it's just a Twisted plugin. The title should be changed.
The title is fine. It just says image resizing. Image/GraphicsMagick are a whole different ballgame.
Re: OpenRoss – fast, scalable, on-demand image resizer
#23I'm curious to know how people feel about offline (pre-transformed) vs. on-demand transformations. Are there any HN'ers out there that have worked on a site with a large set of images, and have an opinion on this? Adobe's Scene7 product works in an offline mode as far as I can tell, and seems to have captured a large segment of retail companies with product catalogs.
Re: OpenRoss – fast, scalable, on-demand image resizer
#24I just built a very simple version of this in about 100 lines of go, using http://github.com/disintegration/imaging for the image processing.
I was surprised how... latent downloading from S3 is, and how it didn't seem to matter if I was running on Digital Ocean or EC2, downloading the image from S3 was always the slowest part. (Digital Ocean was actually faster!)
It takes about a second to process an image, but it is cached in front of CloudFront similar to the article.
Any tips for improving the latency from S3?
Re: OpenRoss – fast, scalable, on-demand image resizer
#25I would love to see a golang version of this.
I wrote something similar during the GopherCon hack day, maybe it's useful: https://github.com/ericflo/slimgfast (disclaimer: haven't run it in production)
Re: OpenRoss – fast, scalable, on-demand image resizer
#26This architecture can definitely save a bundle on storage costs but usually it runs into slowness when resizing, or, run into problems with image quality when resizing repeatedly.
22ms for a GraphicsMagick resize is quite fast. I'm curious what the average input and output sizes were used when computing that number?
Re: OpenRoss – fast, scalable, on-demand image resizer
#27Looks like you built your own http://cloudinary.com but with less features
Re: OpenRoss – fast, scalable, on-demand image resizer
#28You should definitely limit the sizes that can be generated otherwise with URLs like http://host/WIDTH/HEIGHT/MODE/path/to/image it's pretty easy to mildly DDOS you.
Re: OpenRoss – fast, scalable, on-demand image resizer
#29Based on all the links to similar apps in this thread, writing an image-resizing service to sit behind a CDN seems to be a right of passage. My creation from a couple years ago: https://bitbucket.org/btubbs/thumpy/src
It's still running happily in production.
Re: OpenRoss – fast, scalable, on-demand image resizer
#30Earlier quoted context omitted.
They say that, but there's one giant missing ", because..." in that paragraph. They never explain why they render in 10 sizes (why don't they know which sizes they need), and why is loading one of those sizes on a mobile app not feasible. It's stated like that and left hanging in the air. Either their use case is very weird, or they're deliberately vague for some reason only they know about. Also to clarify why 10 si…
When the site was originally designed, there were only 4 or 5 sizes, one for the feed, one for the product page, one for related products, one for thumbnails, etc. As the design changed, extra sizes got added to the image processing, and as with most early stage start-ups, it worked therefore there was no need to fix it. We eventually ended up in the position of having 2.5M products all with preprocessed images of ce…
But the nice thing is - using a storage solution where you don't pay for what you don't use.