Blender AgX in darktable (proof of concept)

[Macchiato17 (Lars Fiedler)]

@kofa @g-man no video from my side, but I can reproduce the behavior (5.3.0~git949.610a6048, Linux Mint 22.2):

• when resetting AgX, the pivot target output picker works as intended afterwards (in my example, it changes the value from 18% to 20,73%)
• as soon, as a value has been manually set for pivot target output (also if I just set it to 18% manually), a click in the picker triggers the measurement (I can see the frame and the “working” toast message), but after the calculation finished, the value remains at 18% (or at any other manually set value).

Hope this helps to debug this. Shall we file an issue on github?

[g-man]

If you can reproduce and have the time, please start a GitHub issue. Otherwise I will start one in around 8hrs.

[kofa (István Kovács)]

Wayland, current master 5.3.0+950~g8f05fbc64b

[Macchiato17 (Lars Fiedler)]

@g-man @kofa I just opened the following issue

AgX: pivot target output picker not working, if value has been entered manually before

[Macchiato17 (Lars Fiedler)]

Just updated a small difference in the github issue, as I double-checked again with current master (5.3.0+950~g8f05fbc64b) and can still see the issue:

as soon, as a value has been manually set for pivot target output after resetting the module and having used the picker once

Perhaps this is the little difference here…

[kofa (István Kovács)]

At 28 seconds, you pick the pivot from the whole scene. The pivot in and out are picked:

We read +0.17 EV for the input, meaning 18% * 2^0.17 = 20.25% output, and a target output of 20.56% – this is where the default curve, with the pivot mapping 18% to 18% would map the input 20.25% (effective contrast is slightly above 1, so the output is slightly above the input).

Then, at around 0:25, you say, without changing the pivot input, that you want to set the curve to map 0.17 EV to 18% output:

Then, at 0:36, you click the picker, which then does what users requested it to do, and maintains the current output, since the input is not changed:

Please go back to Blender AgX in darktable (proof of concept) - #2276 by ndrw.

Quoting the docs – see the bold italic at the end:

pivot target output: sets the target output linear value (power) for the tone selected by the pivot’s input. The value is indicated on the y-axis. Note that the scale of the y-axis is not uniform, and depends on the curve y gamma, described in the section advanced curve parameters. The corresponding color picker adjusts both pivot relative exposure (setting the point of highest contrast) and pivot target output, attempting to preserve the average brightness of the selected region.

Since you set that region to have an output of 18%, the picker maintains it.

[Macchiato17 (Lars Fiedler)]

Thanks for your explanation (again) and I still need to digest this and understand the implementation deeper. Seems as if I am still enjoying a steep learning curve here

[g-man]

I would have not closed the issue. This is still not a normal behavior for the sliders in my opinion. Based on previous discussions, I understood the first slider to place the pivot to be XXEV from the mid-gray using the picker area, but I assumed it was using the mid-gray from the exposure module (in reality the pipe) or some pseudo absolute value (mid gray from the input exposure range). I dont think that’s what’s really happening.

[Macchiato17 (Lars Fiedler)]

Well as far as I understood, the feature works as designed / intended (even though it’s currently also quite puzzling to me). But I still need to understand and digest the mechanics “behind the scenes” and therefore trust István that the implementation is fine at this point.

So it’s perhaps an item for possible later improvements, one may re-open the issue anytime…

[kofa (István Kovács)]

As requested, implemented and documented, the picker should not change the brightness of the selected area.

The picker was used to measure the whole scene. It found that the average input brightness was 20.25% (0.17 EV above mid grey). With the default curve (mapping 18% to 18% and a contrast of 2.8), that input is mapped to an output of 20.56%. This is what the algorithm set as the output value.

Then, the user changed the output to 18%.

Then, the user picked from the whole image. The average of the input was still 20.25%, and the current output was 18% (what was set by the user), so the picker tried (and succeeded) to maintain that.

[alpinist]

@alpinist

Perhaps in filmic documentation “including or not the output transfer function” only refers to how the y axis is scaled? If this is the case, I consider it super confusing: Plotting the same function with different axes does not modify the function. This would be the same kind of confusion that we discussed above for the tooltip.

Turns out that’s indeed the case:

Critique of Filmic RGB graphs/documentation

Hello, In my experience, the Filmic RGB graphs and its documentation are misleading to the point that they hinder understanding of how the module (and the pixelpipe) really works. Here, I write down what I have found out by examining the source code. I would have loved to know this when I started to learn Darktable, so perhaps others will find this interesting. Here are the questions that I had: Looking at the x-axis of the different plots, what is the difference between “EV scene” and “%…

[kofa (István Kovács)]

