Media library strips color profiles => significant image color problems

[gregbenz]

If you upload a JPG with an embedded profile (such as P3 or some other wide gamut), the reprocessed image in the media library is stripped of its color profile. This is likely to result in significant display errors for any image not encoded as sRGB, including: desaturation, clipping of gradients or vibrant colors, and hue shifts.

Tested with WP v6.2.2 and PHP v7.4.33

[joemcgill]

Thanks for the report @gregbenz. Could you share more about the WordPress setup where you are seeing this behavior? If you visit the Info Tab in your website's Site Health page (under tools in the menu), there is a "Media Handling" panel with more information about what image processing libraries are available on your server. Can you copy and share that info here as well?

[gregbenz]

Thank you for the quick reply, @joemcgill
Would retention of the profile rely on Imagick?

Here you go:
Active editor WP_Image_Editor_GD
ImageMagick version number Not available
ImageMagick version string Not available
Imagick version Not available
File uploads Enabled
Max size of post data allowed 256M
Max size of an uploaded file 256M
Max effective file size 256 MB
Max number of files allowed 20
GD version 2.3.3
GD supported file formats GIF, JPEG, PNG, WebP, BMP, XPM
Ghostscript version 9.56.1

[gregbenz]

Apparently so, just tried with Imagick and the profile was retained.

Not sure where, but might be an opportunity for WordPress to note potential optimization through hosting settings to enable it if native support in WP_Image_Editor_GD is out of scope.

[joemcgill]

Thanks for confirming @gregbenz! I had thought that Imagick was required for preserving color profiles, though I'm not sure the last time we took a look at trying to retain support in the WP_Image_Editor_GD class. For what it's worth, WordPress will default to Imagick if it's available on a server and fall back to GD if not.

Related tickets:

#36684
#11877
#11671

[gregbenz]

@joemcgill Thanks!

Are NCLX / CICP tags retained? That's probably increasingly helpful. As AVIF takes off, I'd expect compact formats like that are used over embedding a full ICC profile. I can't think of a great reason to embed a full profile for sharing images on the web once that's fully supported.

[joemcgill]

Currently, the only profiles that are retained when WP strips metadata from an image are 'icc', 'icm', 'iptc', 'exif', and 'xmp' (Imagick only).

See: ​https://github.com/WordPress/WordPress/blob/6.2.2/wp-includes/class-wp-image-editor-imagick.php#L919-L934

There is a filter that can be used to keep the editor from stripping meta, image_strip_meta, but that will also retain any other unnecessary or potentially private metadata on each resized image, so use with caution.

[gregbenz]

That page says WP v6.2.2 does not include that feature. Are you saying there's some other way to override a local WordPress instance to retain CICP/NCLX via ImageMagick?

Thank you for all the great info!

[ironprogrammer]

This ticket was reviewed during bi-weekly Test triage.

Yes, @gregbenz, the reference provided in comment:6 refers to the ​`image_strip_meta` filter, which can alter metadata retention behavior during resize.

Because the existing image profile filters cited by @joemcgill function as intended (not a bug), was including the CICP/NCLX data something you will pursue separately? I'm asking before suggesting this ticket be closed, in case you wished to re-characterize it as an enhancement request should you feel these profiles should be retained by default.

[gregbenz]

@ironprogrammer While I am personally OK using ImageMagick instead of the native WP image processing, I do think it would be best practice not to strip profiles like this.

It can cause significant saturation/color issues for images not encoded in sRGB, and that's likely to increase in time as wide gamut is used more broadly. And the file size impact of these codes is small (I assume historically larger ICC profiles were a problem with small images and set the pattern for stripping everything back at a time when we didn't have CICP/NCLX). So I would suggest this as a feature enhancement which will benefit the community at large, but I'm in good shape myself now that I understand the behavior and how to work around it.

Thank you,

[ironprogrammer]

Okay, I've set this ticket to enhancement for further discussion, then. If you have time, please provide any additional info that might be helpful for discussion, or metadata in addition to CICP/NCLX that might be worth considering to improve wide gamut support.

[gregbenz]

@ironprogrammer I'd sum it up this way:

(1) Stripping a wide gamut profile causes all RGB numbers to be interpreted incorrect, resulting in substantial color error.

(2) sRGB is based on display technology from over 30 years ago. Most modern displays support P3 or other wider than sRGB gamuts. The desire to share images supporting them will continue to increase.

(3) Browser support is already widespread and it is generally safe to share such images, unless reprocessing strips the profile (as is the case here).

(4) There is no user warning or rejection of wide gamut files, so it is easy to make the mistake of trying to use an image which will be harmed by the profile being stripped. And many people would probably not be aware of workarounds using ImageMagick.

I would hope this is a fairly simple enhancement for CICP/NCLX, as all that is needed is to not remove the metadata. I recognize that converting an ICC profile to such a format (or stripping it down to just an ICC profile with a CICP tag) would not be simple - but keeping any ICC profile (as is) would also be ideal and should be similarly straightforward to preserve without changes. If file size is a concern, the content creator can always strip the profile or ensure they use a format supporting CICP/NCLX rather than embedded a full ~1k profile.