• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

Visual deflicker is driving me crazy!

Sad
Offline
#1 lage
Hi.
Since i cant shoot in holy grail mode, i rely heavily on visual deflicker.
But there must be some serious faults with the computing algorithms.
Running 1 pass is pointless. The changes in the computed luminance levels are so microscopical, that running 50 passes isn't enough to get the levels within the green line.
Then you run 50 passes of refinement. 100% CPU usage but levels still not within the green line.
Then you run another 50 passes. this time it does nothing , except increases the counter how many passes you have run. Right now it says i have run 250 passes of deflicker, in reality, it has run 150. It's still flickering.
To actually get it to work again, you have to select another set of images, then back again.
Then you run a set of refinements again. This run it starts by undoing previous refinements, so that the end result is worse than before you run the last passes!!! AAAAARGH!!!

Why these microscopical changes in luminance level? There must be an estimated level (green line) you want to get to? Why not set that level in the first pass, and then fine tune the level if necessary?

Something has to be done. Right now LRTimelapse is useless for me. The ramping is good, but if i cant get rid of the flicker, it's pointless.

As it works now, it would be faster if i had the option to type in the luminance level manually.

And performance. Java is a memory hog, adobe dng converter is eating CPU. Approx 1s per image times 1300 images times 150 passes of deflickering. Thats 54 hours. On a 6 core Intel i7 with 32GB RAM...
BR,
Lage
Offline
#2 gwegner
Are you only here to complain, or do you want help? If so please calm down a bit and let me help you. You can trust me that visual deflicker in LRT is the best you can get, for a reason it's the leading technology to deflicker on a raw file basis.
But you have to use it correctly.

First thing: there is also a reason, why there is a "Holy Grail Wizard". Because it speeds things up, which makes Deflicker more efficient. You say you can't use it. I think there might be a way, so let me know, why you can't use it.

Second: You need to set a meaningful reference area for deflicker, as explained in my deflicker tutorial. Otherwise, LRT will only see the whole image as one number and try to equilize this number across the sequence. If you have huge contrast images this might not be the best way. So make sure to find a suited reference area which shows the flicker effect only.

Third: Deflicker will only work with Luminance, not Contrast. If you have changes in Contrast, you can deflicker as long as you want, you'll never get rid of it although you might have a smooth curve. If you use a reference area, then you will be deflickering for that part, but in fact introducing flicker to other parts because the contrast changes.
The bigger the differences in luminosity in the images, the more contrast changes LR will introduce with some tools like Dehaze, Clarity, Whites, Blacks. Often it helps trendously to use the tone curve instead of the whites/blacks to do the editing. This is described here: http://lrtimelapse.com/news/use-the-new-...me-lapses/

Bottomline for visual deflicker as will most tools: you need to know them and use the correctly then they will deliver the results that you expect. Let me know why you think you can't use the holy grail wizard.
Check out my e-book Time Lapse Shooting and Processing!
Subscribe to the LRTimelapse Newsletter!

lrtimelapse.com - advanced Time Lapse Photography made easy!
gwegner.de - Fotografie, Zeitraffer, Video, Reisen.
facebook · Google+ · twitter · vimeo
Offline
#3 lage
No, i'm not only here to complain. I have reported several bugs that i found, that should be helpful to you.
But when something doesn't work I'll complain. I hope that you don't take it personally.
Of course i want help, but it's not easy to stay calm after wasting so many hours trying to get a decent output from deflicker.

First thing: I'm working on a timelapse of the lunar eclipse. It was shot with a Pentax K-3 and sky-watcher 200PDS Newtonian telescope. Temperature during this 5 hour shoot was -20°C. There is no way i can be on site and manually adjust exposure. I have to rely on automatic exposure. You have explained earlier to me that the holy grail wizard is not usable when using automatic exposure. Atmospheric interference causes exposures to differ slightly from image to image, thus causing flicker.

Second: The images is the moon against a black background. The whole image is the meaningful reference area.

Third: I have now re-edited my keyframes and set clarity, blacks, whites and dehaze to 0. All issues i mentioned in my original post remains the same. So what am i not using correctly now?

Could you please answer the questions i raised in my original post:

-Why these microscopical changes in luminance level? It takes hundreds of passes to get to the right level.

-Why does it stops working when doing several refinements? (Looking in the logfile revealed the cause: LRT believes there is no need for further refinement:
[2019-01-26 15:36:51] DEBUG: Starting multipass deflicker with 50 passes.
[2019-01-26 15:36:51] DEBUG: Pass 1 with 0 frames to deflicker.
[2019-01-26 15:36:52] DEBUG: Pass 2 with 0 frames to deflicker.
.
.
.
There is definitely need for further refinement, but LRT just ignores it.
Selecting another folder and back again gets refine to start working again:
[2019-01-26 15:45:44] DEBUG: Starting multipass deflicker with 50 passes.
[2019-01-26 15:45:44] DEBUG: Pass 1 with 989 frames to deflicker.
[2019-01-26 15:53:34] DEBUG: Pass 2 with 914 frames to deflicker.
.
.
.
But then, as mentioned below, it undoes previously acheived refinements before starting to refine again.)

