Create Task
Maniphest T16449

Krita Color Management strategies after compositors getting color management compatibilities
Open, Needs TriagePublic
Actions

Description

Many compositors are going to receive color management features very soon, which will break Krita's own color management. This task is supposed to gather all information about these changes and invite for discussion on how to do color management in the future.

Windows 11

Windows 11 implement (currently optional) feature called "Auto Color Management":

Bascially, Windows 11 implements a color management at the GPU level. The user should provide a custom made ICC profile with non-standard tags, which describes the display with the following traits [see question 1]:

  • color primaries (standard tags)
  • white point (standard tags)
  • XYZ white point adaptation matrix (non-standard tag)
  • custom LUT for the final (delinearized) color (non-standard tag)

There is an application that can convert normal ICC profiles generated with DispCAL into the new MHC2 format: https://github.com/dantmnf/MHC2/tree/master

With these changes, the client application (e.g. Krita) loses all access to the display pixel values and cannot control it anymore. The application can create a surface of any of the following types:

  1. sRGB 8-bit
  2. scRGB 16-bit FP (with extra range available via negative values) [see question 2]
  3. Rec. 2020 PQ 10bit

This surface will later be converted into the "canonical composition color space (CCCS)", which is scRGB with negative values, composed with other windows/applications and then fed to the display calibration pipeline. All the conversions are performed with Absolute colorimetric intent, that is, all the values outside the destination range are just clipped [see questions 3, 4, 5]

Questions:

  1. Is this format enough to do proper color management for a display? (should we ask people from DispCAL for that?)
  2. Does LCMS actually support this extra range of scRGB available with negative values?
  3. Can we actually do any color proofing with this pipeline? How should we do that? Will it involve extra color conversions and how many?
  4. Will we lose any precision because of the clipping in the "calibration pipeline"? I guess we are now locked in "Absolute colorimetric" intent (unless the user adjusts that via a different king of profile, though I have no Idea how)

Wayland

Wayland is going to do something like that, except they plan to pull the entire LCMS into the pipeline and allow ICC-tags for the surfaces (I have no idea who needs that actually).

They both plan to do the same thing and none of them plan to allow any kind of pass-through or raw surface modes, which will cause exactly the same problems and with Windows 11 (and the same troubles)

dkazakov created this task.Jun 1 2023, 3:02 PM
woltherav added a comment.EditedJun 1 2023, 3:29 PM

Windows questions:

  1. scRGB is somewhat controversial because it is 80% imaginary numbers, and I'm pretty sure every color management person you will talk will be very sad about its central role in the windows color management pipeline.
  2. Yes, it should, see this paper on lcms' unbounded mode.
  3. I imagine that all we can do is create a proof from image space -> proofing space -> scRGB and sent that to windows, and accept that it is out of our hands afterwards.
  4. I think for win 11 we'll have to make clear that perceptual and saturation rendering intents will not be supported (perceptual and saturation would need to be applied after windows is done compositing which we have no control over). This is also not much of a problem, because to have good color accuracy, you'd want to use absolute or relative colorimetric intent anyway, with absolute being preferred (because that mimics paper color... in theory, sometimes absolute is the exact same as relative depending on the implementation), so for color accuracy on the screen this is fine. (As far as anything involving scRGB is fine... >_> )

For wayland, we'll have a discussion coming monday. I think we should make clear that all we're worried about is that if both Krita and the wayland compositor are 100% spec compliant, is it still legit for us to complain about it being slow (because the compositor has been set up in such a way that it is doing double the amount of work). There might just be a simple culture difference here, where lag is always a bug, we'll just have to ask. I think the Wayland situation is far less troublesome than the Windows one, tbh. For one, it doesn't center scRGB.

dtorop added a subscriber: dtorop.Jun 4 2023, 1:08 AM