Opened 16 months ago
Last modified 2 months ago
#60889 reopened defect (bug)
wide gamut AVIF is desaturated (retagged as sRGB on upload)
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Media | Keywords: | |
Focuses: | Cc: |
Description
So great to see the new AVIF support in WordPress v6.5!
I am seeing one issue with processing images encoded with a gamut wider than sRGB, they are getting desaturated as the the color Primaries have changed from P3 ("SMPTE EG 432-1") to "sRGB or sYCC".
The image should remain encoded in the source gamut when resized/compressed.
Attachments (3)
Change History (20)
This ticket was mentioned in Slack in #core-media by antpb. View the logs.
16 months ago
#3
@
16 months ago
Hey @gregbenz - thanks for the bug report and for the zip of sample images.
I have read reports of some issues with color profiles AVIF and Imagick that may be related, not sure if/when they were fixed. I'd like to do some more testing and research to see if we can determine if this issue has been reported and/or fixed.
A couple of questions:
- How can I reproduce the issue? is the difference in the images obvious when viewing them, or are you using a tool to check the image gamut?
- Can you reproduce on instawp.io? (they have AVIF support and are good for testing)
- if your server GD has AVIF support, do you get the same issue? you can use this mini plugin to switch to GD as the default: https://gist.github.com/adamsilverstein/c8b5d0145aeda7fe0a04e4573f2c7c32?permalink_comment_id=3968231
#5
@
16 months ago
Hi @adamsilverstein-
- The difference is obvious to me visually. You can also confirm details with exiftool by extracting the metadata with the command of the form "exiftool -a -u -g1:3 -w txt testImage.avif" and look at the Color Primaries (around line 35 or so).
- I don't see a simple way to upload / test via instawp.io.
- When I change my site to use GD, I also see failure. I'll attach that result as well for reference.
The issue to me appears that an sRGB tag was simply re-assigned to the image without changing the numerical data, resulting in loss of saturation in the rendered image. Had the image actually been properly converted to sRGB, the result would be that the test image would only reduce the saturation of the swatches using the full P3 range (ie 6 swatches would look like 3 after conversion to sRGB, as that would simply clip the colors). Conversion to sRGB would also be an incorrect result, but I mention it as it may point to the root issue involving some request in the code to simply assign a color space tag (via NCLX in this case).
#6
@
16 months ago
Note that you can visually assess in a color-managed browser like Chrome. The saturation change in the source image is most obvious for red and green in the test image.
This ticket was mentioned in Slack in #core-media by antpb. View the logs.
15 months ago
This ticket was mentioned in Slack in #core-media by antpb. View the logs.
13 months ago
#9
@
10 months ago
Hi @gregbenz - looping back to check on this ticket. Thanks for the details about how to test; I was hoping for some way to automate Gamut testing.
I expect this issue is related to how we are using Imagick (or GD) to process the images. I see Imagick has several commands that seem related such as setImageColorspace
(I'm not sure what command we need to use though). To fix this issue, we may need to change some output settings (ideally based on detecting the format or colour Gamut of the uploaded image).
If you open a ticket on the Imagick repository, please link back here so I can follow.
#10
@
9 months ago
After testing with ImageMagick, this appears likely to be an issue with IM (though perhaps there is a command which may be sent to IM to work around this issue without any update from IM).
#11
@
9 months ago
Thanks for the additional testing!
Note: this seems closely related to https://core.trac.wordpress.org/ticket/58435 which you previously reported, although that one is about JPEG images.
#12
@
9 months ago
- Resolution set to wontfix
- Status changed from assigned to closed
It appears the resolution here will be an update to IM (to include a fix from libheif)
https://github.com/ImageMagick/ImageMagick/issues/7715#issuecomment-2433063930
I'm going to close this for now, as it seems likely that the issue would resolved with a future update to IM without requiring updates in WP.
#13
@
9 months ago
For future reference if validation is needed after pending updates to IM:
When successful, the result of the following EXIFTOOL command would show the same values for both source and the transcoded AVIF image:
exiftool -colorprofiles -colorprimaries -transfercharacteristics -matrixcoefficients -videofullrangeflag myFile.AVIF
#15
@
3 months ago
- Resolution wontfix deleted
- Status changed from closed to reopened
This bug is still affecting WordPress v8.6
#16
@
2 months ago
I believe the issue still exists in the latest version of ImageMagick. I downloaded latest ImageMagick 7.1.1-47 and ran the following command:
magick input.avif -rotate 360 output.avif
I used the same image @\gregbenz provided, and I can see that the resulting output.avif appears desaturated. I also converted the same image to JPEG (using the conversion option in macOS Finder — most other conversion methods I tried caused desaturation) and ran the same command. The resulting output.jpg looks the same as the original.
#17
@
2 months ago
@karthikeya01 Could you add that to the IM bug report? (https://github.com/ImageMagick/ImageMagick/issues/7715#issuecomment-2433063930)
May need to log as an ImageMagick bug, not clear where a change may be needed. I see the above results when using:
ImageMagick version number 1809
ImageMagick version string ImageMagick 7.1.1-26 Q16-HDRI x86_64 21914
Imagick version 3.7.0