Hard-to-solve flickering issue with pfstmo_mantiuk08

[Eat Dirt]

Hi there,

I am used to pfstools since a while,  as I am tone mapping 16mm HDR film scans. I got a problem recently that I've never had before when some exr images contain sun reflections on some objects.

Best seen in images:

https://curl.irmp.ucl.ac.be/~chris/upload/flicker/

If you check out the input "*.exr", they're all good. But the tone mapped one (see README for the piping command of pfstmo_mantiuk08) are flickering from a frame to the other by at least 1 stop. This happens each time the sun is directly reflected  on an even tiny object in the picture (like the pole of the skier)

Any idea to fix this would be welcome!

Cheers,

Chris.

[Rafal]

The original sequence (in *.exr) varies in exposure from frame to frame. You can check that with:

pfsin bagneres_00179*exr | pfssize.exe -r 0.25 | pfsgamma.exe -g 2.2 | pfsout gamma_bagneres_%04d.png

If you:

pfsin bagneres_00179*exr | pfssize.exe -r 0.25 | pfsview

you can see that he histogram shifts between the frames. 

The tone-mapping will preserve the flicker in the original frames. 

I suggest that you adjust the exposure so that the median luminance value is the same across the frames. 

Best,

Rafal

[Eat Dirt]

Thank you for your answer. Indeed, I do see that.

The problem is that the original exposures (3 of them per exr frame) are already of constant exposure from frame to frame, and I can check that their median luminosity across exposures is stationary. It seems the problem shows up only when I am merging them into exr, only there the median luminance is getting shifted to low value as to compensate for the sun flashes.

Is there a way to create the exr at given median value ? (I am using dcraw2hdrgen and then pfshdrcalibrate -r linear -c none -b 12)

Thanks again for you feedback!

[Eat Dirt]

I have found a workaround,  not really satisfactory though, which is to "sigma clip" at 5 sigma above the median my raw exposures before merging them into exr. Then the final tone mapped images are no longer flickering. But, this is somehow killing the purpose of having an HDR image in the middle :-/

Cheers,

Chris.

[Eat Dirt]

Still no satisfied with the workaround, I am digging into the code... My problem comes from this normalization that  I have now commented, and this fixes all my problems!

--- pfstools-2.2.0/src/camera/robertson02.cpp.orig 2023-11-28 22:13:31.142020563 +0100
+++ pfstools-2.2.0/src/camera/robertson02.cpp 2023-11-28 22:14:04.783371761 +0100
@@ -348,7 +348,7 @@
     {
       if( (*rgb_out[cc])(j) == -1)
         (*rgb_out[cc])(j) = mmax[cc];
-      (*rgb_out[cc])(j) /= max3(mmax);
+      // (*rgb_out[cc])(j) /= max3(mmax);
     }
 
   VERBOSE_STR << "Exposure pixels skipped due to deghosting: " <<

On pfsv, I can see that the histogram is now at higher EV (5 stops). But all exr frames now show a consistent histogram, consistent across multiple frames. If I set one unique exposure level, then all the different exr frames exhibit the same mean luminosity, independently of the presence of any solar flashes (aka, extreme points in the luminosity distribution).

If I understand well the code, this max norm is to prevent things to go haywire and exceed bpp sampling? Especially useful is  the dynamical range is small. But, for an animation, or movie, it is a catastrophe. It completely kills the time-coherence of exr calibration from frame to frame, even if the LDR input frames are time-coherent :-/

May be you could add an option allowing to skip this normalisation?

An intermediate solution could possibly be  a median normalisation, it would be more robust to distribution tails and would keep some calibration coherence across multiple exr frames. That could not be worse than this max anyway!

Best,

Chris.

[Eat Dirt]

My way :)

https://curl.irmp.ucl.ac.be/~chris/upload/flicker/pfstools-2.2.0-normoptions.patch