Big reply to everyone in a single post ahead.
Well, kind of. The pipeline looks roughly like this:
For raw files, the data is in the native format (bayer, X-Trans, …) up to demosaic
, after that it’s in camera rgb. Regular images are in their original color space (sRGB, AdobeRGB, XYZ, Lab, …).
In input color profile
all colors are transformed to Lab and stay that way up till output color profile
. There the image is converted to either the display profile or the export profile, depending on which pipe is running. In the very end the data is then converted from float to whatever the output medium needs.
So there are basically three “working profiles”, the one used for most modules is Lab, and the other two depend on the file and output. There are plans to replace the final parts of the processing with a fixed RGB profile, most likely linear Rec.2020, and then a final conversion to the output profile, but that’s just an idea so far.
That is what cairo currently tries to do and fails with on OSX since Apple broke their API.
2 and 3 are kind of the same, and are definitely what needs to happen some day. At least once
gets resolved. By then GTK+ needs a way to tag widgets with a color profile or alternatively tell it to leave areas of the screen unmanaged. But I don’t expect that to be a pressing issue for years, given how Wayland people deal with this.
That would be awesome. As a first step, could you try using CGColorSpaceCreateDeviceRGB()
and then copyICCData()
on the result and share the ICC profile with us? Please make sure that you have some display profile configured system wide that is NOT sRGB first so we can actually distinguish it.