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

Started by dmilligan, October 17, 2013, 12:32:09 AM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

dmilligan


pilgrimage

Hi,I bridgeramp latest version installed.How I Can this problem ? Where is the problem ? Pls Help me ?


Adobe Bridge Message ;

An error occurred while running a startup script named 'Bridge'.  It may not be compatible with this version of Bridge; you can check for available updates by selecting the Updates command from the Help menu.  The script has been disabled, but can be re-enabled in the 'Startup Scripts' section of Preferences.

Error in /Users/xxxsss/Library/Application Support/Adobe/Bridge CS6/Startup Scripts/Bridge.jsx
Line 1740: <td class="blob-line-code"><div class="code-body highlight">
<div class='line' id='LC1'><span class="err">#</span><span class="nx">target</span> <span class="nx">bridge</span></div><div class='line' id='LC2'>
</div><div class='line' id='LC3'><span class="cm">/* Copyright (C) 2013 David Milligan</span></div><div class='line' id='LC4'><span class="cm"> *</span></div><div class='line' id='LC5'><span class="cm"> * With additions (C) 2014 by Paulo Jan</span></div><div class='line' id='LC6'><span class="cm"> *</span></div><div class='line' id='LC7'><span class="cm"> * This program is free software; you can redistribute it and/or</span></div><div class='line' id='LC8'><span class="cm"> * modify it under the terms of the GNU General Public License</span></div><div class='line' id='LC9'><span class="cm"> * as published by the Free Software Foundation; either version 3</span></div><div class='line' id='LC10'><span class="cm"> * of the License, or (at your option) any later version.</span></div><div class='line' id='LC11'><span class="cm"> *</span></div><div class='line' id='LC12'><span class="cm"> * This program is distributed in the hope that it will be useful,</span></div><div class='line' id='LC13'><span class="cm"> * but WITHOUT ANY WARRANTY; without even the implied warranty of</span></div><div class='line' id='LC14'><span class="cm"> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the</span></div><div class='line' id='LC15'><span class="cm"> * GNU General Public License for more details.</span></div><div class='line' id='LC16'><span class="cm"> */</span></div><div class='line' id='LC17'>
</div><div class='line' id='LC18'><span class="kd">var</span> <span class="nx">percentile</span> <span class="o">=</span> <span class="mf">0.7</span><span class="p">;</span></div><div class='line' id='LC19'><span class="kd">var</span> <span class="nx">evCurveCoefficent</span> <span class="o">=</span> <span class="mi">2</span> <span class="o">/</span> <span class="nb">Math</span><span class="p">.</span><span class="nx">log</span><span class="p">(</span><span class="mi">2</span><span class="p">);</span></div><div class='line' id='LC20'><span class="kd">var</span> <span class="nx">keyframeRating</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span></div><div class='line' id='LC21'><span class="kd">var</span> <span class="nx">iterations</span> <span class="o">=</span> <span class="mi">3<
/

dmilligan

Looks like you downloaded the HTML page containing the script rather than the script itself

pilgrimage

Hi, How Can I Solution ?

Your writed solution past !

Thankyou.


tsskin:
Great! Let me deflicker some other timelapse. Be back with the results.
Thank you!

itsskin:
An error occurred while running a startup script named 'BridgeRampingScript'.  It may not be compatible with this version of Bridge; you can check for available updates by selecting the Updates command from the Help menu.  The script has been disabled, but can be re-enabled in the 'Startup Scripts' section of Preferences.

Error in /Users/itsskin/Library/Application Support/Adobe/Bridge CC/Startup Scripts/BridgeRampingScript.jsx
Line 736: int timeout = 30;//30 seconds
Illegal use of reserved word 'int'

dmilligan:
Haha, I've been writing too much C recently...

dmilligan:
try it now

itsskin:
You are awesome :D Working now. int... var... who cares :D
Please give me some some time to run it with some test material.

pilgrimage

I am try new upload script.

But New Error Message ;

An error occurred while running a startup script named 'BridgeRampingScript'.  It may not be compatible with this version of Bridge; you can check for available updates by selecting the Updates command from the Help menu.  The script has been disabled, but can be re-enabled in the 'Startup Scripts' section of Preferences.

