GNOME Bugzilla – Bug 554498
No colour conversion when image does not have embedded ICC profile
Last modified: 2014-04-02 16:34:54 UTC
Please describe the problem: Eye of Gnome displays correctly the colours of JPEG images, which have embedded ICC profile or "Exif:ColorSpace" is set to "1" and when xicc atom of X is set to the monitor ICC profile (with tools like xcalib, xicc, dispwin). JPEG image without any of the above metadata is displayed without colour transform to the colour space of the monitor as defined by xicc atom. Reasoning is that sRGB colour space is de facto standard for PCs and images on the internet. E.g Mozilla Firefox 3.x does so, GIMP and CinePaint have settings to allow user to set assumed colour space if no profile is embedded in the image, etc.) This bug affects users with monitors having the gamut different from sRGB. (E.g. the wide gamut LCD Samsung SyncMaster XL20 capable of displaying AdobeRGB gamut.) Steps to reproduce: To reproduce the bug, the user must set xicc atom to some wide-gamut colour space. (If the user does not actually have a wide-gamut display, the colours would look wrong to him. But for the test of the bug, it is okay to do so.) 1. Prerequisities Install package "icc-profiles" to have some standard ICC profiles in the system. Install ImageMagick to be able to strip metadata. Install xicc to be able to set a monitor profile to the xicc atom of X. Obtain a test image in sRGB and make two versions of it: one with embedded profile, the other one without any metadata. Any image from the internet would work, but special colour targets exist, e.g. http://www.normankoren.com/ColorChecker_sRGB_small2.jpg. ColorChecker_sRGB_small2.jpg has already sRGB ICC profile embedded, to make a copy without the ICC profile run: "$ convert ColorChecker_sRGB_small2.jpg -strip stripped.jpg". Make sure xicc atom of X is set to wide gamut colour space to make the difference clearly visible. Run "$ xicc /usr/share/color/icc/LStar-RGB.icc" and verify with "$ xprop -root | grep _ICC_PROFILE" (it should output lot of numbers. The empty output means xicc atom is not set) 2. Test Open both images in two separate EoG windows. Actual results: The colours of the two images are not the same. ColorChecker_sRGB_small2.jpg shows less saturated colours (which is correct in this test case) than the stripped.jpg. Expected results: The colours of the two images should be identical - if EoG would have assumed that an image without a profile is in sRGB colour space. Does this happen every time? Yes. Other information:
Another one from my "Things-I-Forgot-To-Fix-During-Summer-List".
Any plans to correct the bug? It keeps me off from using EoG since it is not reliable for displaying the image colours.
(In reply to comment #2) > Any plans to correct the bug? > Actually yes, but I'm currently undecided (besides my chronical lack of time lately) on what to do in the situation where there's an image we don't support reading the embedded profile (like TIFFs).
Yes, fighting with time is endless... As I understand, colour managed display of TIFFs/SVG does not work anyway at the moment. So I would leave it for those troublesome formats as is (and instead look for a simple way how to indicate the user the image is not colour managed).
Hmm, color management support seems to be coming to gdk-pixbuf: http://git.gnome.org/browse/gtk+/commit/?id=60e0183ac9a56fa0d05971a8cf90798053b430c7
I think I might have filed a duplicate: https://bugzilla.gnome.org/show_bug.cgi?id=668369 However, I did attach a patch.
Created attachment 270515 [details] [review] srgb.patch
The problem is that RGB images without embedded profile are treated as if they have the monitor profile attached. In such cases, the similarity of your monitor profile to sRGB is inversely proportional to falseness of displayed colors. PNG is a special case, which already works mostly correctly, as eog either attaches an internal sRGB profile to such images if the sRGB chunk is present, or builds and attaches an RGB profile based on the cHRM chunk. Only if both are missing does the bug appear. I'm attaching a patch that assumes sRGB color space for RGB images without attached profile. This is the correct and recommended behavior. http://www.w3.org/Graphics/Color/sRGB
Comment on attachment 270515 [details] [review] srgb.patch Index: eog-3.8.2/src/eog-image.c =================================================================== --- eog-3.8.2.orig/src/eog-image.c +++ eog-3.8.2/src/eog-image.c @@ -695,7 +695,11 @@ priv = img->priv; - if (screen == NULL || priv->profile == NULL) return; + if (screen == NULL) return; + + if (priv->profile == NULL) + /* Assume sRGB color space for images without ICC color profile */ + priv->profile = cmsCreate_sRGBProfile (); /* TODO: support other colorspaces than RGB */ if (cmsGetColorSpace (priv->profile) != cmsSigRgbData ||
Created attachment 270598 [details] [review] srgb.patch
Didn't know the W3C recommendation. Since it's apparently working in other viewers, I am giving it a try. Pushed with indentation fixes. commit dfdc1874b09e06d47369d33c2b6bad9f0d664c5c Author: pdknsk <> Date: Mon Mar 3 22:46:19 2014 +0100 Assume sRGB when image doesn't have an ICC profile attached This seems to be no problem with other image viewers and is apparently also recommended by W3C. https://bugzilla.gnome.org/show_bug.cgi?id=554498 --- This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
*** Bug 668369 has been marked as a duplicate of this bug. ***