Posts: 0
Threads: 0
Joined: Jan 2018
Neither scenario (HG nor basic Visual Workflow) seems to work for a sunrise sequence I am testing this on. As an example, as the sun appeared behind a ridge, there was an immediate -1 stop change applied to the shutter speed. De-Flicker does not seem to be able to handle such a large change (even two passes), and thus I worked toward trying to 'manually' get the HG workflow to help accommodate it. The changes in brightness can be seen in the Preview and Visual Luminance values, so I guess I just don't understand why LRT4 cannot predict what is necessary to match brightness from these measurements? I was able to do it 'manually'--albeit with a tremendous amount of effort--a year ago when I first produced the sequence, and was hoping your software would allow me to automate the incredibly laborious process.
I get that the 'in between' values that automatic camera modes potentially select could indeed induce some flicker, but it seems to me that that is exactly what De-Flicker is/could be used for. I completely respect your views as both an expert time-lappist and the developer of the software, but I guess there must be some technical reason that you cannot explain for not allowing the software to at least try and normalize the brightness values when shot in Auto modes.