Display Profile

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:

  1. it does indeed do nothing but I don’t think so (otherwise other people would have noticed wonky colors before now)
  2. 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

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.

3 Likes

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

4 Likes

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 ?

2 Likes

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.