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

How to deflicker time lapse - 2 Pass advanced workflow

Offline
#1 gwegner
Okay, a lot of discussion has taken place because of uncertainties regarding the best way to deflicker. As a matter of fact it is a fairly complicated thing. The biggest constrain is, that LRTimelapse does not "see" developed images. Thus deflickering will be done on the original JPGs or - in the case of RAW files - on the JPGs embedded as preview in the RAW.
The more you change your development settings, the more inaccurate deflickering could get. This is because a lot of the Lightroom/ACR development settings doesn't act linear. Not even the exposure.

That's not really a problem, if you do it right you will get fantastic results, but you have to know how to do it.

My workflow:

1st pass
  1. Prepare your original images as usual in LRTimelapse
  2. Save
  3. Load the folder in Lightroom
  4. Make your edits/keyframes but don't exaggerate
  5. Save metadata
  6. Load the folder in LRTimelapse
  7. Make your transitions
  8. Turn on deflicker, set reference area (see deflicker tutorial!)
  9. Use the Smoothness slider to get a fairly smooth curve but please don't overdo it!
  10. Save your changes
  11. Go back to Lightroom, read the changed Metadata.

So far for pass 1. If you have done a lot of processing to you images (thus changing the end appearance severely in contrast to the original files/previews) you will run into the situation, that the original/preview images doesn't match with your development results. In this case I recommend making a second pass.

2nd pass
  1. Export the images with LRTExport plugin like you would for rendering the video.
  2. Open the LRT_*-folder with the intermediate sequence in LRTimelapse, ignore the warning. You may have to "refresh" above the folder panel to see the new folder.
  3. Initialize the XMP-Metadata
  4. Deflicker as usual
  5. Save
  6. In Lightroom: Load metadata for this new sequence
  7. Export time lapse video

Background:
this way you circumvent the constraint mentioned above. Applying all your settings in the first pass will provide of the whole dynamic range your RAW files offer, a slight deflickering will not harm as well. Now you are safe to switch into JPG processing.

In the second pass we don't need a huge dynamic range anymore, what we need is accurate input to LRTimelapse for deflickering. Because all of the settings are already applied, we can focus on deflickering with no side effects.

Certainly you can use this Idea for a ACR/AE based workflow as well.

My experiences gave me really great results with this workflow, please let me now if this works for you as well.

