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.