Evaluate Imagick for image processing

[following5]

logs/images/add currently uses the GD library for image processing.

Imagick is said to be faster, produce sharper resized images and comsume less memory. It also may allow stripping Exif data without resampling.

services/devel/sysinfo shows which image libraries are available at which OC sites. Imagick currently is installed only at OC.de. The OCDE code uses Imagick if available, else falls back to GD.

(@wrygiel: could you tag this issue with a new label "Component-Images"?)

[andrixnet]

OCRO server supports ImageMagick (out of the box, as part of a full Slackware installation).

Please post this at OPENCACHING-PL as well.

[following5]

Imagick is a PHP extension that builds on ImageMagick. When you have updated the Opencaching.RO site to the current OCPL code, I can verify if this PHP module is availabe to opencaching.ro/okapi.

Please post this at OPENCACHING-PL as well.

Why? The evaluation and implementation of this (low-priority) issue is independent from any local fork or site. If it will be implemented some day, and needs any action by a lokal code fork or site to enable it, they will be informed.

[andrixnet]

Sorry, my bad. While ImageMagick library is part of the distribution, the imagick PHP module is not. This would add a library dependency requirement.

Second, OPENCACHING-PL also empolys image resize actions (at least) and would definitely benefit from quality and resource usage improvements.

And if OKAPI will implement it at some point in the future, even with gd fallback, then again, the entire code could benefit and process images in a uniform way, with optimum resource usage.

[following5]

And if OKAPI will implement it at some point in the future, even with gd fallback, then again, the entire code could benefit and process images in a uniform way, with optimum resource usage.

For now, it's just a rumor that Imagick delivers better quality and resource usage. This issue is about evaluating that - see the title.

If you want better JPEG quality, you may ask OCPL developers to add a setting for that. Both OCPL code (in SimpleImage::save) and OKAPI code (JPEG_QUALITY in okapi_settings.inc.php) allow to change the JPEG quality for the GD image processor. Remember that better quality = larger image files.

[andrixnet]

By better quality I was referring also to resize algorithms and filters that ImageMagick supports.

[following5]

Ok. We need to evaluate if these capabilities are worth the effort to implement it. I.e. resample and resize some sample images with GD and with different Imagick filters, adjusting the JPEG quality so that both deliver the same file size, and then look if the Imagick pictures are noticably better. And compare the performance and memory usage.

[andrixnet]

Let's start with the famous "Lena" reference image.
https://en.wikipedia.org/wiki/Lenna#/media/File:Lenna.png

Usage for ImageMagick JPEG compression: http://www.imagemagick.org/Usage/formats/#jpg
Usage instructions and many examples for ImageMagick resizing: http://www.imagemagick.org/Usage/resize/

There could be 3 test phases:

1. resize comparison with saving in a lossless format (image visual quality). I would suggest resizing to smaller size that is NOT a multiple of 2. (like scaling down to 2/3 or smth)
2. JPEG compression results from same image, same quality factor on both sides (or equivalent same quality factor, in percentages). Also sampling factor (see http://www.imagemagick.org/Usage/option_link.cgi?sampling-factor ) and Huffman table optimizations. To look for: resulted file size, resulted visual distortion. Also to use some test images that feature sharp edges with higly saturated colors (where JPEG is worst).
3. memory usage, processing time.

I can put up some comparison runs using command line utilities (at least for ImageMagick).

[following5]

Good luck!

For me this issue is low-prio, no idea if and when I will work on it.

[wrygiel]

BTW - I have worked with both GD and ImageMagick. The latter has much more functionalities in regard to image processing, the former seems better when drawing graphics from scratch. Not sure about the quality, but lossless stripping EXIF data is a good feature to have.