Display Profile

The option “system display profile” is the preferred setting when working with a calibrated display

I’d think the option “none” would be preferred as the system has already applied your display profile.

I’m guessing most people using dt have calibrated their displays and I’d guess that pretty much all of them have their display profile applied system wide. So anything on the monitor has the display profile applied; Including dt. So if you then apply that profile again in the software, it all starts to look a bit wrong. For me this mainly affects the shadows making them to light.

I find sRGB works best as the display profile, maybe because my monitor is close to sRGB? But it would be nice to have a “none” option as seen in other software.

No that is not how it works, the system already applied the VCGT calibration curve but that is only part of the full profile (and theoretically that part could also be done in SW). Even if the desktop supports full color conversion[1] there are often ways to bypass it since for color critical applications it is often better to do it in the application (since only the application has full knowledge about what it needs to do)

If things look wonky your profile is probably wrong or seeing as you say that sRGB looks fine you might be on MacOS (GTK/Cairo bug) but I think darktable already has code for that situation.

A none options wouldn’t do what you think it does, it would just handout the non-color corrected to the desktop/OS, this would also be wrong on MacOS since it (when using Cairo/GTK) sRGB.


[1] AFAICT only MacOS supports does this currently we are working on getting it in Wayland, note that GTK currently has a bug in MacOS meaning it only supports sRGB output

I’m on win7 btw.

Well, what I think a “none” option would do is make my images look like they’re supposed to; As they do in gimp, rt, firefox, etc.

If the system isn’t applying the full profile, that’s fine. I still prefer something that looks right over something that looks wrong.

If the sw could override the system’s application of the profile and apply it more fully then great! But that’s not what it’s doing. It’s simply applying the profile on top of what the system has already applied.

Only gimp is color managed in the above example[1], also a none option wouldn’t work for darktable since there are a couple of modules that work after setting it to output profile. On top of that a none option does not make the picture look like it is supposed to do, it would look like no color management took place (or to put it otherwise as if your working profile is your display profile this is a bad idea)

As far as I know windows 7 does no full screen color management so this shouldn’t be happening, I think your display profile is probably wrong. If I am wrong and windows is fully color managed then this is again a bug in cairo/GTK

To re-iterate a none option is not what you want since if the OS is applying a display profile it will probably do so from sRGB (without further info from the application) meaning you are working in sRGB so why not tell your application that or worse you are now effectively working in display space with won’t be a nice working profile and will lead to a bunch of issues. If a display profile is double applied this is a bug and the current workaround is to set sRGB as output (this is also the case for gimp and any other application, none is a bad idea).

In short a none option will not make the colors look like they are supposed to look


[1] Browser color management is fairly complex discussion but since a) a lot of sites strip EXIF information (including color profile) and b) it is not complete it boils down to effectively not being color managed at all.

Rawtherapee? But the point is you have a “none” option in these which is selected by default and they show images as they’re supposed to look (with the help of the os colour management of course).

We’re talking about the display profile here, not the output profile.

Win7 is colour managed. We wouldn’t be having this conversation otherwise. :wink:

Selecting a display profile doesn’t select that profile as a working profile.

But it does.

Sorry missed raw therapee there

True that is indeed a mistake

According to the information I have found win7 isn’t but I don’t use win7 (I use linux) so I might be wrong, information on this is rather hard to find.

It effectively does since there is no transform from working/output to display that should happen when a proper display profile is set. In the case of full display color management it will require a way to communicate the working profile to the OS if that isn’t the case the OS will fall back to a default most likely sRGB, in that case you are effectively working in sRGB (since the transform is sRGB → display)

If you would select none it does so effectively since now you don’t have a working → display conversion anymore (again unless you have a fully color managed desktop in which case you most likely have sRGB → Display).

If it does then something is either horribly wrong with your workflow or your output profile, might I suggest looking at your images on someone else computer, you will probably be surprised.

I don’t know where you found your information but I use win7 and I’ll say it again… it is colour managed.

“Working profile” and “the profile I’m visually working in” are two different things. I am visually working in 97% sRGB but that isn’t the working profile that dt is using under the hood.

I don’t know the techy details but from the sw’s pov it’s the same as if I hadn’t calibrated my monitors. The os does the colour correction.

Frankly, I don’t know why you can’t see the simple logic here. The os applies the display profile and the sw also applies the display profile resulting in the display profile being applied twice.

Okay fine, lets assume windows 7 is fully color managed[1], you still don’t want a none option

Normally yes but if you don’t have a working profile → display profile conversion the distinction disappears and effectively you are now working in the display profile irregardless of what you actually assigned (since it is pushing those pixels directly to the display without conversion), note this is only the case without fullscreen color management. Now according to your information windows 7 is color managed in which case a color conversion happens, since darktable (and GIMP, and I believe rawtherapee) don’t tell windows what their working color space is (there is no way to do this currently with GTK/cairo) you will get an sRGB ->display profile conversion, this is only right when the working profile is sRGB

What happens in an uncalibrated/unprofiled scenario is undefined with regard to color management, a none option effectively disables color management (in application) those are 2 different things. OS doing color management is also different from the above 2 options since unless an application tags its outputs (darktable doesn’t do this) the OS has no way to know what it is and has to assume something most likely it will assume sRGB.

It is not nearly as simple as you make it out to be assuming you are right in that win7 does color management your best bet is to set display to sRGB for all applications that you believe do a double profile, anything else won’t do what you believe it does.


[1] Under the hood darktable uses cairo which in turn uses GDI, according to this CreateDIBSection function (wingdi.h) - Win32 apps | Microsoft Learn no color management is done here (see ICM under Remarks). So maybe it is a bug in windows :wink:

Okay, gonna step out into what I maybe don’t fully understand, but I don’t think any OS at this time does “color correction”. That would imply that application software was delivering the color metadata associated with the pixels being displayed to the OS, and the OS was doing the “cmsTransform” (borrowing a LittleCMS function name).

That your display hardware looks nice with sRGB data imposed upon it is a fortunate thing. Mine at home is like that, and indeed has a “sRGB” setting that seems to closely align with the sRGB profiles I have handy, and my calibrated display profile gamut as plotted xy is pretty close. But I go to work and try the same and it fails horribly, two displays side-by-side that are set to be sRGB, and they render markedly different in both color and tone.

I don’t think a (none) setting in darktable is a reliable way to do what you’re looking for. For that, I’d consider going to the OS and removing whatever display profile is designated, so that neither it or the hardware LUT is in play.

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).

1 Like