Display Profile

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

Cheers agriggio

Also seeing this it seems Cairo/GTK on moderns Windows (7+?) as it has on MacOS X, probably will need some further investigation tough since the functions used should bypass the system CMS (but that was tough of the MacOS X functions as well).

This needs to be fixed since otherwise rolling out full system color management on Wayland will show the same issues.

Everything I write here may be entirely wrong, as ever since I delved into color management I forget even my own name, but as far as I know it’s correct.

What “color managed” here means is that the monitor profile is made available to programs which know how to use it (IIRC Windows uses an environment variable for that), and that the gamma calibration curves (if the ICC profile has them) are loaded into the VCGT (video card’s gamma table). Loading them affects everything you see on screen, everything changes, so you might be mistaken into thinking that everything is now color-managed, but that is not the case! The gamma curves get you only part of the way there.

Calibrated != profiled, two different things. Calibrate = tweak the knobs or press the buttons to get things (white point, tone curve, color balance) into the right ballpark, and optionally conjure simple gamma curves (1D LUT) which can but don’t have to be stored in an ICC file, which are to be loaded into the graphics card’s gamma table and therefore affect everything. Profile = feed the monitor a reference color, measure the result, document the difference, and store a matrix or LUT in an ICC file to correct for that. Color-managed programs can use the matrix or LUT from an ICC file to correct the colors.

As you see, the ICC file can contain multiple things, some of which (the calibration curves which get loaded into the VCGT) affect everything you see on screen, and others (matrix/LUT profile) which do not, and instead must be handled on a program-by-program basis.

If at the time the ICC profile was created there was a non-linear curve in the VCGT, then the same curve must be loaded into the VCGT AND the program in question must use the matrix/LUT profile for colors on screen to be correct. Using the calibration curves alone, or using the profile alone, will not result in correct colors.

This seems to be where you’re getting stubbornly confused. Just because an ICC profile is “loaded” in a color management system (Windows Control Panel, colord, DisplayCAL, etc.) does not mean you now have correct color everywhere. All that happens when you load this profile in a CMS is that the calibration curves are loaded into your VCGT (and so all colors on screen change, but are not correct yet), and some sort of standardized pointer is set (_ICC_PROFILE X11 atom, environment variable, etc.) which allows color-aware programs (RawTherapee, darktable, GIMP, etc.) to find the ICC file and to use it.

RawTherapee falls back to sRGB when using “Monitor profile: None”.

Get an ICC profile with inverted colors, such as this one: cms/bgr-test.icc at master · haasn/cms · GitHub
This profile swaps the red and blue channels, so it will be immediately clear whether it’s being used or not. It has no VCGT calibration curves (i.e. linear).
Apply it the same way you should apply your monitor profile, and you will see just how color-managed your system is.


You’re believing this because you’ve told the application to convert to sRGB for display, and your display hardware gamut happens to be close to that, and all looks good on the screen. And, I’d be suspect of your display profile, can’t tell for sure from the discussion but it may be ill-formed. @Claes, I really need to write that colorspace transform missive…

Really, really, really, there’s no further color conversion going on in your OS. Let’s clarify that:

  • Windows: no.
  • Linux, no, not yet, but go read the Wayland Color Management thread.
  • MacOS: apparently yes, I don’t have one so I’m not going to assume anything about how it works

So do we all have to explicitly say “my display is calibrated and profiled” or can we do without the legalese…

Thanks for the run down.

This partial colour management was mentioned earlier and as I said then, that’s fine. You say the colours are not right yet but to the naked eye they are. And if that’s just the gamma curves then they do a pretty good job. Images in the colour managed app’s and non-colour managed app’s are practically identical. (except windows photo viewer :grinning: )

MacOS loads the VideoLUTs and tags the display space with the installed profile. The only thing it does differently is to (by default) run all the application display pixels though the CMM. If the application does nothing, the pixels are assumed to be sRGB and color managed appropriately. For true color management to happen though, the application has to tag the pixels it is sending to the display with the source color space, just like MSWindows, X11, or any other color managed system.

The key point in this discussion seems to be the age old one that 99.99% of people who learn about color management for the first time assume that a profile is “color correction”, somehow magically “fixing” the color to be “right”.

Of course the reality is more nuanced than that - a device profile does not contain a “correction”, it contains a description of device behavior, so that color conversions (i.e. “corrections”) can be created on the fly between any two colorspaces by a CMM. For color management to happen, two profiles are involved. The applications have to supply one of them (source), and the OS supply the other one (destination/display).


Well, the key point for me is that the purpose of this discussion is lost in technicalities that are not necessary.

To summarise:
The display profile is applied twice.
A “none” or sRGB display profile choice avoids this.
“none” is effectively sRGB.

Well, if you think you understand it so well, why pose a question here and then offhandedly disregard everything those with a clue tell you ?


I don’t think I understand it so well… I think I don’t need to understand it so well to solve the issue raised here.

I’m not on top of the concept myself, but this thread started by @ggbutcher has gotten me closer to understanding than anything previous:

Insert your scenario into the diagrams in that thread and it may help.

