PNG original image not affected by conversion filter

[pixlpirate]

Filter used:

<?php

add_filter('image_editor_output_format', function( $formats ) {
    $formats['image/png'] = 'image/avif';

    return $formats;
});

To reproduce:

1. Add the following filter to functions.php
2. Upload a PNG image, e.g. image.png
3. Note that the sub-sizes of image.png are converted to AVIF (if any), but original image remains in PNG

Expected behavior:

• The original image should be converted

---

Possible cause
This issue may come from line 265 of the wp-admin/includes/image.php
At this point, PNG images are skipped before checking the defined output format.

<?php

// Do not scale (large) PNG images. May result in sub-sizes that have greater file size than the original. See #48736.
if ( 'image/png' !== $imagesize['mime'] ) {
...
}

A possible fix could be

<?php

// Get output format if image needs to be converted
$output_format = wp_get_image_editor_output_format( $file, $imagesize['mime'] );

// Do not scale (large) PNG images. May result in sub-sizes that have greater file size than the original. See #48736.
if ( 'image/png' !== $output_format ) {
...
}

[adamsilverstein]

Hi @pixlpirate -

Thanks for the bug report. Can you verify that your server supports AVIF? You can check under Tools->Site Health->Info->Media.

Additionally, can you try changing the filter to output WebP images instead of AVIF to see if that works? (98%+ of servers support WebP, while on ~30% support AVIF).

[pixlpirate]

Hi @adamsilverstein

Thanks for your reply. I’ve tested different output formats, including AVIF, WebP, and JPEG, and the issue seems to be related to the input format rather than the output format.

(Note that all the following tests were performed with images of the same dimensions)

---

Dropping a JPEG file in the media library:

Input:

• image.jpg

Output:

• image.jpg
• image.webp
• image-150x150.webp
• image-300x300.webp
• etc.

Results:

• ✔️ The original image is preserved
• ✔️ The original size is generated in the target format
• ✔️ The thumbnails are generated in the target format

I had similar results for the following input formats: JPEG, GIF, AVIF, WebP

---

Dropping a PNG image in the media library:

Input

• image.png

Output

• image.png
• image-150x150.webp
• image-300x300.webp
• etc.

Results:

• ✔️ The original image is preserved
• ❌ The original size is not generated in the target format
• ✔️ The thumbnails are generated in the target format

[adamsilverstein]

@pixlpirate excellent, thanks for clarifying!

Note that the sub-sizes of image.png are converted to AVIF (if any), but original image remains in PNG

I missed this in reading your original report, we get many reports of AVIF not working so I jumped to that as a possible cause.

This may be related to an issue reported with the Performance Lab plugin: ​https://github.com/WordPress/performance/issues/1798

I will try to reproduce this and review the fix you suggested.

Some follow up questions:

• Does this happen with ALL PNG uploads?
• Can you share you site health->media data - I'm curious which media library/version is handling the PNGs in case that is related.

[pixlpirate]

I missed this in reading your original report

No problem! 🙂

I tested the following combinations, the problem occurs in all of them:

• Size range between 270px to 4320px, square, landscape, portrait
• 8-bit / 24-bit
• With / Without alpha layer
• With / Without interlacing

I’m using PHP GD (cf. site health attached), I can try to switch to ImageMagick if you need more tests.

[adamsilverstein]

Thanks for all of the details, let me try reproducing first and we can go from there.

Fix an issue where PNG uploads failed to create full sized images when outputting in an alternate format (eg. WebP or AVIF).

Trac ticket: https://core.trac.wordpress.org/ticket/62900

[adamsilverstein]

@pixlpirate the issue was indeed in the block of code you identified.

In ​https://github.com/WordPress/wordpress-develop/pull/8253 I added a conditional to take the output format into consideration when skipping full sized PNGs. The original logic applies for normal PNG uploads, but is skipped when the output format is not PNG.

Can you give the PR a test to verify it fixes the issue on your end? It worked in my testing.

[pixlpirate]

Hi @adamsilverstein

I tested the PR and it works like a charm. Thanks again for your help!

[adamsilverstein]

@pixlpirate Thanks for confirming.

It would be nice to add a unit test here to validate/enforce the fix before committing.

[flixos90]

