This post was last modified: 2011-02-25, 19:03 by Joachim Buambeki.

Hi,

I've been playing around with the black levels in ACR and it seems you can get a very close approximation of it using curves with the following settings:
in / out:
13 / 0
127 / 124
191 / 189
253 / 255

This way one could apply the same contrast boost "Blacks" in ACR offers later.
I don't have done tests yet if that helps to stabilize deflickering, but I thought I could share it with you guys.

Best Regards
David

To clarify things a little bit (for those not involved yet):
The "blacks-bug" is a finding, that user ev1te made and shared in the timescapes.org forum. It's not approved that it's really a bug in ACR.

My impression (yet) is, that it doesn't really matter. LRTimelapse does not "see" the developed images. So it calculates deflicker on the source images - when you shoot RAW on the JPG-previews embedded in the RAW files.

Because of this I strongly recommend to turn off in camera settings like "D-lighting", "auto enhance", dynamik compression" or similar when shooting time lapses because those settings affect the previews embedded in the raw files!
In changing lightning conditions this would severely weaken the deflicker algorithm.

Joachim, could you please explain how do you think I could improve deflickering in LRTimelapse based on your finding?

Joachim, could you please explain how do you think I could improve deflickering in LRTimelapse based on your finding?

I don't know how you evaluate the amount of flickering exactly, but since you are examining the overall luminosity of the embedded OOC Jpegs it's probably not important for the LRTimelapse analysing stage at all.
I remember you wrote somewhere on timescapes.org that your deflickering algo takes the "Blacks" respectively the ACR standard conversion into consideration at some extent. If yes you could re-evaluate your algo with "Blacks" set to zero.

The problem is that even if your deflickering is 100% accurate (which it will probably never be), you will still have slight changes in luminosity (not even uniform over the whole frame) that are very distracting because of how ACR handles data internally.

The idea behind the curve I posted is to apply it later in AE to prevent sudden changes in the dark tones because two adjacent frames had a significantly different exposure and were therefore affected by the "Blacks" issue (which affects the overall image if my calculated curve is correct) after they have been deflickered by adjusting the exposure via the .xmp data.
Of course I wouldn't be surprised that there are more issues like that when using the "Recovery" or "Fill Light" sliders for example.

If you're pedantic and using AE, probably the best way is to pass linear data (with deflickering and WB shift applied) into the timeline and do everything else later via filters and adjustment layers.

At the moment this is all I can say, I am also a not so sure how to circumvent the whole issue effectively.

Best Regards
David