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

 Replying to [comment:68 siliconforks]:
 > Replying to [comment:66 nosilver4u]:
 > > I think the disconnect here is ''when'' one checks the image
 colorspace. I just tested on 22.04 with IM 6.9.11-60 as well and get
 Imagick::COLORSPACE_GRAY after quantizing the image.
 >
 > OK, I see that it works for me now if you run `quantizeImage` first,
 then call `getImageColorspace` - it returns `Imagick::COLORSPACE_GRAY`.
 >
 > However, the question then becomes: is that actually the right thing to
 check?  Suppose you have an image which is similar to the `oval-or8.png`
 image above, but grayscale.  Then won't that also be identified as
 `Imagick::COLORSPACE_GRAY`?  Then won't forcing it to `png8` destroy the
 alpha values in the image?
 >
 > I think what you probably want to check here is what @SirLouen alluded
 to above in https://core.trac.wordpress.org/ticket/63448#comment:61 - you
 want to check whether the image has 1-bit alpha transparency.  If so (or
 if it has no transparency at all), then it should be safe to use `png8`
 format; otherwise no.  But I'm not sure if there's an easy way to do that,
 or if it's even worth doing considering that this is probably only useful
 for a fairly rare edge case.

 I was about to check for this, because on my debug yesterday, I found that
 I could not get into the `COLORSPACE_GRAY` conditional and I could not
 understand why. Then I noticed that the images were not into that color
 space but RGB as I commented above (according to Imagick). But what I did
 not try was sequentually checking for this after a Quantization (and now
 makes all the sense to me, because the original tests before this last
 patch were passing for `test8.png` which happened to do this sequence.

 As you say, things start to become extremely tricky when gray images, have
 an alpha of 8-bit. Then quantization can't handle the image, but `png8`
 restores it and at the same time destroying all gradients.

 I'm not sure if we should consider this as "an edge case". Let's say that
 you have a picture gallery with full greyscale pictures. The impact is
 going to be there.

 But at the same time, it seems that Imagick cannot find (to what I've
 researched, but the last time `IHDR.color-type-orig` was found in the
 wild).

 About the 257 colours, it was this tricky strategy to preserve more
 quality in gradients (in exchange for a less optimized result). It's
 interesting because I can only see this quality improvement in one of my
 screens.

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