Error in /Users/alperaykut/Library/Application Support/Adobe/Bridge CS6/Startup Scripts/BridgeRampingScript.jsx
Line 81: var rampCommand = MenuElement.create("command", "Ramp...", "at the end of Thumbnail", this.rampMenuID);
create redeclared

dmilligan

strange, I have no idea, works fine here with CC, and I'm pretty sure it has worked with CS6 in the past

pilgrimage

ı new installed mac os bridge CC.Solution Problem :)

thankyou.

barepixels

What is the proper way to deflicker with key frames in Bridge



As you can see above, there is a huge jump in exposure between 151 and 152 (ETTR ISO jump)

What if I want a smooth transition from 146 to 157.  how do I set a keyframe for them?  do I put 1 star for frame 146 and 2 stars for frame 157?  Also what you would recommend for the percentage?
5D2 + nightly ML

dmilligan

Just put one star for any frame you want to be a key frame (it won't be touched). You can also just select only those frame and deflicker them (first and last frames automatically become keyframes). The default percentile is usually pretty good. You can look at the preview, it will show you where that percentile falls on the image.

barepixels

I can not get it to work

First I had them as 16bit TIF and ran like 60 time
Then I convert all to JPG and tried 30 times
The I isolate just them 12 JPGs and try 30 times

Didn't see any changes

Thnx
5D2 + nightly ML

Danne

I actually tried this little trick and got some good results on my raw files a while ago(see below). Try flatten your images first before deflicker. After deflicker go back with contrast etc.

"The best way to get good results deflickering going day to night I lowered contrast and blacks to get a much flatter picture. I this expected? When deflickering contrasty series I get inconsistencies that wont deflicker. Thought I should share my little tip.
Thanks
/D"

dmilligan


dmilligan

Quote from: barepixels on August 02, 2014, 07:27:59 PM
I can not get it to work
Works fine here. Maybe try opening all the images in the ACR dialog and click synchronize. This should create/initialize the XMP metadata if it's missing.

barepixels

@Danne   thnx for the tip

@dmilligan  that was it.  The problem I have is with Adobe Bridge 2014 and ACR, my bridge is not working with ACR nicely... need to find a fix.  Once I hear those files works for you I tried the synchronize via Bridge CS6 and ACR and it works beautifully.  Thank you so much.



LRTimelapse and dmilligan's amazing Adobe Bridge Script
5D2 + nightly ML

isaacgolding

For what it's worth I just discovered this script and have gone back through my old time lapses and been throwing them at the script.   The stuff I shot in simple AV mode time lapse seems to be a lot better than the stuff I shot  via ETTR time lapse.

I'm still trying to wrap my head around the ETTR Time lapse.  But for me my problems seemed to be around time lapse day to night and ISO changes...  the pictures would keep getting brighter and brighter in ETTR mode and the ISO values would start climbing..

To be clear here... what I'm trying to suggest is that if you are doing ETTR timelapse and throw the results at the the deflicker /ramp script I would suggest the following:

Start with AV mode.  It's a tried and tested method of shooting timelapse with a SLR and for the most part your only problem is flicker.  Shoot a good 3 or 4 hours of 30 sec interval captures and shoot it with sunset right in the middle of the timeline.

Then bring those captures to ACR and the deflicker script. This is exactly what I'm doing right now.   I took 3 cameras out tonight.  A GoPro (just because I can)... a Canon 350D shooting raw in AV mode with intervolmeter and the 5dmark3 shooting ETTR with ML.  I can tell you my 5dMK3 stuff is just a hot mess and I'm pretty sure its my fault.   But the 350D stuff deflickers real nice in ACR with the script.    This might be a good starting place for you to figure out where the problems are.


Joachim Buambeki

Quote from: Joachim Buambeki on November 07, 2013, 03:32:58 AM
Will take a while, sorry.
I just realised my CPU fan isn't working anymore and probably didn't in the last days aswell....
So my general lagginess in Bridge and the random crashes I had were likely caused by that.
I'll get back to you ASAP.

Hi David,

took me abit longer than expected to get everything running again... I hope you excuse my slightly delayed update on my problem.  ::)
I see you kept working on the script in the meantime, really glad to see it still beeing maintained.
The good news are that I got a new machine that should serve me much better than the old one. Bad news is that I still have the same problem with the same sequence I tried last time I wrote in this forum. I did a three pass deflickering with a percentile of .7 and .25 (that is the value that targets the even foreground) but the flickering is still much worse after deflickering than with the original sequence (where there was *almost* none). Everything on a fresh installation of CC2014 on OSX.
If you need it I can send you a small encode of the sequence via dropbox if you need it.

