Keyframes seem to be emitted from deflicker adjustments, with their 'Exposure' left set to exactly what was manually selected no matter how much compensation is applied to the frames either side, causing the keyframes to flash.

CR2 files (Canon 5DmkII) - LRTL 2.3.1 - LR4.3 - Mac OS 10.8.3

Cheers,

Andy.

That's by design. Keyframes are meant to be "stuck" - otherwise when you match exposures between holy grail keyframes they will change as well and not match anymore.
Normally you should take care of flickering when shooting - especially for sequences with lots of keyframes.

But the frames either side of the keyframe DO have their exposure adjusted by the average brightness smoothing/deflicker algorithm. So in the final processed sequence keyframes can often have exposure values a third to half a stop different than the frames either side, causing a flash frame.

Are you saying the ABS/deflicker algorithm should aim to level everything out so the set keyframe brightness is the target and all other frames are adjusted to match this? If so this is not working properly for me. It will often apply considerable gain across keyframes, with just the keyframe itself omitted from this adjustment.

I would recommend to take care to avoid flicker when shooting Holy Grail (shoot wide open, use manual lenses or even "twist" the lens).
The thing is no matter if I do it the current way (stick the keyframes) or let the deflicker touch the keyframes - you will always get second best results when doing holy grail on flickering sequences.
The deflicker has to deflicker each segment separately so at the joints you might still have differences in brightness - regardless if it do it this or that way.

thanks for this info.. now i understand why I was getting flash frames ;-)

Hey Gwegner,

Aperture flicker is not my problem. I use the deflicker feature to smooth environmental changes. It does this well, making hectic shots much easier on the eye. Even if the deflicker is slightly different section by section, the results I get are good. This is the main reason I use LRT.

For example, I might see exposure running along at -0.3ish for a fair number of frames, because this section of the shot is bright sunlight, there is lens flair or some other reason. It will then jump back up to 0 for the keyframe, and then back down to -0.3ish afterwards.

I have to go through and manually adjust keyframe exposures as best I can based on the values LRT has chosen for the previous/subsequent frames. On complex sequences this is quite tedious and LRT would definitely do a better job than me.

Would it not be better for these frames to be adjusted by LRT? Even if the adjustment is not perfect, and the deflicker is not consistent between the sections, it's better than flash frames or manual adjustment!

I avoid using keyframes, other than the start and end, when I can. I essentially avoid using LRT unless I need this smoothing feature, which is to me invaluable and I've found nothing else that will take the edge off nature like this.

I've been reading through some of the features in LRT3, file management sounds like it could save me hours. It would be even better if handling keyframe deflicker was on the way too.

Cheers,

Andy.

Hi Andy, I understand. I might consider making this an option. In former versions of LRTimelpase I had it implemented like you want it (keyframes being touched by deflicker) - people complained about that because "KeyFrames" are meant to stay where they are. So I changed it.
So as I said, I might introduce expert option in the settings to switch between this two behaviours.

Hey Gwegner,

That would be fantastic. I guess I'm not using this feature entirely as intended, but it works really well. As I said, I find it invaluable.

I'm half way through grading a short with around 60 timelapse shots in it. Having this option would save me a lot of mucking around. And it's so easy to forget to adjust the keyframes and then spend two hours rendering rubbish. An option to handle this would be greatly appreciated.

On a separate subject, have you seen this?
http://www.magiclantern.fm/forum/index.p...0#msg54570

Not a perfect ramping solution but better than the hideously unreliable bulb options. Would the .xmp's Magic Lantern creates be useful to LRT? Also, I've found sequences produced like this suffer from minor contrast flicker even when exposure has been corrected. Have you ever tried using a combination of exposure and contrast adjustments to correct flicker?

Thanks for your help,

Andy.

@Andy: I just implemented the setting to allow the keyframes to be altered again by deflicker. After doing some tests I decided to set this as the default again. It will be in the next beta. Thank you!

For my thoughts on the Magic Lantern feature see here: http://forum.lrtimelapse.com/Thread-must...nitialized

Great stuff. Thank you.

And like CloudLapser, I'll send you an ETTR sequence once I have one worth working with. The software's pretty experimental right now but it has potential. It's metering from a RAW histogram, so could be pretty accurate.