Intervalometer based on this formula...

[jimbr549]

I shoot time lapses of stormy weather.  Conditions can go from sunny skies to very dark in very short order.  Currently, I manually adjust my shutter speeds by 1/3rd stop increments in order to compensate for the changing light, then I fix the bumps in post using Lightroom and LRTimelapse.  I shoot at the shortest write times possible (2 seconds) and I will on occasion run into a collision state as my exposure time gets longer.  So, i'm wondering if it would be possible to configure the  intervalometer to work based on this formula:

Shutter speed (variable) + Write time (fixed)  =  Interval

An intervalometer that worked on this dynamic formula would be a huge asset to me and would make Holy Grail photography a breeze if a person is willing to do the manual ramp necessary.

I'm willing to fairly compensate anyone willing to make this happen, there are NO products on the market at this time that can do this and I think it would be very popular.

Jimbr549

[dmilligan]

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

[jimbr549]

I guess I'm not understanding how this works, dmilligan.

If I set my camera to manual, 1/125th shutter, intervalometer set to take an image every 2 seconds, what setting would I use in advanced intervalometer to ramp the interval based on shutter speed?  I may well finish my TL with a 1.5 second shutter, at which point I will have a collision between shutter and interval, thereby losing frames as the buffer clears.

[dmilligan]

You won't loose frames "as the buffer clears" that's not how it works. If the interval time is less than the shutter speed, the next picture is just taken as soon as the camera is ready (so the interval time is no longer strictly held). Just try it => set the shutter speed to 10s and the interval time to 9s and see what happens.

The only reason you would need to allot extra time between frames is if you were trying to give some ML routine that runs after an image is taken (aka AETTR) time to run.

I recommend avoiding this situation altogether because the result will be an accelerating, decelerating, or temporally jittering sequence. Just make your interval time a little longer than the slowest shutter speed you're going to need.

For "holy grail" I would recommend using AETTR, no intervention necessary, you just set the AETTR slowest shutter to a little less than the interval time (I like to use 30s shutter, 45s interval). Here's a 15 hour, day-to-night-to-day timelapse that I shot completely unattended: http://www.magiclantern.fm/forum/index.php?topic=12330

[andyshon]

AETTR is probably too slow for most of what Jim does. I've posted a test aettr/weather shot before, and it manages the exposure extremely well. But the results are a bit quick and do stutter due to shifting intervals. With manual exposure adjustment though you could avoid this, and with no aettr or deflicker processing time wouldn't be an issue.

Be interested to know if it works for you Jim? And how's that lazy susan working out?

PS. Jim, this is Andy from Light and Time.

[jimbr549]

 Just try it => set the shutter speed to 10s and the interval time to 9s and see what happens.

I know what happens.  It's called a collision and, eventually, you will have missed frames in your time-lapse sequence as the camera can't shoot another image until the buffer clears.



 Just make your interval time a little longer than the slowest shutter speed you're going to need.

EXACTLY what I am trying to AVOID.  Shutter speed (variable) + Write time (fixed)  =  Interval would avoid it 100% of the time.

[dmilligan]

You don't know what happens. Try it!

[jimbr549]

Hey, Andy! 

I remember your "Moon Tides" TL, it really impressed!  I haven't been to your Vimeo page in a while, I'm going to drop by later today and see what you've been up to.

You're right of course, AETTR is too slow.  I suspect I'm going to have to use the computing power of a cell phone to get that manual control I want.  Somebody, somewhere is going to be able to do it.  The Timelapse+ has maybe a shot at it, I haven't heard back from the developer yet.  That's a $200 device, so that kinda tells you what the value is for me.

