[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