Sorry, I don't use the XMP workflow, so cannot test the proposed changes. Would replacing crs:Exposure2012 with crs:LocalExposure2012 in Post Deflicker XMPs do the trick, or it requires some more?
It’s not enough just to change crs:Exposure2012 to crs:LocalExposure2012.
The full ‘GradientBasedCorrections’ block has to be used (code block from Reply #3)
And you have to divide the value by 4 (that is what i have not understood yet).
Have a sample image where the moving subject (in your case, turbulent water) could not be avoided by adjusting the percentile? Have a short clip (30 frames or so) where metering on turbulent water creates flicker? (just curious, would like to play with such a DNG or CR2 sequence).
I have scenes in which the problem occurs. For example, here at the end 1:10
If you would take the whole picture to Deflickern, then the sky begins to flicker at the end. In this case you should only use the sky to deflicker. With LRTimelapse you can specify an area in the image to calculate.
I'm not sure if you can do anything with my CR2 files. They come from a Canon G1x or S110. In addition, the exposure with CHDK was continuously changed in 1 / 96EV steps. In the EXIF data only the rounded 1/3EV values can be found. With my 6D I haven’t done any timelapse yet.
Indeed, the best place for deflickering is at post-processing stage (as you can adjust settings and repeat as needed); this in-camera implementation is more like a proof of concept.
I agree. That's the best way.
Even if the way in the camera is easier for the user.
Back then, there were many examples showing strong flicker in LRTimelapse with ML intervalometer (even with the old bulb ramping implementation).
Yes I have seen them. Could be a problem with wrong EXIF values? LRTimelapse need them correct. If there are not correct LRTimelapse get confused. I have the same problem with CR2 from CHDK.
I have no idea what algorithm LRTimelapse uses
I can now pretty much follow the results of LRTimelapse …
or whether the issue was fixed in later versions,
In that case only the visual deflicker workflow helps in LRTimelapse. This works only on calculated exposure values from RAW.
but I've got good results with median (or some other percentile) instead of plain average (percentiles are robust statistics, while average is not).
I do both in my post-processing workflow (median and average).
This is my workflow:
- calculating exposure values from a specific area in RAW Data.
- running a median over the values to remove outlier
- running an average to smooth background cure.
- calculate differences from background