png images bit depth is modified in resized images

[wpfed]

Hi,

When I upload a 8 bit png image graphic, WordPress resizes as usual but modifies the bit depth to 24 or 32 bit, depending if their is a alpha channel. Without Alpha channel it is 24bit, with it's 32bit.

The problem with that is that the file sizes end up being multiple times bigger than the original image.

I opened a ticket with ImageMagick ​https://github.com/ImageMagick/ImageMagick/discussions/3825

Some of the replies included these solutions:

Setting bit-depth to 8 in the way done in the script may not be adequate for PNG. I think the only way to ensure that is to preface the output name with PNG8:filename.png. But I am not sure if it will preserve you transparency if the input has transparency. But the best thing to resolve that would be simply to try it.

Scaling the image, depending upon the scaling method, most likely will add more colors than the 256 limit for 8-bit color. So the image has to be forced to quantize colors to the 256 limit in order to save as 8-bits. Otherwise, it is saved as 24 or 32-bits. So specifying PNG8:filename.png will save as 8-bits.

PNG00: Inherit PNG color and bit depth from input image(​https://legacy.imagemagick.org/Usage/formats/#png_formats)

Also here are related tickets I was able to find:

https://core.trac.wordpress.org/ticket/36477
https://core.trac.wordpress.org/ticket/30402
https://core.trac.wordpress.org/ticket/48736

Thanks!

[wpfed]

Update from the ImageMagik pros:

I found that if you, say, blur the file and save with PNG8:filename.png, the 8-bit alpha format is preserved with only a small increase in file size. ImageMagick cannot achieve the same level of optimization as specialized programs such as you used. So the file size went from 105K to 112K. So have WordPress change the code so that when 8-bits is desired, add the PNG8: prefix to the filename.

[antpb]

#58960 was marked as a duplicate.

[antpb]

A report of this was filed in https://core.trac.wordpress.org/ticket/58960#comment:4 and @tgsrvrs shared a source image to reproduce this in the comments. We've closed it as a duplicate, but if anyone needs a source image that would be the place to grab one. :)

( props @tgsrvrs )

[tgsrvrs]

Replying to antpb:

#58960 was marked as a duplicate.

There was nothing done about this for 2 years? Are you planning on fixing this? Otherwise can you please tell me where exactly I have to hook into to fix that on my own. I do not have weeks for that, let aside years! This is major because otherwise I would have to disable srcset on the whole site, and then it is not available for other pictures.

[tgsrvrs]

@wpfed provided the solution already, it is nothing more than adding a PNG8: to the resize command, like

 convert Test.png -resize 83% PNG8:tmp.png

for Imagick. As he pointed out that results in slight increase of a few bytes because of optimization limitations but we are far from a few 100% that renders WP core solution as it is unusable in current state

[adamsilverstein]

Looks like this issue was discovered in another ticket and a PR there may resolve it: https://core.trac.wordpress.org/ticket/36477

[adamsilverstein]

@wpfed Thanks for opening. This should be fixed by https://core.trac.wordpress.org/changeset/59589 so closing as such. If that is not the case, feel free to re-open.

[desrosj]

Duplicate of #36477.

Going to mark this as a duplicate so that it points to the canonical location of discussion for this bug.