-Why does it undo previous refinements when running refinements again, causing the final result to be WORSE than before i ran the refinement?

I still believe there are issues in the deflicker algorithms that needs to be remedied.

BR,
Lage
Offline
#4 gwegner
I've just also shot the lunar eclipse and deflickered - and I can assure you that those shots are the most difficult ones, because you are really going on the edge of what the camera sensors can handle in terms of dynamic range.

Further recommendations:
- set the reference area to the moon. That's what you want to have deflickered. The dark areas around will be underexposed and mislead the deflicker. Make sure that it only covers the moon. If you need to, you can animate the reference area to follow the moon.
- If you set the Accuracy to "more" on the deflicker panel, the algorithm will use a smaller threshold before it decides that the image is deflickered fine.
- If you shot in A-Mode and your camera created "jumps" in brightness (blue luminance curve shows zig zag form), you can mark those jumps with 2*/3* keyframes (keys 2 and 3 in LRT) and then apply the holy grail wizard (you'll need to reset deflicker otherwise the effects will add up). Most cameras smooth the adjustments in A-Mode, that's why the keyfames wizard by default doesn't detect changes when in A Mode. But if your camera produces discrete jumps, you can force it to work, as I've described.

In practical use over the years I never had to do more then 10 refine passes. If you need to, there is something else wrong - editing, reference area etc...
Check out my e-book Time Lapse Shooting and Processing!
Subscribe to the LRTimelapse Newsletter!

lrtimelapse.com - advanced Time Lapse Photography made easy!
gwegner.de - Fotografie, Zeitraffer, Video, Reisen.
facebook · Google+ · twitter · vimeo
Offline
#5 lage
Yes there are jumps in brightness, but small and a lot of them.
I started from scratch and let the holy grail wizard run(seems like LRT thinks i shot i M mode) But it overcompensates way beyond what i can adjust wit the stretch slider. How come? I've tried different values for aperture, but that has no effect.
Shutter speed varies from 1/3200s to 2s. I did one manual adjustment during the shoot, changing ISO from 100 to 200 during the eclipse, and back again after.

BR,
Lage
Attached Files
Thumbnail(s)
   
Offline
#6 gwegner
Okay, in that case the holy grail wizard is not the right tool. It's designed for sunsets and sunrises.
In that case I'd go for Visual Deflicker/refine with a reference area on the moon.

What I also can see from that image is that the images (even those of the uncovered moon) are quite underexposed. That means the black areas around the moon are clipped to black. This makes the deflicker fail, if you don't set a reference to the moon.
Check out my e-book Time Lapse Shooting and Processing!
Subscribe to the LRTimelapse Newsletter!

lrtimelapse.com - advanced Time Lapse Photography made easy!
gwegner.de - Fotografie, Zeitraffer, Video, Reisen.
facebook · Google+ · twitter · vimeo
Offline
#7 lage
Is there a way to copy the reference area from one frame to another, to a new position but keeping the size and proportions of the reference area?
Offline
#8 lage
Yes, they are intentionally exposure compensated -3EV, to prevent blown highlights during the partial eclipse phase.
Offline
#9 gwegner
The reference area will be migrated to the whole sequence by default. If you set a second one to another frame, you'll get asked, if you want to calculate an animation between those. The size of the reference area cannot be copied, but it also doesn't matter if it changes a little bit.

Underexposing 3 stops is not a good idea, since you'll loose a lot of dynamic range. The whole purpose of the holy grail approach (changing camera exposure while shooting) is to prevent this and get the best exposed images possible throughout the whole sequence.

Here is a timelapse of the lunar Eclipse that I shot in 2015, and edited with LRTimelapse back then.

https://www.youtube.com/watch?v=Ub9lDTnqcJ4
Check out my e-book Time Lapse Shooting and Processing!
Subscribe to the LRTimelapse Newsletter!

lrtimelapse.com - advanced Time Lapse Photography made easy!
gwegner.de - Fotografie, Zeitraffer, Video, Reisen.
facebook · Google+ · twitter · vimeo
Offline
#10 lage
Underexposing 3 stops is not a problem for the Pentax, and it prevents the blown highlights seen in your timleapse above.
The dynamic range is still sufficient.
Picking the moon as reference area worked much better, and here lies the root cause to all my deflicker problems, i believe.
Nearly all my timelapse shooting are done in low light conditions, very low light, like aurora and other night shooting.
There are simply no brighter areas to use as reference area, and LRT can't handle deflickering at low luminance levels, it seems.
Either the granularity of the luminance levels are too coarse, or LRT is doing the calculations too rough, not using all 3 decimals of the luminance values.
Using the moon as reference area is actually the first time ever i've got a flicker-free timelapse, and it only took 14 passes.
But this shoot is an exception for me. I normally have to rely on much darker reference areas.
So what can be done to improve deflicker processing with low light reference areas?

...also check out: