Script for deflickering and ramping ACR (.xmp) settings in Bridge

[PaulJBis]

I am no experienced colorist, but changing white balance (hint: gamma correction), contrast and other things localy on an already highly graded image with a bad ratio of noise vs. signal (like a noisy milky way shot) is pretty hard to do for me within After Effects. If you would attempt to try/do it you would defeat the whole purpose of the scripting which is getting highest quality output from a RAW file IMHO. In that case you would be better off to output a flat interpretation of the actual RAW file and do ALL (=global and local) adjustments in AE or a designated colour grading suite like Speedgrade or Resolve.
By the way, all those features are implented in commercial software, some of them based on requests made by users.

I'm late to this, but...: if I understand you correctly, the underlying problem here is that Adobe Camera Raw can't pass to AE a true 32-bit image with all the dynamic range of the original RAW file. Hence your desire to do everything (even things like gradients) "before" AE, in the RAW processing phase.

Well, a possible solution might be here. In the last comment to this thread:

http://prolost.com/blog/2013/5/15/space-monkeys-raw-video-and-giving-us-all-youve-got.html

Stu mentions a tutorial about how to get the most dynamic range from Camera Raw:

http://prolost.com/blog/2006/3/16/linear-color-workflow-in-ae7-part-6.html

I wonder if you might find it useful.

[PaulJBis]

Oh, the same thing happens to me too. I get the ExtendScript toolkit window; in the Javascript Console to the side, I get: "temp file path: C:\Users\Paulo\AppData\Local\Temp\PercentilePreview.jpg"... but the file in question is not there.

I'm on Adobe CS6 (using Bridge 64 bit), on Windows 7.

Since I do have some experience with coding, I'll do some research and see if I can debug this.

Okay, I found the bug. In line 690 of your script, where it says:

output.exportTo(tempFilename, 100);

It should be
 

output.exportTo(tempFile, 100);

 Instead. According to the docs, the exportTo() function takes as its argument a "File" object, not a string.

I just tested it on Windows, and it does work. What I don't know is whether it will break on the Mac... 

Edit: works on the Mac too.

[dmilligan]

thanks I updated github

[NeonHeatDisease]

Finally something that works. Thank you so very much. Please PM the me the paypal link if its still not public, I'd love to contribute. Also:

[NickZee]

Nice Work @NeonHeatDisease
I found the PP links here, http://davidmilligan.github.io/BridgeRamp/ at the bottom.

Mr. Milligan,

I want to thank you for the effort you put into this script.  It is a true gem. 

What values need to be entered for Ramping Temp and Tint of TIFFS? 

Raw Temp is measured from 2000 to 50000 but with TIFFS -100 to +100.   And Tint from -150 to +150 in Raw and -100 to +100 with TIFFs.

Thank you

   

[dmilligan]

thanks!

Open a tiff and change WB/tint, and then look and see what gets written to the xmp sidecar, it might actually be a different tag name for non-raw data (in which case I'll have to update the script), otherwise you should just be able to set what you want in the first and last frame and do ramp multiple with WB and Tint check boxes checked and it will ramp from the first frame to the last.

I'll have a look in a bit.

[PaulJBis]

Hello again.

I'm starting to do some work to adapt the script to my workflow, which involves grading the RAW files to be as flat as possible and importing them into AE in order to do all the color correction there. This implies, among other things, using process 2010 for the RAW files... but also implies using a completely linear tone curve and zeroing out all the enhancements in Camera Raw (Brightness, Contrast, etc.).

I asked you a while ago whether the deflicker algorithm would work too in process 2010, and you mentioned that it wouldn't make much difference... but what about using PV2010 *and* the linear curve? (Note that, unlike in process 2012, the "linear curve" in PV2010 is really linear, at least AFAIK). Your current formula for calculating EV values is:

Code: [Select]

    (2 / log(2)) * log(value)
Would it serve equally for a linear curve?

[dmilligan]

Would it serve equally for a linear curve?

Doesn't matter what kind of curve you are applying to the image, the exposure slider still operates in EVs (on a logarithmic scale).

[painya]

I have a ton of footage for a movie I'm shooting and there is horrible flickering when we shoot indoors (we Didn't have kino flos or enough light to keep everything lit). If I export these as Tiff's and use this script will that work or at least help?

[dmilligan]

it certainly should

[painya]

Thank you so much! You just saved me a couple hundred bucks!

[PaulJBis]

I've modified the script to add a few things that I needed:

-The ability to ramp parameters from process 2010, instead of process 2012.

-The ability, likewise, to deflicker using the exposure value for process 2010, and the ability to save the deflickering data (the EV values) to an external file.

-I've also implemented an Undo stack. It's a new menu command: when you select it, it gives you the chance to undo the last few ramp/deflickers you've done, without having to back up the XMP files. (I should note: this feature currently works, but it has a few inconsistencies that I'd like to iron out).

@dmilligan: are you interested in merging these changes? How should I send them to you?

[dmilligan]

yes that would be great, the best way would be to submit pull request on github

[PaulJBis]

Okay. I'll have to learn to use git and open a github account first then... 

[smarjoram]

Hello, should this script work with jpegs? I have a very long sequence - images were taken every 10 minutes over a couple of years - with daylight - as you can imagine, it's quite flickery! I've installed the script and it shows up ok but when I try to use it I always get the 'more iterations may be needed' dialogue. I tried a short section with 20 iterations but still got the message.

I'm using a mac and CS5.5. I tried converting the files to tiffs, adding Camera Raw Default Develop settings, with/without keyframes. Not sure what else to try. I'd be extremely grateful for any help.

[PaulJBis]

The script might tell you that it needs more iterations, but do the results look acceptable to you? I've had cases where the script said so, but I still liked the results.

As for your question, the script works using the metadata stored in the XMP sidecars. You might have to configure your system so that it stores the metadata there, instead of in the file itself (I don't remember right now what Bridge does with JPEG files).

[dmilligan]

Yeah, the margin the script uses to determine if more iterations are needed is kind of tight. Basically the median of the histogram must match the expected value within 1. The idea being that this is as theoretically as good as the script can do, and if say you just left the script going over night and let it do as many iterations as it wanted, you wouldn't want it to stop until it knew it absolutely couldn't do better. What may actually be 'acceptable' to a human is an entire other matter, and probably somewhat looser. I usually just do a few and even if it says more are needed, I just watch it to see if its acceptable and if it is, I don't bother with more.

If you find, however, that the script isn't affecting the exposure value, and that's why it thinks it needs more iterations, then that is a problem.

[smarjoram]

Thanks for getting back so quick. I can't see any difference in the images - or any sign of xmp files. Would I need to give the images some first? - so it can then alter them? I suppose that's what I thought I might be doing when I added the default develop settings.

[PaulJBis]

Thanks for getting back so quick. I can't see any difference in the images - or any sign of xmp files.

Try entering Camera Raw's preferences and setting it to "save image settings" in sidecar XMP files.

[PaulJBis]

dmilligan: I just sent you a git pull request. If you have any doubts, feel free to ask.

[smarjoram]

Try entering Camera Raw's preferences and setting it to "save image settings" in sidecar XMP files.

Spent the afternoon trying out this and everything else I could think of - just don't think it'll work with jpegs or dngs that have the xmp data embedded. Would like to be proved wrong though - will have a look at GBdeflicker and LRtimelapse but would like to have a cheaper option. Would love to hear from anyone who got a jpeg sequence to work.

[dmilligan]

Ok, I think I fixed it, try the latest version. Before you run the deflicker you need to open all your jpegs in ACR (select them, right click and then 'Open in Camera Raw'), change the exposure setting for all of them (to some small amount like 0.05, change the first one and then just click synchronize) to 'initialize' the xmp metadata. Then it should work.

Maybe I can eventually figure out a way you won't need to open them in ACR first. But for now it doesn't work if you don't do that.

[smarjoram]

Thanks again for looking into it for me - I just downloaded a new version and tried again - still no luck I'm afraid. I apply the slight tweak to the exposure in ACR, synchronise and click done. I can see the slight tweak has been applied and there's a small icon in the top corner showing that it has xmp data. I apply the deflicker and I always get the 'more iterations' message. If I check the images in ACR I can see that the exposure is unaffected from frame to frame - whereas I'd expect there to be small adjustments after deflickering.

Let me know if you have any other ideas. As the time-lapse is still going to be running for another year I might go and switch over to raws from now on.

[dmilligan]

Update: just merged the pull request from PaulJBis. Some nice new features including undo and the ability to use Process 2010.

[Danne]

sweet