Intervalometer Ramping Module (adv_int.mo)

[PaulJBis]

It was mentioned previously before but is there anyway to reinclude the holy grail auto ramp exposure?

Ramping exposure is certainly more intuitive for things like sunset timelapses. This said, I've been experimenting myself with AutoETTR and this module, and it seems to work quite well. The only problems I find are:

-AutoETTR tends to overexpose (and blow out) the night pics. a1ex pointed me to the SNR limits options, and they indeed seem to work... Which brings the question: would it be possible to keyframe and ramp the SNR limits?    (A value of 6 works for daylight shots, while 4 is better for nighttime ones).

-Using the deflicker script precludes you from importing your raw sequence to After Effects in HDR 32 bits, following this recipe by Stu Maschwitz:

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

Since it also uses Camera Raw and sets the values for the entire sequence... and it uses process 2010.

dmilligan: would the exposure compensation values that your script sets change too much if they were calculated using process 2010, instead of 2012? Or is that irrelevant? Also, I read that you started developing your script for AE before switching to Bridge, because AE was too slow. How slow would you say it was? 10x slower? 50x slower?

(I'm asking because I'm considering porting it to AE, so that I can use it in conjunction with a linear 32-bit workflow, but I'd like to know before if the slowdown makes it unusable).

[dmilligan]

-AutoETTR tends to overexpose (and blow out) the night pics. a1ex pointed me to the SNR limits options, and they indeed seem to work... Which brings the question: would it be possible to keyframe and ramp the SNR limits?    (A value of 6 works for daylight shots, while 4 is better for nighttime ones).

Yes, it would be possible for the module to ramp ettr settings. Personally, I don't fool with the SNR limits. I usually hit my exposure limits at night anyway, it must not be very dark where you are

-Using the deflicker script precludes you from importing your raw sequence to After Effects in HDR 32 bits, following this recipe by Stu Maschwitz:

Uh, last time I checked there's only 14 bits of data in a CR2. There's no benefit to using 32 bit in AE. 16-bits is more than plenty to fully represent every possible value in a RAW file. (If you use a 16bit workflow in AE, nothing will be clipped that wasn't already clipped in the original RAW file, 32 bit is unnecessary unless you're actually doing HDRI and have HDR merged 32 bit TIFFs or something that you're running through my script, in which case you should be able to get 32 bit output into AE just fine)

would the exposure compensation values that your script sets change too much if they were calculated using process 2010, instead of 2012? Or is that irrelevant?

nope, it should be easy to change to script to use process 2010 if you want to, but I don't think it will make much difference

Also, I read that you started developing your script for AE before switching to Bridge, because AE was too slow. How slow would you say it was? 10x slower? 50x slower?

IDK, that's not really what happened. AE is really slow at rendering previews, because it renders the full size CR2 when you try to playback a RAW sequence. Bridge renders quick, low-res thumbnail previews. It's much faster to use these to preview your sequence then to wait for AE to render out something. Just try it.

The other main reason I used Br is that you get the multi-file ACR dialog and you can preview your ACR settings on any image in the sequence (AE only lets you see the very first image). You often need to ramp stuff like WB, and it's just much easier in Br with being able to star keyframes, open them all in the ACR dialog, match up the WB, then apply a ramp with the script.

If AE gave you some kind of access to ACR parameters like the way the effects work, and you could create keyframes for them and such, then AE would be much faster and easier. But that's just not possible.

It's not so much the speed of the deflicker algorithm, but the UI is better and easier and it's just faster for me to do the things I need to do. You might very well get the deflicker itself to run faster in AE, IDK.

[noealz]

If ETTR is here to stay and theres no way to bring back the one stop holy grail ramping method, then I have just one question.

Does ETTR exposure continuously rise only?

There are times when you are doing a timelapse when the exposure changes because of a cloud or something and so exposure takes a small dip but after it passes it goes up again and this causes problems with flicker too.

Does ETTR exposure only rise without taking those small dips? Because that would be very nice.

I hope that I was able to put it into the right words.

[Audionut]

AutoETTR is an exposure tool.  So exposure settings change with scene luminance changes. 

http://www.magiclantern.fm/forum/index.php?topic=8850.0

[noealz]

If there was a way to prevent an ettr timelapse ramping timelapse to go down in exposure and only increase in exposure, it would be very good and prevent flicker.

I know there is a deflicker option but this could help eliminate that step.

[Audionut]

It would not prevent flicker.  It would simply limit exposure increments to increases.

[PaulJBis]

Yes, it would be possible for the module to ramp ettr settings. Personally, I don't fool with the SNR limits. I usually hit my exposure limits at night anyway, it must not be very dark where you are

Bright lights, big city  . I'd imagine that changing SNR limits would be useful, for example, when doing a day-to-night timelapse of New York (not that I live there, nor is my city *that* bright, but there's plenty of artificial light here).

Uh, last time I checked there's only 14 bits of data in a CR2. There's no benefit to using 32 bit in AE. 16-bits is more than plenty to fully represent every possible value in a RAW file. (If you use a 16bit workflow in AE, nothing will be clipped that wasn't already clipped in the original RAW file, 32 bit is unnecessary unless you're actually doing HDRI and have HDR merged 32 bit TIFFs or something that you're running through my script, in which case you should be able to get 32 bit output into AE just fine)

I know Canon CR2 only has 14 bits, but even so, there are advantages in working in 32 bits (after all, even the Red Epic's sensor is only 14 bits too, and people in the film/VFX industry work regularly in 32 bit float). The advantage is not so much in the "32 bits" part, but more in the "floating point" part. Working in float gives your software more precision when applying color grades, and allows you to stack up color correction tools non-destructively, even if the original source material is less than 32 bits.

Anyway, since I prefer to use the grading and keyframing tools in AE, what I'm trying to do is to import the full dynamic range of the original raw into AE, preserving detail in the highlights so that they aren't already "pre-clipped" when AE touches them. Stu Maschwitz's recipe is designed precisely to do that. I'll post here with further updates when I start porting your script to AE.

[firstlight]

I'm trying to start a timelapse at f3.5 iso1600 in aperture priority mode at night for the stars, and then have it ramp to f8 iso100 around sunrise. It is in take pics like crazy mode so there's no delay between frames. I have the settings changed just like described here but the settings don't change at the set global time. Is this because the camera has to be in M mode and not AV? This is on a 550d by the way... Thanks a lot, I'm stumped and really want to get this working ASAP!

[dmilligan]

I'd highly recommend using AutoETTR as opposed to Av. I also highly recommend setting a fixed interval, you do typically want some time between frames, and you really want a fixed interval (or a smoothly ramping one). With exposure being chosen by an automatic routine, the shutter time will jump around which will cause all sorts of strange temporal jitter. Exposure flicker we can handle easily, but temporal jitter is impossible to fix.

As for why it's not ramping, do you see the 'Ramping ...' appear on the screen? You do have to set at least two keyframes (it won't just start from where you are). A screenshot of the menu settings and also the 'List Keyframes' would be helpful to figure out what's going on.

[DoryBreaux]

Anyone else having trouble with this on the 7D? Or am I just missing something here... 

[dmilligan]

care to elaborate?

[DoryBreaux]

I've tried to set it up several times and it wont ramp anything.

Set the camera to the initial state
Set Keyframe
Back to canon menu and set second keyframe state
Set keyframe
etc
Turn intervalometer on and set normal properties
Start sequence

Stays at the last state the camera was set at.

[dmilligan]

Set everything up like you did and then goto "List Keyframes" and tell me what it says, or just take a screenshot of it, or do a "Save" and post the contents of the save file (SEQ.TXT in the ML config directory).

[DoryBreaux]

https://www.dropbox.com/s/i6ganqhmjpoq3fy/20140528_113401.jpg

When I start the sequence, it holds in the current state and seems to completely ignore the keyframes.

[dmilligan]

Does it work if you don't use global time?

[DoryBreaux]

I was using global time.

[dmilligan]

I know. Does it work if you don't use global time?

[DoryBreaux]

Oh, ha. No it doesnt.

[RLaudi]

@dmilligan: while I was looking into the picoC/TCC scripting option of ML to implement some ramping ideas (and had to find out it's disabled at the moment) I bumped into your brilliant adv_int module which does exactly what I was looking for, so thank you very much for this great tool!

[johnpooley3]

@dmilligan Thank you very much for your work on this awesome module, this is exactly what I have been trying to find for a while now.

I am running a 650D with Nightly.2014Jun22.650D104 (Because it's the only one I could get the module to load on) and have set the keyframes and have enabled the intervalometer correctly, but the camera never actually ramps the attributes once I begin the sequence. Rather than gradually change the attributes, the attributes remain at their state previous to the start of the intervalometer (which would be the state of the first keyframe or if I forget to change it back, the state of the last keyframe). I am using frame timing rather than clock, and have tried saving and clearing keyframes repeatedly to no avail. The list of keyframes correctly shows the keyframes I've set. What could I be doing wrong?

[dmilligan]

Do you see "Ramping..." on the screen when running?

[johnpooley3]

Do you see "Ramping..." on the screen when running?

Nope I only ever see the intervalometer timer and the pictures taken counter...

[dmilligan]

It will say "Ramping" if it's doing some ramping so if it doesn't then there's something about your keyframes that is making it think there's nothing to ramp. There are a couple of caveats: you need to have an initial keyframe (if you only make 1 keyframe it won't work). Any parameters you're ramping should be enabled for all keyframes => you can't do something like t1: Tv, t10: Av, t20: Tv, t30 Av

[johnpooley3]

@dmilligan could you take a look at this album: http://imgur.com/a/Ni24I

I took a picture of every step and was unable to get the "Ramping" indicator.

Thanks!

[dmilligan]

okay, it doesn't appear you have done anything wrong, that setup should work, and it works just fine on my cameras, there must be something strange going on that is specific to the 650D, as I don't have one, I can't really troubleshoot it myself. Does it work if you use "External Source"? (For "External Source" to work you need to have image review enabled) If it does then there's probably something wrong with CBR_INTERVALOMETER, which should be getting called from shoot_task.