[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 has-unit-    |     Focuses:
  tests changes-requested needs-dev-note         |
-------------------------------------------------+-------------------------
Changes (by SirLouen):

 * keywords:  has-patch has-test-info has-unit-tests changes-requested =>
     has-patch has-test-info has-unit-tests changes-requested needs-dev-
     note


Comment:

 Replying to [comment:88 siliconforks]:
 > For grayscale images, I'm not sure if it makes a difference if you call
 `quantizeImage()` and then call `setOption( 'png:format', 'png8' )`, or if
 you skip the `quantizeImage()` call and just call `setOption(
 'png:format', 'png8' )`.

 I've been researching a bit on how `png8` operates under the hood.
 Basically, it's a quantization with certain very specific parameters.
 Some (not all) [https://imagemagick.org/script/defines.php info here]
 It doesn't histogram the colours as the original image (as we were doing
 before), but it samples, resulting in way faster processing speeds.
 Also forces a 1-bit transparency (as we were seeing with the alpha issues
 we were facing).
 It appears that it also adds some dithering
 Resulting, mostly, in the smallest size possible but losing a ton of
 shading in the process.

 This function, was designed for converting very simple images, into an
 indexed PNG. I feel, overall, we have been playing a bit with all this as
 trial an error. Identifying both images in 44.png, I can see that the
 colour difference is massive. Almost double the colours used.

 So I can get one first conclusion: png8 is not ideal for already png8
 indexed images. Quantizing is okish, will show a little improvement for
 most images (specially with the safe approach we are using)

 Now for the grey images, I'm using test8.png for the test:

 With only png8 = 13Kb result
 With only quantize = 74kb results (expected, this was the original bug)
 With both = 11Kb result

 So, basically, running both isn't resulting in a massive improvement.

 To put an ending for this, I was thinking of suggesting you, omitting
 quantization from greyscale images
 But after a little last debugging, I remembered why we can't really do
 this: we cannot identify greyscale images without a quantization first.
 This was the first "bug" of Imagick we identified with @nosilver4u
 And this is why we were doing two runs: one for quantization first (to
 identify those gray images as `COLORSPACE_GRAY` and then another for
 compressing into png8 (otherwise they end with an even larger size than
 the original image).

 So let's consider this a hacky way to bypass the colorspace trouble with
 greyscale images, and not have the issue of the increase in size due to
 the quantizing troubles. Conclusion: You can leave it as-is now with one
 thing:
 I think all this must be documented. All this thought process has been
 highly convoluted, with numerous edge cases all over the place.

 Maybe you could add in L538 something a comment like:
 > "And we need to first quantize greyscale images, because we have not
 found a way to identify their Colorspace without quantizing first."

 And we can call this a day. Furthermore, I'm adding `needs-dev-note`
 because this should be documented somehow.
 [https://make.wordpress.org/core/handbook/tutorials/writing-developer-
 notes/#what-should-a-dev-note-include According to the Handbook], as we
 are solving all this in a less than ideal way.

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