> The proper point to clamp black and white in scene-referred is filmic RGB. >
Correct to some extent, in scene-referred pipeline. The “why” is important, though, and not relevant to non-filmic pipelines. …could eventually produce problems in other parts. With a floating-point pixel pipeline, we do not have the general problems which come with an integer pipeline as in Ps/Lr. They have integers which MUST be between 0 & 255/65,535 (8-bit/16-bit). If at any point in the pipeline, the number falls below or above those values, it clips to the extreme value. That leads to banding in the shadows/highlights. With floating-point, the colours are represented by 0 for blackest black, and 1 for whitest white. If at any point, the number falls below or above those values, they remain at whatever the value is, until another module in the pipeline adjusts it again. At the end of the pipeline, before exporting, there are three ways to handle ‘out-of-gamut’ values. 1. clip any value below zero or above one. 2. normalise the values to fall within the range. (The lowest value becomes zero, the highest value becomes one, and all other values are squeezed in. 3. I cannot recall. The problem with the filmic module is that it uses a log function, and there is no log defined for a negative number. Therefore, the filmic module might crash or give incorrect interpretations for negative numbers. There are several ways to fix that. 1. clip negative numbers before the filmic module. 2. normalise negative numbers before the filmic module. 3. replace the log function with trigonometric substitution, or something, where negative numbers can be handled. 4. I am really not sure. I would really have to think about it. Currently, I have tried to switch my workflow from LabCIE to FilmicRGB, and, despite the warning, have still been sometimes adjusting my black level with the [exposure]→[black level correction] slider. So far, the [filmic rgb] module has not crashed out on me, nor messed up my subject. One reason may be that, because I use the {clipping indication} to ensure that no part of my subject goes too far beyond that 2% margin, (actually, in 3.8, it is -12.27 EV), very few pixels, if any, (in the subject), goes into the negative. I suppose I could use the {gamut checking} option instead of the clipping option for a more certain outcome, but the end result is more or less the same; no negative values to worry about. Another reason may be that the [input colour profile] module —which has options for handling out-of-gamut colours— comes AFTER the [exposure] module and BEFORE the [filmic rgb] module. A third reason could be great error-handling routines in the [filmic rgb] module to handle the log of negative numbers. Whatever the reason, so long as I do not end up clipping (crushing) my shadows in the [exposure] module into negative values, the image seems to be just fine at the end of my pixel pipeline. (Truth be told, I do not actually know what would happen IF I dropped the blacks into the negative). If one is NOT using [filmic rgb], —or any other module which does functions where the result of a negative number input is NAN,— then using the [exposure]→[black level correction] slider is not really a problem. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Tue, 25 Jan 2022 at 11:33, Guillermo Rozas <guille2...@gmail.com> wrote: > > ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org