Hi!

I've got about 100 timelapse sequences to be edited, most are shot in manual and don't flicker, but sunsets are shot in Av and some of them are flickering a lot, probably because I didn't use bramping - I believed flickering could be removed in post.

Ihave been evaluating LRTimelapse 3 for a couple of weeks, and installed version 4 yesterday. In LRTimelapse 3 I had to do several passes of deflicker on certain sequences shot in Av mode, to get rid of flicker. After 3 passes flicker still would be visible, although it was substantially reduced. This would mean I had to either lose quality because of recompressing with JPEG several times, OR I had to spend a lot of time and disk space using TIFF as intermediate format.

I'm very happy to see the new feature with visual deflicker in LRTimelapse 4. It makes the whole process a lot easier. But, it seems like the visual deflicker is not working 100%. After testing several sunset sequences with heavy flickering (shot in Av mode), I would say deflicker reduces the flickering by about 50-70%. That means I still have to do several passes of deflickering.

Attached images from one of the most extreme sequences. The images are raw images straight from the camera (Canon 700D), not edited in any way. (I read that heavy editing in LR could cause the deflicker to misbehave, at least in LRTimelapse 3 where the embedded preview was used as reference for exposure compensation)

Flickering is still visible after four passes in the clip below. I used maximum smoothing. It seems like the deflicker algorithm just doesn't compensate enough. Measuring the amplitude of the flicker curve gives me the following figures:

Original raw: 100% flicker ("reference")
Deflicered: 33% flicker left
Refined: 14% flicker left
Refined again: 6% flicker left
Refined 3rd time: 4% flicker left (fourth pass)
and so on...

I will probably get it right after 5-6 passes, but it is very time consuming - especially if I need to do more editing in Lightroom - in that case I might need to redo all passes of deflickering. In the long run I would probably end up not doing that last edit in Lightroom and end up with a sequence I'm not 100% satisfied with.

The sequences I've tested don't have clouds or other disturbing objects that would cause big changes in average brightness. I've tried different reference areas - whole image, sky only, ground only, or sky/ground combined.

Attached images from a time lapse in Monument Valley, capturing a phenomenon that happens only twice a year, and only when the weather conditions are right...

Original sequence, and yeah it is flickering!
   

After deflickering, max smoothing:
   

After refining, max smoothing:
   

Refined again, max smoothing:
   

Fourth pass. Flicker is still visible.
   

I've never seen so bad flicker- how did that come? You cannot expect LRTimelapse do do wonders on sequences like this. GIGO principle... Garbage in, Garbage out :-)

But maybe you have only missed to set the reference area: draw a rectangle to the sky area, to isolate this as a reference for the flicker. Then try again.
I'd still like to know, what is causing those big bumps in the blue curve...

Yeah, in that particular sequence the flicker is terrible, I'm not sure what caused it, the shutter speed varies a lot more than it should. From 1/30 - 1/80 - 1/30 seconds frame-to-frame in the beginning to even worse; 4 - 13 - 4 seconds in the end of the sequence.

But I also think this clip is a very good example to reproduce this "bug" or "missing feature" that I know other users also have been asking for. One user suggested automatic multi-pass deflicker, which would be a good idea if the algorithm is impossible to change..

However, if the deflicker algorithm just would invert/mirror the blue flicker curve with amplitudes of 100% instead of 50-70% like it seems to be doing, I think it should be possible to produce perfect results after just one pass of deflickering.

The best solution would be if your algorithm could adjust the images to perfectly fit the smooth green curve automagically. Send me the source code and I'll code it for v. 4.1? :-D

I guess it's a bit more complicated than " deflickerStrength = deflickerStrength * 1.5;".. But if you were able to figure out an algorithm that could adjust the images to follow the green curve (maybe by multiplying the exposure compensation values with a non-linear function?), users would also be able to do heavy editing/cropping/rotating of images in Lightroom and still get perfect results.

Or, to use a different term: Garbage in - Gospel out :-)

For a start, I would be very happy to see a slider/setting where you could set the "strength" of the deflicker, from 0-200% for example, and at the same time you could see the light red curve change in the preview..

Regards,
- Jørn

Jorn, you can trust me, the deflicker is fine like it is. It's not just adding strength. I've put lots of research into that algorithm and for the vast majority of sequences and users it works awesome. If it would be improvable, I'd already done it.
My focus is on "regular" sequences, that were carefully shot. Not totally messed up sequences.
I'd recommend shooting in M Mode like any serious time lapser does and learning the holy grail approach for transitions. I mean there is a reason that people use this.

In 4.0.3 I removed a bug that might have caused deflicker to be applied too weak on some sequences. Please check the new version.

Hi again!

Deflicker seem to be much better now, using version 4.2. It's still not applied strong enough on this particular "worst case" sequence I'm testing with, but now I can get acceptable results after about three passes, compared to maybe six passes in the earlier version. Also I've upgraded my rig from an old quad-core i7 to a brand new one with dual SSD drives, effectively cutting rendering times in half. So all in all I'm happy with the new version.

It seems that the crazy variations in exposure on the sequence above will lead to the sky being brighter while the ground becomes darker on some of the images. No matter if the images are perfectly aligned to average brightness, dark or bright parts of the image will still flicker. Maybe it could be possible to fix this with a (much) more complex algorithm which not only adjusts luminance but also contrast based on a histogram or 25/75 or 10/90 percentiles. Uhm. I'll tell you when I've figured out the algorithm :-P

Anyway, the visual deflicker is a very good feature, highly appreciated. :-)

Yeah, let me know ;-)

I found a way to get perfect results, I almost couldn't believe it was true after all this trying and failing :-D

If I don't follow the suggested workflow shown in the UI, and instead do deflickering first - and *afterwards* do the LR edit and auto transition stuff, I get close to perfect results in most situations.

In the particular worst-case clip above, I did adjust one thing on the keyframes before deflickering, I set the Lightroom preset to "Camera Landscape" to match the shot (and probably the embedded JPEG previews in the RAW files?). Then I deflickered and refined a couple of times, and finally I could edit the keyframes in just any way I wanted - cropping, contrast, exposure, everything, and the final results were still not flickering!

Noticed a few other strange things happening though:

- The preview when popped out to full screen seems to shaking a bit, moving a little bit up/down/left/right from frame to frame, even if the clips are not shaking at all.

- Keyframe crop angle sometimes jump to a completely different value, for example if I set the first frame to 0,5 degrees and the last frame to -0,5 suddenly the last frame could jump to 4 degrees and all the frames in between would also be wrong after auto transition. Had to erase all xmp files, restart LRTimelapse and start from scratch to get rid of the wrong values.

- Another tiny bug is that the preview sometimes won't render all images, about half the images may randomly be rendered with previous metadata or maybe with embedded JPEG images.

These bugs have happened a few times now, I've finished editing about 50 of 100 clips, and unexpected things still happens now and then.. but it seems like it helps to restart LRTimelapse between the clips.

Anyway, these are just minor bugs and are not bothering me at all.

This post was last modified: 2015-08-13, 11:42 by Gunther.

It's hard for me to retrace the bug you are talking about, without seing them and the log file.

Animating the crop is always a bit risky due to the way lightroom handles it. If you animate the rotation, make sure to have space around the crop. If some value (like crop) gets messed, you can reinitialize only this value by right clicking onto the table header of one of the crop values and "Initialize column".

Thanks for the tip with deflickering first, indeed, in some cases this might help (indeed it would do quite the same as "simple deflicker" in the basic workflow) - but I wouldn't recommend it as general approach.