ImageMagick image size limitations?

Author Message

Petter Arneson

Monday 24 October 2005 3:48:39 am

I'm currently working on a picture database, and I get into trouble when the customer publish pictures with size 12-14 mb. The customer uploads images with webdav, that workes fine, but when I browse the gallery it times out. It works fine with smaller images, so I guess the problem lies where ImageMagick tries to genererate the image class used for preview. When I publish only one large image, it takes approx. 60 sec, but when I try publishing two at once it times out.

According to log: "Query error: Lock wait timeout exceeded", and "Transaction in progress failed due to DB error, transaction was rollbacked."

I tried reducing jpeg quality to 50%, then I got errors:

Warning: eZImageShellHandler::convert
Failed executing: /usr/bin/convert '-quality' '50' '-geometry' '205x137' 'var/lha/storage/images/bildegalleri/hv0035/2089-1-nor-NO/hv0035.jpg' 
'JPEG:var/lha/storage/images/bildegalleri/hv0035/2089-1-nor-NO/hv0035_bildethumb.jpg', 
Error: , Return: 9

Error: eZImageManager::createImageAlias
Failed converting var/lha/storage/images/bildegalleri/hv0035/2089-1-nor-NO/hv0035.jpg      to alias original in directory var/lha/storage/images/bildegalleri/hv0035/2089-1-nor-NO

Any ideas?
Is it possible to tweak ImageMagick somehow?

www.vzt.no

Geoff Bentley

Wednesday 27 February 2008 11:57:29 am

I'm getting a similar error, but only for siteaccesses which are clustered, ie storing the storage folders in the database.

Small images seem to work ok (say < 50kb) but anything over brings up the same error:

Warning: eZImageShellHandler::convert  	Feb 27 2008 16:58:51

Failed executing: /usr/bin/convert '-quality' '75' '-geometry' '160x144>' 'var/ezpen/storage/images/users/community_users/ftp/test_ftp/32122-8-eng-NZ/test_ftp.jpg' 'JPEG:var/ezpen/storage/images/users/community_users/ftp/test_ftp/32122-8-eng-NZ/test_ftp_hero.jpg', Error code: 1

Error: eZImageManager::createImageAlias 	Feb 27 2008 16:58:51

Failed converting var/ezpen/storage/images/users/community_users/ftp/test_ftp/32122-8-eng-NZ/test_ftp.jpg to alias 'original' in directory 'var/ezpen/storage/images/users/community_users/ftp/test_ftp/32122-8-eng-NZ'

I've looked around these forums and found little joy in resolving this matter.

Any thoughts, anyone?

Linh Vu

Thursday 28 February 2008 3:12:50 pm

You can try activating ImageMagick warning definitions so you know what's going on with those error codes. There isn't any list of error codes for ImageMagick unfortunately.

Put this in your root .bashrc or whichever shell config you're using:

alias convert='convert -regard-warnings'

Or put that option -regard-warnings in the ezpublish config for ImageMagick (I'm not sure if this will work, but the previous way will definitely work).

If I had more time, I would write less code.

Linh Vu

Thursday 28 February 2008 3:18:35 pm

Btw it could be that ImageMagick is using way too much memory/disk and bombs out as a result. You may want to try setting the limits with this: http://www.imagemagick.org/script/command-line-options.php#limit

If I had more time, I would write less code.

Geoff Bentley

Sunday 02 March 2008 3:11:10 pm

Thanks for that. I don't think the problem is with size limitation, but with clustering. Images stored in the database are not found by imagemagick because it's trying to open the image on the filesystem, rather than through a http request (which would be caught by the Apache config).

I imagine this has been resolved in 4.0? We're currently on 3.9.

cousin mosquito

Tuesday 23 March 2010 8:34:06 pm

In my case it was caused by a clash of ownership after copying image files from one server to another.
In the new install I noticed that any new images uploaded were owned by daemon.

I changed the existing images (which were not loading) to daemon:daemon and the problem went away.

Asking the dumb questions for your benefit

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.