Processing skies with clipped channels in Darktable filmic/sigmoid

ariznaf · January 22, 2022, 10:23pm

Ok, don’t call it saturation.

But just keep relations between r/g/b while darkening and it will do and won’t be a much pale color than when you llok to the sky in situ.

DT abandoned the lab perceptive model in favor of liner rgb in order to keep energy relation in the editing process.
Nut now i discover that it is making perceptive corrections in every step and that it can heavily break that relations and reprocity law…

I understand it is difficult or even imposible at currenr state of the art to keep that relations and keep colors under control.
But it can then be in the base of difficulties with expanding highlights.

So may be a tool that operates directly over the original data may help and circunvent that.

May be exposure module would have more options to do that in cooperation with color balance?

Reading your last part of the unswer i am confused now.

You previously said that DT makes gamut checking at each step, an corrects colors to be in gamut.

Now you say that tone eq oprates previously tu cat and no gamut correction is made.

So, is just color calobration the one that makes gamut checking and previous modules do not have that check?

In that case there will be no problem with that.

kofa · January 22, 2022, 10:28pm

It is my understanding that tone equalizer is equivalent to a number of masked exposure modules (that is, it does not distort colours).

ariznaf · January 22, 2022, 10:31pm

But previously it was said that DT makes gamut checming and corrections at each step, so it will chance colors.

In that case if you apply a correction with exposure or tone eq that provokes some OOG values and then rvert it with the opposite operation with the same module you won’t have the same image.

anon41087856 · January 22, 2022, 10:36pm

Not really. The corrections are made at constant luminance and hue, we just compress the chroma. Meaning we whiten the spectrum but the energy should be preserved more or less.

I don’t know what the reciprocity law is, but there is no other way. Again, each and every color profile is expressed against CIE XYZ 1931 2°, it’s not new, and it’s everywhere. The whole image formation model is grounded into the tristimulus, the one of the camera first, and the one of the human being later. A camera has never been a spectrophotometer.

At every step where we may introduce gamut escapes, like in color calibration (CAT is dangerous), color balance (chroma is dangerous), and soon in filmic (again, non-linear stuff is dangerous). Now, exposure and tone EQ (which is actually an exposure) affect saturation uniformingly, so there is no risk in there.

Matt_Maguire · January 22, 2022, 10:42pm

Ok, I see there has already been some discussion in the meantime. Here is a screenshot of an example where tone equaliser is used to increase the local contrast in the sky.

The lefthand side is a snapshot with no tone equaliser, and the right hand side has tone equaliser enabled. This photo is not a great image – is a snapshot taken through the window of a building, and you can see some reflections that are accentuated in the RHS of the image, but at least you can see the effect on the evening sky.

If we are going to expand 2EV to cover the 8EV of control points, we are probably going to want to jack up the mask contrast by 3-4 EV. The mask exposure is reduced so that the brightest part of the image still falls within the control points. You can see the histogram summary, where the RHS of the light grey bar doesn’t extend all the way to the right, but on the left there is an orange indicator to show that there are luminance levels in the image that fall below the left-most control point. Fine tuning is done with the mask enabled, and mousing over parts of the image to ensure a reasonable spread of mask values in the area of interest.

Because the goal of this is to locally increase contrast in the highlights, you don’t really want smoothing, so I set the smoothing diameter to a 0.01% minimum. Ideally one would select “preserve details = no”, but it seems in that case there is no mask contrast compensation slider in that case.

ariznaf · January 22, 2022, 10:45pm

Ok so not every operation is at risk og suffering gamut correction.

May we conclude we should make the correction of the sky as early as posible, may be at exposure correction or judt after it?
And that tone eq will be the adecuate tool cor maki g it and be reasonable sure it will receive data with relations among r/g/ preserved from original values?

In that case two gone eq or exposure operations that are oposite won’t provoke any change to image.
That is what i mean by reprocity law,.
And that you can make a photo with a exposition and get the same results than with another one exposed xEV more ad then corrected in -x EV in software, as long as you don’t clip lights.

priort · January 22, 2022, 11:12pm

If you see halos tweak the feathering slider for the mask…very small adjustment will usually correct it…

priort · January 22, 2022, 11:14pm

Would you be happy to lose the shadow on the right side??..maybe just me but seems to be lighten a bit much on the right side leaving the lighting on the building very flat overall??

priort · January 22, 2022, 11:16pm

It comes right after exposure by default so not that high

ariznaf · January 22, 2022, 11:22pm

Well just one correction to chang your color and put it in gamut and make it a nearly white and you woul loose the option to revert your overexposed sky and get the color relations there were in priginal data.

priort · January 22, 2022, 11:40pm

Color is not changing…H and L are constant from what AP said and there is only compression of chroma…so its like tweaking the chroma slider in CB module…I don’t think this will hugely impact things colorwise and if data is out of gamut the values don’t mean anything do they?? They would be undefined so how would you work with them?? At least that is how I see it.

I think how things are handled by the white balance and highlight reconstruction put finger prints on the data before it gets to the other steps…and potentially have more impact on overexposed data than those downstream modules??

anon41087856 · January 23, 2022, 12:16am

You are inventing problems that aren’t there and missing the more pressing problems that are very real.

The display-referred gamut volume (above) is a kind of double cone, because display-referred is bounded… and bounded by the top cone. The scene-referred gamut volume is made of only the bottom cone that points at black and goes on forever.

