I'm in the market for such a solution and it's interesting how many services go stale or miscalculate their bandwidth costs (if they offer hosting) and close.
Resize.ly is copyright 2013, still in beta and offer unlimited for $9.
http://imagefly.io/ looks a bit more grown up but it's copyright 2013 as well, last blog post over two years ago, last tweet over a year ago.
Thanks for those links (Especially the last one). Resize.ly is just beta, so let's see what they come up with in the near future.
On another hand, I hope there will be a resizing/compressing service inspired by Pied Piper (Silicon Valley series) sometime soon.
Sounds good till you get to maintenance and scaling. Thumbor isn't as install and forget if you value being able to recreate the environment from scratch, scale out, rotate and secure the keys, solve tmp directory issues, ensure availability etc...
Having just finished several months of working with and tweaking thumbor for a large volume website I can see how just paying for a service would be appealing.
Thumbor isn't as install and forget if you value being able to recreate the environment from scratch, scale out, rotate and secure the keys, solve tmp directory issues, ensure availability etc...
Nothing is install-and-forget if you value those things, because valuing those things is the opposite of wanting install-and-forget software.
Would you mind sharing some detail about the issues you had with tmp dirs and availability? I deployed Thumbor a few months ago and it's been pretty much install and forget. I'm curious about what issues I might have in future as it scales.
Sure. For the record the Thumbor cluster I was working on needed to have 100% uptime and be configured to mitigate any potentially DDoS situation even if the secret key was leaked. It also needed facial detection and GIF (animation) resizing support.
The tmp directory is never emptied unless you restart the machine. So to get around this you have to write a cron job to remove the older downloaded and resized images. However in my load tests this caused issues with Thumbor and so I ended up having the cron job only delete files over a certain age. However this still leaves the possibility that Thumbor could fill up the entire disk and crash the machine.
Other issues were having the ability to rotate the Thumbor key. This is somewhat supported by Thumbor, in that the previous keys images will still be available but the key rotation is not done for you. I was using AWS so stored the key in a protected s3 bucket and gave roles access to pull the key and when it detected it was modified restart Thumbor.
The last an main issue was the ability to spin up a new version of Thumbor itself. In the time it took me to get it from development through to production the dependancies changed so much that facial detection broke halfway though. I fixed this initially by freezing the pip dependancies but then the underlying dependancies caused issue at a later day. In short I was unable to spin up a new version which was identical to the previous. Generally were I work we tear down and spin up fresh instances all the time so this was an issue. We resolved this by installing Thumbor in a docker container.
Don't get me wrong. A big fan of Thumbor and it was the right solution for what I needed to do but these issues really made myself and others considering paying a 3rd party for a while.
Thanks for elaborating, I appreciate it. I don't think my installation is getting enough load to see these tmp issues yet, but good to know what I might have to deal with in future. I agree that with so many dependencies, Thumbor is a great candidate for deploying with Docker.
Btw, I didn't realise you were the searchcode.com guy, great site!
I've been running it for months without issues. Yes every so often it fills up the /tmp directory - setup a cronjob or something, but it is basically install and forget.
(My install gets maybe 10-20 requests a second, so maybe I'm at the low end of usage I don't know, but it works fine for me).
It depends on if you ever need to recreate it. I was checking my ability to spin up a thumbor instance a few months after deploying it only to discover that it was not possible using the deployment scripts I had even with frozen pip requirements.
For comparison the thumbor instance I am working with does thousands.
My alternative is a digital ocean VPS with a nodejs server with the ImageMagick module. Super easy to use, but I'll say thumbnor looks like a good solution too. Thanks for the link!
Nearly anonymous "my friend works there" posts aren't a ton of help, but I'll just say my buddy Kelly (https://twitter.com/kellysutton) works on Imigix, he used to work on this dropbox for PSDs thing (layervault) and he's awesome, so I'd tend to believe that imgix is awesome by association alone.
We switched to imgix recently (after using pre-processed versions using carrierwave / ImageMagick / cloudfront), and it works pretty well for us. There were a few odd glitches setting up, but once it's up and running it seems to do really well.
One neat feature of imgix is its auto format, which converts images to webp/progressive Jpeg on-the-fly based on the browser headers[0].
I'm not associated in any way with imgix, just a fairly new customer.
The big difference between ImageRack and most others solutions is that you pre-define the available image manipulations templates on the server side (for example a template for thumbnails, large images, iPad sizes etc.). I'm not a fan of letting the client generate multiple versions of an image by changing the URL (i.e. http://resize.ly/450x150/http://resize.ly/img/kittens/kitty-...).
I'm one of the developers of http://imagefly.io. We are still very much active and doing development on the service. We have paying customers and our own photo products depend heavily on the service.
We clearly need to update the copyright info on the page and make some new blog posts!
It fails horribly for me. Most software fails too (try to downscale the original in your favorite browser!), but this somehow ruins the base background gray too somehow.
Sorry for the test image being a little harsh, it's not mine (also some reading material how downscaling should be implemented):
What's happening actually? I wanted to learn image processing but always get hung up. Can you just give an quick note about what's happening here? or direct me to any links?
I think my last link describes the problem accurately from the ground up.
TL;DR the raw pixel values are typically not linearly proportional to the luminescence of the color channels. But a cone cell in the eye actually averages the luminescence of different areas if you look at a fine structured image from far away, so if you want to emulate the perception of the eye then you have to average luminescence values instead of raw pixel values. The conversion is well defined by the colorspaces in use. Most pictures on the Internet uses the sRGB colorspace, which is not linear.
Color perception and colorspaces are actually not straightforward in the sense that naive algorithms often fail. But the basics are not that hard.
Although I passed this one no problems, I find animated gifs to be the worst thing to resize, especially the ones where the changes are part of a layer over another layer
layer two is just enough to cover layer one and make the hand move, the rest is transparent. but at least the layers are the same size
some animated gifs have the new layer not the same canvas size as the layer underneath, so you have to adjust the layer offsets correctly or they end up all over the place
Well gifs being palette based does add to the problem more. Well the obvious solution is to use the color values for rescaling and averaging (in a proper colorspace), resize the image then build a new palette from the new colors. Well this palette generation isn't exactly straightforward either.
Oh I see. For the png it's darker then my original (both the copy of the original and the downscaled), but the text reads "RULES", so that's something.
A couple of stupid questions: (1) Aren't there already several providers of this kind of service? (2) If so, what does this service claim to do better? (3) How is image scaling hard enough to justify a business model?
No problem, I only know this because I had to use it yesterday. It's not fully supported yet, but it's good enough as long as you keep using src as a fallback
Yeah, I prefer <picture> for two reasons – being able to gracefully use new image formats and being able to do art-direction type changes using media queries – but the great thing about the polyfill is that you're not forced to pick one.
I didn't expect this to get so much attention or I'd have written some context. I came across this while researching solutions to the old thumbnails problem. It doesn't look like it took off or is maintained but I thought it was interesting.
Image resizing is a hard problem. At a place I used to work at we wrote a custom distributed image thumbnail generation system for user supplied images. It was pretty complex and used a database and pub/sub message queueing to propagate changes from a SAN file system. The main issue was that the underlying image libraries weren't suited to running on a web server. It leaked memory like mad. This resulted in layers of sophisticated monitoring and automatic restart systems being built on top.
It shouldn't have to be this hard. If a progressive format like JPEG2000 or WebP takes off then browsers can just download enough data to fill whatever pixels they need to fill.
I have a lot of other thoughts on this but they can wait for a blog post. If anyone is interested?
We switched to Cloudinary.com a few months ago. We're in love with them. They have a slew of integration libraries and support things like document to image conversion out of the box.
http://cloudinary.com is the best at this. Just look at their customers list. They also handle video just as seamlessly and have a pretty generous free tier with a great control panel and useful manipulations (like recognizing faces). We've been using them for a while and everything has been perfect.
is the pricing better than imgix?
Also, for as an opensource alternative, we use https://github.com/die-net/fotomat as a S3 proxy. It's very fast and scales well
50 comments
[ 304 ms ] story [ 1108 ms ] threadResize.ly is copyright 2013, still in beta and offer unlimited for $9.
http://imagefly.io/ looks a bit more grown up but it's copyright 2013 as well, last blog post over two years ago, last tweet over a year ago.
http://6px.io/ seems more active.
I'm tending towards http://www.imgix.com/
All solve resizing-as-service, I just want to make sure to use a service that's still around in a couple of years for my projects.
* Spin up a VPS somewhere for a few dollars a month.
* Install thumbor
Having just finished several months of working with and tweaking thumbor for a large volume website I can see how just paying for a service would be appealing.
Nothing is install-and-forget if you value those things, because valuing those things is the opposite of wanting install-and-forget software.
But if someone is asking to pay to take away the pain the probably do value some of those things, hence paying for some install and forget service.
The tmp directory is never emptied unless you restart the machine. So to get around this you have to write a cron job to remove the older downloaded and resized images. However in my load tests this caused issues with Thumbor and so I ended up having the cron job only delete files over a certain age. However this still leaves the possibility that Thumbor could fill up the entire disk and crash the machine.
Other issues were having the ability to rotate the Thumbor key. This is somewhat supported by Thumbor, in that the previous keys images will still be available but the key rotation is not done for you. I was using AWS so stored the key in a protected s3 bucket and gave roles access to pull the key and when it detected it was modified restart Thumbor.
The last an main issue was the ability to spin up a new version of Thumbor itself. In the time it took me to get it from development through to production the dependancies changed so much that facial detection broke halfway though. I fixed this initially by freezing the pip dependancies but then the underlying dependancies caused issue at a later day. In short I was unable to spin up a new version which was identical to the previous. Generally were I work we tear down and spin up fresh instances all the time so this was an issue. We resolved this by installing Thumbor in a docker container.
Don't get me wrong. A big fan of Thumbor and it was the right solution for what I needed to do but these issues really made myself and others considering paying a 3rd party for a while.
Btw, I didn't realise you were the searchcode.com guy, great site!
Yes thats me! Thank you!
(My install gets maybe 10-20 requests a second, so maybe I'm at the low end of usage I don't know, but it works fine for me).
For comparison the thumbor instance I am working with does thousands.
One neat feature of imgix is its auto format, which converts images to webp/progressive Jpeg on-the-fly based on the browser headers[0].
I'm not associated in any way with imgix, just a fairly new customer.
[0]http://blog.imgix.com/post/90838796454/webp-jpeg-xr-progress...
Feel free to check it out: https://github.com/diarmuidie/ImageRack
The big difference between ImageRack and most others solutions is that you pre-define the available image manipulations templates on the server side (for example a template for thumbnails, large images, iPad sizes etc.). I'm not a fan of letting the client generate multiple versions of an image by changing the URL (i.e. http://resize.ly/450x150/http://resize.ly/img/kittens/kitty-...).
We clearly need to update the copyright info on the page and make some new blog posts!
http://www.4p8.com/eric.brasseur/gamma-1.0-or-2.2.png
The resize.ly version (2x downscaled):
http://resize.ly/256x128/http://www.4p8.com/eric.brasseur/ga...
It fails horribly for me. Most software fails too (try to downscale the original in your favorite browser!), but this somehow ruins the base background gray too somehow.
Sorry for the test image being a little harsh, it's not mine (also some reading material how downscaling should be implemented):
http://www.4p8.com/eric.brasseur/gamma.html
thanks
TL;DR the raw pixel values are typically not linearly proportional to the luminescence of the color channels. But a cone cell in the eye actually averages the luminescence of different areas if you look at a fine structured image from far away, so if you want to emulate the perception of the eye then you have to average luminescence values instead of raw pixel values. The conversion is well defined by the colorspaces in use. Most pictures on the Internet uses the sRGB colorspace, which is not linear.
Color perception and colorspaces are actually not straightforward in the sense that naive algorithms often fail. But the basics are not that hard.
seems I pass this one ok, https://thisaintnews.com/view/picture/138385/downscale-test
Thanks to https://metacpan.org/pod/Imager
Although I passed this one no problems, I find animated gifs to be the worst thing to resize, especially the ones where the changes are part of a layer over another layer
e.g. look at this one in gimp/photoshop
https://thisaintnews.com/static/user/pics/1218067200/1218395...
layer two is just enough to cover layer one and make the hand move, the rest is transparent. but at least the layers are the same size
some animated gifs have the new layer not the same canvas size as the layer underneath, so you have to adjust the layer offsets correctly or they end up all over the place
Infact I have a few evil gifs for testing this
https://thisaintnews.com/view/picture/138386/test-gif-1
https://thisaintnews.com/view/picture/137264/test-gif-2
https://thisaintnews.com/view/picture/137265/test-gif-3
https://thisaintnews.com/view/picture/138387/test-gif-4
I can't remember the exact differences, but I do remember they go from easy to hard to resize correctly
I guess what I was getting at is they're my acid test for image scaling
edit: also I mean the smaller image, on the left of the big one. The big one is probably a copy of the original
I'm hoping to see something like the picture element suggested here:
http://www.smashingmagazine.com/2011/11/html5-semantics/
<picture alt="angry pirate">
</picture>Would something like this be possible to implement with React or Web Components? Or will we have to wait for HTML6?
In my opinion, responsive images really shouldn't be a server-side concern, much less something that should require a third party service.
https://css-tricks.com/responsive-images-youre-just-changing...
http://caniuse.com/#feat=srcset
The polyfill looks amazing too. Looks like it polyfills both the picture tag itself as well as the srcset property on img that mrbig4545 mentioned.
We use it to scale 10million images / day across 3 c3.large boxes with ave response time of 120ms.
source https://thisaintnews.com/static/user/pics/1438214400/1438778...
resized http://resize.ly/cache/thisaintnews.com/11a454f11a5a6b091c84...
https://news.ycombinator.com/item?id=10054060
Image resizing is a hard problem. At a place I used to work at we wrote a custom distributed image thumbnail generation system for user supplied images. It was pretty complex and used a database and pub/sub message queueing to propagate changes from a SAN file system. The main issue was that the underlying image libraries weren't suited to running on a web server. It leaked memory like mad. This resulted in layers of sophisticated monitoring and automatic restart systems being built on top.
It shouldn't have to be this hard. If a progressive format like JPEG2000 or WebP takes off then browsers can just download enough data to fill whatever pixels they need to fill.
I have a lot of other thoughts on this but they can wait for a blog post. If anyone is interested?
On top of that, they want you to pay to use their "cloud service"?
http://rsz.io/ is another great service that's free.
You can use your own CDN in front of both to save costs and use your own bandwidth.
What does that mean? What does Resize.ly do exactly?