My displays are not set to sRGB, they’re calibrated and cover much of the sRGB gamut. I set the display profile in dt to sRGB because it works.
So the os gets image data with bad colours and turns them into good colours… that sounds like colour correction to me.
The OS is just getting whatever your software delivers as an image and blatting that to the screen. The only “correction” available in that part of the pipe is the hardware LUT loaded into the video card, if your display profile had one for the OS to load.
I’ll leave describing the specifics of that to folks more knowledgeable of such. As an application programmer, what I do know is that in Windows, display “color management” is about Windows telling me what profile to use for display output. And I write the code to do the color transform before rendering the image…
Glenn,
Time to show your flowchart again?
/Claes
That still sounds like colour correction to me.
I’ve done a little coding myself and all I’ve had to do for the display profile to be applied to an image is print it to a window. The cms does the rest.
The calibration curve (that @ggbutcher is talking about) is officially not even part of the color profile although it is often stored in the VCGT tag, it is just there to make the display profile a little bit nicer.
Anyway which API did you use to to print an image to a window? Since I am pretty sure that is not the one darktable (actually GTK/Cairo) is using, to one they use should actually bypass the windows CM (if it doesn’t do that, that is actually a bug!)
When you did such in code, did you do it with a function call that communicated the color characteristics, also known as “the profile”, of the image you provided? If not, then the OS doesn’t have the information it needs to change anything with respect to color. That hardware LUT can’t do this by itself, it needs the preparatory work of the application software’s color transform as the input for what it does.
My point is that the conversion from dt’s internal colorspace to display is not so simple as you’re thinking, and depending on the profile, part is done in the application, and part may be done in the video card. To reliably remove that from the pipe and just send whatever dt has internally to the display, you need to remove the display profile from the OS, so it doesn’t load the LUT into the video card AND it doesn’t make the rest of the profile available to dt…
The Wayland color managment thread is the only discourse I know of about including what you think is going on in an OS, and they’re a good ways away from having an implementation…
I wrote this a few weeks ago:
In the graphic, the “Convert to Display Profile” is what we’re teasing apart here.
Win32, no profile info. I wasn’t colour managing it, the system was.
Nobody’s saying the colour management process is simple. Just that when the system is colour managing the displays, then colour managing again on top of that produces wrong colours. Gimp and rt do fine with a “none” display profile.
It is what it is.
If you don’t pass in any profile information the system can’t color manage, so either the system got it from the file you loaded, or it displayed the wrong color. It would explain a lot more if you told us which API you used.
Yes everybody agrees that doing color management double is wrong, but it is also wrong to have a none option since that option either bypasses color management and since the application doesn’t tell windows what color space it is in[1] you will get wrong colors (e.g. prophotoRGB gets converted as if it was sRGB) or the application sneakingly assumes sRGB anyway and you get right colors but in that case none doesn’t mean none. Either case is bad, so giving a none option in my mind does not make sense.
All in all I would say set your display to sRGB since according to you that works (which it should, this sounds very similar to the cairo/GTK bug on MacOS). The proper solution is to make Cairo/GTK handle color management better this will not only fix this, but also the MacOS bug and will be needed for Linux in the future with color managed wayland. Adding a none option is not the right solution!
[1] Cairo/GTK doesn’t have an option for this
Sorry, I never noticed anyone agreeing that…
Colours are fine from gimp, rt and other app’s without sw colour management.
Dt works fine with no display profile installed producing consistant (if not perfect) colours. Why can’t it just do the same when there is a display profile installed and leave colour management to the system. And don’t say it needs a display profile to convert etc. It doesn’t need one when there isn’t one.
Because doing that is wrong from a color management perspective, I don’t know why gimp/rt/etc do display correctly since I don’t have time to go trough their code but my suspicion would be that none actually means sRGB. Also for various technical reasons you don’t want to leave the color management to the system for color critical work but want to bypass the systems one (MacOSX supports this alas this is not exported via Cairo so darktable can’t use it and I bet Windows color management also supports this but probably again not exposed via Cairo).
And yes programs do need either a display profile (if there isn’t one we need to assume either working space is display or display is sRGB second option is probably better) or we need to tell the system our working profile (and rendering intent and if we want to use blackpoint compensation).
Thats exactly what macOS does. (I don’t know about Windows or Linux).
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.
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?