Only if you want to interfere with the display colour management. Everything you paint to the screen in windows has the display profile applied. As mentioned earlier, there may be ways to get around this but that is just standard.
But to apply the display profile we need to know the source profile, Cairo/GTK has no way to hand this over to the system (see the MacOS X bug). Yes I know this is a rather unfortunate decision but it was made in a time when full desktop color management didn’t exists and so the GTK/Cario devs did build everything to be in device/display space (as we say hindsight is 20/20).
To make it clear to do any color management in an ICC workflow you need at least 2 profiles, a source profile and a destination profile, and some meta information (rendering intent). For displaying an image the source profile will be the profile the image is in, with destination profile being the display profile. For an image editor the source profile will be the working profile.
To make use of the system CM you need to tell it the source profile and the meta information, sure it can assume something but as we all know “assumptions are the mother of all f***ups”
PS. As an example of why you would want to bypass the system color manager, ICC profiles support up to 15 color channels since the windows internal bitmaps (well any OS for that matter a buffer with 15 color channels will be very application specific) don’t support this the application needs to do a conversion to get the most accurate conversion it needs to convert directly to display space.
Surely you only need to know the value of each pixel and convert it according to the display profile. You don’t need to know the named space that pixel is from, only it’s value.
Where are you reading this? There’s no such standard of which I know…
If what you assert were the case, why are there differences between how Windows Photos and the old windows photo viewer display pictures in the same running windows instance? One is color-managed, and the other is not.
Really, in Windows the application is responsible for doing the display transform, prior to rendering. @paulmiller, thanks for pointing out that MacOS actually does this… I know what you see in the OS dialogs could imply that’s what’s happening, but really, it is not. All Windows is doing is telling applications where to find the display profile, so they all can be using the same one when they do the transform.
1 Like
Ah yes, the old windows photo viewer. I don’t know what the problem is with it but it does have the display profile applied to it. And when you turn off cms it still shows a very different image than any other app.
Nope, you need to know what that value means (which is what the profile is for) so you always need 2 profiles (since you also need to know what the output means)![1]
As an example saturated green in AdobeRGB and saturated green in sRGB are 2 completely different colors in both cases the value will be (0.0, 1.0, 0.0) for the RGB triplet, if we wanted to convert sRGB to adobeRGB we would need to know that we started with sRGB and that we want to end in adobeRGB. This is also true for the display and its profile.
[1] Okay there is one exception and that is the device link profile but to create one you would first need 2 normal profiles and will only be valid for one color space to one other color space (it is a one to one mapping), these days this mostly used internally in a CMS for performance reasons.
That’s what calibrating your monitor is for. That’s what all those patches are about. It shows a colour, sees how it differs on screen and so learns how to show that colour so it looks right. (simplistic I know 
)
Ok, so what does rt do when no display profile is selected?
Only for your display so after a calibration/profiling you know what (x,y,z) means for your display, but an application is not working directly in display color space (for various reasons) so its (x,y,z) can mean something different. To map this last triplet to the first we need to know what this second triplet means (otherwise no mapping function can be created).
2 Options:
- it does indeed do nothing but I don’t think so (otherwise other people would have noticed wonky colors before now)
- It assumes sRGB
The display is the only thing I’m talking about.
But it is not the only thing that matters
No, there’s life, the universe and everything… But for now I’m only talking about the display.
Yes but to convert to the display you need to know where you are coming from, it is of no use to just talk about the display in color management
That’s just not true in windows at least. You can just paint a bitmap or and icon or text to a window and the display profile will be applied.
That is because windows (or any other full color managed OS) will assume something probably sRGB, not because there is no input profile!
Why isn’t the point. The point is you don’t have to supply a source colour space.
The why is important, without that information you will be stuck with only handling sRGB and can’t handle any other input color spaces, which is a bit sad.
Also checked the code from Ratherapee and with an empty profile it will assume sRGB
Cool, that makes me feel better about just using sRGB in dt then.
hi @Marctwo,
@dutch_wolf is right.
fyi, ‘None’ in rawtherapee means bypass LCMS but still assume the display is sRGB. so, it still does colour management. see RawTherapee/iplab2rgb.cc at dev · Beep6581/RawTherapee · GitHub