1 Like

@Marctwo just wants a (none) alternative for setting the dt display profile. That would probably solve @anon41087856’s angst regarding filmic’s need to compensate for such.

I’m actually ok using sRGB especially after reading that rt’s “none” falls back to sRGB.

My main concern though is that others may be experiencing this issue without realising as dt (unlike gimp, rt) sets the system default profile by default as well as recommending it in the manual.

I have had suspicions that dt pipeline’s lead to apply the display profile twice for a long time, but assessing what you see needs a reference, and finding one is not trivial. You need to know every step of the pipe (app CMS, OS CMS, GPU driver VCGT, screen DAC), and since the doc is always scarce and practically useless, well… nobody does that.

But, again… Your average FOSS dev wires whatever CMS to his broken soft, and then claims it’s color-managed, even if nobody understands what’s going on in said CMS and next in the pipe, except maybe the CMS’s dev (that’s like 3 people in the whole opensource community). So… app’s devs try to figure out the CMS, CMS’s devs call app’s devs ignorant, and TL;DR ICC backfired because it wrapped linear algebra into black magic in such a way that it’s now faster to code your own CMS for your particular pipe than trying to strip down whatever CMS (assuming you are looking for reliability, otherwise CMS are a bliss and allow you to do wrong things in no time).

Hence Open Color IO.

Basically, ICC stuff is messing with your images encoding (display characterization) and, typically, with your video card gamma tables (VCGT → display calibration). VCGTs have many problems, being on Windows or Linux. First of all, they often get ditched randomly, because of the GPU driver, because of the system CMS, when you hot-plug or unplug an external screen, or because of a challenging planets alignment. Then, they behave inconsistently in a multi-display setup. Finally, you actually don’t know what is being corrected by the calibration or by the characterization. So, using dispcal GUI, you might skip the calibration (and VCGT build), and directly to the characterization, so you never rely on the flimzy GPU stuff (assuming your screen is not of the super-blue laptop LED kind).

So, you have 2 choices here : faith or wrath. Pick one.


I’m working on an OCIO tool for rawproc, and I don’t see any attention paid to this in that library. One just manually transforms to one display at a time. Or (likely), am I missing something?

lol. Yes, I’m afraid one of them is.

It occurred to me that if windows is only loading the calibration data (as suggested earlier) then it seems it must be this data that is applied twice. If so, shouldn’t these app’s only be applying the profile data? Shouldn’t they just ignore the calibration data in the icc file?

Maybe I need two profiles; One with calibration data for windows to load and one without to use with the app’s. I need to read a bit to see if/how I can exclude calibration data from the output files with the argyll tools.

A little digression. Make sure you disable features like Night Light (or f.lux) and HD Color (win10). Sometimes I forget about Night Light and it messes with my colours. Also, it is possible that it doesn’t return to the proper calibrated or profiled state!

In general, colour management “exists” in Windows but it is very tricky to get it right and working. Hence, I don’t bother and maybe I am lazy too. :stuck_out_tongue:

It shouldn’t need to check the source code to be sure but if that is the case that is definitely a bug.

If the bug you mentioned above is indeed present then this would be the workaround, but I still suspect that we are having a similar issue as is seen on MacOS that has been silently introduced into windows somewhere/sometime.

That’s not something that happens casually - (as a developer) you’ve got to really work hard to make a bug like that !

It’s certainly frustrating when applications try and cover up what they are doing, so as “not to confuse the user”, making it hard to diagnose problems in workflows. But isn’t darktable open source ? It should be possible to poke around in it and figure out if there is a bug.

A systematic, scientific approach is best in diagnosing color workflow issues.

Re-inventing the wheel may be a great way of understanding how to build wheels, but it’s not a great way to get from A to B when a vehicle and highway are already waiting for you.

For all its warts, ICC color management for output devices such as displays is very mature. Well proven free libraries like lcms, lots of applications that support it, and a huge body of knowledge about how it works and how to use it (tons of books, articles, and even people to ask if you get stuck).
Yes, color management can be hard to get you head around if you haven’t come across it before, but like anything technical, all it takes is a little effort.

Well, no it’s not. Embedding display setup encoded in a profile is an Apple idea - it’s not part of offical ICC. But setting devices to a good working state and making sure they stay in that state is all part of the process needed before making profiles. Taking advantage of common system capabilities to automate some this often tedious and error prone aspect is a good thing.

Not really. Most of the time people sort their systems out so this doesn’t happen.

I don’t know why you think that. Modern systems like XRandR are multi-monitor aware. MSWindows and OS X have ben multi-monitor aware for some time.

Yes you do - a characterization never does correction. The whole point is that profiles are used to create color space transforms on-the-fly. There is no “correction” - instead, an encoding in one colorspace is changed to an encoding in another, with the aim of preserving the color values. Neither the source space nor the destination space is correct or incorrect, they are just different encoding with different limitations. Thinking about this as a “correction” will lead you to grief.


Something that’s confusing me in darktable is when I change the display profile the historgram changes. This shouldn’t happen, right?