Also:
Did you ever think about a feature to stabilize/deflicker white balance? When the sun is covered by clouds the colour temperature becomes cooler (right?!), could that be eliminated by looking at the histogram to adjust the WB?

Could you implement a feature to auto create a certain amount of keyframes automatically to the context menu? Like selecting it and then it evenly creates n amount of keyframes evenly over the whole sequence. For a sunset, editing the start and end point just isn't sufficient.

What about an option to initialise metadata? That would make it easier to deal with animating the gradient but you could also add the author of the image and other metadata (location for example) without Lightroom.

What about an option to create a backup of the XMP data within the sequence folder that is just called "XMP Snapshot - date and time" or something? That is the way I backup my xmp files and would save me quite a few clicks in the process. :-)

About the context menu:
IMHO it would easier to spot the script options if they weren't divided by the dividing lines. If you don't want to change that, can you tell me how to do it (I would also add an asterisc or something for myself), please? I guess different colours are out of the questions because Adobe doesn't allow that?!


Keep up the good work, David!

Cheers
JB

Joachim Buambeki

David, I would like to revisit the deflickering topic again. Please excuse me if I just don't understand it what you are saying:

Quote from: dmilligan on November 04, 2013, 05:14:03 PM

Technically it's not the average, but the median (or some other percentile of your choosing, median is simply the 50th percentile), which is much more statistically robust than the mean. Notice how the median is the same between the two different statistical distributions on this graph, while the mean and mode are different (a histogram is a type of statistical distribution)

Your two different parameters are exactly the same thing in terms of this algorithm. You can either correct the exposure completly to the target or not by some amount. Change this by adjusting the coefficient I mentioned. Make it smaller. 2 / log(2) is the best estimation of the ACR black box that I've found, it would represent 100% deflicker (or at least as close as we can get by guessing). 1 / log(2) would be like 50% deflicker. 0 / log(2) would be no deflicker at all.
Yes, that should be possible assuming Br always uses the sidecars and doesn't ever store the metadata directly in the files, which has always been the case in my experience.

There are basically two different scenarios for deflickering:
1. A sequence where you have exposure changes that are totally unwanted, for example if shot in AV mode. Here you want to totally eliminate the changes in brightness of the sequence.
2. A sequence that is technically perfect (shot in M, lens with no aperture flickr, etc) but there is natural light flicker caused by passing clouds that make the image too dark.

I understand you can ellimate flicker for 1. with the script but with 2. I don't want the changes in brightness to be totally eliminated but just weakened (not 1 or 2 EV as in the RAW sequence but .4 to .8 approx in the render) to recreate how the human eye/brain perceives it when beeing on location. How does that work with the current algorithm? This what I was talking about in this post and the illustration of the curve.

Cheers
JB

Joachim Buambeki

Hi Paul,

I just re-discovered this thread and found your reply to me burried a few pages ago, so please excuse my late reply to this!

Quote from: PaulJBis on March 10, 2014, 05:46:13 PM
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.

First, let me say thank for those two links. I am not sure how exactly the info in the second link can be translated to the recent version of ACR. The problem is that when the sliders are at zero the image is far away from beeing linear. The problem was discussed by Christian Bloch here aswell. I assume the settings he recommends approximate a linear gamma pretty well tough. Writing this post I would think that one should be able to find out pretty close what settings create a linear gamma on PV2012 with Photoshop and the colour picker when comparing the same image processed with PV2010. Need to look into that when I find time...

Cheers
JB

dmilligan

