Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Joachim Buambeki

#26
Quote from: dmilligan on October 30, 2013, 09:39:31 PMTry it now as is, run the script from the ExtendScript Toolkit (not as a startup script), I've included some debug info, it should display the filename of the temp file in the upper right console log. Send me the output from that.
Sorry, I don't know what the "ExtendScript Toolkit" is and how to use it, could you give me a link with more detailed description, all I found is this (which is from 2006).
#27
Quote from: dmilligan on November 01, 2013, 04:50:47 AM
@JB,
I finally figured out the gradient corrections (GND, Radial filters) thingy in XMP API, so I added it to the script.
Caveat: All frames must already have the same number of gradient corrections applied before running (just 'synchronize' from the first frame in ACR dialog once you've created the gradient correction, then modify it in each keyframe).
AWESOME! I will try it and report back here, I will laos have a look at the debugging stuff you posted before.


#28
Quote from: itsskin on October 31, 2013, 07:39:16 AMBut I think deflicker is not changing keyframes. And IMHO it should - otherwise deflikering is not working correctly if several keyframes are set for changing color temperature for example.
From my perspective it is working exactly as it should.
By adjusting the exposure of the keyframe and the deflickering adjust the surrounding frames to that target - if you don't touch your exposure this is your target. Just open all the keyframes in ACR and bring the exposure/brightness close to each other.
#29
Quote from: dmilligan on October 30, 2013, 09:39:31 PMTry it now as is, run the script from the ExtendScript Toolkit (not as a startup script), I've included some debug info...
Quote from: dmilligan on October 31, 2013, 01:52:04 AM
I put some code to write some debug info in the console to try and track down JB's issue, I guess it automatically opens extendscript if you do that, you can just comment out any lines that start with $.writeln.  I'll take it out once we figure it out.
Thanks, will run some tests tomorrow. Gotta go to bed now.

Another thing:
Could you add adjustments that divide the deflickering into:
- average exposure = how much the algorithm tries to straighten out the exposure graph
- deflicker strength = how agressive the algorithm is adjusting the exposure to the average exposure

Why?
I am working on a sequence where the sky is free from any flicker but the foreground in on the other hand is flickering because of clouds (that aren't in the frame) that cast large shadows. I am now running a render where I am blending those two together in AE but I wanted to keep some of the flicker on the foreground trying to make it look similar to how the human eye with its adaptive vision would see it (if one could see in timelapse, hehe). I did that by just weakening the flicker (with commercial software) instead of trying to get rid of it totally.
Could you implement that? Feel free to come up with better names for those options.
#30
Quote from: dmilligan on October 30, 2013, 12:09:04 PM
Just search for "var tempFilename ="
Did hardcoding it work for you?
Didn't get to try it before. With the latest version and the modification Bridge hangs if I press the "Preview" button - before the modification it just didn't do anything if pressed.
#31
Quote from: dmilligan on October 30, 2013, 03:00:55 AM
Some updates:
...
You can specify a crop for the histogram analysis. You just have to enter x,y,width,height (in percent), no way to allow you to draw it with some sort of UI, but the preview will draw the crop box so at least you can see where it is.
...
Great update, would you please give me the line in the script to hardcode the folder to enable the preview? It's not 533 anymore.
#32
Quote from: dmilligan on October 29, 2013, 02:09:08 AM
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.

My idea was as following:
- Run the part (that isn't yet implemented in that way) of your script that creates keyframes (I would prefer to be able to choose the number of keyframes that are then evenly distributed instead of every n-th frame) 
- choose the 1* filter in Bridge so only the keyframes are displayed
- Ctrl+A to select all of them
- open them in ACR and adjust until it looks good
- apply deflicker if needed
- render out

The auto set keyframes would just be there for a more convenient workflow, nothing more.
#33
Quote from: dmilligan on October 28, 2013, 10:03:31 PM
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.
#34
I always get:
QuoteReference Error: k is undefined
when I run the deflickering at the same frame.
#35
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).

#36
Interesting script.
Would it be possible to modify that script that it loads a bracketed RAW timelapse sequence and does the same than with the laternating video sequence?
If yes, could ghosting be removed aswell?

That would be great, because one could skip the HDRI creation of bracketed timelapse sequence totally. :-)
#37
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.
#38
Quote from: dmilligan on October 25, 2013, 02:22:27 PMBut 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.

Quote from: dmilligan on October 25, 2013, 02:22:27 PMMy 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.

Quote from: dmilligan on October 25, 2013, 02:22:27 PMNo, 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...)

Quote from: dmilligan on October 25, 2013, 02:22:27 PMThat 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!

Quote from: dmilligan on October 25, 2013, 02:22:27 PMProbably. 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.

Quote from: dmilligan on October 25, 2013, 02:22:27 PMThat'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?

Quote from: dmilligan on October 25, 2013, 02:22:27 PMIt 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?

Quote from: dmilligan on October 25, 2013, 02:22:27 PMIt 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.

Quote from: dmilligan on October 25, 2013, 02:22:27 PMLike 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.

