#53653 closed defect (bug) (fixed)
Scaled down WebP images may be with much larger file size than the original
Reported by: | azaozz | Owned by: | azaozz |
---|---|---|---|
Milestone: | 5.8 | Priority: | normal |
Severity: | normal | Version: | 5.8 |
Component: | Media | Keywords: | has-patch fixed-major commit dev-reviewed |
Focuses: | Cc: |
Description
As reported in https://wordpress.org/support/topic/webp-very-large-filesize-5-8-rc2/.
It appears that when ImageMagick is used to create the WebP sub-sizes, the output is set to lossless even though the original image is with lossy compression.
Attachments (1)
Change History (16)
#2
@
3 years ago
Interesting, our code assumes that images with the VP8X header are animated or alpha, lossy should have the VP8 header.
Maybe @marylauc or @blobfolio can shed some light on this.
Can you provide some test images so we can see what you are working with? When you are exporting your image, can you verify that lossy is enabled?
In my testing I converted my jpeg to webp with https://squoosh.app before uploading (using lossless). My subsizes were all lossless, and each webp image was smaller than the jpeg counterpart.
#3
follow-ups:
↓ 5
↓ 8
@
3 years ago
In 53653.diff
- Only use lossless format for WebP output when header detection determines image is lossless.
Fixes previous logic to favor using lossy format as default, only using lossless when the image engine supports it and we know the image is lossless. Image engines don't support alpha or transparency for webp yet as far as I know anyway.
#4
follow-up:
↓ 9
@
3 years ago
Moving some of my findings over here from Slack (beginning of conversation):
My reading of the spec (https://developers.google.com/speed/webp/docs/riff_container#example_file_layouts) agrees with @azaozz's finding that VP8X
doesn't necessarily mean lossless or animated.
Right now, core is assuming VP8X
always means animated.
This happens when wp_get_webp_info()
is called here:
https://github.com/WordPress/wordpress-develop/blob/master/src/wp-includes/class-wp-image-editor-imagick.php#L206
Then, VP8X
sets animated-alpha
as the type:
https://github.com/WordPress/wordpress-develop/blob/4eb17be18cdf7b2cf8e4dd4e4511dda76a5e9a11/src/wp-includes/media.php#L5170
So a lossy WebP from Gimp, for instance, is detected as animated, then saved as lossless.
webpinfo
indicates that the files from Gimp, whether lossy or lossless, are valid, and all use VP8X
, regardless of the extra info I tell it to include.
Lastly, I think this a separate issue, but to make sure it's documented --
When a JPEG is loaded, then saved as a WebP, only the JPEG compression settings are used, as set_quality()
is run only on load, as far as I am aware.
https://github.com/WordPress/wordpress-develop/blob/28ea7b18cf23e9e373a52cad21a739b030e3fced/src/wp-includes/class-wp-image-editor-imagick.php#L200
#5
in reply to:
↑ 3
@
3 years ago
Replying to adamsilverstein:
In 53653.diff
- Only use lossless format for WebP output when header detection determines image is lossless.
Fixes previous logic to favor using lossy format as default <snip>
Tested this, and it looks to do as expected so far.
It would be even better if we could detect lossless images more accurately (there are still VP8L
images located within files that begin with VP8X
sections, which core is currently not detecting), but I agree that it's much better to default to assuming we should save as lossy than lossless.
This ticket was mentioned in Slack in #core by desrosj. View the logs.
3 years ago
#8
in reply to:
↑ 3
@
3 years ago
Replying to adamsilverstein:
Patch works as expected here too, thanks.
Only use lossless format for WebP output when header detection determines image is lossless.
That leaves the opposite case: VP8X
with a VP8L
"chunk" will produce lossy sub-sizes. However agree this is a smaller issue. Opened #53663 to try to fix WebP features detection, can even try it for 5.8.1.
#9
in reply to:
↑ 4
@
3 years ago
Replying to mikeschroder:
Thanks for the detailed explanation!
It would be even better if we could detect lossless images more accurately (there are still VP8L images located within files that begin with VP8X sections, which core is currently not detecting)
Yes, wp_get_webp_info()
needs fixing/update so it can detect the rest of the info when the type is VP8X
. Can see some js code for that, nothing in PHP though. See #53663.
#10
@
3 years ago
- Owner set to azaozz
- Resolution set to fixed
- Status changed from new to closed
In 51435:
#11
@
3 years ago
- Keywords fixed-major commit added; needs-testing removed
- Resolution fixed deleted
- Status changed from closed to reopened
Reopen for the 5.8 branch.
This ticket was mentioned in Slack in #core-media by desrosj. View the logs.
3 years ago
#15
@
2 years ago
Note: This issue here avoided to create responsive images that are larger in file size than their original by avoiding to create lossless responsive images from lossy originals.
Now as extreme as this may seem but in #57238 there's one case where the reverse is happening! The first 2 next smaller sized versions in the responsive images set are lossy (!) but nevertheless larger in file size than their larger original which is lossless and with an alpha channel. Only the 3rd responsive image is then smaller in file size than the original. Check it out!
Looking a bit more, seems all WebP images exported by Gimp 2.10 (latest) are detected as
animated-alpha
bywp_get_webp_info()
despite that they were saved as lossy and lossless (no animation).Looking in the file headers, the "type bits" are indeed
VP8X
. Seems this is a problem with the JPEG => WebP converting software or these bits cannot be used to reliably detect lossy and lossless WebP images.