While it's a valid topic to raise, I do wonder whether this can be considered a bug or an intentional limitation.

I certainly agree it's unexpected that the original image is not converted while its subsizes are converted.

But before we change anything related to the PNG limitation, we should research for history why that condition to exclude PNGs was implemented in the first place and whether it's still relevant or can be revised.

Depending on the outcome of that research, I think we should either remove the PNG limitation so that it works the same way for all formats, or we could consider disabling it also for the subsizes in that case so that it's consistent. Although then one may argue it's still better to have only the sub-sizes available as AVIF than all of them being PNG.

[adamsilverstein]

I did review the ticket where this was introduced (https://core.trac.wordpress.org/ticket/48736), trying to avoid creating a full sized image that was larger than the uploaded image. I suspect the original bug was not really addressed by the fix, and may have been the bit depth issue we recently fixed where 8 bit PNG uploads were output as 24 bit making them much larger (#36477).

Please review the ticket, maybe I missed something there.

I think we should either remove the PNG limitation so that it works the same way for all formats

I would be in favor of removing it, let me give it a try.

I avoided doing this previously to minimize the changes/risk, however I question whether the original fix was correct anyway.

This check is no longer required. The larger output files issue was resolved separately in https://core.trac.wordpress.org/ticket/36477.

Trac ticket: https://core.trac.wordpress.org/ticket/62900

All image sizes remain smaller than the original large uploaded PNG, including the full sized and large size.

[adamsilverstein]

@flixos90 - I created an alternate PR that removes the PNG exclusion entirely - ​https://github.com/WordPress/wordpress-develop/pull/8275. This essentially reverts https://core.trac.wordpress.org/changeset/46809

added for "Upload: Exclude PNG images from scaling after uploading. Fixes a case where resizing a very large PNG may create a scaled image that has smaller dimensions but larger file size than the original."

I retested this after removing and no longer see the original issue, all PNGs aer smaller than the upload.

Worth reviewing without whitespace changes visible: ​https://github.com/WordPress/wordpress-develop/pull/8275/files?diff=unified&w=1

I am not opposed by any means, but I would like us to get people that were involved in the original change from https://core.trac.wordpress.org/ticket/48736 to weigh in on whether we're now in a good place to remove the exclusion.

Sounds good; hopefully we can get this in before beta. I can add some unit tests here to validate the behavior,

I can add some unit tests here to validate the behavior

I looked into this. I did not find a sample image on any of the previous tickets. For my own manual testing, I created a very large PNG that weighs in at over 6MB., I'm not sure this change warrants adding that much to the repo weight.

### test image

​new-test-large.png.zip

The larger output (PNG) files issue was resolved separately in https://core.trac.wordpress.org/ticket/36477, fixed in https://core.trac.wordpress.org/changeset/59589.

Yep, seems fixed. As far as I remember the original report was of a PNG with large dimensions but quite small file size. Tried to find one like that but couldn't, all PNGs that I tested seem to create smaller sub-sizes.

The larger output (PNG) files issue was resolved separately in https://core.trac.wordpress.org/ticket/36477, fixed in https://core.trac.wordpress.org/changeset/59589.

Yep, seems fixed. As far as I remember the original report was of a PNG with large dimensions but quite small file size. Tried to find one like that but couldn't, all PNGs that I tested seem to create smaller sub-sizes.

Thanks for reviewing / testing.

[adamsilverstein]

I have added a test for the latest version in https://core.trac.wordpress.org/ticket/62900 and confirmed this is safe to remove. This should be good to go.

[adamsilverstein]

In 59844:

Media: fix full size image generation for PNG uploads.

Remove a limitation that prevented PNG uploads from generating the full sized image. Fixes a bug where using the image_editor_output_format filter would not generate full sized images as expected. The removed code was present to prevent overly large PNG image output, however this issue was resolved separately in #36477.

Props: adamsilverstein, pixlpirate, flixos90, mukesh27, azaozz.

Fixes #62900.

Trac ticket: https://core.trac.wordpress.org/ticket/62900

[adamsilverstein]

In 59845:

Media: fix indentation for media.php.

Follow up to r59844.

Props: mukesh27.

See #62900.

Committed https://core.trac.wordpress.org/changeset/59845