Quote from: dmilligan on October 25, 2013, 02:22:27 PMThe 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.

Quote from: dmilligan on October 25, 2013, 02:22:27 PMNo, 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)

Quote from: dmilligan on October 25, 2013, 02:22:27 PMTell 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.


#39
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.
#40
Quote from: Danne on October 25, 2013, 08:57:53 PMI 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".
#41
Quote from: Danne on October 25, 2013, 08:12:47 PM... 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.
#42
Quote from: dmilligan on October 22, 2013, 11:41:55 PM...(I was thinking you wanted me to come up with some kind of dialog/UI for creating keyframes, the rating thing is not to hard at all) and I have implemented it for the deflicker and a new "Ramp All ACR Settings" menu.
Actually that was part of my earlier post. It would be nice to have dialoge that asks you how many keyframes you want to create and then those are evenly distributed among the sequence. Right now you have to rate them with 1 star by hand which takes quite a bit of time if you want to have 10+ keyframes for day to night sequence .

Quote from: dmilligan on October 22, 2013, 11:41:55 PMGood idea, thanks.
The latest version works great, so we all have to thank you! :-)

Quote from: dmilligan on October 22, 2013, 11:41:55 PMMark the frames that you don't want to be touched (used as keyframes) with 1 star. First and last selected frames are assumed to be keyframes even if not marked. Deflicker will run the histogram matching on a ramped EV target from one keyframe to the next. "Ramp All ACR Settings" works basically the same way, except just blindly ramping all settings from one keyframe to the next.
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.

Deflickering works on the histogram of the preview thumbnails that are extracted based on the current .xmp settings, right? Is it a problem if I use a super flat profile like this, if yes could you make it more robust?

Could the deflickering be sped up by working on lower resolution DNGs of the same images? That would be great since you store the DNG and original RAW files in the folder with just one .xmp file for each pair of images (or you just copy the .xmp files to another folder if the DNG and RAW file have the same name).

Would it be possible to have the deflickering only using certain parts of the frame?
The reason is that for example you want to have the shadows or general foreground flickerfree, since you don't care about the sky as much or vice versa (or you want to to deflicker them separately and merge them later in AE for ultimate smoothness).
Would it be possible to have preview window where I can draw a rectangle that specifies where the brightness is measured? If yes, could that area also be animated (for motion control shots where the camera rotates/pans)?

Could the multi-pass deflickering for best precision be automated?
With a dialogue where you select the amount of passes (you mentioned somewhere more than 3 is not necessary) and maybe a second input field for the line skipping of the last pass (if necessary, I still don't understand how that works -see below), it then does everything by itself and purges the cache automatically between the passes (I know I'll forget that half of the time...). 

What exactly does percentile do?
How does the "Line Skip" work? Does it skip lines in the histogram?
What is preview under deflickering supposed to do? I get nothing when I press it.

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)

Is it possible to adapt your script to stereoscopic sequences (especially the deflickering!)?

I am not sure if it is necessary, but commercial software initalises the .xmp files before working on them, I think it does that because otherwise it doesn't work reliably, for the gradients mentioned above it is probably necessary. I am not sure if you know that or if that information is of any use for you, but I thought I'd mention it.
Creating keyframes and the initialisation could also be combined into one dialogue.

Quote from: dmilligan on October 25, 2013, 01:24:43 AM
Renamed 'Ramp All ACR Settings" to 'Ramp Multiple...' and added option to select which things to ramp (like the ACR dialog when you select 'Synchronize...').
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 FX-Vignetting could be added aswell for the sake of completeness (Grain is useless since it generates a static noise pattern).
The checkboxes for the colour adjustments are a bit random, why don't you order them by the name of the colour and and Hue/Sat/Lum (for example "Aqua Hue, Aqua Saturation, Aqua Luminosity")
Could you add ramping for the curves too?


Quote from: dmilligan on October 21, 2013, 02:14:56 PM
I decided to go with Br instead (hence the script I created), it's much faster. AE takes several seconds to render a RAW frame, even on low quality (this is so annoying, why adobe why?!), Br has some kind of fast preview mode that takes fractions of a second. It's just much easier and faster to do in Br.
I hope you don't mind that I pulled that quote into this thread, it seems to fit better in here.
I would love to have everything in AE instead of going back and forth between it and Bridge. Can you call Bridge from within AE for the .xmp stuff? Deflickering would take as long as full length render time of sequence (meaning hours) if done entirely in AE...
Maybe you could consider it again once the Bridge script is more mature?


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).


Thanks for your time and keep up the good work!

Is there way to tip you for all your effort so far? I would be happy to do that if you keep the script under GPL. :-)
#43
Quote from: dmilligan on October 21, 2013, 03:21:17 AMIf you would like to write a C++ plugin to Br for calculating the histogram I would gladly incorporate it into the script.
Unfortunatelly I have zero programming knowledge. A while ago I stumbled over this but never got it to work because it is written for CS5 and doesn't work with later versions. I am not sure if it is of any use or your script is already doing something similar to get the histogram.
#44
Quote from: RenatoPhoto on October 21, 2013, 12:05:10 AM
Probably something like this: C:\Users\RE\AppData\Roaming\Adobe\Bridge CS6\Startup Scripts

