2 ms·

Since author is talking about security a bit, I'll add. Be careful, if there is a bug somewhere in imagemagick or it runs out of memory, it could easily take do

by zzzcpan 13y ago

Since author is talking about security a bit, I'll add. Be careful, if there is a bug somewhere in imagemagick or it runs out of memory, it could easily take down an entire worker process and abort every connection there.

staunch 13y ago
Another concern is parsing user supplied images, which opens you up to security problems in your image library.
- zzzcpan 13y ago
  Yes, this too. So, to sum up: it should only run isolated from everything else and be used as a service.
dddd_david 13y ago
You have to be especially careful with Imagemagick because it calls through to format specific libraries (libjpeg, libpng, etc) and the implementation of THOSE libraries can have a huge impact on your application. For instance, say you are generating thumbnails for JPEG images. Most Operating Systems ship with the IJG libjpeg, but a few have switched or are considering switching to libjpeg-turbo, a forked binary compatible library that has several performance enhancements. One thing libjpeg-turbo doesn't do though, is implement the DCT scaling functionality of libjpeg, which is a way of efficiently downscaling jpeg images without fully decoding the image (and of course has an impact on image quality as well). The most important benefit of using DCT scaling for generating thumbnails is that it has much lower memory overhead. Since you don't need to decompress the entire image first, it can be done block by block, which means full-image sized buffers don't need to be allocated (which is what Imagemagick will try to do by default). Generating a small thumbnail of a large (10,000 x 20,000 pixel) image will allocate large amounts of memory, whereas using the DCT scaling option will allocate only small working buffers and complete much faster. If you're running an image processing server, these considerations are vital. Long story short, if you stop thinking about your code at the level of the Imagemagick API (or whatever graphics library you choose), you can end up with more problems than you might realize.
- zzzcpan 13y ago
  Agreed.

by zzzcpan 13y ago

staunch 13y ago

Another concern is parsing user supplied images, which opens you up to security problems in your image library.

zzzcpan 13y ago
Yes, this too. So, to sum up: it should only run isolated from everything else and be used as a service.

dddd_david 13y ago

You have to be especially careful with Imagemagick because it calls through to format specific libraries (libjpeg, libpng, etc) and the implementation of THOSE libraries can have a huge impact on your application. For instance, say you are generating thumbnails for JPEG images. Most Operating Systems ship with the IJG libjpeg, but a few have switched or are considering switching to libjpeg-turbo, a forked binary compatible library that has several performance enhancements. One thing libjpeg-turbo doesn't do though, is implement the DCT scaling functionality of libjpeg, which is a way of efficiently downscaling jpeg images without fully decoding the image (and of course has an impact on image quality as well). The most important benefit of using DCT scaling for generating thumbnails is that it has much lower memory overhead. Since you don't need to decompress the entire image first, it can be done block by block, which means full-image sized buffers don't need to be allocated (which is what Imagemagick will try to do by default). Generating a small thumbnail of a large (10,000 x 20,000 pixel) image will allocate large amounts of memory, whereas using the DCT scaling option will allocate only small working buffers and complete much faster. If you're running an image processing server, these considerations are vital. Long story short, if you stop thinking about your code at the level of the Imagemagick API (or whatever graphics library you choose), you can end up with more problems than you might realize.

zzzcpan 13y ago
Agreed.