Join GitHub today
v1.4.6: Image quality setting has no effect with Imagick #834
Changing the Image Quality setting in the Image Options seems to have no effect on the file sizes created. A setting of 50 on all sliders creates the same sized image as a setting of 85. Using v1.4.6 with Zenpage theme and PHP Imagick library 3.1.2. I clear the album's cache each time and newly created images are the same size (bytes).
Actually, the resized image which is smaller than the original one ends up with a larger file size. Original is 659x518 at 88,082 bytes and the resized one is 580x456 at 111,236 bytes. This is with the Image Quality set to either 50 or 85.
On the version I have installed on my PC, it's using PHP GD library bundled (2.0.34 compatible) and the Image Quality setting does have an effect. On the webhost if I uncheck Imagick in the Image Options to use the GD library then the Image Quality settings make a difference.
So, it seems to be some hard-coded thing using Imagick? I prefer Imagick as it retains all the ExiF and IPTC information.
So I guess, should the Image Quality settings affect Imagick? If it should, then it sounds like a bug. acrylian suggested I file this per this thread: http://www.zenphoto.org/support/topic.php?id=1145864
This is likely the culprit: http://www.php.net/manual/en/imagick.setcompressionquality.php#96836
in zp-core/lib-Imagick.php, in method zp_imageOutput:
Imagick::setCompression --> Imagick::setImageCompression
I currently have no way of testing the indicated change, though. Imagick::setImageCompressionQuality has no version info in its PHPDoc, so it's possible that it could break older versions of Imagick.
I made the following code change in that file and uploaded it to my webhost:
And it seems to have worked. A setting of 50 now creates the 580x456 image at 37,458 bytes and at 85 makes it 71,186 bytes. I'm guessing the same would need to be done for the other image types but all I'm working with for now are JPGs. So, at least with my version of PHP and IMagick that seems to work. :)
@ntsikerdanos: Thanks, great to see you are still here. I remembered that my host has Imagick again after a recent server upgrade. So I can test as well now.
Strange that php.net list both methods each without any comment about deprecation or something (both list a 2.0.0 somehow). Based on a quick web search I guess the change would be save to use.
I am sure the real GitHub kagutsuchi will be suprised about his mentioning here :-)
added a commit
Jul 2, 2014
Since MarkRH was able to verify that the fix works, we could probably go ahead and close this issue. I'll leave that up to you, @acrylian :)
Imagick documentation isn't the best, unfortunately. There are a number of other methods like this one where there are two variants - one that works and one that doesn't. Thankfully, it's easy to switch between them.
Imagick::setImageCompressionQuality is likely safe to use and won't break things. I'll bet it's got the same version info as Imagick::setImageCompression, which was added in Imagick 2.0.0.