Make WordPress Core

Opened 3 years ago

Last modified 12 months ago

#53408 new defect (bug)

png images bit depth is modified in resized images

Reported by: wpfed's profile wpfed Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.7.2
Component: Media Keywords:
Focuses: Cc:



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

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(

Also here are related tickets I was able to find:


Change History (6)

#1 in reply to: ↑ description @wpfed
3 years ago

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.

This ticket was mentioned in Slack in #core-media by joedolson. View the logs.

12 months ago

#3 follow-up: @antpb
12 months ago

#58960 was marked as a duplicate.

#4 @antpb
12 months ago

A report of this was filed in 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 )

#5 in reply to: ↑ 3 @tgsrvrs
12 months ago

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.

#6 @tgsrvrs
12 months ago

@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

Note: See TracTickets for help on using tickets.