Saturday 7 September 2013

ImageMagicking

Most of today I was trying to fix some issues I was having with ImageMagick. The first issue was my image thumbnails generated with my new 'workflow' were much larger than the old ones. While debugging this I noticed that when I applied a second transformation to an image with an orientation exif/xmp property that had been converted using auto-orient, the new image would be rotated wrongly (it would be rotated correctly as per the first image, but then also have the orientation exif property so that it gets rotated again).

I managed to solve the rotation issue by setting the xmp-tiff:orientation to horizontal (using exiftool) after the first transformation with auto-orient. The main issue of thumbnail size I did a range of tests and found that when the image was resized to 500 px wide / tall before creating a thumbnail made the thumbnail smaller in file size. But I couldn't work out why.

Before posting to the ImageMagick forum I thought I better try with the latest version in case it was an old bug that had been fixed. But when I built the latest ImageMagick it had no JPEG or TIFF support. I then spent a long time trying to get the dependencies and ImageMagick built correctly. I didn't manage to get LZMA support working, but I did get JPEG and TIFF support (though there were a various warnings when building that the lib files looked like they'd been moved).

When I then tried ImageMagick again, it still wouldn't work and said it needed lcms. So I built lcms (can get it from the ImageMagick delegates downloads, and then had to build ImageMagick again. (Building each dependency and ImageMagick typically takes quite a bit of time).

ImageMagick now didn't error out, but froze. I checked with top, which said the process was sleeping. Using -debug All gave useful output so I could see what was happening. There was some errors to do with Registry value shred-passes not being defined or something. After looking it up, I set it to 0. I also noticed that the tmp directory I was telling ImageMagick to use didn't exist. Whoops! Strange how the previous version worked okay with the same command though.

Now ImageMagick would just freeze after removing the tmp files, no errors. I tried various iterations of input image sizes. It worked with extremely small images, so after much experimentation I found approximately the smallest image it would break with - a 25px x 38px jpeg. I modified the command to remove the various options and operations, and found that it would work when the application of an ICC profile (color profile conversion) was missed out.

After much debugging I checked the ImageMagick info and found that the limit memory and memory-map options are meant to be specified with the unit of measurement. I had 64 and 128 as the values, so it was using bytes as the unit of measurement. I wonder if this is something that has changed, since the old version worked okay with those values, and it seems odd (though it is a possibility) that I would have missed off the unit of measurement. Changing them to even very small values e.g. 64kiB and 128kiB, and now ImageMagick worked fine.

I am not sure whether the memory-map value refers to RAM or disk, so I set 32MiB for both values for actual use. Hopefully that will be a reasonable amount without pushing me over my memory limits on my shared webhosting account.

After posting my issue on the thumbnail sizes I got a reply pretty quickly that pointed out the issue was the quality setting. On the 500px image I had set quality to 80, and was not setting quality on the thumbnail. So the thumbnail produced from the larger image had the same quality (98), and the thumbnail produced from the 500px resized image had the same quality (80), leading to a smaller file size. It was obvious once it was pointed out.

So I decided to set a quality of 60 on the thumbnails, which is probably more than good enough. It also made me realise that I wasn't applying a quality to my larger images, which should have been set to quality 80. So I corrected that as well.

No comments: