Intervalometer - Where possible, include Action settings in calculation of Recording Time

[GoogleCodeExporter]

The current calculation of recording time doesn't take any Action settings into 
account. 

In cases where the shutter speed cannot be known beforehand, no additional 
calculation can be done. However, there are cases where additional computations 
can be taken into account:
1)EAEB Bulb Min/Max, and the number of exposures that result from the EV 
settings.
2)Long Exposure.

Original issue reported on code.google.com by colinban...@gmail.com on 9 May 2012 at 5:24

[GoogleCodeExporter]

Not sure that we should do this:

The calculator errs about the total recording time when the time required to 
take a "shot" (be it an EAEB sequence, or a long exposure) is longer than the 
specified time between shots. But that is an abnormal situation, not something 
that the user is expected to do on purpose.

Besides, when this happens we must take into account not only the time required 
to take a photograph, but also the time needed to write the images to the card, 
and the flash's recycle time, and ...

On the other hand, I could understand the need to warn the user about 
potentially absurd parameters, like a time between shots shorter than the 
exposure time.

Original comment by eduardo....@gmail.com on 9 May 2012 at 6:43

[GoogleCodeExporter]

I might be missing something here, so please correct me if I have overlooked 
something. 

In Long Exposure I enter an exposure time of 5 minutes. In the intervalometer I 
set Time as 1 minute and Shots as 5. Given these settings, the minimum 
recording time should be 30 minutes. However, the calculated recording time is 
5 minutes. If the calculator is going to be that inaccurate, why bother with it 
at all? 

I should have mentioned in my previous post that what we should calculate is 
the *minimum* recording time (Min. record time). It then becomes a simple 
matter of documenting that time for writing to the card, flash recycle time, 
auto shutter speeds and other unknowns are excluded from the calculation. If we 
do take into account the parameters that we can control, we'll be far closer to 
the truth than not (as demonstrated in the long exposure example above).

Original comment by colinban...@gmail.com on 9 May 2012 at 8:21

[GoogleCodeExporter]

No, I do not think you are overlooking anything; but we are not agreeing on 
where "the problem" is.

As you know, in version 20120415 the "Time" value in the intervalometer sets 
the cadence of actions, not the pause between the end of an action and the 
beginning of the next one; in your example, a "Time" of one minute means that 
the camera should perform an action every minute, no matter how long that 
action takes. Obviously, it's impossible to make a five-minute exposure every 
minute; what you get, instead, are 5 long-exposure shots in a burst.

So, from my point of view, "the problem" in your example is not in the 
calculator, but in the parameters, because we are asking the camera to do 
something impossible; and 400plus should prevent that situation from happening 
(not letting the user set those values, for example), or perhaps warn the user 
and deactivate the calculator. In your example, a "recording time" of 25 
minutes will be pretty accurate, and I see the point of your argument; but not 
for shorter exposure times, when the other factors become more important.

Original comment by eduardo....@gmail.com on 9 May 2012 at 9:17

[GoogleCodeExporter]

"As you know, in version 20120415 the "Time" value in the intervalometer sets 
the cadence of actions, not the pause between the end of an action and the 
beginning of the next one"

Indeed, I did overlook this :)

Original comment by colinban...@gmail.com on 9 May 2012 at 10:00

[GoogleCodeExporter]

I think that the source of my confusion was that I was not making the mental 
association between two parts of the user guide.

So the following statement could be taken out of context:

"Time: the interval time (in minutes:seconds) between each shot (or group of 
shots). Values range from 00:01 to 05:00." 

However, the statement is further qualified elsewhere:

"Notice that 400plus will always try to maintain a constant cadence of shots, 
independent of the exposure time: if configured to shot at 15s intervals, for 
example, then one shot will be taken exactly every 15s, even if the exposure is 
10s. If one shot in the sequence has an exposure time longer than the 
configured interval time, 400plus will skip as many shots as needed and 
reschedule the sequence."

The way I interpret this statement for the long exposure action is, for example:

If I were to set the long exposure to 30sec, and in the intervalometer set time 
to 15 sec for say 5 shots, then the following is what I expect when the 
intervalometer script is run:

1) The first shot begins
2) 15 sec later, interval time is skipped because the exposure is not complete.
3) After 30 sec, exposure is complete.
4) The 15 sec interval timer kicks in.
5) After 15 sec the next exposure is taken.
6) 1-5 is repeated for the remaining shots.

However, I wasn't able to check the above because the camera completely locks 
up soon after the intervalometer script is run.

Original comment by colinban...@gmail.com on 10 May 2012 at 6:29

[GoogleCodeExporter]

I'm sorry if the user guide is confusing; I'm not an English native speaker, 
and sometimes I struggle to find the words that explain what I want to express.

What the guide tries to say is that the "Time" parameter indicates the schedule 
when the camera will try to perform each action, irregardless of the duration 
of each action; if the camera is busy when an action is due to start, then the 
script will wait until the next scheduled action.

For example, imagine a "Time" parameter of 5 seconds, and exposures ranging 
between 1 and 4 seconds (let's suppose camera is in Av mode, and light 
conditions change during the script):

Time (s) : # · · · · # · · · · # · · · · # · · · ·
Exposure : * *       * * * *   *         * *

Now, imagine that one of the exposures takes longer than 5 seconds (let's say 
7):

Time (s) : # · · · · # · · · · # · · · · # · · · ·
Exposure : * *       * * * * * * *       * *

Notice that the third photograph does not take place 5 seconds after the second 
one, but at second 15. In your example, if you want the camera to wait for 15s 
after each 30s exposure, just set the "Time" parameter to 45s. Under your 
model, the intervalometer becomes unpredictable if the exposure is not constant.

I'm working on the intervalometer issues right now, by the way; it is a top 
priority for me.

Original comment by eduardo....@gmail.com on 10 May 2012 at 7:21

[GoogleCodeExporter]

No, the confusion was mine, not the guide. Your graph above explains the 
working perfectly, without words. It's how I intepreted the text. In my 
example, I was just trying to understand what happens in a particular scenario. 
However, are you saying that the timer can't work as I described?

Time:     #...............#...............#
Exposure: *********************************

Assuming time to write card is negligible, I expect the second time interval to 
be skipped, and the second exposure to begin on the third interval (okay, 
that's close, and the third interval could be missed, so let's make the 
exposure 25 sec, instead of 30 sec).

The whole point of the exercise was to see how the long exposure, which can be 
up 100 min, will work with max value for time, if max time happens to be less 
100 min + required interval between shots. 

Original comment by colinban...@gmail.com on 10 May 2012 at 8:42

[GoogleCodeExporter]

If the exposure time is 25s, and the interval time is 15s, then I would expect 
a photograph to be taken every 30s:

Time:     #...............#...............#...............#...............
Exposure: ***************************     *****************************

But then, to achieve this result, I would have set the interval time to 30s 
instead: interval times shorter than the exposure times do not make sense 
(except in the case of variable lighting conditions, perhaps); if the camera 
permits these situations is just because I was too lazy to code it properly.

Original comment by eduardo....@gmail.com on 10 May 2012 at 9:19

[GoogleCodeExporter]

"interval times shorter than the exposure times do not make sense (except in 
the case of variable lighting conditions, perhaps);"

Agreed. Also, if the max interval time you can set is less than an explicitly 
set long exposure time, you don't have any other choice other than skipping 
intervals. I don't see any issue in this scenario, once it's understood how the 
timing works. 

Original comment by colinban...@gmail.com on 10 May 2012 at 9:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Edu, the clarifications you added to the user guide are well done. I haven't 
mentioned this before, but the first sentence in the section "Time-lapse 
calculator" doesn't make much sense. Better would be:

"If you plan to make a time-lapse movie with the photographs taken with this 
script, you can specify a desired reproduction frame-rate, and the script will 
calculate the resulting reproduction time."

Original comment by colinban...@gmail.com on 11 May 2012 at 2:34

[GoogleCodeExporter]

Change applied; many thanks for the suggestion.

Original comment by eduardo....@gmail.com on 11 May 2012 at 4:58

[GoogleCodeExporter]

We cannot calculate the action time but for a small set of cases (camera must 
be in Tv or M modes only, safety shift disabled, ...); and even in those cases, 
we can only do a rough estimate (time to write to the card must also be taken 
into account, for example). Sometimes we will be able to warn the user that he 
is using absurd values, quite often we won't.

At the end, I feel this is too much work for a half-working solution; I'll add 
a warning to the User Guide, and close this issue.

Original comment by eduardo....@gmail.com on 2 Aug 2012 at 9:11

• Changed state: WontDo

[GoogleCodeExporter]

Agreed!

Original comment by colinban...@gmail.com on 2 Aug 2012 at 11:54