As to the lazy susan, I chunked that and am now running Chinese made slewing bearings.  I have the machinist lined up to make an aluminum body (it's called the Wedge) that mounts on a video cage and really make the package nice and very easy to use.  I'm waiting on Tokina to actually release their hydrophilic filter and get some pricing on various sizes.  I really think hydrophilic is THE way to go on my little device, but I won't know until I can get my hands on one.  Hopefully I'm done by spring.   

AETTR is probably too slow for most of what Jim does. I've posted a test aettr/weather shot before, and it manages the exposure extremely well. But the results are a bit quick and do stutter due to shifting intervals. With manual exposure adjustment though you could avoid this, and with no aettr or deflicker processing time wouldn't be an issue.

Be interested to know if it works for you Jim? And how's that lazy susan working out?

PS. Jim, this is Andy from Light and Time.

[jimbr549]

OK, I will try it today and get back to you.

You don't know what happens. Try it!

[andyshon]

The Wedge, I like it. Taking tokina a while that filter int it. I keep checking too. Not much new on our vimeo. Working on a natural history short, which has been turning me into a recluse for months now. Recording foley today, great laugh. Should be online in january with a bit of luck.

I haven't tried to use the ML intervalometer like this but I've never known it to drop a frame, even with ettr and deflicker running. I have had some crashes but I think they were down to the deflicker module.

I find it hard to imagine an external device doing as good a job as ettr. I trust it more than any other auto exposure system I've used. But it does come with a time premium. Great for day to nights, tides and shadows. Not so good for people, animals, or weather! I guess you're stuck out in the rain, getting numb fingers.

[jimbr549]

Ok, I started out at 1/30th, 2 second interval, decreased shutter by 1/3rd, shoot 10 frames, decrease again.  As soon as the shutter speed dropped to .8sec, there was no longer enough time between exposures for the camera to display any info on the screen (global draw is OFF) and without a histogram, I'd be shooting blind, so even if the camera never had a buffer clearing pause, this wouldn't work for me. 

Thanks for your efforts, DMilligan.  ML is an incredible tool, and people like you have polished it to the point of excellence.

OK, I will try it today and get back to you.

[jimbr549]

Here is what I've decided to try, for anyone interested.

Under the assumption that ML (with the advanced intervalometer active) will not fire shot #2 before shot #1 has fully written to the card, I'm going to use that to my advantage even though I won't be able to see the histogram.

I'm going to use DSLR Controller to monitor my shots on my android tablet.  Shooting raw and tiny jpegs, I'll have the jpegs sent to the tablet and that should keep me within a shot or two of current exposure and I'll be able to adjust exposure/ISO from the tablet as needed.  Plus, with a portable modem, I'll be able to sit in the car instead of being out in the lightning.  That's good because lightning is scary. 

When I was testing the new, improved intervalometer the other night, there was only a split second after the shutter closed and the next shot began that I was able to adjust the camera settings.  I'm hoping that DSLR Controller will have a "wait" function and will hold a command until the camera can accept it, but I'm not sure on this. 

If you are interested in DSLR Controller, go here:

http://dslrcontroller.com

[Audionut]

Under the assumption that ML (with the advanced intervalometer active) will not fire shot #2 before shot #1 has fully written to the card, I'm going to use that to my advantage even though I won't be able to see the histogram.

ML will fire the shots at the intervalometer period.  It doesn't care if the previous shots are fully written to the card or not, because it doesn't matter.  Cameras are capable of buffering three images or more.

When I was testing the new, improved intervalometer the other night, there was only a split second after the shutter closed and the next shot began that I was able to adjust the camera settings.

Adjust the "take pics" setting.  Make it longer then the shutter period, with sufficient time added for you to adjust settings.

I'm hoping that DSLR Controller will have a "wait" function and will hold a command until the camera can accept it, but I'm not sure on this. 

It won't.  The intervalometer is either on, or off.

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

[dmilligan]

ML will fire the shots at the intervalometer period.  It doesn't care if the previous shots are fully written to the card or not, because it doesn't matter.  Cameras are capable of buffering three images or more.

I would change that to "ML will try fire the shots at the intervalometer period". ML will wait until it knows it can take another picture (with some timeout, I think maybe ~3 seconds):

Code: [Select]

    lens_wait_readytotakepic(64);

The camera is capable of buffering multiple frames, but if the buffer is full, ML will wait until there's at least enough buffer to take another picture. (lens_info.job_state tells us this, and lens_wait_readytotakepic() polls this function until the timeout).

Code: [Select]

/**
 * This tells whether the camera is ready to take a picture (or not)
 * 5D2: the sequence is: 0 11 10 8 0
 *      that means: 0 = idle, 11 = very busy (exposing), 10 = exposed, but processing (can take the next picture), 8 = done processing, just saving to card
 *      also, when job state is 11, we can't change camera settings, but when it's 10, we can
 * 5D3: the sequence is: 0 0x16 0x14 0x10 0
 * other cameras may have different values
 *
 * => hypothesis: the general sequence is:
 *
 *   0 max something_smaller something_even_smaller and so on
 *
 *   so, we only want to avoid the situation when job_state == max_job_state
 *
 */

static int max_job_state = 0;

int job_state_ready_to_take_pic()
{
    if (max_job_state == 0) return 1;
    return (int)lens_info.job_state < max_job_state;
}


PROP_HANDLER( PROP_LAST_JOB_STATE )
{
    const uint32_t state = *(uint32_t*) buf;
    lens_info.job_state = state;
   
    if (max_job_state == 0 && state != 0)
        max_job_state = state;
   
    if (max_job_state && (int)state == max_job_state)
    {
        mirror_locked = 0;
        hdr_flag_picture_was_taken();
    }

    #ifdef CONFIG_JOB_STATE_DEBUG
    static char jmsg[100] = "";
    STR_APPEND(jmsg, "%d ", state);
    bmp_printf(FONT_MED,0,0, jmsg);
    #endif
}


Adjust the "take pics" setting.  Make it longer then the shutter period, with sufficient time added for you to adjust settings.

Well, I suggested that too, but apparently that's not good enough for OP.

[Audionut]

Oh indeed.  I should know that too from taking bias frames.

[jimbr549]

It's a simple formula, actually.  It is:

Shutter speed (variable) + Write time (fixed)  =  Interval

Either ML, in it's current state, is capable of this or it's not.  Either it could be coded to work with this formula or it could not.  I was just asking a question (and offering compensation, money meets mouth kinda thing), no need to get all panty wadded.

I've been shooting TL for a few years and I have a decent understanding of how it works.  I came here to inquire about a tool that might do something different.  A simple, concise explanation of how the new, improved ML intervalometer works would suffice if it addressed my specific question.  ML is "good enough" for what it is and I will continue to use it, as I have for the last 3 years. 



"I would change that to "ML will try fire the shots at the intervalometer period". ML will wait until it knows it can take another picture (with some timeout, I think maybe ~3 seconds)"

That's called a collision.  Frames are missed while the buffer clears. 


Adjust the "take pics" setting.  Make it longer then the shutter period, with sufficient time added for you to adjust settings.

As I said, that's what I'm trying to avoid.  I know, it's "out of the box".  Oh, well.

Maybe the simple solution is to fire frame #2 when frame #1 is finished writing to the card.  Maybe a 1/2 second pause could be put in-between?



Well, I suggested that too, but apparently that's not good enough for OP.

Correct. It's not.  It's an inflexible solution.  I'm looking to do something different.  I'm willing to pay for it.  As a developer, what more could you ask for?  It's a funded challenge.  Whatcha got?

[Audionut]

That's called a collision.  Frames are missed while the buffer clears.

If you take frames faster then the write speed of the storage system, to the point where the, in camera buffer, is also full, you have reached an hardware limit that ML cannot fix, adjust, make better, hack, or anything else.  What you see is what you get.

Frames are not missed, they are delayed.

I'm willing to pay for it.  As a developer, what more could you ask for?  It's a funded challenge.  Whatcha got?

A coding challenge that benefits the greater userbase, funding is not required.

[dmilligan]

Frames are not missed, they are delayed.

Exactly my point, which is what OP was asking for in the first place. But after that was explained, the goal posts were moved again, and the requirement became not only to not drop frames, but to also add some time between frames for image review and settings adjustment.

Shutter speed (variable) + Write time (fixed)  =  Interval

This is already implemented by ML, and I have already explained how. ML will delay the interval until it the camera is ready to take another picture. But this also isn't what you are really asking for, what you are asking for is to add an additional, user adjustable delay for image review and settings adjustment.

Whatcha got?

It would really only take one line of code (pretty much anywhere in the intervalometer section of shoot_task) to do what you're asking:

Code: [Select]

    msleep(2000);

Though, you'd probably want to make it a customizable setting, which would require another line or two of code. It could probably also be done from a module.

[jimbr549]

I've read your posts, thanks for the input. 

My kit to use DSLRController should arrive today and I'll be running some tests to see how many shots I can get while performing a manual ramp and at what point a collision/missed frame occurs.

JB