Closed GoogleCodeExporter closed 9 years ago
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
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
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
"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
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
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
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
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
"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
[deleted comment]
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
Change applied; many thanks for the suggestion.
Original comment by eduardo....@gmail.com
on 11 May 2012 at 4:58
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
Agreed!
Original comment by colinban...@gmail.com
on 2 Aug 2012 at 11:54
Original issue reported on code.google.com by
colinban...@gmail.com
on 9 May 2012 at 5:24