GNOME Bugzilla – Bug 739989
Incorrect display colour management
Last modified: 2014-11-23 21:31:35 UTC
Gimp displays incorrect colours, both with colour management on and with colour management off. To be more precise - I believe that the OS does an unwanted colour space conversion and Gimp needs to work around this. OS version 10.9.5. I believe this bug is specific to Mac OS. Steps to reproduce the problem 1. Create an image containing three coloured areas, with colours (255, 0, 0), (0, 255, 0), and (0, 0, 255). Save two versions of the image, one with sRGB profile embedded and one with Adobe RGB profile embedded. 2. In System Preferences > Displays > Color select Adobe RGB. (If you cannot see Adobe RGB, uncheck Show profiles for this display only.) The change occurs immediately. 3. Launch Gimp and set the colour management preferences as follows: Color managed display RGB profile sRGB Monitor profile Adobe RGB Display rendering intent Relative colorimetric File open behaviour Ask what to do 4. Open the two image files created in step 1. If you are asked whether to keep the profile or convert the image, choose Keep. Use DigitalColor Meter, set to native values, to read the RGB values sent to the display. (In /Applications/Utilities). The expected result is sRGB profile (219, 0, 0), (144, 255, 60), (0, 0, 250) Adobe RGB profile (255, 0, 0), (0, 255, 0), (0, 0, 255) The actual result is sRGB profile (187, 0, 0), (183, 255, 83), (0, 0, 245) Adobe RGB profile (219, 0, 0), (144, 255, 60), (0, 0, 250) Note that the actual result with the Adobe RGB profile is the same as the expected result for the sRGB profile. The actual result with the sRGB profile is two successive conversions from sRGB to Adobe RGB (i.e. convert to Adobe RGB, assign sRGB profile, convert to Adobe RGB again). The expected results come from profile conversions done within Gimp, taking results from the pointer readout. 5. Close the image files and set No color management in the Gimp colour management preferences. 6. Open the two image files again. The expected result with DigitalColor Meter for both files is (255, 0, 0), (0, 255, 0), (0, 0, 255) The actual result for both files is (219, 0, 0), (144, 255, 60), (0, 0, 250) We are getting an sRGB > display (Adobe RGB) conversion. More generally, a file with an sRGB profile will be correctly converted for display when colour management is off! 7. Close the image files. 8. In System Preferences > Displays > Color select sRGB. 9. Set the Gimp colour management preferences as follows: Color managed display or No color management RGB profile sRGB Monitor profile Display or sRGB 10. Open the image file that has the sRGB profile. The actual result is the same as the expected result (255, 0, 0), (0, 255, 0), (0, 0, 255) Compare this with the result in step 4 for the file with the Adobe RGB profile: when all the profiles are set to Adobe RGB, the expected result is not obtained. The only way to get the pixel values sent to the display unchanged is to make the setting described in step 8. I suspect that this is what is happening. The display always has a colour profile. By default, the OS creates the profile from the gamma and primary information in the EDID. The OS always colour manages the display. If an application opens an image window without specifying a colour profile, the OS assigns the sRGB profile and then does colour management. This behaviour was new in OS 10.8. Hence we get an unwanted conversion from sRGB to the display profile. Therefore the workaround in Gimp would be: a. Gimp obtains the display profile from the OS. b. Gimp specifies the display profile when opening an image window so that the OS does not do a colour space conversion.
GIMP does get the profile from the OS, that is not the problem. The same color correction is happening twice, but we do need GIMP to convert from the image's profile to something. Please try setting sRGB as display color profile (disabling "from system"), this should cause GIMP to convert from the image's colors to sRGB, and the system from sRGB to the motitor profile.
This is actually a duplicate. *** This bug has been marked as a duplicate of bug 708579 ***