When filmic rgb is disabled, how is the image tone-mapped for preview?

Software darktable
#1

Hello,

I’m trying to better understand how Darktable’s pixel pipeline works.

When using scene-referred workflow, the filmic rgb module converts image data from linear scene-referred to gamma-corrected display-referred. But what happens when filmic rgb is disabled? The preview image seems still gamma corrected, but what does it actually show?

My question can be also reformulated as follows: what happens if all modules that can be disabled are disabled? Then, the only active modules are:

  • raw black/white point
  • demosaic
  • input color profile
  • output color profile

My understanding so far is that up to input color profile, the image data is in the native units of the camera as found in the raw file. For scene-referred workflow, input color profile converts the data to some standard linear working profile. And output color profile converts this (by default) to sRGB.

I wonder about the following:

  • The export profile chosen in output color profile seems to have no effect on the preview. I guess that’s because preview is done in sRGB (on an sRGB screen)?

  • What determines which linear space color is mapped to sRGB white for the preview?

2 Likes
#2

I think that I can answer my questions myself. Could someone correct me if I’m wrong?

It seems to me that filmic rgb only behaves as if it was mapping from linear scene-referred to gamma-corrected display-referred. In fact it’s mapping from work profile (i.e. typically “linear Rec2020 RGB”) to the same work profile.

The filmic tonemapping curve seems to be plotted with a horizontal axis that is log(I), where I is the input intensity (in the work profile), and a vertical axis that is O^0.25, where O is the output intensity (again the the work profile). This is the curve that is indeed applied, but the output of the module is still linear RGB.

One can also think of it as follows: filmic does indeed map from linear RGB to gamma-encoded RGB, but then immediately undoes that gamma encoding (but not the tone mapping).

The conversion to sRGB at the very end of the pixel pipeline seems to occur in the same way independently of whether filmic is enabled or not.

#3

Preview is handled by the display profile…that is not filmics role…
Gamma is handled by the profiles and determined by the chosen colorspaces selected for/assigned to each…at least that is how I understand it…

1 Like
#4

Say we only look at the histogram and configure it to use the work profile. Then (I believe) we see the histogram of the image as it exits the pixel pipeline, but has not yet been affected by the display profile.

We can see that the work profile of the pixel pipeline is “linear Rec2020 RGB” up to the end of the pipeline, because switching the histogram from “work profile” to “linear Rec2020 RGB” does not change what it displays.

Meanwhile, I learned that the gamma that filmic applies is called “hardness” and by default (option “auto adjust hardness”) is auto-selected such that the orange dot in the filmic diagram remains on the diagonal.

#5

On filmic and gamma: New Sigmoid Scene to Display mapping

#6

When you use filmic for tone mapping it must interact with the “gamma” applied by the input profile and that applied on exit in the output profile…In essence it bridges the gap to use Glenn’s words

As noted in the manual wrt hardness

“This parameter is the power function applied to the output transfer function, and it is often improperly called the gamma (which can mean too many things in imaging applications, so we should stop using that term). It is used to raise or compress the mid-tones to account for display non-linearities or to avoid quantization artifacts when encoding in 8 bit file formats. This is a common operation when applying ICC color profiles (except for linear RGB spaces, like REC 709 or REC 2020, which have a linear “gamma” of 1.0). However, at the output of filmic rgb , the signal is logarithmically encoded, which is not something ICC color profiles know to handle. As a consequence, if we let them apply a gamma of 1/2.2 on top, it will result in a double-up, which would cause the middle-grey to be remapped to 76% instead of 45% as it should in display-referred space.”

@ggbutcher summed up I think your original question of what if going on when you don’t use filmic…

Quoted

"With regard to tone, if you were to take a raw image, convert to linear TIFF, and display it on a calibrated setup, you’ll likely find it’s too dark, dull, or both. What’s missing is the base curve, filmic curve, or whatever curve you decide to use to lift the image out of light-linear to whatever the rendition medium takes as input. The purpose of the tone curve we use in raw processing is to bridge that gap, but not go so far as to handle the rendition transform.