Quote from: Joachim Buambeki on August 15, 2014, 08:03:51 PM
If you need it I can send you a small encode of the sequence via dropbox if you need it.
Yeah, that's probably the easiest.

Quote from: Joachim Buambeki on August 15, 2014, 08:03:51 PM
Also:
Did you ever think about a feature to stabilize/deflicker white balance? When the sun is covered by clouds the colour temperature becomes cooler (right?!), could that be eliminated by looking at the histogram to adjust the WB?
That sounds really complicated, and without much benefit. You'd also need to analyze the raw data, I only have access to a preview. However, if you have a proposal or description of how to do that mathematically, I'd certainly be willing to try and implement it.

Quote from: Joachim Buambeki on August 15, 2014, 08:03:51 PM
What about an option to create a backup of the XMP data within the sequence folder that is just called "XMP Snapshot - date and time" or something? That is the way I backup my xmp files and would save me quite a few clicks in the process. :-)
PaulJBis already implemented undo:
https://github.com/davidmilligan/BridgeRamp/pull/1

Quote from: Joachim Buambeki on August 15, 2014, 08:58:50 PM
I understand you can ellimate flicker for 1. with the script but with 2. I don't want the changes in brightness to be totally eliminated but just weakened (not 1 or 2 EV as in the RAW sequence but .4 to .8 approx in the render) to recreate how the human eye/brain perceives it when beeing on location. How does that work with the current algorithm?
There's no way to tell the difference analytically, so there's no way to do anything other than simply remove the flicker. Seems like it would look better without flicker anyway, even if the flicker being eliminated was 'natural'.


Joachim Buambeki

Quote from: dmilligan on August 15, 2014, 11:06:46 PM
Yeah, that's probably the easiest.
Will double check everything again and then send you samples of the unprocessed sequence and the processed as x264 encode, okay?

Quote from: dmilligan on August 15, 2014, 11:06:46 PM
That sounds really complicated, and without much benefit. You'd also need to analyze the raw data, I only have access to a preview. However, if you have a proposal or description of how to do that mathematically, I'd certainly be willing to try and implement it.
AFAIK white balancing is shifting the multiplier (<1, 1 or >1) of each channel in linear gamma, right? I just read this thread again and at the beginning you say that assume a gamma curve for the deflickering, is that correct? Why don't you use that curve to get somewhat close to linear and then compare the histograms of adjacent images with each other to find out if there is an offset? This is basically the same as deflickering, just separately for each color channel, right?
Please see the first 50secs of this video to illustrate the issue I am talking about - I am aware that you need to much more funky processing to get the results they are getting but fixing the WB would be a good start for less severe sequences.

Quote from: dmilligan on August 15, 2014, 11:06:46 PM
PaulJBis already implemented undo:
https://github.com/davidmilligan/BridgeRamp/pull/1
I noticed that after I installed the latest version of the script, but I am not sure how to use that really. Maybe Paul can chime in to explain it to me?

Quote from: dmilligan on August 15, 2014, 11:06:46 PM
There's no way to tell the difference analytically, so there's no way to do anything other than simply remove the flicker. Seems like it would look better without flicker anyway, even if the flicker being eliminated was 'natural'.
I don't think flicker should be completely removed in those cases because then it looks too unnatural.
Just for my understanding: The amount of passes run by the script mostly targets the precision of the deflickering and not the averaging, right?
I see that an algorithm has a hard time distinguishing between the two cases, that is why I am asking for the option to adjust the deflicker strength. I will try to rephrase the post I linked to.



Red graph = average image brightness (per frame)
Green graph = brutally averaged brightness target
Blue graph = gentle brightness target for pleasing and natural results©
Black bars = keyframes 1., 2. and 3.
With the current algorithm, everything between the keyframes 1. and 2. would get averaged out (represented by the green graph), right?
The blue graph represents my idea of the deflickering strength, when the strength is 100% the blue graph will look like the green one, when the strength is 0% the blue graph will be no different to the red one. When adjusting the strength to 40% the graph has about the appearance like in my illustration.
Maybe it is possible to be able to adjust high frequenzy and low frequenzy smoothing (I hope this is the right terminology for this) separately:
High frequenzy (HF) flicker would be single frames that are just off (because the AV mode made a bad decision or whatever the reason is). These spikes need to be eliminated obviously.
Low frequenzy (LF) flicker would be the smoothing of the curve on a wider scale, when the sequence gets darker because of bypassing clouds for let's say 50 frames between keyframes 1 and 2, we want it to be a bit darker (.5EV) but not as dark as the RAW files (1.5EV), also there should be gentle roll-off into this.

