You seem to confuse some things there. DispCal, gnome-color-manager, colord-kde, xiccd and all the others do two things: they load the VCGT (the gamma curve) from a profile into the graphics card and provide a way for applications to retrieve the system display profile by putting it into the _ICC_PROFILE X atom. In the case of colord based solutions they also tell colord, a system daemon that acts as a database for color information, about the profile, so that applications can get the profile that way. Once Wayland will be used something like colord is the only way as the X atoms will most likely stop being supported.
Now you have a display that is correctly gamma corrected, that means that brightness response is as intended. However, that is only half of what display color management is doing. For full support every application has to query the system display profile (or let the user set it manually, doesn’t matter in the end) and use that to transform the input pixels to the display’s color space. Only with gamma changes from the video card AND the application’s color transforms together you will have correct results. The rendering intent btw. is part of the latter step that is done in the applications. The gamma shaper has nothing to do with it.
When I said that the application has to transform the colors there are two parts involved. First it needs to be able to extract the image’s color profile or determine its color space otherwise (some image formats don’t require a full profile embedded but have a simple flag for some common and well known color spaces like sRGB and AdobeRGB). Then it has to be able to somehow get the system’s display profile. With these two pieces of information it is able to transform FROM the image’s color space TO the display’s. Unfortunately some programs only support half of that and assume (for example) sRGB for the other. So instead of proper color management they always assume images to be sRGB (when only the display profile is supported but not the image’s which is quite rare) or treat every display as being sRGB while supporting image profiles (which is the common case, for example gwenview ignores display profiles while supporting image profiles). The only benefit of such a program is that you can compare images to one another when they have different image profiles. You are not able to assess the real looks of it though.
Rendering intents are a third feature on top of that which defines how to treat image colors that are not representable in the display’s color space. When showing sRGB images on a wide gamut display that doesn’t matter at all as all colors can be shown. Looking at AdobeRGB images on an sRGB display (or one with an even smaller gamut which is quite common with laptops for example) you DO want to be able to configure the rendering intent.
Sorry for the long post. Feel free to ask for details if anything is unclear.
Tobias
PS: When using more than one monitor the situation gets a little more complicated as there is more than one system display profile now. In short, colord will just work in that case while the X atom approach needs some hacky extension.
I do let DisplayCal install system-wide, but there are multiple possible reasons why someone would not want that. For example because doing so will prevent them from being able to manually select a monitor profile in digiKam, and because they might prefer to use color management systems such as Colord or Oyranos instead.
One does not “install color management”.
Nothing will be color-managed if it does not support color management. What may happen, if one sets DisplayCal to do so, is that the calibration curves will be loaded into the video card gamma table and so change the colors in the whole X system, but that is just one piece of the puzzle and does not alone constitute correct or complete color management.
On Windows, in RT, at the bottom of the preview part of the window, I have boxes to choose profile (I guess monitor profile) and rendering intent. I don’t have those in my KDE / Linux. There’s nothing there. Should I have it?
I tried to turn on color-management, I have enabled color correction in composer settings, but when I turn on qcmsevents, the tray icon remains grey, not colored.
EDIT: I have just found that: “Kolor Manager currently does not seem to be working with Plasma 5 even with Git version”. That’s not good for KDE…
@dr_Fell from within RawTherapee go to Preferences > Color Management (from memory, maybe I got the name of the tab wrong) and set your ICC profile folder. Then, after restarting RT, you will see entries in the monitor profile combobox beneath the preview in the Editor tab.
Ditto for Oyranos and colord last time I tried them, but you don’t need them. Installing a profile from DisplayCal loads the calibration curves into the VCGT and sets the _ICC_PROFILE atom for you. For correct color management, the calibration curves must be loaded into the VCGT and you must select your monitor profile in the combobox under the preview in RawTherapee’s Editor tab.
Optional step:
To verify that the calibration curves are loaded into the VCGT, run
“argyll-dispwin -c” (or just “dispwin -c”)
Your whole screen should instantly look different. If it didn’t instantly look different after running that, it means the calibration curves weren’t loaded. Run
“argyll-dispwin -L” (or “dispwin -L”)
to load the calibration curves from the default profile (the one DisplayCal installs becomes the default) into the VCGT - your screen should look instantly different.
True after a fashion however one might install little cms and also in the case of dispcal Argyll Color Management System. This can also cause none colour managed packages to become colour managed. The thing that surprised me about these is that they all work happily installed on the same system and all show exactly the same monitor profile.
I only use absolute colourmetric.
In terms of RT I have never noticed an internal method of causing it to select a particular display profile. This may be 'cause I only use the editor interface via right click open with. However I do know that my monitor profile is being used also by a couple of none colour managed packages that I use regularly.
As my current version of Firefox doesn’t handle my LUT correctly I have to turn colour management off in it other wise it reads the rgb values incorrectly. Once it’s disabled the colouring is correct and also matches everything else I use.
I’m a bit concerned about the KDE plasma problem mentioned but assume that DispCal will sort that out for me by installing system wide. I have been holding back on upgrades due to concerns of this nature but can’t for much longer.
One does not install colour management?
As my current version of Firefox doesn’t handle my LUT correctly I have to turn colour management off in it other wise it reads the rgb values incorrectly. Once it’s disabled the colouring is correct and also matches everything else I use.