wide gamut AVIF is desaturated (retagged as sRGB on upload)

[gregbenz]

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.

[gregbenz]

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

[adamsilverstein]

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

[gregbenz]

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).

[gregbenz]

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.

[adamsilverstein]

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.