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

[dmilligan]

When shooting with Nikon in manual mode and adjusting exposure along a sunset/rise you don't have any flickering (except natural light flicker) if you use a manual lens apart from the obvious jumps in brightness. Could you implement a special mode for that where the two adjacent are just matched (pull down the brighter frame by half of the difference in EV and push the darker one by the same amount) and the rest is adjusted accordingly to the surrounding keyframes? Could they be detected based on metadata?
That is why I suggested to mark them with 2 and 3 stars for the first and second image of those pairs. According to my experience with deflickering that is based on image content you can only make it worse if you have perfect source material.

But you don't have perfect source material, you have flickery source material. It has discrete jumps in it. It sounds like you don't trust my algorithm (which it's not my algorithm, just my implementation). Why don't you try it and see if it doesn't produce satisfactory results. I think the error between the calculated EV and what ACR exposure actually does (it is 'image-adaptive' apparently) is going to be larger than the error achievable with several passes of deflickering, and that will be completely automatic.

Deflickering works on the histogram of the preview thumbnails that are extracted based on the current .xmp settings, right?

yes

Is it a problem if I use a super flat profile like this, if yes could you make it more robust?

My estimate for how to convert from the color space to exposure values is probably going to be wrong if you do that. Why not deflicker first, then apply the picture style? I think that should work.

Could the deflickering be sped up by working on lower resolution DNGs of the same images?

No, it's spending 99.99% of it's time generating the histogram from an already lowres 8 bit bitmap. The time it takes Br to generate this preview is a tiny fraction of the total time. Really the only way to significantly speed it up is to generate this histogram natively, which I haven't found a way to do. (or get Adobe to improve the efficiency of their javascript engine)

Would it be possible to have the deflickering only using certain parts of the frame?

Yes, but:

Would it be possible to have preview window where I can draw a rectangle that specifies where the brightness is measured?

That is something I thought about and would like to do, however, that would be incredibly difficult if not impossible to do in ScriptUI. After several hours of simply trying to display an image in ScriptUI (for the percentile preview), with no success I gave up . I just write the preview to a temp file and tell it to open it.

Could the multi-pass deflickering for best precision be automated?

Probably. I prefer to just check between each pass to see if I need to do another one, but I can add an option to run it multiple times. I'm pretty sure I can force Br to regenerate it's previews, so that shouldn't be a problem.

What exactly does percentile do?

That's the percentile of the histogram that is used to match histograms. If you choose 0.7 the script tries the make the 70th percentile on each histogram all at the same brightness.

How does the "Line Skip" work? Does it skip lines in the histogram?

It just skips pixels in the image when calculating the histogram. Analgous to how your image sensor line skips when shooting video. The only other way to speed things up is a 'crop' which difficult to define for the reasons mentioned previously.

What is preview under deflickering supposed to do? I get nothing when I press it.

It should pop up an image with the deflickering percentile highlighted in red dots, to help you choose the best percentile. (This might be a windows pathname issue, I'll see if there's a cross platform way to do this)

Any chance to get those animated gradients I mentioned? That would be tremendously useful for sunsets, milkyway and dolly shots. If you do that please implement the possibility to ramp more than one (3 linear and 2 radial ones should be more than sufficient)

Like I said before, I think it's probably best to do stuff like that in AE. You can work with 16 or even 32 bit data in AE, so I don't see the need for trying to do this kind of stuff in ACR.

Just a suggestion for better usability - maybe you could create tabs or divide them another way like they are arranged in the Camera Raw Dialogue? Also check groups additionally to single checkboxes.

The way the script is set up that would be hard and add a ton of UI code that I don't really want to have. The script automatically generates all those checkboxes based on a simple list of ACR property names which is easy and requires very little code. I'd rather keep this script somewhat simple.

Could you add ramping for the curves too?

No, it's not a simple scalar property, it's a collection of x,y points, very hard to ramp. Explain to me mathematically how to ramp a curve defined by varying numbers of x,y points. Just use the parametric curves.

I would love to have everything in AE instead of going back and forth between it and Bridge.

Alt-Tab. Br has much faster previews (pretty much the only way to quickly check flicker and get your deflicker right), and the multifile ACR dialog. IDK what I would do without Br when editing timelapse/raw, it would be a huge pain in the ... without it.

Bug report (though only a minor one):
The last digit of the amount of selected images is cut in half verticaly (meaning the right half is not displayed).

Tell Adobe to fix their buggy scripting UI

[Danne]

Tried importing to after effects, the cr2 as a sequence. This however doesn,t allow metadata to follow within every cr2 but applies only the first cr2 that pops up in acr. My last timelapse has no xmp sidecarfiles. It stores metadata inside the actual cr2. Might have something to do with it.

I really, really like the ramping script in bridge created by simply starring pics. metadata gets save quickly and I can switch between lightroom and bridge really fast.
Still exploring the deflicker option. Does a good job most of the time but started testing different percentiles which led to flicker in darker shots.
For now I export finished cr2 to jpeg which gets imported to AE and exported to prores. Works nice!
Thanks

[dmilligan]

Tried importing to after effects, the cr2 as a sequence. This however doesn,t allow metadata to follow within every cr2 but applies only the first cr2 that pops up in acr. My last timelapse has no xmp sidecarfiles. It stores metadata inside the actual cr2. Might have something to do with it.

The ACR dialog only pops up for the first image, just ignore it and click okay, AE should still abide all the ACR metadata settings you've already set in Br for the rest of the images. Try it and see if this is not the case. I'm not sure why AE doesn't give you the multifile ACR dialog like Br does when you import a sequence, this seems to have been a blunder on Adobe's part.

[Danne]

Big blunder from adobe. Tried but unlike lightroom and multfile acr in bridge and photoshop ae does not apply individual metadata in sequence import. Maybe why it,s so fast importing. This is why I trust lightroom and bridge for my postproduction with stills/timelapse much more atm...

[Joachim Buambeki]

... ae does not apply individual metadata in sequence import. Maybe why it,s so fast importing.

I can assure that AE can do this, I did it dozens of times - not sure where the problem lies but your maybe have a look in your preferences in AE or ACR.

[Danne]

Yeah, maybe.
I import my sequence without xmp sidecar files. Could it be it? Information shows up in other applications though? Is there something else maybe? Tried googling it but couldn, t find any direct answers. Suggestions are welcome

[Joachim Buambeki]

I import my sequence without xmp sidecar files. Could it be it? Information shows up in other applications though? Is there something else maybe?

Yep. That is the problem, the sidecar files have to there for EVERY image. Lightroom stores those sidecars in its catalogue (or whereever...) by default, you can write them to disk with "Photo->Save metadata to file".

[Danne]

Yes, found out! Lightroom creates xmp files for camera specific raw files. However, in my workflow using dualiso cr2 the metadata is created inside the file. THis information is read by bridge and acr in photoshop but not in AE. Bummer. Now, how to create sidecarfiles for those nonspecific raws?

[Joachim Buambeki]

I guess you're working with DNG files and not CR2 files then?!
No idea what to do then, but AFAIK you can have sidecar files with DNG aswell.

[Danne]

dual iso dng:s named cr2, will try naming them back. I have some tricks using xmp sidecars created with magic lantern changing original cr2 to converted dualiso named cr2. Kind of screwy but it works

Can,t find out how to create sidecarfiles  for dng:s?

[Danne]

Found this little plugin tool for lightroom. Creates sidecar xmps. Think it uses exiftool. Worked with AE, yey
http://www.robcole.com/Rob/ProductsAndServices/xEmPLrPlugin/

Oh man the rendering time in AE. Back to lightroom

[Joachim Buambeki]

But you don't have perfect source material, you have flickery source material. It has discrete jumps in it. It sounds like you don't trust my algorithm (which it's not my algorithm, just my implementation). Why don't you try it and see if it doesn't produce satisfactory results. I think the error between the calculated EV and what ACR exposure actually does (it is 'image-adaptive' apparently) is going to be larger than the error achievable with several passes of deflickering, and that will be completely automatic.

I know that ACR is image adaptive, but I also know that adjusting metadata the way I described it works 100% (for more info see this). It is not that I don't trust you, it is just that I have a hard time believing that an(y) automatic algorithm can be better, especially for stereoscopic content (did you have a look at this?) where I suspect the deflickering to wreak havoc on a sequence because it treats each eye differently.

My estimate for how to convert from the color space to exposure values is probably going to be wrong if you do that. Why not deflicker first, then apply the picture style? I think that should work.

Yeah, I realised I could do that this morning aswell - probably the best way around it since you don't ramp anything except WB when use use such a development setting anymway.

No, it's spending 99.99% of it's time generating the histogram from an already lowres 8 bit bitmap. The time it takes Br to generate this preview is a tiny fraction of the total time. Really the only way to significantly speed it up is to generate this histogram natively, which I haven't found a way to do. (or get Adobe to improve the efficiency of their javascript engine)

Too bad, it was just an idea.
About getting Adobe to change anything with their software: Nice try mate. :-p (while researching for input on your HDR script I stumbled again over this - pure comedy gold...)

That is something I thought about and would like to do, however, that would be incredibly difficult if not impossible to do in ScriptUI. After several hours of simply trying to display an image in ScriptUI (for the percentile preview), with no success I gave up . I just write the preview to a temp file and tell it to open it.

Too bad, would be really cool to have that working. I am crossing my fingers you'll find a way!

Probably. I prefer to just check between each pass to see if I need to do another one, but I can add an option to run it multiple times. I'm pretty sure I can force Br to regenerate it's previews, so that shouldn't be a problem.

Since rendering those sequences in AE takes hours if you work with 6-7K RAW files I would rather run one 20 minute high precision pass more than necessary than having to realise my sequence would have needed another final deflickering pass.

That's the percentile of the histogram that is used to match histograms. If you choose 0.7 the script tries the make the 70th percentile on each histogram all at the same brightness.

So I should choose a percentile that represents the luminance area that I care about most (might be my shadows or mids aswell) to be flickerfree, right?

It just skips pixels in the image when calculating the histogram. Analgous to how your image sensor line skips when shooting video. The only other way to speed things up is a 'crop' which difficult to define for the reasons mentioned previously.

That doesn't sound like it would introduce a huge margin of error. Since 3 is default I guess you recommend that?

It should pop up an image with the deflickering percentile highlighted in red dots, to help you choose the best percentile. (This might be a windows pathname issue, I'll see if there's a cross platform way to do this)

I suspect I should get an image like this post? There is no popup happening on my Win8 64bit CC Bridge.

Like I said before, I think it's probably best to do stuff like that in AE. You can work with 16 or even 32 bit data in AE, so I don't see the need for trying to do this kind of stuff in ACR.

Too bad if I can't change your mind about that.
I am sure an experienced colorist might be able to do something prettly close on a already highly graded high ISO file, but I can certainly say that I can't and I am sure most others can't too. Doing that within ACR on the other hand is as easy as child's play. Commercial software also supports animating those gradients by the way. If it is not too much work for you please consider implementing it.
Another point would be that you could skip using After Effects totally (by using Bridge to render out the images) with the animated gradients implemented which is a significant cost advantage for users of the script.

The way the script is set up that would be hard and add a ton of UI code that I don't really want to have. The script automatically generates all those checkboxes based on a simple list of ACR property names which is easy and requires very little code. I'd rather keep this script somewhat simple.

No biggie, for me, it was just something that caught my attention.

No, it's not a simple scalar property, it's a collection of x,y points, very hard to ramp. Explain to me mathematically how to ramp a curve defined by varying numbers of x,y points. Just use the parametric curves.

.xmp files support up to 12 (?) different adjustment points in a curve. If those points are all initialised first and all have the same input value, can't you ramp the output values? I just don't like the parametric curves because I get finer control over the image with the real curves (treating each RGB channel is also only possible with them - not that I used that in the past)

Tell Adobe to fix their buggy scripting UI

Again, no biggie. Just thought I'd mention it.


Another thing:
Since you can access the lowres 8bit images, would it be possible to generate a fast preview clip from that? It would be splendid to render out a quick 480p/720 preview that still has all the adjustments made in ACR in very little time to see if the grading and deflickering works as one expects.

[Joachim Buambeki]

By the way:
I just sent David a tip via paypal as a sign of appreciation for the time he is investing free of charge and I encourage others that use this script and want David to keep working on it to do the same aswell.

[Danne]

Paypallink?

[dmilligan]

If anyone wants to, PM me and I'll send you my email for donating with paypal.

[dmilligan]

So I should choose a percentile that represents the luminance area that I care about most (might be my shadows or mids aswell) to be flickerfree, right?

Yes, but statistically speaking, I think you want to try and stay as close to the median as you can. (The farther you get from the median the more effect small transients are going to have, if you think about it this makes sense)

That doesn't sound like it would introduce a huge margin of error. Since 3 is default I guess you recommend that?

I haven't really fully tested how much error this creates, 3 is just a guess, so you're welcome to run some tests and see if you can come up with a better value. I will change the default in the script based on what you find.

I suspect I should get an image like this post? There is no popup happening on my Win8 64bit CC Bridge.

Try messing with line 533 in the script. That is just based on some boiler plate code I found for creating a temp file, perhaps the '/' is making it not cross-platform. Try just hard coding a valid windows path name there and see if it works.   i.e:

Code: [Select]

var tempFilename = "c:\\temp\\myfile.jpg";
If that's the problem, I'll try and see if there's a more cross platform way to handle file names in the API.

Too bad if I can't change your mind about that.
.xmp files support up to 12 (?) different adjustment points in a curve. If those points are all initialised first and all have the same input value, can't you ramp the output values? I just don't like the parametric curves because I get finer control over the image with the real curves (treating each RGB channel is also only possible with them - not that I used that in the past)
Again, no biggie. Just thought I'd mention it.

I'll look into these. The main issue is that these are not simple scalar properties in xmp, so I'd have write specialized code for ramping them instead of being able to reuse the same generic code to ramp any simple scalar property (with those the only thing have to change is the 'name' of the property, so I just have a list of all properties and loop through it applying the ramp with the same code)

Another thing:
Since you can access the lowres 8bit images, would it be possible to generate a fast preview clip from that? It would be splendid to render out a quick 480p/720 preview that still has all the adjustments made in ACR in very little time to see if the grading and deflickering works as one expects.

Good idea! It's easy to save the previews to a low res jpg, that should make it easy to do a fast render, could also be useful for fast proxies. (Also, I've found that I can preview in Br by just holding down the arrow key to fast scroll through the previews)

[dmilligan]

Too bad if I can't change your mind about that.
I am sure an experienced colorist might be able to do something prettly close on a already highly graded high ISO file, but I can certainly say that I can't and I am sure most others can't too. Doing that within ACR on the other hand is as easy as child's play. Commercial software also supports animating those gradients by the way. If it is not too much work for you please consider implementing it.

After trying for a little while, I cannot figure out how to read and write the xmp metadata for gradient corrections. Documentation for Adobe's xmp API is pretty much useless, I just can't make sense of it (reading the other values was possible b/c I found enough example code out there to do it). As I would never use this myself, and there are other ways to do this, I don't see much of a reason to keep trying.

I think there are lots of easy ways to do what you are trying to do in AE:
Duplicate your sequence so that you have two different ones.
Give one set the ACR settings for one side of you gradient, give the other the ACR settings for the other part of the gradient.
Import these into two different layers in AE, then you can blend between the two with a simple gradient layer mask of your choosing. You can make the layer mask look like anything you want, so you're not just limited to linear or radial. You can use all of the great animation tools in AE to control the movement of this mask, you can even link it up to a motion track to have it move automatically. This is what I would do if I was trying to do what you are talking about. It's so much easier, powerful, and flexible to do it this way. I also see absolutely no reason this would produce inferior results in terms of quality.

[Joachim Buambeki]

Thanks for your effort so far.
Unfortunatelly the solution is not that simple.
If you reopen the ACR in AE to AE to change the settings you're working on the Camera RAW Sequence in the "Projects" panel NOT on the duplicated layer you chose. This means of course that the changes will be visible not only in that duplicate layer.
The alternative then would be to import the sequence twice, but this means I would need a second copy in a different folder with second set of ramped .xmp files which is not really what I would consider a smooth workflow experience. Also nothing would be linked to one another (let's say my sky has always to be a bit warmer than the forground but I am ramping the white balance of the foreground).

[dmilligan]

The alternative then would be to import the sequence twice, but this means I would need a second copy in a different folder with second set of ramped .xmp files which is not really what I would consider a smooth workflow experience. Also nothing would be linked to one another

That's what I'm talking about, duplicate of all the files. I realize it's somewhat of a hassle, but it is at least possible, and not too difficult to do it like this. (It's at least easier than figuring out Adobe's XMP API)

WB is really the only thing that is absolutely necessary to do in ACR like this (it's pretty much the only thing that is a 'destructive' part of the debayer process). If you just need to do something simple like adjust exposure, saturation, contrast, etc. you can use an adjustment layer with a mask in AE: http://forums.adobe.com/message/4623729

[Joachim Buambeki]

I always get:

Reference Error: k is undefined

when I run the deflickering at the same frame.

[dmilligan]

I always get:when I run the deflickering at the same frame.

Should be fixed now, I also added auto keyframing for deflicker and there's some code to do multiple iterations, but I haven't figured out how to purge the preview cache yet so it's disabled.

[Joachim Buambeki]

Should be fixed now, I also added auto keyframing for deflicker and there's some code to do multiple iterations, but I haven't figured out how to purge the preview cache yet so it's disabled.

Thanks. Why is the auto keyframing in the deflicker module?!
Am I not supposed to adjust image parameters on every keyframe according to my liking and THEN run the deflickering? Wouldn't it make sense to create keyframes before the deflickering because of that? I am confused.

[Danne]

Wow! good progress. Multiple ramping, nice! Question. What is auto keyframing suppose to do?
Thanks again for this!

[Danne]

Hi again. Workflow question.
Will ramping reset the deflicker runs? Tried deflicker, then running a multiple ramp. This resets my deflicker exposure values to follow exposure ramp. Would be nice to keep the deflicker settings and ramp from those instead of resetting.

[dmilligan]

Thanks. Why is the auto keyframing in the deflicker module?!

Okay, now I don't really understand what you want it for. If you're going to manually edit settings for keyframes, how much more difficult is it to mark that keyframe with a star? I figured the auto keyframing thing would only be very useful if you were trying to do everything automatically, and it only makes sense for deflickering. For ramping you have to manually edit each keyframe anyway.

Hi again. Workflow question.
Will ramping reset the deflicker runs? Tried deflicker, then running a multiple ramp. This resets my deflicker exposure values to follow exposure ramp. Would be nice to keep the deflicker settings and ramp from those instead of resetting.

If you want to change the exposure after a deflicker you need to use the single ramp and check the 'additive' checkbox. If you want to do a ramp multiple after deflicker, you need to uncheck the Exposure2012, so that it is not modified.