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

WordPress Trac noreply at wordpress.org
Fri May 23 00:11:51 UTC 2025


#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 SirLouen):

 I see the problem with this png8 method and the image provided:

 {{{
 The original has an 8 bit alpha
 Channel depth:
     red: 8-bit
     green: 8-bit
     blue: 8-bit
     alpha: 8-bit
 }}}

 While the resultin has an 1 bit alpha

 {{{
 Channel depth:
     red: 8-bit
     green: 8-bit
     blue: 8-bit
     alpha: 1-bit
 }}}

 Hence the result is a massive degradation in the transparency gradients.
 This is what happens when you don't truly know whats going on behind the
 scenes with this poorly documented functions from Imagick.

 Doing a little research I see this old SO topic
 https://stackoverflow.com/questions/13327675/php-imagick-quantize-
 transparent-equivalent
 Commenting that the best way to preserve transparency is using 257 colors.

 I don't see much differences between 256 aned 257:

 [[Image(https://i.imgur.com/TToK7y1.png)]]

 Except for the fact that switchin `png8` for

 {{{
 $this->image->quantizeImage( 257, Imagick::COLORSPACE_RGB, 0, false, false
 );
 }}}

 Makes `cloudflare-status.png` and `test8.png` also fail

 While `256` makes only `test8.png` fail (so this is what @nosilver4u
 comments about greyscale images for png8 instead of quantization?)

 One idea that comes to my mind is using quantization only for alpha
 channels over 1 bit alpha. The problem is that there is a bug or something
 in Imagick, and is that in Q16 builds (like the one I'm using), it will be
 reporting 16 bit alpha in images like `test8.png`, that in reality, has a
 1 bit alpha, provoking the troubles that nosilve4u
 [https://github.com/Imagick/imagick/issues/672 described in the Imagick GH
 Issue]

 Conclusion: Edge cases are all over the place and playing with depths in
 Imagick seems to be a little random depending on the Imagick version we
 are using, so the only solution here is reverting to the old idea but
 sticking to 257 colours in the Quantization for maximizing transparency
 colour quality.

 The only problem is that I have not found a Imagick method that can
 identify the `test8.png` greyscale to set it to `png8`. I've tried with
 `getImageColorspace` and its always reporting `13` for `sRGBColorspace` in
 my tests (probably in the original code it was being quantized with low
 bit depht, I have not checked this).

 Also tried with `getImageType` with `IMGTYPE_GRAYSCALE` but its not been
 catched it either :(

 TL;TR: For this solution I would need to find a method that identifies the
 `test8.png` as a greyscale 1-bit alpha depth and use `png8` for that edge
 case (or find some consistent method that identifies alpha channel depth
 and use quantization for anything over 1)

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


More information about the wp-trac mailing list