This is the original sequence without deflicker:
[Image: http://dl.dropbox.com/u/2088648/web/img/...ithout.jpg]

Here after the 1st pass (slight deflickering applied):
[Image: http://dl.dropbox.com/u/2088648/web/img/...stpass.jpg]

And here is the end result after the second pass, you can see the blue line is very smooth and flickerless:
[Image: http://dl.dropbox.com/u/2088648/web/img/...ndpass.jpg]
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
#2 Joachim Buambeki
Hi Gunther,

interesting, I had the same idea yesterday, but saved the reply to Alan's questions as a draft to write a more in detail reply later:

Quote:...
what you are requesting would require a two pass deflickering process that is hard to implement and would require lots of manual work or extensive of scripting if I am not mistaken.
We are basically discussing the issue you mentioned in this thread.
...


About the use of this method in AE:
Instead of doing a second pass in LRTimelapse you could use GBDeflicker directly in After Effects. The general consensus seems to be that this is the best deflickering software for timelapse (of course after having access to RAW data like LRTimelapse has), though I can't comment on how their deflickering algorithm performs compared to LRTimelapse'.
They have some neat ideas how to get flicker free footage like keyframing, perhaps you could adopt some of those into LRTimelapse?


To squeeze out the last bit of quality of the RAW files you could create a project file of the first pass of deflickering and use this to fine tune the .xmp data of the RAW images in a second pass.

Like that:
- Adjust RAWs in LR or Bridge
- save .xmp
- import .xmp/RAW files into LRTimelapse -> ramp values, deflicker
- save .xmp
- save project file (not yet implemented)

- Open in LR or Bridge, export developed Jpegs (no need for full quality/resolution)

- import developed Jpegs into LRTimelapse with the project file
- analyse them
- apply fine tuned deflicker data to the (already pre-deflickered) .xmp files values from the first pass.
- save .xmp data

- be happy


I don't know if that would lead to a visible improvement compared to the Jpeg workflow, so keep it with a grain of salt. In theory the results should be superior because of the bigger latitude of the RAW files.

Out of curiosity: Would you mind explaining how the deflickering works? Does it just measure overall luminosity (or the luminosity in the specified square) or is it using some fancy weighting?


Best Regards
David

PS: Have you to tried to run a third pass? I am curious if there is any improvement in doing so (especially with a fully RAW based worklflow).
Vimeo <<->> flickr
Offline
#3 Joachim Buambeki
Added some further questions and tried to clarify the text.

This post can be deleted.
Vimeo <<->> flickr
Offline
#4 apsphoto
Thanks for the detailed instruction. I have been thinking about this a lot. What if you did not want to export to jpg but wanted to keep the raw file as long as possible. (Whether it makes a big difference in a video I am not sure but coming from a mostly still photography background I want to keep the raw as long as possible). Sorry to drag this out but what I have is a sequence I want to save but there are some frames in the middle that have a radically different exposure because of an error in ramping. I can make them close to what the others are but it would be nice to include them in the deflicker.

I tried your method and it will work. However what I was thinking is that you could run the first run through LR-Timelapse like normal. Then go back and revist adjusting the exposure on the ones that need some fine tuning. Then instead of exporting to jpg, export to DNG. The DNG files has a new preview jpg that includes all the changes from the export but still has the raw frame data. The problem is that I have not been able to get Lightroom to write a xmp sidecar file for DNG because it embeds all the XMP data in the file header. Now if LR-Timelapse could read the header from the DNG file you could in essence run through another round of processing and adjustment and fine tune it based on the updated previews from the previous run. Then the XMP data could be written back to the header, then the DNG's could be read back into Lightroom or AE or whatever. This could be repeated as many times as needed without running through jpg compression, etc.

I don't know if this would work or if it is possible but I thought I would bring it up.

Alan
Alan Smallbone
Orange County, CA. USA
Offline
#5 gwegner
Hello Alan, thats a good idea, and I suppose it would work, if LRTimelapse were able to work with DNG. Unfortunately I couldn't manage to find a way to read / write metadata from / to DNG. Unfortunately Adobe doesn't provide a proper Java API.

Anyway: the difference in quality should be very slight, if noticable at all. The main development takes place in step 1, here you have all advantages of RAW-file processing. In step two only slight changes in exposure are made, I really doubt that someone will see a difference, if working with 100% quality JPGs.

Nevertheless I promise I will keep on looking for a way to work with DNG... (if some of you guys know an api, please let me know!)
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
#6 Joachim Buambeki
Hi Gunther,

what about the method I proposed? It offers the same benefits as working with DNG, but one doesn't have to convert the CR2 files to another proprietary file format.
Since I like to colour grade my footage futher in AE, working with JPEGs instead of the equivalent of 16bit tiffs (by opening the RAWs) is something I would like to avoid at all cost.

Best Regards
David
Vimeo <<->> flickr
Offline
#7 gwegner
Quote:-import developed Jpegs into LRTimelapse with the project file
- analyse them
- apply fine tuned deflicker data to the (already pre-deflickered) .xmp files values from the first pass.
- save .xmp data

Joachim, the idea is good, but I'm afraid it will not work.
If you develop the JPG and deflicker on that basis, you start with Exposure 0 for all images. If you apply the deflicker (for example +0.1) on this jpg you will get different results than applying the same amount of exposure correction to a raw with a previously set Exposure from maybe +1 leading to +1.1.

Normal Workflow:
RAW: Exp +1 -> JPG - > Exp +0.1

Your Workflow (gets the +0.1 from intermediate JPG):
RAW: Exp +1 -> RAW: Exp +1.1)

LR will develop this differently because Exposure is not linear in AC.

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
#8 Joachim Buambeki
Gunther, that is a valid point.
But can't you convert the values?
For example:
Correcting the Jpeg by +0.1 stops would translate to +1.05 (instead of +1.1) stops if for the if the RAW has been already corrected by 1EV.
Is my math correct?

Vimeo <<->> flickr
Offline
#9 apsphoto
(2011-03-04, 10:40)gwegner Wrote: Hello Alan, thats a good idea, and I suppose it would work, if LRTimelapse were able to work with DNG. Unfortunately I couldn't manage to find a way to read / write metadata from / to DNG. Unfortunately Adobe doesn't provide a proper Java API.

Anyway: the difference in quality should be very slight, if noticable at all. The main development takes place in step 1, here you have all advantages of RAW-file processing. In step two only slight changes in exposure are made, I really doubt that someone will see a difference, if working with 100% quality JPGs.

Nevertheless I promise I will keep on looking for a way to work with DNG... (if some of you guys know an api, please let me know!)

Gunther,
I found this, it should work, they support cameras that produce DNG:
http://jrawio.rawdarkroom.org//

I don't know if you tried it or if this is what you use currently. I am not much of a programmer but I will poke around and see what else I can find.

Thanks!

Alan
Alan Smallbone
Orange County, CA. USA
Offline
#10 gwegner
thank you apsphoto, jrawio is what I use. But unfortunately it doesn't allow to read/write xmp-metadata from generic DNG files.
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

...also check out: