Make display and display2 color profiles global

[aurelienpierre]

Currently, the output display profiles are built in colorout module only (in commit_params), and used while computing the pipeline for preview.

In a sensible imaging app, the GUI would also be color-managed, noticeably the hue/saturation sliders or to display illuminants. For this, we need the display profile to be global in darktable, for example in dartktable.gui, and prepared at launching.

Then, a global utilitary would be nice like XYZ_to_display(float XYZ[3], GdkRGBA rgb_out, dt_dev_pixelpipe_type_t type), where type would be DT_DEV_PIXELPIPE_PREVIEW2 or DT_DEV_PIXELPIPE_PREVIEW.

This needs to use LCMS2 since external profiles can be whatever, from 3×3 matrices to 3D LUTs or 3×curves.

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[johnny-bit]

hey @dtorop - this FR and yours https://github.com/darktable-org/darktable/issues/9027 could be a part of whole if possible. Making profiles global and allowing choosers everywhere would be very desireable indeed.

[dtorop]

I'm intrigued.

My idea of #9027 is of limited scope -- just duplicating code to put the same widget currently in lighttable's bottom panel into tether's bottom panel. The widget changes darktable.color_profiles->histogram_type and darktable.color_profiles->histogram_filename which are already global.

What @aurelienpierre is proposing is way more ambitious, but I like the idea. It's a good argument that the various hue/saturation sliders would do better with a reference colorspace. I struggled with this last year on the histogram, and ended up just blindly displaying CSS colors and hoping that they were in the ballpark to the monitor. There's dt_XYZ_to_Rec709_D50() code now for vectorscope, which is really just crossing fingers and hoping the displayed color has some relationship to the intended color. XYZ_to_display() would be far preferable. Part of the idea of #9052 is to do some compositing tricks in display space to make unprofiled graphs look good on a variety of screens.

One reason this could be very nice: Right now colorout converts to display profile in the full/previewpreview2 pixelpipes, which makes all operations post-colorout in preview (e.g. scopes, overexposed) be really hacky and sometimes incorrect. Presumably an iops still working after colorout (borders, watermark) are off between screen and export versions?

As an exercise, enable plugins/lighttable/export/force_lcms2 from conf, switch display profile to a CLUT profile, then change the "intent". Note that the histogram changes depending on the intent. This is wrong -- the scope results shouldn't vary with the display profile. You can also see this if you set overexposed to "saturation only" and vary display intent on a highly saturated image.

Could colorout always convert to the export profile, then have a colorspace conversion to display profile at the very end up the pipeline? This makes things "right" and would produce fewer weird surprises.

Regarding implementation, I can see a couple paths:

• Make bauhaus colorspace aware. This could simply be converting a few CSS color values to display colorspace. Of course not all widgets are bauhaus widgets, so this would be inconsistent, but could be paired with other code.
• Make individual widgets colorspace-aware as needed. Does the colorpicker already do this, to display color "right"? Or is it working in display colorspace, so it doesn't even need to bother? Certainly the center view does this ad hoc conversion work (dt_view_image_get_surface()).
• Have widgets write to a Cairo image surface, do colorspace conversion, then dump to screen. The histogram graph, for example, already uses an intermediate buffer (though the overlaid buttons do not): https://github.com/darktable-org/darktable/blob/383b9489a3a66ca24ce8f21c8be8c2c7f3c7aa1f/src/libs/histogram.c#L841 https://github.com/darktable-org/darktable/blob/383b9489a3a66ca24ce8f21c8be8c2c7f3c7aa1f/src/libs/histogram.c#L931-L933
• Deal with a color profile aware compositor or window manager -- offload to the OS. Is this possible? I remember a lot of discussion a year or two ago about Wayland not being built to allow this.

I worry about processing speed if LCMS is an option for this work, but am not too worried if the solution can handle selective updates of display regions. The center view and preview are already potentially LCMS color profiled. Various widgets, if color profiled, would only need to be redrawn on user interaction. It could also be an opportunity to warn users with CLUT display profiles, as matrix profiles should be good enough in most cases.

Aren't all color profiles already global? That is, they're in dt_colorspaces_t, darktable.color_profiles. I guess this could move to darktable.gui->color_profiles?

[github-actions[bot]]

This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[github-actions[bot]]

This issue did not get any activity in the past year and thus has been closed. Please check if the newest release or master branch has it fixed. Please, create a new issue if the issue is not fixed.