[wp-trac] [WordPress Trac] #63448: Image quality significantly degrades for resized PNGs with transparency in WordPress 6.8.1

[WordPress Trac]

#63448: Image quality significantly degrades for resized PNGs with transparency in
WordPress 6.8.1
-------------------------------------------------+-------------------------
 Reporter:  elvismdev                            |       Owner:
                                                 |  adamsilverstein
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  6.8.2
Component:  Media                                |     Version:  6.8
 Severity:  critical                             |  Resolution:
 Keywords:  has-patch has-test-info dev-         |     Focuses:
  feedback has-unit-tests commit fixed-major     |
-------------------------------------------------+-------------------------

Comment (by siliconforks):

 My thoughts on the matter:

 I would be inclined to just change the line `$this->image->setOption(
 'png:format', 'png8' )` to use `quantizeImage` instead, and then simply
 not worry about the issue with the [https://github.com/WordPress
 /wordpress-
 develop/blob/0d7c6c579f6302f629c8fce267744a408828f657/tests/phpunit/data/images
 /png-tests/test8.png test8.png] image (i.e., just remove that test from
 the test suite).  I just think that it's a pretty marginal edge case
 issue:

 * It's not a quality issue - the quality of the resized `test8.png` seems
 fine.

 * Yes, there is a file size issue (so it is essentially #36477 again) -
 however, it seems like it would be a fairly rare edge case since as far as
 we can tell it will only happen for grayscale images?

 * Also - assuming that it happens only for grayscale images - the file
 size is likely to be fairly small anyway.  The size blowup with grayscale
 images will probably not be anywhere near as bad as some of the cases we
 saw in #36477.

 Replying to [comment:63 nosilver4u]:
 > I added some debugging into our code in EWWW IO, and it's definitely
 detecting `Imagick::COLORSPACE_GRAY`. If you're still not getting that,
 I'd be curious what version of IM you've got.

 This doesn't seem to be working for me, either.  I tried testing some
 different things - I'm not actually certain what the difference between
 `getColorspace` and `getImageColorspace` is, but it doesn't seem to matter
 since neither one seems useful here.  Here is a simple test program:

 {{{#!php
 <?php
 $filename = 'test8.png';
 echo $filename . "\n";
 $image = new Imagick( $filename );
 echo 'getColorspace() = ' . $image->getColorspace() . "\n";
 echo 'getImageColorspace() = ' . $image->getImageColorspace() . "\n";
 echo 'COLORSPACE_UNDEFINED = ' . imagick::COLORSPACE_UNDEFINED . "\n";
 echo 'COLORSPACE_RGB = ' . imagick::COLORSPACE_RGB . "\n";
 echo 'COLORSPACE_GRAY = ' . imagick::COLORSPACE_GRAY . "\n";
 echo 'COLORSPACE_SRGB = ' . imagick::COLORSPACE_SRGB . "\n";
 }}}

 This is what it displays on my system:

 {{{
 test8.png
 getColorspace() = 0
 getImageColorspace() = 13
 COLORSPACE_UNDEFINED = 0
 COLORSPACE_RGB = 1
 COLORSPACE_GRAY = 2
 COLORSPACE_SRGB = 13
 }}}

 > My dev server with Ubuntu 24.04 is running IM 6.9.12-98 and seems to
 work.

 I tested it on an older Ubuntu 22.04 system with ImageMagick 6.9.11-60.
 So possibly there is an issue here with older ImageMagick versions - but
 even aside from that, I'm still not certain the logic is correct.  If the
 purpose of this is only to handle images like `test8.png` it may be
 simpler to just not worry about this particular edge case.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63448#comment:64>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform