Page 1 of 1

Thumbnails of very large images

Posted: 2015-06-04T06:42:37-07:00
by printer57
I am using imagemagick to create thumbnails of images uploaded by users to our webserver. Mostly, this works beautifully, thank you, developers. But users have been known to upload enormous images in various formats. That's ok, this is a print prepress operation, some of these images really do need to be enormous.

I have been using a line like this in my php code to trigger creation of small thumbnails on demand when a URL is accessed with an http GET:

Code: Select all

system("convert $inputFile -resize $width x $height -colorspace RGB -profile sRGB.icm -strip $destinationFile 1> debug1.txt 2> debug2.txt", $systemreturn);
When the input file is very big (I'm thinking of a 125Mbyte jpeg file) this takes a long time to execute on the slow LAMP server processor. If the http GET times out (after 75s on my browser), the PHP code gets killed.

* If the PHP code is killed, does that also send kill to convert?
* If kill is sent to convert, can that result in convert leaving files lying in /tmp?

I have seen instances where multiple files named magick... have been left in /tmp, each more than 1Gbyte in size. Eventually /tmp fills up and the server stops working until I fix it. I'm seeking any solution to this I can find, while still enabling users to see thumbnails of giant images.

This is a 1-processor LAMP server running ImageMagick 6.5.4-7 2014-02-10 Q16.

I've seen advice elsewhere on this forum to process large images with stream but that does not support -scale. Can I reduce image pixel count with stream? Is stream useful? Thanks!

Re: Thumbnails of very large images

Posted: 2015-06-04T07:02:34-07:00
by snibgo
I don't do server stuff but, yes, if IM is killed it can leave large files in your temp area. You might create a cron job to keep it clean.

Re: Thumbnails of very large images

Posted: 2015-06-04T07:34:37-07:00
by Bonzo
On a site I have when a new user visits the page some php code runs and deletes any files over a certain age in the temp directory. The temp file names all start with the date they were created and php checks this against the current time so as not to delete a file that is being used!

Re: Thumbnails of very large images

Posted: 2015-06-04T09:26:59-07:00
by fmw42
-resize $width x $height
The should have no spaces on either side of the x. May be irrelevant to your problem.

Re: Thumbnails of very large images

Posted: 2015-06-10T01:52:46-07:00
by OlgerD
Bonzo wrote:On a site I have when a new user visits the page some php code runs and deletes any files over a certain age in the temp directory. The temp file names all start with the date they were created and php checks this against the current time so as not to delete a file that is being used!
That just makes me cringe.
1. what happens if no new user visits your site for months? Is that temp folder on the bootdrive? Buildup of garbage and crash imminent? If it completely fills up your bootdrive, you're unlikely to be able to boot it normally.
2. Code injection is a pretty common thing nowadays. And while there may be no known vulnerability in your specific scenario at this point in time, that may have changed tomorrow.

Much better is to use cron or whatever your OS is to schedule a php or OS script to do the cleanup.

Re: Thumbnails of very large images

Posted: 2015-06-10T02:10:36-07:00
by OlgerD
printer57 wrote: This is a 1-processor LAMP server running ImageMagick 6.5.4-7 2014-02-10 Q16.

I've seen advice elsewhere on this forum to process large images with stream but that does not support -scale. Can I reduce image pixel count with stream? Is stream useful? Thanks!
Make sure you have plenty of memory available and use IM 64bit. I create PSD files with IM that end up 500+MB in size using convert. In memory convert can eat in excess of 3GB for a short period of time to create those files. Our systems are 16GB 64bit Win7 so not really concerned about that, but it's something to be aware of. Using 64bit as opposed to 32bit IM also makes a bit difference.