Or search in C:\Users for "scripts"
I figured it out, I had to create folder myself within the Bridge directory and put the script in there. Maybe this should be added to the initial post?
#45
Quote from: dmilligan on October 20, 2013, 11:31:33 PMI like your idea about using the the existing ACR settings to do the ramp, I can have the dialog pull the values of the selected setting from the first and last selected photos as the default for the text boxes. And then also have some kind of "ramp all" option.
I don't really think keyframes are necessary, just select the photos in groups and do one ramp at a time. I don't think that's any more difficult than defining keyframes, and makes things much less complicated for the script (and me).
I am just talking from a user POV, so I don't know how much work the coding is and I am grateful for the work you put in, but IMO keyframes are crucial for an easy workflow. For me ramping those sets is pretty annoying when having 10+ keyframes, especially since I tend to re-edit my keyframes alot during editing.
If keyframing would be implemented like layed out in my previous post (or in a similar manner) this could become a serious alternative for commercial software (which uses the star rating in the manner I proposed), the deflickering could even be able to surpass it in quality because it works directly with the output of ACR's render engine.

Quote from: dmilligan on October 20, 2013, 11:31:33 PMIs stuff like this really necessary to do with ACR? Why not do stuff like that in AE? You should be able to achieve exactly the same results.
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.

Quote from: dmilligan on October 20, 2013, 11:31:33 PMJust use the deflicker.
I would have to run deflickering then within every set of keyframes to keep them at the brightness I want them to be, right? This is again a case where the proposed keyframing integration would be handy for a much smoother workflow.

Quote from: dmilligan on October 20, 2013, 11:31:33 PMThis is already possible, just use the "additive" mode.
Maybe you could create a small wiki like with your HDR script to clarify things?

Quote from: dmilligan on October 20, 2013, 11:31:33 PMJust use the deflicker.
So, the deflickering would have to be processed again in sets of neighboring keyframes? If yes, my plea would be the same as in the first paragraph of this posting.

Quote from: dmilligan on October 20, 2013, 11:31:33 PMI think it should be pretty robust. It's based on the histogram, so transients should be okay as long as they have a relatively small impact on the overall histogram distribution. A1ex could answer questions about the theory behind this, better than I can.
Ok, I'll try if I can break it with one of my sequences with such frames.
By the way: Is deflickering supposed to be that slow? With high precision, it takes half an hour on my 4GHz quadcore (though only one core seems to be used).

PPS: Did you see my reply to this thread? Just in case you missed it.
#46
Quote from: dmilligan on October 20, 2013, 11:40:00 PMI have no idea why people use that crap. (or why they PAY for it when linux is FREE!).
The day you or anyone else hacks together a patch for Adobe programms to use the MacOS (=Unix) version on Linux I am done with Windows - I'll give you my word on that...

Quote from: dmilligan on October 20, 2013, 11:40:00 PMMaybe try doing a search for "Bridge CC", though I've heard Win8's search is pretty much totally useless, would end up searching the internet, even if you are just looking for a local file.
Thanks, I'll do some searching on the interwebz, I wasn't able to find the folder with the search in the explorer - not that this ever was of any use since I am with Win95...

#47
Quote from: dmilligan on October 20, 2013, 09:50:06 PM
It seems that some folks downloaded the link I posted in the OP, which is actually an html page for the script, not the script itself, which is why you had trouble running it. I have updated the OP with the link to the actual raw file, so you can just right click and download, sorry for the confusion. (If you saw a bunch of html tags in an error message, this is probably what happened)

Sorry for asking, but where am I supposed to put the scripton my Win8 CC version? I don't have the folder you're describing in your opening post. As of now I am opening the script by opening it in Bridge each time I start it.
#48
Feature Requests / Re: Time-lapse interval less then 1s
October 20, 2013, 07:12:36 PM
Thanks for the suggestion, I just googled it, that is a software that runs on my laptop?! I will never use a laptop on a shot again, I had too much trouble with those things in the past and I am done with that.
I already have an external intervalometer that can do that and should get a new one that goes way beyond that soon, but it would be nice to have that in camera aswell.
#49
Quote from: smilem on October 11, 2013, 04:01:48 PM
Is it possible to have Dark Frame Subtraction?

There is a programm called Pixelfixer that should be able to do what you are asking for.

#50
Feature Requests / Re: Time-lapse interval less then 1s
October 20, 2013, 06:08:44 PM
I already put up a request a while ago for such a feature.
It is not so much about having the possibility to shoot intervals of less than a second (though there are definatelly uses for intervals that short!), but to have finer granularity for the interval.
Beeing able to choose 1.5 sec instead of 1 or 2 makes a tremendous diference for example (no, I don't want to speed it up in post - you never get the same quality when fixing stuff you should have taken care of while shooting).