Removing HF flicker would only take into account the brightness of adjacent images while LF deflickering also takes into account the original brightness of the RAW file.

If the amount of passes is doing what I assume above, running multiple passes would improve the precision in the high frequenzy (and to some extent also in the low frequenzy) deflicker but not average out everything untill it has the same brightness.

Hopefully my idea is clearer now.


JB

dmilligan

Quote from: Joachim Buambeki on August 16, 2014, 10:59:33 AM
Will double check everything again and then send you samples of the unprocessed sequence and the processed as x264 encode, okay?
sounds good

Quote from: Joachim Buambeki on August 16, 2014, 10:59:33 AM
I don't think flicker should be completely removed in those cases because then it looks too unnatural.
Just for my understanding: The amount of passes run by the script mostly targets the precision of the deflickering and not the averaging, right?
The script runs extra passes b/c the preview is not totally accurate, and the deflicker amount is basically a best guess. In a prefect world I would be able to know mathematically how much some exposure adjustment would affect the histogram, but ACR is a black box and the preview I have to work with is limited. Hence, my guess is not perfect. Let's say I measure the median (not average, the script doesn't do anything with averages!) of two images I want to have the same apparent exposure, 120 and 140. I know I need to move the median by 20 units, but when I convert that to EVs with my approximation and then give that to ACR, I don't always end up with 140 and 140 when I measure the median again, I might say end up with 146 and 140 (my guess was too big). Better, but not perfect. So it's sort of ends up being like Newton's method. Once all the histograms match the expected values that should yield flicker free results, the script stops.

Quote from: Joachim Buambeki on August 16, 2014, 10:59:33 AM
Maybe it is possible to be able to adjust high frequenzy and low frequenzy smoothing (I hope this is the right terminology for this) separately:
High frequenzy (HF) flicker would be single frames that are just off (because the AV mode made a bad decision or whatever the reason is). These spikes need to be eliminated obviously.
Low frequenzy (LF) flicker would be the smoothing of the curve on a wider scale, when the sequence gets darker because of bypassing clouds for let's say 50 frames between keyframes 1 and 2, we want it to be a bit darker (.5EV) but not as dark as the RAW files (1.5EV), also there should be gentle roll-off into this.
All of this you are proposing would add way too much complication to what is a very simple and effective algorithm that is based on simple and robust statistical methods. I would also argue that "low frequency" flicker is not actually flicker at all by definition.

Joachim Buambeki

Hi David,

I just wanted to process the files to show that deflicker doesn't work but the problems with the script and me seem to never end no matter what OS or version of the software:




Before applying deflicker, all I did was processing the downrezzed DNGs (that were created from CR2 files), the first and last frame were marked with 1 star and their exposure was lowered (small amount for the first keyframe and larger amount for the second one). After pressing OK, the script stays stuck at the process shown.
Also, Bridge is behaving very buggy (with DNG, CR2, NEF files) - but I don't think it did when installed but only since a few days. It almost always crashes at some point. Restarting the computer also doesn't help. It always asks me to purge the cache when started again.
I don't remember it doing that the first time I was writing in this thread again two weeks ago.

Any ideas, David? I would really get this working because it is basically all I need to process my TLs but it seems it is not meant to be. :-(

Cheers
JB

PS: Did you get my PM?

dmilligan

Looks like you selected the undo data file to be deflickered (which is not an image).

getho

Just starting out with this. After using panolapse and LRtimelapse I'm stoked, cant wait to get into it: seems to have a vastly less faffy workflow

Just a quickee: read this thread but couldn't see any info on the analysis crop.  are the x,y values percentage or pixel values?

dmilligan