where did they get the yeti image in the demo?
Show HN: Imgix.js, a JavaScript library for responsive imaging
21–30 of 33 posts
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#22where did they get the yeti image in the demo?
I'm not sure what "yeti" image you are referring to. All images were purchased royalty free images from iStockPhoto.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#23Earlier quoted context omitted.
I just had to write an image server for work and found it incredibly hard. What's your on-the-fly image processing setup look like?
I'd break it down into two parts. The first is the image transformation. For this we use graphics magic, and based on the params in the querystring, we'd crop, resize, alter the quality, anchor the image to a focus point and so on. Not copy and pastable, but [1] should give you a rough idea. Also [2] is code we use to get the file type and size of the image (gm identify can be painfully slow). The second part was a b…
I have heard anecdotally that graphicsmagick and imagemagick both have awful memory leaks. Did you run into this? We serve ~400 reqs/sec from our image server after putting a CDN in front of it, so we couldn't work with memory leaks.
File size was a problem for us too, as was file format. We needed a solution that would work with pngs, jpegs, gifs and tiffs.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#24Earlier quoted context omitted.
I just had to write an image server for work and found it incredibly hard. What's your on-the-fly image processing setup look like?
Had to write image server myself and it wasn't really hard. Nginx to handle existing files. Python + Pillow + cherrypy (or could be any other microframework) to handle image processing on the fly and then caching processed image to the disk. All in all around 350 lines of code in python. And something like 100 lines in nginx (because of a heavy filename processing and inner url rewriting). Result - facebook-like imag…
What was the max throughput your server could handle? We ended up using Go because we serve 400 - 600 reqs/sec and Python/Ruby solutions didn't have high throughput.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#25Earlier quoted context omitted.
Had to write image server myself and it wasn't really hard. Nginx to handle existing files. Python + Pillow + cherrypy (or could be any other microframework) to handle image processing on the fly and then caching processed image to the disk. All in all around 350 lines of code in python. And something like 100 lines in nginx (because of a heavy filename processing and inner url rewriting). Result - facebook-like imag…
It's about total cost of ownership A: Imgix = cost of imgix subscription + integration time * hourly rate (it's dead simple) B: Rolling your own = dev time * hourly rate + maintenance/ops time * hourly rate For most orgs B > A. For most individual programmers since hourly rate is not a factor A < B.
If you have to pay for hardware to run it on, that would be part of B.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#26Earlier quoted context omitted.
I'd break it down into two parts. The first is the image transformation. For this we use graphics magic, and based on the params in the querystring, we'd crop, resize, alter the quality, anchor the image to a focus point and so on. Not copy and pastable, but [1] should give you a rough idea. Also [2] is code we use to get the file type and size of the image (gm identify can be painfully slow). The second part was a b…
I have heard anecdotally that graphicsmagick and imagemagick both have awful memory leaks. Did you run into this? We serve ~400 reqs/sec from our image server after putting a CDN in front of it, so we couldn't work with memory leaks. File size was a problem for us too, as was file format. We needed a solution that would work with pngs, jpegs, gifs and tiffs.
I hate to be all self promotion, but this is why imgix exists as a service. We aren't running gm or imagemagick. One of our statements is that "this cannot be built in a weekend" as many engineers are quick to claim how easy an implementation it is when coming across our service.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#27Earlier quoted context omitted.
I have heard anecdotally that graphicsmagick and imagemagick both have awful memory leaks. Did you run into this? We serve ~400 reqs/sec from our image server after putting a CDN in front of it, so we couldn't work with memory leaks. File size was a problem for us too, as was file format. We needed a solution that would work with pngs, jpegs, gifs and tiffs.
I hate to be all self promotion, but this is why imgix exists as a service. We aren't running gm or imagemagick. One of our statements is that "this cannot be built in a weekend" as many engineers are quick to claim how easy an implementation it is when coming across our service.
Did you run across the memory leak issue too? Could you talk about the imgix stack? I'm curious to know what it is like.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#28Earlier quoted context omitted.
Had to write image server myself and it wasn't really hard. Nginx to handle existing files. Python + Pillow + cherrypy (or could be any other microframework) to handle image processing on the fly and then caching processed image to the disk. All in all around 350 lines of code in python. And something like 100 lines in nginx (because of a heavy filename processing and inner url rewriting). Result - facebook-like imag…
What was the max throughput your server could handle? We ended up using Go because we serve 400 - 600 reqs/sec and Python/Ruby solutions didn't have high throughput.
I've never tested its throughput - there was no reason to do that because all of the processed images are saved and stored as long as those files are accessed at least once a week.
So, the answer is pretty much this: it'll handle as many rps as nginx serving static files can handle.
If we are talking about unique requests each requesting to process unique image - I'm pretty sure linode server CPU it's running on will choke.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#29Earlier quoted context omitted.
Had to write image server myself and it wasn't really hard. Nginx to handle existing files. Python + Pillow + cherrypy (or could be any other microframework) to handle image processing on the fly and then caching processed image to the disk. All in all around 350 lines of code in python. And something like 100 lines in nginx (because of a heavy filename processing and inner url rewriting). Result - facebook-like imag…
It's about total cost of ownership A: Imgix = cost of imgix subscription + integration time * hourly rate (it's dead simple) B: Rolling your own = dev time * hourly rate + maintenance/ops time * hourly rate For most orgs B > A. For most individual programmers since hourly rate is not a factor A < B.
That's certainly true. I'm not saying that this service doesn't have any value. Just wanted to share my experience with writing similar solution.
It's good to be dev and have spare time for stuff like that. You learn stuff while making such projects, you save money and it just works.
About money, judging by the pricing on imgix page (and if I understand pricing correctly, I'm saving around $300 per month ($50 for cheapest plan + $250 for traffic).
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#30Earlier quoted context omitted.
I'd break it down into two parts. The first is the image transformation. For this we use graphics magic, and based on the params in the querystring, we'd crop, resize, alter the quality, anchor the image to a focus point and so on. Not copy and pastable, but [1] should give you a rough idea. Also [2] is code we use to get the file type and size of the image (gm identify can be painfully slow). The second part was a b…
I have heard anecdotally that graphicsmagick and imagemagick both have awful memory leaks. Did you run into this? We serve ~400 reqs/sec from our image server after putting a CDN in front of it, so we couldn't work with memory leaks. File size was a problem for us too, as was file format. We needed a solution that would work with pngs, jpegs, gifs and tiffs.
I worked for a company that used ImageMagick for compositing images together and resizing them to one of ~60 sizes (different page locations, device types, etc.). While it worked, and it was at the core of the company's technology, it was truly the worst software I have ever had to wrangle into a production service.
You name it and ImageMagick could do it:
- Leak memory
- Perform terribly until you find the magic incantation that is 10x faster
- Output wildly different images after a minor patch release
- Remove / change options after a minor patch release
- Enormously degrade performance after a minor patch release
- Have numerous security vulnerabilities all the time, which require frequent upgrades
- Dump core more often than you might like
I heard that GraphicsMagick was superior in that it maintained some consistency of behavior between versions, but it doesn't have all of the functionality of ImageMagick. So we couldn't switch to it.
Another company that I worked for had a fleet of several thousand servers running constantly just to thumbnail user uploaded images, and it was not unheard of for it to fall behind.
IM / GM are the stock answer to process images, but from my experiences they have no place in a production system. I think this is an area that is pretty poorly served by open source software; there are lots of libraries to handle different image formats, but no good infrastructure exists to tie it all together (that I'm aware of).