Please discuss filmic and its documentation elsewehere (in other topics, on the dtdocs Github etc). I brought it up as part of an explanation, but let’s keep this topic on AgX. It’s huge enough as it is.

[alpinist]

I opened a new thread because of that. Here, I just quoted a message from this thread, where we were discussing AgX vs filmic for the purpose of understanding AgX. Thanks again for your explanations. They were very useful for me.

I thought that if someone followed that discussion, they might be interested in the answers of some of the questions raised there. For me, this helped understanding tonemappers in Darktable in general, and AgX in particular.

[kofa (István Kovács)]

@g-man

I understood the first slider to place the pivot to be XXEV from the mid-gray using the picker area, but I assumed it was using the mid-gray from the exposure module (in reality the pipe) or some pseudo absolute value (mid gray from the input exposure range).

I don’t understand what ‘mid-gray from the exposure module’ or ‘some pseudo absolute value’ should mean.
However, the slider does not adjust mid-grey. Mid-grey, by definition, is 18% absolute value, R = G = B = 0.18 linear, in any RGB space.

The input slider positions the pivot relative to mid grey; it shifts the point of highest contrast.
The output slider sets the output (luminance) the given input should be mapped to.

By default, the input is at mid-grey (0 EV shift), and the output is also mid-grey (18% linear output).

Using the ‘output’ picker, you can shift the point of highest contrast to another part of the image, without changing its brightness. Unfortunately, due to technical limitations (if used for the first time, darktable always sets the picker to cover almost the whole frame), unless the average of the image is initially 18%, you do get a shift the first time you enable it.

After the 1st application, when you move from area to area, the output should be preserved quite well.

In previous implementations, the output was always recalculated as if the pivot was in the original 18%->18% position. That means, once you moved the pivot, the output would always change compared to what you saw on the screen.

For example, here I picked the pivot from the sky, L=93. The green patch in the bottom right corner measures at L=62:

If I pick from that green patch, its L=62 is kept almost unchanged, instead of being set to whatever it would end up with the 18%->18% pivot:

Calculated with old method, using the 18%->18% mapping, L would be 44:

And the image after moving the pivot would look like this:

So, to reiterate: the aim is to keep the current luminance of the area selected for the pivot, only shifting the contrast there.

So, new method:

Old method:

[alpinist]

@kofa

s is AgX without primaries adjustment, and without preserve hue:

When I try to reproduce the above (same test image, all modules disabled except AgX, AgX set as described: defaults without primaries adjustment, and with preserve hue set to 0%), I obtain the following:

This is on Darktable from git/master from a few days ago.

Any ideas why in my case the colors fade to white?

[priort (Todd Prior)]

If I had to guess @kofa was using srgb primaries… I think that leads to the similar image that he shared…

[kofa (István Kovács)]

The input image is in Rec 709. If the pipeline is set to Rec 2020, a larger space, then all colours are somewhat desaturated (because Rec 2020 is larger). So, Rec709 red (1, 0, 0) may be (0.8, 0.1, 0.1) in Rec 2020, which is like applying attenuation. And since Rec 2020 primaries are also ‘rotated’ with respect to Rec 709, you get the full effect.

You can find a diagram e.g. here: What is Rec.709 vs Rec.2020 in video? | Digital Camera World

[alpinist]

@priort

If I had to guess @kofa was using srgb primaries… I think that leads to the similar image that he shared…

@kofa

The input image is in Rec 709. If the pipeline is set to Rec 2020,

Thanks for the explaination. I understand the point about the different color spaces, but what should I set exactly in Darktable to reproduce @kofa’s screen shot (the one that I show just above)?

I tried tweaking the module “input color profile”. The closest I can get to @kofa’s screen shot is by leaving “working profile” at “linear Rec2020 RGB” and changing “input profile” to “linear Rec2020 RGB”. But this still gives strange discolorations when AgX is enabled (AgX is set as described above, i.e. defaults with primary adjustments disabled):

What am I doing differently?

[kofa (István Kovács)]

I think I used Rec 709 for everything (input profile, working space, base space in AgX).

Note that the display profile also influences the (displayed, but not the exported) result, sometimes in surprising ways. Best set it to sRGB (the simple built-in ‘web-safe’ profile) for this experiment.

[alpinist]

@kofa

I think I used Rec 709 for everything (input profile, working space, base space in AgX).

Thanks! The “base primaries” setting in the “primaries” tab of AgX was the missing bit. I had to set it to Rec 709 as well.

By the way, this is a small inconsistency in the AgX UI: enabling the “disable adjustments” check box in the “primaries” tab of AgX hides settings and uses default values instead. But the value chosen for “base primaries” remains in effect even when hidden!