Darktable 5.4 might under wayland apply color profile twice

[eburema]

I might be reading the code wrong but I think #19646 might be doing the wrong thing, if it is running under a wayland compositor with the color management protocol enabled. This goes wrong since wayland color management is by design full screen (this is necessary to make SDR/low gamut applications look good on HDR/wide gamut monitors)

How it goes wrong:

• darktable queries colord and gets an output (icc) profile
• darktable uses that profile to render the buffer out in display color space but does not use the wayland color management to tell the compositor it is doing so (<- this part I'm not 100% sure about since that depends on GTK stuff I'm not familiar with)
• Since the compositor is unaware that darktable is doing any color management it will assume the buffers are in sRGB and will wrongly do an sRGB to Display transform

As can be seen from the above sequence this will apply an unwanted color transform, provided darktable is running on wayland and the wayland compositor supports the color management protocol. I see a couple of ways around this:

• Use the color managment protocol I think in particular wp_color_management_output_v1 and wp_color_management_surface_v1 are worth a look in this case (the first to replace the call to colord, the second to make the compositor aware of the surface colorspace)
• If the above is not possible the next best option is to set the display to be sRGB and let the compositor handle the rest (of course a user override is desirable here), this will have the effect on not really be able to use wide gamut monitors but at least should keep the colors (mostly) correct (since on a wide gamut monitor sRGB to Display transform should be a no-op mathematically speaking).

I hope I'm wrong here and this issue can just be closed

[TurboGit]

I'm not saying that we are not doing things right, but when I have implemented this it seemed to me that the profile was properly applied and the color ok. Do you have evidence that the Darktable is not displaying properly some images?

[eburema]

I'm not saying that we are not doing things right, but when I have implemented this it seemed to me that the profile was properly applied and the color ok. Do you have evidence that the Darktable is not displaying properly some images?

I'm working on a proof on concept but so far ran into issues that gnome color management seems to be kinda broken - at least for me, gnome disables full screen color management in VMs (or anything that doesn't have a gamma curve on its CRTC), and also seems to disable it if any monitor has a profile that doesn't include a VCGT (making it kinda useless in case you only profiled but didn't calibrate) - on KDE it is probably less of an issue since kde doesn't use colord at all (at least for its wayland color management). I have a hunch (though sadly can't confirm it yet) that the reason you didn't see anything strange is due to this gnome brokenness

[TurboGit]

Indeed, I'm on GNOME and using colord. Thanks for looking at this.

[eburema]

Small update might do a larger write up of this when back from holiday but in short Gnome is doing doing the wayland color management wrong in a way that benefits darktable in this case. In short so far with my testing gnome only loads the VCGT into the video card and doesn't do anything else this is in contrast to KDE that not only loads the VCGT but then also applies the rest of the profile for any non-colormanagement aware applications. They way KDE does it is intended behavior with how wide gamut displays are becoming more available (most people probably don't like it when everything is over saturated suddenly when they buy a new screen and/or put screen in HDR mode), and gnome is thus kinda broken (though again in a way that benefits darktable in this case).

I've tested this with a profiles that swaps red/green channels, and/or decrease the blue calibration in the VCGT.

tldr: For now darktable is fine, on KDE colord isn't used for colormanagment in wayland (the colord-kde plugin/addon is in fact bit rotting and only compatible with X11), and under gnome it currently broken in a way that benefits darktable.

Not sure if I should close this issue?

[dhoulder]

Not sure if I should close this issue?

I vote to leave it open. If the only reason we're not seeing problems is because some other software (gnome) is buggy, then the problems will reappear when those bugs are fixed.
In https://wayland.app/protocols/color-management-v1#wp_color_management_surface_v1:request:set_image_description we have…

By default, a surface does not have an associated image description nor a rendering intent. The handling of color on such surfaces is compositor implementation defined. Compositors should handle such surfaces as sRGB, but may handle them differently if they have specific requirements.

… which sounds to me like a well-behaved Wayland compositor with color management enabled will assume darktable is rendering into sRGB because we're not indicating otherwise and will then translate that into the monitor colorspace.

on KDE colord isn't used for colormanagment in wayland

Presumably in KDE monitor profiles are managed by something other than colord? Won't kwin still assume the darktable surface is in sRGB and then convert that into the monitor colorspace, no matter how that monitor profile is obtained?

[eburema]

KDE it is managed by kscreen (on the cli can be queried via kscreen-doctor), and then applied in kwin. So really depends on what darktable does when it doesn't find a system profile via colord (assuming running under wayland so no xatoms available) if it defaults to sRGB things should work out mostly fine (since KDE does indeed assume sRGB). Setting the display to be sRGB explicitly in darktable should work as a workaround if that isn't the case.

[MichaelVarvarin]

So really depends on what darktable does when it doesn't find a system profile via colord (assuming running under wayland so no xatoms available) if it defaults to sRGB things should work out mostly fine (since KDE does indeed assume sRGB).

Darktable under KDE seems to default to sRGB, even though color rendering is a little bit different from Chromium with sRGB tagged images (I'm using Chromium as reference since it fully supports Wayland color management).

However that is still an issue since it requires you to disable color management in KDE if you want to edit in wide-gamut.

[wilecoyote2015]

This issue is also very relevant for Hyprland: native ICC support is landing here and it supports the Wayland color management protocols ( hyprwm/Hyprland#12711 )
Here, we have exactly the situation where the display transform is applied twice:
You provide the ICC profile for you display in the Hyprland config. Hyprland then transforms the rendered colors from the respective client's color space for the display.
If the display profile is also applied by darktable, it is applied twice as Hyprland does not get the Information that the client darktable already provides the pixels in display space and assumes sRGB.
The correct pipeline, as far as I understand, would be that darktable does the transform and passes the info about the used color space to Hyprland via the protocol, so that Hyprland does no tranformation for this client.

For now, there is some Workaround if you use Hyprland:
Set

render { 
    cm_fs_passthrough = true 
}

In Hyprland config. This will cause Fullscreen applications to bypass Hyprland color management. So you need to run Darkable in Fullscreen and use the display profile as usual in darkable. This way you get correct color rendition of your other applications while still using proper color management in darktable.

[Zamundaaa]

Your interpretation of what's happening looks correct to me, and that's exactly why we dropped colord support in KDE Plasma. Afaik Gnome 50 also comes with full color management support, so this will also stop working on Gnome.

Use the color managment protocol I think in particular wp_color_management_output_v1 and wp_color_management_surface_v1 are worth a look in this case (the first to replace the call to colord, the second to make the compositor aware of the surface colorspace)

You should not use wp_color_management_output_v1 if it can be avoided, wp_color_management_surface_feedback_v1 is for getting the best image description for a surface (and with that you don't need to track outputs either).

Note that only one wp_color_management_surface_v1 can exist per Wayland surface - if GTK creates its own color management surface, it will crash. It's completely safe to assume GTK 3 will never do that, but I just wanted to mention it for the future: if Darktable is ported to GTK4, you'll either want to switch to using GTK4's color management APIs, or have some API in GTK to make sure it doesn't create a color management surface.