resizing paletted PNG images in WordPress

[nosilver4u]

ImageMagick version

6.9.11-60 Q16 x86_64 2021-01-25

Operating system, version and so on

Ubuntu 22.04

Description

Hi folks,
We're trying to sort out some long-standing issues in WordPress in regards to the resizing of paletted PNG images: https://core.trac.wordpress.org/ticket/36477#comment:53
Also connected to #3825, and we've tried a few different things without landing on a good solution.
As for versions tested, besides the 6.9.11 release, I've also tried the same solutions with 7.1.1-19

The main problem we're trying to solve, is that resizing a paletted image introduces more colors, and then the image can no longer use a palette, and the result is a larger file size than the original, anywhere up to 4-6x (or worse). Most of my testing of the various solutions has been with the image from #3825: https://ewwwio-downloads.b-cdn.net/png-tests/deskcat8.png
More examples:
https://ewwwio-downloads.b-cdn.net/png-tests/17-c3-duplicate-entries.png
https://ewwwio-downloads.b-cdn.net/png-tests/cloudflare-status.png
https://ewwwio-downloads.b-cdn.net/png-tests/Palette_icon.png
https://ewwwio-downloads.b-cdn.net/png-tests/rabbit-time-paletted.png
https://ewwwio-downloads.b-cdn.net/png-tests/test8.png

Here's some things I've tried:

1. Per @fmw42 and https://stackoverflow.com/questions/10348743/how-to-convert-png32-to-png8-via-imagick-in-php I've tried to prefix the filename with 'png8:' in the call to writeImage() at https://github.com/WordPress/wordpress-develop/blob/869b847bd392a92f2ae5b4d1c9c761b86c231990/src/wp-includes/class-wp-image-editor-imagick.php#L913
   Though this is supposed to have worked at some point, it now throws a fatal error, though this is caught by WP and we simply end up with no resized images/thumbnails:
   PHP Fatal error: Uncaught ImagickException: Cannot write PNG8 or color-type 3; colormap is NULL '.../wp-content/uploads/2024/05/cat-desk8-10-300x290.png' @ error/png.c/WriteOnePNGImage/9666 in .../wp-includes/class-wp-image-editor-imagick.php:914
2. Also per that thread on stackoverflow.com, I tried the quantizeImage() method, which is the only way that I've successfully solved the file size issues. But this introduces new issues, notably that quantizeImage() likes to add black (or dark) pixels on the edges between colored pixels and transparent ones:
   
3. Paul Bearne wrote up a patch on the WP issue to use setImageType() to change the image back to paletted: https://github.com/WordPress/wordpress-develop/pull/6455/files#diff-aa67e8e559403b1ebcdf8808e0c30b6c723286028d071f2a30f1eee0c0b8d595R845
   This only worked on Palette_icon.png, all the other images above still had resized images larger than the original.

The quantizeImage() method seemed the most promising, and works great if there is no transparency. I found this related post illustrating the issue: https://stackoverflow.com/questions/14031965/convert-32-bit-png-to-8-bit-png-with-imagemagick-by-preserving-semi-transparent/14032098#14032098
It doesn't seem to be 100% consistent, as test8.png comes out all right after quantizeImage().

I've tried altering the parameters to quantizeImage() to no avail. Dithering or not, expanded the tree all the way to 8 (maybe higher), but as soon as the image is quantized, the black pixels show up.
Is there some way to modify the alpha channel so that quantizeImage() will handle it better? Or is there some other solution we're overlooking?

For brevity, here is what we are trying to accomplish:

• Given a PNG8 (or other paletted image), resize it. In the instance of deskcat8.png, we can use the target size of 1140x1102.
• End up with a paletted image to prevent the file size from ballooning out of control. Given deskcat8.png and the specified target dimensions, the file size should never be larger than the original.
• Avoid quality issues, such as color shifts or black pixels around the edges of transparent sections of the image.

[fmw42]

Did you preface the output image name with "PNG8:"such as PNG8:output.png?

[nosilver4u]