I’ve run across a few well-exposed images which didn’t require a tone curve; the display transform did the lift to perception in these cases quite nicely."

1 Like
#7

Thanks for the pointers!

So the answer to my original question (what happens if filmic is disabled), is that then actually no tonemapping occurs. Black and white are fixed early on in the pixel pipeline and these get mapped to sRGB black and white. The dynamic range of the RAW image is squeezed linearly to the sRGB range (or something similar: “perceptual intent”)

The source of my confusion was that filmic’s tooltip claims that it maps from linear to non-linear RGB. But in fact both its input and output seemt to be (at least with the default config) covered by the “linear Rec2020 RGB” profile.

In my understanding non-linear RGB is something like sRGB, i.e. linear RGB to which some form of gamma-correction has been applied. If I understand correctly what filmic does is rather a nonlinear transform within a linear RGB space.

1 Like
#8

Well no, if the display profile has a non-linear TRC, that is applied.

This and a couple of other threads are compelling me to make my “raw processing” video, where we open a raw file and lay on the operators one-by-one, until the image looks good. I have found nothing like that exercise to tease apart what’s being done and why.

#9

@ggbutcher Well if you really want the full monty…https://www.odelama.com/photo/Developing-a-RAW-Photo-by-hand/

#10

The tool tip tells you that the module will accept linear or non linear data and the its actions are not linear and its output is non linear. The pipeline works in stages and each stages or profiles has a color space which defines the primary colors, WB and transfer function to allow for correct colorspace converstions and display. Linear just means that a gamma of 1 was used, sRGB is a specific color space and its not linear.it uses a gamma of 2.2 generally by definition. The role of filmic and issues around the pipeline and linear parts of the workflow are well discussed here Darktable 3:RGB or Lab? Which Modules? Help!
if you have not seen this and basically I find this the best way to see what filmic is doing to the image
image …

#11

I’m kinda confused now.

The data is linear (no gamma correction)aafter reading input. Then setting input profile, it is still linear.

It’s then converted to the working space (linear rec2020 by default). It then stays there until you save the file.

So during the whole pipeline it’s in working space (linear rec2020). A module may internally convert to something it needs (lab for example) do its thing and then convert back.

But every module starts and ends with the working profile as I see it. But this is in my head,I might be really wrong.

So what are you watching when working on a file? It’s the output of the very last module (linear rec2020) converted to sRGB and displayed. Or if you have a color profile active on your display, it’s converted to that and displayed

When saving the file, the output profile is picked from the export settings or the output setting in the file.But the same idea : convert to output file and write,instead of convert to display profile and display.

It’s in this step that gamma correction is done,because it’s part of the color profile conversion .

‘scene referred’ and ‘display referred’ I explain over-simplified in my head that scene-referred means that the possible values can span outside the 0.0 - 1.0 range. In other words, there can be (a lot) of captured signal that is not mapped to how you want it to look on a display.

This is why not all modules are suitable in this stage,they clip of values outside 1.0 which you still want to use.

Filmic has the job to decide which captured signals end up where in your final 0.0 - 1.0 range.

#12

I wrote this a while ago, a generic description, might be of help:

https://discuss.pixls.us/t/article-color-management-in-raw-processing/11521

#13

Without having ever looked at the source code, this is what I observe. For example:

  • Switch the main histogram to “work profile” (right-click on the little warning sign icon at the bottom right). Unless I am mistaken, the histogram reflects now the output of the pixel pipeline.
  • Disable any non-linear modules like filmic rgb.
  • Now, when you increase/decrease exposure bias in the exposure module by 1 EV, you observe that any features move to the right/left as if the horizontal axis had been stretched/compressed by a factor of 2.
#14

Basically the simple answer to this in the past from Aurelien was set your working profile wide so like rec2020. Then be sure that your histogram is set for that as well, ie the working profile. If you never have an issues during your edit then all the other profiles will handle the conversions to display or output as needed. For output if you enable littleCMS you can choose how the mapping is treated…ie either relative or perceptual would be the normal choices …maybe absolute if you are calibrating something…it doesn’t have to be too complicated