Visualise recommended colour spaces of the pixelpipe in module order (feature request)

Here are 3 examples of a nice visualisation of the pixelpipe:

(Thanks, @s7habo!)

The nice features in this visualisation are:

  1. Filmic (the transition from linear to perceptual) is clearly marked.
  2. The modules are colour-coded for their input and output spaces.

I am wondering if such a visualisation could be incorporated into the active modules view, or into a new expanded view of the “module order” utility module (both seen below in the screenshot).

Note: to preserve the greyness of the UI, it doesn’t have to be colour-coded; indicative icons or any other visual hint would be fine.

simply have a look at the default order. Those modules below filmic are linear.
Don’t move modules around just because you can do it - darktable gives you full control but also the possibility to shoot yourself in your foot :wink:

2 Likes

I think it’s not that simple. (Edit: added quote to point out what I am responding to.)
Using the v3.0 RAW order (darktable 3.9.0+152~g033df440c), you get the following before filmic:

  • rgb levels, rgb curves (both are marked as handling display-referred input and producing display-referred output)
  • color mapping (display-referred I/O, Lab processing)
  • color look up table (display-referred I/O, Lab processing)
  • astrophoto denoise (display-referred I/O, Lab processing)
  • negadoctor (display-referred I/O)
  • graduated density (scene-referred input, display-referred output)

Plus, at least contrast equalizer has its default blending mode set to Lab, but all its presets use RGB (display), which is rather confusing. Update: see Location of Contrast Equalizer in the Pipe Line · Issue #10546 · darktable-org/darktable · GitHub and also Fix default blend colorspace for contrast equalizer module and dummy IOP by glasl · Pull Request #10798 · darktable-org/darktable · GitHub

3 Likes

@kofa I think (and may be wrong; sorry) that in your reply you responded to the “how to cook with darktable” title within the illustration. However, I would like to focus on the feature request itself, which is to visualise the information at a glance (as opposed to the current mouse hover tooltips or referring to the manual) — regardless of how this information is going to be (mis)used.

These are really useful references, thank you! Especially Aurélien’s reply to the first one ( #10546).

Sorry, I didn’t quote properly Martin’s comment, which was what I was responding to. I think the feature request is helpful, at least until all modules have been reworked to support a scene-referred workflow / replaced with scene-referred equivalents.

1 Like

What is the logic if filmic is not used…

I think the main difference between modules marked as handling input scene referred and those marked as handling display referred is that the former can handle unbounded values (they do not clip). Even modules marked as handling scene referred input and producing scene referred output may perform non-linear operations (e.g., tone equalizer, which is a kind of curves tool).

For example, this image was processed without filmic. tone curve would have clipped anything above 1, but there was no such data in its input:

Or one with much higher DR (note that I moved color balance rgb after the rgb curve):

rgb parade before / after rgb curve and color balance rgb:
image
image

Besides the linear portions of scene referred (with strict value <-> energy proportionality) giving us physically correct behaviour, using scene referred lets us forget about clipping. Adjusting curves when all your data is squashed in the shadows is not fun:
image
Raising exposure would push most of the image above 1, and display-referred modules would simply clip. That is where filmic (or any other scene-referred → display-referred module) comes in.

1 Like

I meant more that if filmic was not used on the edit and thus not considered the threshold then what module would be the new threshold where red ones dare not go below … :slight_smile:

And what I was trying to explain was that, the way I understand it, if you’re careful not to exceed 0 EV anywhere, you should be OK.
I’d avoid ‘red’ modules before the physical corrections (lens, diffuse or sharpen, etc.). But hopefully, someone who actually knows will chime in. :slight_smile:

Ya I guess I am just trying to understand if they should be hard coded a color unless this carries a consistent meaning…visually if you start to have the modules moving around and you move up green ones okay then you have to identify the red ones to see if it was a green that when up or a red that went down…. If you just wanted a general reference and you assumed filmic was always used I guess you could make it yellow and have the red above and green below…but once somebody messed around the sequence then would it still give a visual cue that was of real benefit… I guess as long as you can turn it off.

Ya I guess I am just trying to understand if they should be hard coded a color unless this carries a consistent meaning…visually if you start to have the modules moving around and you move up green ones okay then you have to identify the red ones to see if it was a green that when up or a red that went down…. If you just wanted a general reference and you assumed filmic was always used I guess you could make it yellow and have the red above and green below…but once somebody messed around the sequence then would it still give a visual cue that was of real benefit… I guess as long as you can turn it off.

1 Like

Maybe instead of colouring, there could be warnings (like we currently have for double white balance) if a module that is designed to take display-referred as input is put directly after a module producing scene-referred output. But that would still produce false positives (e.g. color balance rgb will not necessarily push values above 1, even though it can).

2 Likes

I don’t know what the roadmap is, but perhaps eventually all modules that make sense in a scene-referred workflow will be ported accordingly, so

  1. a standard pipeline for raw images will just end in filmic + output color profile,
  2. and it would be sufficient to just warn the user if that is not the case?