Rawtherapee: Dynamic Range Compression anchor 99->100 gets darker

[Thanatomanic]

@agriggio In testing the Dynamic Range Compression tool for the documentation, I found cases where setting the anchor to 99 and then go to 100 actually makes the image darker. This is not how I expect it to work, so maybe there is something fishy going on in these edge cases?

Here are two files + pp3 for testing. https://filebin.net/t5cyuuc0gauvb1zm

[agriggio]

thanks, I'll take a look

[Beep6581]

I experienced that many times. I rationalized it as being the result of having e.g. a clipped sun in the otherwise-unclipped image which causes the jump in the last 1% of the slider.

[Beep6581]

I uploaded two files to the filebin - one has a clipped point light source (3 small lights) and exhibits the problem, and the other has no clipping and does not exhibit the problem.

[agriggio]

I haven't tried on the attached pics yet, but I think we should simply limit the anchor range to avoid the extremes, which are inherently unstable, and might cause mismatches between the preview and output. I'd propose to limit anchor to 10-90, opinions?

[Thanatomanic]

I would need to understand what the anchor does exactly to judge if it's inherently unstable. Is the value of the anchor translated into the code directly, or through some transformation?

Fwiw: 1) I didn't do output testing, so it might be a preview issue. 2) I saw only gradual changes throughout the range, except by going from 99-100. That alone would be a bad argument to just limit things to 90, because there still might be an underlying issue. Right?

[Beep6581]

1. It's not a preview issue, the saved images match the preview quite well.
2. The point at which the effect of a small change in the slider results in a large change of the image varies. I even have an image (uploaded, 20 1-3.dng) where the strongest jump happens between 98-99, and 99 in this image is overall brighter than 100.

[Beep6581]

I have nothing against limiting the anchor a bit, as it does prevent jumps in most of my photos.

[agriggio]

the anchor is the percentile at which to pick the luminance for exposure scaling. the further you move away from the median, the less "stable" the value becomes. for the extreme points, a single outlier pixel might cause sudden jumps. that's why in practice limiting to 10-90 might be reasonable, but in fact there is no guarantee. also I think there might be an issue with the implementation for the extreme cases: the tool doesn't clamp values, but the percentile algorithm uses a lut and so it clamps (warning: this is just speculation at this point, I didn't investigate yet)

[heckflosse]

@agriggio The percentile algorithm clamps using min and max value of the image, not hardcoded values

https://github.com/Beep6581/RawTherapee/blob/dev/rtengine/rt_algo.cc#L91

[agriggio]

@heckflosse thanks for the correction! As I wrote I didn't test, I was just speculating... wrongly :-)

[heckflosse]

@agriggio Just to exclude a possible wrong calculation, I want to push this:

diff --git a/rtengine/rt_algo.cc b/rtengine/rt_algo.cc
index ae385508a..22ea5c76b 100644
--- a/rtengine/rt_algo.cc
+++ b/rtengine/rt_algo.cc
@@ -172,6 +172,7 @@ void findMinMaxPercentile(const float* data, size_t size, float minPrct, float&
     // go back to original range
     minOut /= scale;
     minOut += minVal;
+    minOut = rtengine::LIM(minOut, minVal, maxVal);

     // find (maxPrct*size) smallest value
     const float threshmax = maxPrct * size;
@@ -190,6 +191,7 @@ void findMinMaxPercentile(const float* data, size_t size, float minPrct, float&
     // go back to original range
     maxOut /= scale;
     maxOut += minVal;
+    maxOut = rtengine::LIM(maxOut, minVal, maxVal);
 }

 void buildBlendMask(float** luminance, float **blend, int W, int H, float &contrastThreshold, float amount, bool autoContrast) {

Any objections?