This script is obsolete; I've implemented the same algorithm directly in the camera (
Post Deflicker (http://www.magiclantern.fm/forum/index.php?topic=10496)).
If you are interested in the internals of this algorithm, you are welcome to take a look.
Bulb ramping is not 100% flicker-free and it will never be, since it measures the exposure from previous shots and it won't account for natural flicker. At fast shutter speeds, the flicker comes from the discrete shutter speeds enforced by Canon firmware.
So, I'm trying to get a script which should do perfect deflicker, based on robust statistics (median) and RAW image data. It should work even if you simply shoot in Auto or Manual, without any ramping.
Version 0.2 - tested on 800 pictures (video below) and added a real-time deflicker graph.
Version 0.1 - only tested on 10 pictures, with very promising results.
You need Python 2.x, numpy/scipy/matplotlib, dcraw, ufraw, imagemagick... and hopefully that's all.
Usage: create a folder named "raw" and another one named "jpg", paste your CR2 files under "raw" and run the script.
# RAW deflickering script
# Copyright (2012) a1ex. License: GPL.
from __future__ import division
import os, sys, re, time, datetime, subprocess, shlex
from math import *
from pylab import *
def progress(x, interval=1):
global _progress_first_time, _progress_last_time, _progress_message, _progress_interval
try:
p = float(x)
init = False
except:
init = True
if init:
_progress_message = x
_progress_last_time = time.time()
_progress_first_time = time.time()
_progress_interval = interval
elif x:
if time.time() - _progress_last_time > _progress_interval:
print >> sys.stderr, "%s [%d%% done, ETA %s]..." % (_progress_message, int(100*p), datetime.timedelta(seconds = round((1-p)/p*(time.time()-_progress_first_time))))
_progress_last_time = time.time()
def change_ext(file, newext):
if newext and (not newext.startswith(".")):
newext = "." + newext
return os.path.splitext(file)[0] + newext
def get_median(file):
cmd1 = "dcraw -c -D -4 -o 0 '%s'" % file
cmd2 = "convert - -type Grayscale -scale 500x500 -format %c histogram:info:-"
#~ print cmd1, "|", cmd2
p1 = subprocess.Popen(shlex.split(cmd1), stdout=subprocess.PIPE)
p2 = subprocess.Popen(shlex.split(cmd2), stdin=p1.stdout, stdout=subprocess.PIPE)
lines = p2.communicate()[0].split("\n")
X = []
for l in lines[1:]:
p1 = l.find("(")
if p1 > 0:
p2 = l.find(",", p1)
level = int(l[p1+1:p2])
count = int(l[:p1-2])
X += [level]*count
m = median(X)
return m
ion()
progress("Analyzing RAW exposures...");
files = sorted(os.listdir("raw"))
i = 0;
M = [];
for k,f in enumerate(files):
m = get_median(os.path.join('raw', f))
M.append(m);
E = [-log2(m/M[0]) for m in M]
E = detrend(array(E))
cla(); stem(range(1,len(E)+1), E);
xlabel('Image number')
ylabel('Exposure correction (EV)')
title(f)
draw();
progress(k / len(files))
progress("Developing JPG images...");
i = 0;
for k,f in enumerate(files):
ec = 2 + E[k];
cmd = "ufraw-batch --out-type=jpg --overwrite --clip=film --saturation=2 --exposure=%s '%s' --output='jpg/%s'" % (ec, os.path.join("raw", f), change_ext(f, ".jpg"))
os.system(cmd)
progress(k / len(files))
[/size]
If you have some RAW footage with lots of flicker, please let me know, I'd like to test the script on some more demanding scenarios.
How big are the RAW files you generate, how big a card did you have for this moonrise? Seems like overkill for timelapse, but better for deflicker I guess.
For this example, the 850 sRAW shots have 10 GB.
There are no extra files generated by this workflow, only the final JPEGs developed from CR2's. The JPEGs took 135 MB.
I have some raw footage with flicker Alex, let me know how do we do it
Quote from: a1ex on September 05, 2012, 08:58:03 AM
If you have some RAW footage with lots of flicker, please let me know, I'd like to test the script on some more demanding scenarios.
I'll test it on something I have did with LRTimelapse, it's a timelapse done during the day only so no bulb ramping.
wow, looks very promising
EDIT: use the latest ufraw from CVS if your raws are coming from a 5dmk3.
Yes, I've used the CVS UFRAW.
You have probably set a ramping speed factor too small.
Quote from: a1ex on September 07, 2012, 02:04:25 PM
Yes, I've used the CVS UFRAW.
You have probably set a ramping speed factor too small.
Compiling the CVS version now, should have a new lapse tomorrow.
0.050 EV for 15 seconds.. same as you suggested to me (if you meant max RampSpeed?).
Here's the graph:
(http://a1ex.magiclantern.fm/bramp/nick-BRAMP027.png)
When the jump occured, ML was ramping at 0.11 EV / picture. When it has to ramp at twice the speed selected in menu, it jumps and no longer cares about smooth transition.
New deflicker test, with some older footage:
I also wrote a small Windows GUI for this: if you'd like to try it, contact me. It should work on Mac too, in Wine.
(http://a1ex.magiclantern.fm/RawDeflicker/RawDeflicker.png)
Would it be possible to output to .xmp instead?
If I understand well, that's some sort of EXIF info, no?
All the script does is to compute an exposure compensation for each RAW picture, so it shouldn't be hard. Do you have any links?
I'd love to try it out as it sounds uber cool! Just need to find some (read: plenty of) time and go grab a timelapse :D
Did you use bulb ramping (in-camera) when capturing the latest timelapse?
The latest example was shot with an older version of bulb ramping.
This was from the same RAW shots: http://vimeo.com/44261518
MSU deflicker could not handle it, so I had to use heavy frame merging.
Quote from: a1ex on September 09, 2012, 03:48:08 PM
If I understand well, that's some sort of EXIF info, no?
All the script does is to compute an exposure compensation for each RAW picture, so it shouldn't be hard. Do you have any links?
Not really an EXIF info, rather a sidecar file associated with the original RAW. If you can manage just to write the exposure compensation into the .xmp, we can continue processing the RAW files in Lightroom / Aperture or whatever program without going through the rather hard process of manual or semi-automatic deflickering. But after your script is done, we can still continue the RAW processing workflow.
Right now, your script is outputting to JPEG and doing so at the beginning of the workflow the postprocessing is done on a rather compressed format.
Wikipedia - XMP file example (http://en.wikipedia.org/wiki/Extensible_Metadata_Platform#Example)
Looks like exiftool can also set xmp tags, so probably it can be embedded in raw files:
exiftool -xmp:ExposureCompensation=2 IMG_1234.CR2
Can you confirm that your software recognizes exposure compensation set in this way? If yes, it's easy to modify the script and set the tags rather than developing jpegs.
YES! Lightroom can definitely read metadata attached to a sidecar .xmp. Don't know for Aperture, but my guess it that it can read attached .xmp's as long as the filename is the same.
Great. Then, I think you can replace the last loop with this:
progress("Updating XMP tags...");
i = 0;
for k,f in enumerate(files):
ec = E[k];
cmd = "exiftool -xmp:ExposureCompensation=%f '%s'" % (ec, os.path.join("raw", f))
os.system(cmd)
progress(k / len(files))
or, for separate xmp files:
progress("Creating sidecar XMP files...");
i = 0;
for k,f in enumerate(files):
ec = E[k];
cmd = "exiftool -creator=me -xmp:ExposureCompensation=%f '%s'" % (ec, os.path.join("raw", change_ext(f, '.xmp'))
os.system(cmd)
progress(k / len(files))
Let me know if it works for you. I don't use Aperture nor Lightroom (just ufraw and some scripts).
Thanks a lot, Alex!
It will take some time, haven't written a single line of code in 15 years, probably it will take me a few days to be able to run a script in python! :)
I'll keep you posted if it works, once I get the grip of it :)
+1 for metadata usage. In Lightroom, it's also super-easy to re-read the metadata for imported images (right click images and select Load metadata from file), and it works great with Lightroom's specific-setting syncing between multiple photos!
Quote from: dan.g on September 09, 2012, 07:09:26 PM
YES! Lightroom can definitely read metadata attached to a sidecar .xmp. Don't know for Aperture, but my guess it that it can read attached .xmp's as long as the filename is the same.
theuy also read exif data so why have another file?
True. But Lightroom doesn't write exposure, white balance, etc. in EXIF in RAW files, afaik. I maybe wrong, though. So, this pushed me and lots of others to use sidecars where data can be both read and written. So, old habits die hard now :)
The script works brilliantly.
Deflickered:
Original:
I'll try the .xmp mod next and see if I can post-process further in Lightroom and still export with no flicker. :)
Thanks for all your hard work Alex!
Quote from: scrax on September 09, 2012, 08:40:04 PM
theuy also read exif data so why have another file?
EXIF data is read-only and shows values that were used at the moment that a photo was taken (shutter speed, aperture, ISO, WB, etc.). XMP files contain much more info, and they are read/write. All the settings available in ACR (Adobe Camera RAW) such as highlights, shadows, noise reduction, colour shifts, etc. can be saved and read from the XMP.
Regarding the XMP files, I don't know if you are aware of this, Alex, but what people is asking for, is something similar to what LRTimelapse (http://lrtimelapse.com) does.
What do you mean? LRTimelapse has a huge feature list and they say it already does almost perfect deflickering.
Here is my test using the script default on a short bramped timelapse at sunset. AE renders of scripted, original and Sapphire plugin flicker remove.
Thanks a1ex for letting me try the script. It works really well. Like others have mentioned here XMP output will be great. I don't have any knowledge of coding or programming so have no idea how easy or difficult it is to implement. No matter what thanks for ML.
Quote from: a1ex on September 10, 2012, 06:42:31 AM
What do you mean? LRTimelapse has a huge feature list and they say it already does almost perfect deflickering.
Far from it really according to my experience :/
Quote from: Nick on September 10, 2012, 12:01:52 PM
Far from it really according to my experience :/
I second that. But then again, it might be that I didn't really get the grip of LRTimelapse. Best thing one can do is to adjust manually every single RAW file, but this is close to a nightmare. And if you aren't a pro obsessed with details, it hardly justifies the time spent on this procedure.
I'm still trying to run the script that Alex provided to us; unfortunately it freezed my PC earlier this morning. Gonna give it a second try before buying a better PC in a couple of months.
btw Nick, nice timelapse, even if it's more or less a technology preview. Can't wait to see some nice footage from you! Also, nice sunset Jayhas!
XMP confirmed to be working, update coming soon :)
Quote from: a1ex on September 10, 2012, 09:12:16 PM
XMP confirmed to be working, update coming soon :)
Great :D looking forward to testing this.
Quote from: a1ex on September 10, 2012, 06:42:31 AM
What do you mean? LRTimelapse has a huge feature list and they say it already does almost perfect deflickering.
I mean the writing to the XMP file, LRTimelapse does that to every RAW file. But from my experience, LRT is not really great at deflickering, I mainly use it for ramping exposures/WB.
I have a shot I'd like to deflicker with your script. Please send me the GUI tool so I can test it.
Edit:
Quote from: a1ex on September 10, 2012, 09:12:16 PM
XMP confirmed to be working, update coming soon :)
Great!
Quote from: a1ex on September 10, 2012, 09:12:16 PM
XMP confirmed to be working, update coming soon :)
Cool! Looking forward to it :)
Quick test I shot yesterday:
The deflickered version is definitely much better, although you can still see when the ramping took place. Next time I will also use the turn-lens trick to reduce flicker caused by EF lens.
This was shot in Av. It did a pretty good job considering the crazy amount of flicker. I guess a second pass will get rid of all the flicker.
I smell some incompatibility with Av mode. Keep the RAW footage for this, it's a good test subject.
Quote from: a1ex on September 12, 2012, 06:43:38 PM
I smell some incompatibility with Av mode. Keep the RAW footage for this, it's a good test subject.
Don't worry, I never delete my RAWs.
I tried everything to save that footage. Finally I got rid of the flicker using LRTimelapse + Donald Graft's deflicker plugin for Virtual Dub, the second one did the magic.
Small question before I test : Will it work with Small raw files (half res) ?
Of course.
Quote from: a1ex on September 29, 2012, 05:06:44 PM
Of course.
Ok thanks. I asked because a famous software I use (DxO) does not support those files afaik.
I had a play with this the other night, worked nicely but my footage was a little shoddy, need to give it another run. :)
Just some general thoughts about bulb ramping/post process correction...
In my mind it seems that how your eye/brain expects to perceive brightness transitions isnt (necesarily) consistent with having the whole scene sampled.
For example,
Lets say you are shooting a timelapse that has 50% foreground items, 50% background hills and sky.
Lets say that where you are standing, there is no cloud cover overhead, consistent lighting conditions of foreground items.
The only change to foreground item brightness occurs with the reducing natural sunlight or whatever.
However in the background of what you are shooting, there are rolling clouds causing rapid variations in brightness to the sky in that portion of your shot.
When the clouds dissapear and it's bright sky, the brightness of the sky causes exposure compensation to the foreground, despite no fluctuating lighting changes actually occuring there.
And vice versa.
The visual impact is an exposure 'wobble' to foreground items which was not present in reality, and a single foreground items flicker event across many frames that is impossible to compensate for when sampling the whole frame.
What I think would work well to eliminate this would to have two groups of RAW files to work from initially.
Folder A contains images to sample from
Folder B contains images to apply correction to
Folder C contains output images
In folder A, you edit the images so that they no longer contain the 'unstable' portions, for example you could crop out the sky, or mask out areas perhaps so it only samples from the foreground or areas where you want the stability in ramping.
Then you run the script, so something like:
FolderA\Image1.CR2 - checks exposure etc of cropped image (foreground items only)
FolderB\Image1.CR2 - applies brightness settings across to the whole scene contained in this file
FolderC\Image1.JPG - the output file
So you should be able to eliminate the 'long' flicker events quite easily I'd imagine.
The video thats a few posts above with the mountain with the clouds rolling overhead is an example of where I think the above methodology would perhaps work great, if you sampled from only the bottom half of the shot for exposure correction.
Right - my solution for these cases would be to crop the input images, so clouds are not included in exposure metering. Or, adjust the percentile a bit, like in ML bulb ramping.
Currently it's not easy to change the percentile - you can get 25% and 75% quite easy with two median calls, but for arbitrary percentiles - this needs to be written from scratch.
Yep for sure.
I'm sure there'll be some software kicking around that can do a batch crop of RAW files. :)
I might take a timelapse where this scenario is likely, and then try run your program against a set of full and cropped RAW files and compare results to see if it would give useful results.
One question.
My understanding of RAW format is that it effectively captures all ISO levels.
However when you are setting up your shot and previewing it, the ISO you've selected adjusts the brightness of the preview shot at least.
So if you were shooting a RAW picture at ISO 100 it'll show you that you need a longer exposure than if you were at ISO 800 (And the bramp jumps ISO too in order to pick a shorter exposure again)
Is it better to aim for exposure time etc to suit ISO 800 (for example) as your end result, to give you more room to move it 'up or down' in post or are you always better off aiming for as lower an ISO as possible?
And if so, is it possible to lock it to say ISO 100 if you're shooting a timelapse in RAW so it adjusts exposure time only?
Captures all ISO?
What do you mean?
???
If you shoot a (for example) 12 second long exposure at F8 in RAW,
My understanding is that whether you shoot at ISO 100 or ISO 800, all of the same information is captured in the file, as ISO is a digital gain/amplification that is applied some time after the RAW data is captured... So can be done in post.
Although, I probably need to read up on it a bit more to get a better understanding.
Quote from: Roman on October 04, 2012, 08:32:50 PM
If you shoot a (for example) 12 second long exposure at F8 in RAW,
My understanding is that whether you shoot at ISO 100 or ISO 800, all of the same information is captured in the file, as ISO is a digital gain/amplification that is applied some time after the RAW data is captured... So can be done in post.
Although, I probably need to read up on it a bit more to get a better understanding.
ISO can't be changed in post, what are you talking about?
???
The "normal" ISO of a camera are generated by amplifying the signal, just like you amplify the sound of an instrument.
The digital ISO are obtained in camera, that's it.
He's half right, sort of.
Analog ISO can't be obtained in post processing.
Sometimes you can obtain the same effect of digitally pulled/pushed ISO in post processing altough the in-camera ISO settings is usually better as it is applied before raw / jpeg processing
depending on camera model, "analog ISO" goes up to 1600 or 3200.
if you go over this value, its just "digital ISO" which can be done in post also.
assuming you shoot RAW
Quote from: nanomad on October 04, 2012, 09:20:02 PM
He's half right, sort of.
Analog ISO can't be obtained in post processing.
Sometimes you can obtain the same effect of digitally pulled/pushed ISO in post processing altough the in-camera ISO settings is usually better as it is applied before raw / jpeg processing
That's what i said. He states that the camera stores a RAW file regardless of the ISO setting chosen which is wrong as the amplification of the signal (the analog way) has to be done when capturing light and passing it over to the A/D converter.
ISO is set at that moment, you can digitally fiddle with it but that doesn't change the true ISO value the photo was taken at.
Okay thanks guys, that makes sense.
I have got a comparison done in the Video section of this forum. I used LRTimelapse and compared its great effort to that of the easy click and forget a1ex program. I am impressed, to say the least! Even at default settings it looks just as good if not better! With a bit of work I think it will be really great!
http://www.magiclantern.fm/forum/index.php?topic=3217.0
http://www.magiclantern.fm/forum/index.php?topic=3221.0
Hi,
I've tried A1ex Raw deflicker script but I still have alot of flickering. Are somebody using this script and do you have any ideas why it is flickering so much? I tried different setting in ML auto, sunset, etc. I have even had the lens "turned" so that the aperture can't change but yet no luck...
http://youtu.be/R5QIl3CQv5M
BR Nicke
Quote from: a1ex on September 05, 2012, 08:58:03 AM
If you have some RAW footage with lots of flicker, please let me know, I'd like to test the script on some more demanding scenarios.
i got .. iwill upload files soon to google drive.. but i got here 100kb/s up so it take moment .if this is still possible
Edit :
its 20 gb ( 922 files ) and my google drive got 5 gb :/ .. i cant upload it :C i can get jpg`s but i thing this is not good idea :/
Hi,
your result looks awesome. I shoot the sun set in the pacific yesterday using bulb ramping on a 600d and ML 2.3. Right after the sun set exposure changed drastically and the frame afterwards is highly overexposed.
So, I'd like to apply the deflicker to jpegs or tiffs since I use Adobe Camera Raw to Develop my files. I like the effect, the clarity regulator has on the look, so i need either to change the original raw files without outputting jpeg or apply deflickering afterwards.
Can this be done?
Cheers!
Status update: latest findings about RAW histogram will allow me to integrate this algorithm in ML. This means flicker-free ramping from 1/8000 all the way to several minutes of exposure. That's called holy grail, right?
Don't expect it overnight. I have all the ingredients for this, but putting everything together is not trivial.
Yes! Great, a1ex :)
That sounds great! Can't wait to test it.
Hi A1ex
I would love to try this out, I've given the script a go, but I'm very new to Python. Any chance I can try out the GUI?
Hi,
In a nightly build I've seen a "LTR holy grail" option in the timelapse submenu.
Does that mean that the new algorithm is now integrated in ML and that we therefore do not need this workflow anymore ?
Thanks
I'm not familiar with the final solution, so please excuse my ignorance if I'm asking a question with an obvious answer to most of you? Has anyone tried using Optical Flow algorithms to reduce the flicker? Or is this using optical flow?