Yes, that was the first solution I listed above. It throws a fatal error in imagick (also above). From what I could find elsewhere, the error message is indicating there are too many colors for a PNG8 image?

[fmw42]

Did you try turning alpha off, then quantize, then turn alpha on?

[nosilver4u]

I tried, but I couldn't seem to find the right way (in Imagick) to mimic the command line options that I was seeing. I believe the CLI was something like -alpha off ... -alpha on, though now I can't seem to figure out where I found that.
At any rate, I just tried it again with this:

$colors = min( 255, $this->image->getImageColors() );
$this->image->setImageAlphaChannel( imagick::ALPHACHANNEL_DEACTIVATE );
$this->image->quantizeImage( $colors, $this->image->getColorspace(), 0, false, false );
$this->image->setImageAlphaChannel( imagick::ALPHACHANNEL_ACTIVATE );

The transparency all turns into black with that route. I see there are ON/OFF constants also, but that's only available in IM 7.0.0 or higher--which could be an option, but not a great one given how many folks are still going to be on 6.9 (or lower).

[snibgo]

Are you shrinking or enlarging the images?

A simple and obvious technique is to resize the input image, then remap the pixels to the input image. This ensures that all the output colours are present in the input image. There will be no added colours, but there may be fewer. For example:

magick deskcat8.png -write mpr:INP -resize 30% -remap mpr:INP x.png

The output is paletted, with one colour fewer than the input, and is about one-third of the size in bytes.

[nosilver4u]

I don't think anyone ever uses WordPress to enlarge images, but at any rate, we're specifically talking about shrinking images here.
We would need a PHP+imagick solution, but I tried your idea anyway.
Note: I used 'convert' and not 'magick', as that's what I have installed, and I can't seem to work out how one gets a 'magick' binary on a Ubuntu system (maybe you don't).
Here's the results, with very nasty speckling around the edges:

[fmw42]

You should post this to an iMagick forum. The maintainers of Imagemagick do not maintain iMagick.

1. I do not know why PNG8: does not work in iMagick.
2. I do not know if MPR: is supported in Imagick.
3. I do not know why your alpha turns black after turning off, process, turn on.

[fmw42]

You could install the "magick" portable binary version of IM in your own directory. See https://imagemagick.org/script/download.php

[nosilver4u]

I did grab the portable package, so I'll use that for testing further, and if your alpha off/on trick works, I'll ping the Imagick folks for further guidance there.

[fmw42]

I believe that alpha_deactivate and activate are IM 7 commands. You need alpha_on and off in IM 6 or 7

[nosilver4u]

Oh? The Imagick docs list activate/deactivate as IM 6.3.8+ and on/off as IM 7+
https://www.php.net/manual/en/imagick.constants.php#imagick.constants.alphachannel

At any rate, I'll try the CLI options as best I can and see if IM can quantize an image without introducing black pixels around the edge when disabling alpha. Just to make sure I'm doing this right, I would need to put the operations in this order: -resize -alpha off -quantize -alpha on...

[nosilver4u]

Okay, I tried a couple things (and found the link where I had seen the alpha on/off suggestion https://imagemagick.org/discourse-server/viewtopic.php?t=22259):

magick deskcat8.png -resize 1140x1102 -alpha off -colors 255 -alpha on deskcat8-b.png
This gives an image with a black background, just like I got via Imagick.

magick deskcat8.png -resize 1140x1102 -alpha deactivate -colors 255 -alpha activate deskcat8-d.png
This unfortunately still has black pixels around the edges.

Am I doing that right, or is there something else I can try?

[snibgo]

The default filter for -resize works well for ordinary photos. But for graphic images, another filter may give a better result, especially when (as here) we want to limit the number of colours. For example:

magick deskcat8.png -filter Point -resize 30% x3.png

The result is paletted.

[nosilver4u]

Wow, that Point filter certainly gives a much better file size, but I don't know that folks are going to love the hard pixels/edges. I know I wouldn't put such an image our website, so I think that's probably a no-go.

[fmw42]

I took your image

and on Mac OSX Ventura and IM 7.1.1.32 Q16 did

magick deskcat8.png -resize 1140x1102 x.png

I see nothing wrong with it. Do you see any issue on your portable version of IM 7 with that command?

[nosilver4u]

That gets back to the original issue that the WP ticket reported: https://core.trac.wordpress.org/ticket/36477
Which is that the filesize is 3.6x the original. I'll update the original question so the specific goals are more clear.

[fmw42]

Doing

magick deskcat8.png -resize 1140x1102 PNG8:x.png

identify deskcat8.png x.png

deskcat8.png PNG 2000x1934 2000x1934+0+0 8-bit sRGB 105705B 0.000u 0:00.001
x.png PNG 1140x1102 1140x1102+0+0 8-bit sRGB 51176B 0.000u 0:00.000

So your original is 105705 bytes and your resized image is only 51176 bytes. So the resized is about half the original size.

The original is

 Class: DirectClass
  Geometry: 2000x1934+0+0
   Colorspace: sRGB
  Type: TrueColorAlpha
  Depth: 8-bit
  Channel depth:
    red: 8-bit
    green: 8-bit
    blue: 8-bit
    alpha: 8-bit
 Colors: 253

    png:IHDR.color-type-orig: 3
    png:IHDR.color_type: 3 (Indexed)

But the resized PNG8:x.png has the blue channel changed from 8-bit to 2-bit and the alpha from 8-bit to 1-bit. Both are indexed according to the PNG tags

Class: DirectClass
 Geometry: 1140x1102+0+0
  Colorspace: sRGB
 Type: TrueColorAlpha
   Depth: 8-bit
 Channel depth:
   red: 8-bit
   green: 8-bit
   blue: 2-bit
   alpha: 1-bit
Colors: 159

png:IHDR.color-type-orig: 3
png:IHDR.color_type: 3 (Indexed)

[nosilver4u]

Unfortunately the colors are a pretty distorted, but it's good to see what that option would look like so I don't have to waste time bugging the Imagick folks to fix the PNG8: prefix.

[fmw42]

So do you understand now how to take your equations and use them in -fx, so we do not have to do it for you each time?

[fmw42]

If I do

magick deskcat8.png -resize 1140x1102 -alpha deactivate -colors 255 -alpha activate zz.png

then I do see black spots around the green circles.

That likely occurs because you have black background in the image, which can be seen by

magick deskcat8.png -alpha off aoff.png

If I try

magick deskcat8.png -background white -alpha background -resize 1140x1102 -alpha deactivate -colors 255 -alpha activate zz.png

This mitigates it but leaves some around. These are from antialiasing which leaves some pixels not perfectly black, but near black. The command -background white -alpha background only changes the pure black to white.

I also tried magick deskcat8.png -fuzz 30% -fill "rgba(255,255,255,1)" -opaque "rgba(0,0,0,1)" -resize 1140x1102 -alpha deactivate -colors 255 -alpha activate yy.png

Which did a little better but did not get all the black spots and changed some colors to white. If you lower the fuzz value it will get your colors back but keep more black spots.

I am not sure what to suggest. You might try making the background white in your graphic when you create it in whatever tool that was. That may be less noticeable when resized. The only other course you have already tried with -filter point.

[fmw42]

Try this with thresholding your alpha channel to avoid the blending with the antialiased pixels. It seems to work to avoid the back anti-aliased pixels.

im7 magick deskcat8.png -resize 1140x1102 -channel alpha -threshold 50% +channel -alpha deactivate -colors 255 -alpha activate zz.png

The result is only 73840 bytes with

 Colors: 255
  png:IHDR.color-type-orig: 3
  png:IHDR.color_type: 3 (Indexed)

[nosilver4u]

I think this is probably the closest so far, and with the latest IM, it was even smaller:
https://test.exactlywww.com/wp-content/uploads/2024/05/deskcat8-g.png
Some of the white's seem to be kind of "washed out", but I think that's better than having black edges everywhere. I'll see if I can work out how to do this now in PHP/Imagick, thanks!