When doing exposure changes, you make color vary along the brightness (dubbed brilliance in dt) axis, that starts from black and follows the dashed lines of equal saturation:

So, any exposure change over an unbounded, in-gamut color will stay in gamut. Any exposure change over an unbounded, out-of-gamut color, will stay out of gamut. No exposure change will ever make a color cross the gamut boundary, in one direction or in another.

So, whether you gamut-map earlier or later, it doesn’t change a thing as far as exposure is concerned. You just catch another equi-saturation line sooner or later, but then you keep moving closer or farther from black, aka at equal saturation.

Of course, when we put an hat on that cone and bound it to display, which happens only in filmic, things change.

But, again, colors out of the visible locus will make any attempt at breaking RGB into a hue/chroma/luminance model fail, especially the Yuv/Ych models since they rely on LMS cone response that is very sensitive to negatives.

ariznaf · January 23, 2022, 12:20am

Yes they do, they have measure the relation between channels that was in the original light.
That was the relation even if the eye cannot see it and is interpreting it as near white due to being quite brilliant.
The camera has correctly registered it as it has better eyes than our eyes.
Butcamera is not measuring that brilliance, if you have hagh values is justdue to having exposed the sky more to do ETTR and preserve more DR.

When you look at that sky in site you don’t reallu see itas white, you see it blue, because your eyes haven’t iver exposed the eye, just you in the camera.

So in your photo, in case the software has made a correction to put the color in gamut, as there is no such brght bluesish color, the sky woul turn almost white and then a gray when you expand the highlights to the left and you will end with a dull pale sky, quite different to what you remember and you have seen in site, as the high values comes from your exposition and depend on it.

But that is what i am trying to dilucidate, wheter that bright orange or bluesish color with a lot of luminosity is converted by DT to a in gamut pale color near white or not, before exposure and tone eq module.

If it is not, there is no problem them and the difficults come from other place.
And if you can use mask tool in tone eq to distribute more controls over last 2EV, that would be the way to make the corrections I was looking for.

anon41087856 · January 23, 2022, 12:20am

Color is changing. There is more to color than just hue. Color is { lightness, hue, chroma } as a pack. But indeed, we try to preserve hue in priority because that’s what holds the most meaning.

europlatus · January 23, 2022, 12:36am

Thanks very much for that. Very interesting and I’m going to play around some more. I’ve always been very fixated on getting the whole tonal range spread nicely over the 8 control points that I haven’t tried these more extreme examples. How many control points did you end up with to work on just the highlights? I’m assuming the mask histogram on the advanced tab doesn’t really show much when the module is used like this and that you have to use your mouse (and mask overlay) to hover and adjust the values?

Matt_Maguire · January 23, 2022, 12:59am

This is same image, this time showing the mask itself, and the level adjustments on the advanced tab.

I should add, this is just a quick edit to show an example of local tone mapping – I didn’t bother to spend much time on the image because it is basically flawed due to the reflections.

priort · January 23, 2022, 1:27am

Ya I should be more careful. Color would change but how large are these corrections??. I assumed small ?? If you are prioritizing hue would these corrections even make “perceptual” changes that a user would notice if you could disable it?? Just curious??

Underexposed · January 23, 2022, 5:08am

I was going for a desaturated look. The kind of look Aurelien once said couldn’t be done until the new color balance rgb. Just to be different from the others who had pretty intense colors. Just experimenting.

priort · January 23, 2022, 5:24am

Ya its all such a subjective thing for many aspects. When I look at images I am too hung up on how they should look too often. For me this calls for the shadows to be preserved or realistic esp on the right side but that how I see it not how it needs to be…or not what could be creative

kofa · January 23, 2022, 4:41pm

@anon41087856 Would it make sense to enable mask contrast compensation in all modes? E.g., with the simple tone curve, one could get more fine-grained control.
If I dumbly change:

kofa@eagle:~/darktable$ git diff
diff --git a/src/iop/toneequal.c b/src/iop/toneequal.c
index c9ea992be..7bd750766 100644
--- a/src/iop/toneequal.c
+++ b/src/iop/toneequal.c
@@ -816,7 +816,8 @@ static inline void compute_luminance_mask(const float *const restrict in, float
     case(DT_TONEEQ_NONE):
     {
       // No contrast boost here
-      luminance_mask(in, luminance, width, height, ch, d->method, d->exposure_boost, 0.0f, 1.0f);
+      luminance_mask(in, luminance, width, height, ch, d->method, d->exposure_boost,
+                      CONTRAST_FULCRUM, d->contrast_boost);
       break;
     }
 
@@ -1620,8 +1621,8 @@ void show_guiding_controls(struct dt_iop_module_t *self)
       gtk_widget_set_visible(g->blending, FALSE);
       gtk_widget_set_visible(g->feathering, FALSE);
       gtk_widget_set_visible(g->iterations, FALSE);
-      gtk_widget_set_visible(g->contrast_boost, FALSE);
-      gtk_widget_set_visible(g->quantization, FALSE);
+      gtk_widget_set_visible(g->contrast_boost, TRUE);
+      gtk_widget_set_visible(g->quantization, TRUE);
       break;
     }

I can get a mask like this:

And with a curve, the sky can be made to display more detail (I used the awkward term ‘can be made to’, as this is not what I’d do with this image – the effect is grossly exaggerated for demonstration purposes, and I didn’t care to mask the sky):

(Edited: changed mask; edited curve not to affect -8EV, as the same change would be applied to lower values as well, changing the whole image.)