Feature Request: Interval ramping for time lapse
724 views
Skip to first unread message
Francis Danforth
Jan 23, 2012, 11:12:51 AM1/23/12
to Magic Lantern firmware development
I thought about this while using the ML bulb-ramping on my 550d. The
only place I can find mention of this technique (and where I got the
term) is from the Little Bramper, an external intervalometer/bulb-
ramper. http://www.thewhippersnapper.com/LittleBramper/Site/Tutorials_&_Support_files/Little_Bramper_User_Manual_v3.pdf
Imagine doing a time lapse of a day to night transition. To get a
smooth transition for the sunset portion, you need an interval less
than 10s or so. That caps your exposure length to 8s. But to continue
this time lapse into capturing the night sky, you need exp lengths
approaching 30s requiring an interval of 32s. What I'm envisioning is
an algorithm that slowly changes the interval between exposures to
allow for a smooth transition between a short to long interval.
The Little Bramper has 2 methods for this. First is a manual mode
where you set the increase in interval in relation to # of shots
taken, eg. every 100 shots the interval doubles (I'm guessing in a
quadratic fashion). This mode allows for adjustment of the interval
and rate of change throughout the lapse. Second is an automated mode
where you set the initial interval and the final interval and I'm
guessing it calculates some nonlinear transition in between.
I can see the difficulties in this, especially with rapid changes in
necessary exposure length creating the possibility of skipped shots.
Also to include something like the Little Brampers manual mode, a
preset number of shots would be needed, not just the current endless
cycle.
I'd love to help with this, but my coding is out of practice. However,
I have been thinking about this algorithmically for the past week and
will continue to do so.
only place I can find mention of this technique (and where I got the
term) is from the Little Bramper, an external intervalometer/bulb-
ramper. http://www.thewhippersnapper.com/LittleBramper/Site/Tutorials_&_Support_files/Little_Bramper_User_Manual_v3.pdf
Imagine doing a time lapse of a day to night transition. To get a
smooth transition for the sunset portion, you need an interval less
than 10s or so. That caps your exposure length to 8s. But to continue
this time lapse into capturing the night sky, you need exp lengths
approaching 30s requiring an interval of 32s. What I'm envisioning is
an algorithm that slowly changes the interval between exposures to
allow for a smooth transition between a short to long interval.
The Little Bramper has 2 methods for this. First is a manual mode
where you set the increase in interval in relation to # of shots
taken, eg. every 100 shots the interval doubles (I'm guessing in a
quadratic fashion). This mode allows for adjustment of the interval
and rate of change throughout the lapse. Second is an automated mode
where you set the initial interval and the final interval and I'm
guessing it calculates some nonlinear transition in between.
I can see the difficulties in this, especially with rapid changes in
necessary exposure length creating the possibility of skipped shots.
Also to include something like the Little Brampers manual mode, a
preset number of shots would be needed, not just the current endless
cycle.
I'd love to help with this, but my coding is out of practice. However,
I have been thinking about this algorithmically for the past week and
will continue to do so.
Joe
Jan 24, 2012, 1:58:22 AM1/24/12
to Magic Lantern firmware development
+1 for this! :) Great idea. I'd also love to see the possibility of
setting a specific time (ie, 40 minutes after sunset when the sky is
sure to be dark) to let the exposure slowly ramp down in order to make
the foreground objects/buildings/mountains turn to silhouettes. Using
a set time, based on the sun, you should be able to get interesting
results. OR, am I completely off base? Can someone with more TL/
bramping experience set me straight? Thanks!
-joe
On Jan 23, 8:12 am, Francis Danforth <danfor...@gmail.com> wrote:
> I thought about this while using the ML bulb-ramping on my 550d. The
> only place I can find mention of this technique (and where I got the
> term) is from the Little Bramper, an external intervalometer/bulb-
> ramper.http://www.thewhippersnapper.com/LittleBramper/Site/Tutorials_&_Suppo...
setting a specific time (ie, 40 minutes after sunset when the sky is
sure to be dark) to let the exposure slowly ramp down in order to make
the foreground objects/buildings/mountains turn to silhouettes. Using
a set time, based on the sun, you should be able to get interesting
results. OR, am I completely off base? Can someone with more TL/
bramping experience set me straight? Thanks!
-joe
On Jan 23, 8:12 am, Francis Danforth <danfor...@gmail.com> wrote:
> I thought about this while using the ML bulb-ramping on my 550d. The
> only place I can find mention of this technique (and where I got the
> term) is from the Little Bramper, an external intervalometer/bulb-
Francis Danforth
Jan 24, 2012, 11:35:35 AM1/24/12
to Magic Lantern firmware development
I just found this example of tethering software with the time of day
specific adjustment you mean, GBTimelapse <http://vimeo.com/35216694>.
It allows you to set a specific percentage decrease in luminance after
a pre-calculated sunset. Very clever and thorough stuff. Without have
a preprogrammed sunrise/sunset calendar or calculator, you could just
consider the length of the time lapse by choosing the number of frames
shot and giving a percentage decrease in luminance from the beginning
to the final frame and just approximate it yourself from trial and
error. Similarly, if you know what you want your final exposure value
to be, you can limit the time lapse by setting the max ISO and the
interval length, thus the maximum shutter speed.
As far as ramping the interval, it seems that in general practice
resetting the interval to 1.5t once shutter speed = t-2s would work
because it is rare that exposure would change by more than a .5 stop
in a short to moderate length interval (at least in my very limited
experience). It certainly would not be a smooth transition in apparent
time if it was a very dynamic scene but it is a simple calculation. No
doubt though that there is an alternative that provides a better
transition.
Also in regards to the ML bulb ramper, would it be possible that
triggering the shutter (or some other programmed button) could reduce
the interval count to 0 instead of exposing at whatever your manual
setting was prior to starting the time lapse/ramp script? This would
be very useful for using the bulb ramper in conjunction with ND
filters. It could allow you to quickly get through the shots necessary
to readjust after a large change in EV, e.g. removing a ND filter from
your lens. Currently taking a shot does the opposite by confusing the
algorithm into thinking what the next adjustment needs to be. It also
does not reset the interval count nor pull up the histogram to adjust
until the interval timer reaches 0.
specific adjustment you mean, GBTimelapse <http://vimeo.com/35216694>.
It allows you to set a specific percentage decrease in luminance after
a pre-calculated sunset. Very clever and thorough stuff. Without have
a preprogrammed sunrise/sunset calendar or calculator, you could just
consider the length of the time lapse by choosing the number of frames
shot and giving a percentage decrease in luminance from the beginning
to the final frame and just approximate it yourself from trial and
error. Similarly, if you know what you want your final exposure value
to be, you can limit the time lapse by setting the max ISO and the
interval length, thus the maximum shutter speed.
As far as ramping the interval, it seems that in general practice
resetting the interval to 1.5t once shutter speed = t-2s would work
because it is rare that exposure would change by more than a .5 stop
in a short to moderate length interval (at least in my very limited
experience). It certainly would not be a smooth transition in apparent
time if it was a very dynamic scene but it is a simple calculation. No
doubt though that there is an alternative that provides a better
transition.
Also in regards to the ML bulb ramper, would it be possible that
triggering the shutter (or some other programmed button) could reduce
the interval count to 0 instead of exposing at whatever your manual
setting was prior to starting the time lapse/ramp script? This would
be very useful for using the bulb ramper in conjunction with ND
filters. It could allow you to quickly get through the shots necessary
to readjust after a large change in EV, e.g. removing a ND filter from
your lens. Currently taking a shot does the opposite by confusing the
algorithm into thinking what the next adjustment needs to be. It also
does not reset the interval count nor pull up the histogram to adjust
until the interval timer reaches 0.
Justin Williamson
Jan 25, 2012, 10:10:27 AM1/25/12
to Magic Lantern firmware development
Wow,
That's the holy grail!
That's the holy grail!
Joe
Jan 30, 2012, 6:07:20 PM1/30/12
to Magic Lantern firmware development
Francis, I feel like all of these are great ideas! I hope that Alex
sees this thread! Keep the good ideas coming...
Cheers,
-joe
sees this thread! Keep the good ideas coming...
Cheers,
-joe
Alex
Feb 1, 2012, 4:14:49 AM2/1/12
to Magic Lantern firmware development
The first implementation of bulb ramping had no limit regarding
shutter speed - if at some point, you needed 10 minutes of exposure,
the intervalometer would have simply waited for that.
But my test with this showed that it introduced a lot of jitter
(motion was far from smooth). That's why the intervalometer now tries
to use precise timing (fixed rate, like in video mode). So if the
intervalometer delay needs to be ramped, this has to be in smooth
steps (1.5x may be too much). If you are OK with 1.5x, you can already
change it manually while bulb ramping is running.
For changing ND filters, it's probably good to have a function to auto-
repeat the shot if exposure difference happens to be larger than,
let's say, 1 EV. But this would only work if exposure for next shot is
computed right after current shot - this requires eiher you to enable
Image Review, or ML to switch to playback mode right after taking a
picture, and this means changing the bulb ramping logic a bit.
The repeated shots could be taken at ISO 6400 (or higher, but 6400
works on all cameras regardless of custom functions status) - just to
make it run faster, because those shots will be deleted afterwards.
shutter speed - if at some point, you needed 10 minutes of exposure,
the intervalometer would have simply waited for that.
But my test with this showed that it introduced a lot of jitter
(motion was far from smooth). That's why the intervalometer now tries
to use precise timing (fixed rate, like in video mode). So if the
intervalometer delay needs to be ramped, this has to be in smooth
steps (1.5x may be too much). If you are OK with 1.5x, you can already
change it manually while bulb ramping is running.
For changing ND filters, it's probably good to have a function to auto-
repeat the shot if exposure difference happens to be larger than,
let's say, 1 EV. But this would only work if exposure for next shot is
computed right after current shot - this requires eiher you to enable
Image Review, or ML to switch to playback mode right after taking a
picture, and this means changing the bulb ramping logic a bit.
The repeated shots could be taken at ISO 6400 (or higher, but 6400
works on all cameras regardless of custom functions status) - just to
make it run faster, because those shots will be deleted afterwards.
Francis Danforth
Feb 2, 2012, 8:47:31 PM2/2/12
to Magic Lantern firmware development
I didn't think about the possibility of simply changing the interval
while the intervalometer is running. I don't have any practical
experience with changing the interval mid-time lapse but now that I
think about it, the motion increasing in speed by 50% between 2 frames
would be visually jarring. If it is implemented it would have to be
gradual.
Your idea about an auto-repeat is excellent. I've tried to implement
it but have run into some problems. I'm sure it could be written more
concisely but in shoot.c I moved
if (bulb_ramping_enabled)
{
bulb_ramping_init();
compute_exposure_for_next_shot();
}
before the intervalometer while countdown loop. In
compute_exposure_for_next_shot() I added
if ((abs(correction_ev_x100)) >= 100) correction_over_1stop = 1; else
correction_over_1stop = 0;
Finally I added
if (correction_over_1stop) intervalometer_skip(); within the
intervalometer countdown while loop
where
void intervalometer_skip()
{if (intervalometer_running) intervalometer_next_shot_time =
seconds_clock;}
It seems to be working in general function except one major problem.
It does not wait for you to exit the menu before trying to initialize
bulb ramping (no 3-second countdown). I imagine I could add a check to
ensure !gui_menu_shown when bulb ramping is initialized but that seems
very sloppy. Suggestions?
Also, your suggestion about looking to a button handler to invoke
intervalometer_skip was fruitful and I was able to map it the the Q-
menu button. I believe I avoided all multi-tasks but I'm not positive.
I have no idea if it is of use to others but until I can figure out an
auto_repeat it will work. As for 50d and 5d2 users, I don't really
know which button would be most practical for this.
Now if only the weather would improve so I could get out and try some
of these things not in my backyard.
while the intervalometer is running. I don't have any practical
experience with changing the interval mid-time lapse but now that I
think about it, the motion increasing in speed by 50% between 2 frames
would be visually jarring. If it is implemented it would have to be
gradual.
Your idea about an auto-repeat is excellent. I've tried to implement
it but have run into some problems. I'm sure it could be written more
concisely but in shoot.c I moved
if (bulb_ramping_enabled)
{
bulb_ramping_init();
compute_exposure_for_next_shot();
}
before the intervalometer while countdown loop. In
compute_exposure_for_next_shot() I added
if ((abs(correction_ev_x100)) >= 100) correction_over_1stop = 1; else
correction_over_1stop = 0;
Finally I added
if (correction_over_1stop) intervalometer_skip(); within the
intervalometer countdown while loop
where
void intervalometer_skip()
{if (intervalometer_running) intervalometer_next_shot_time =
seconds_clock;}
It seems to be working in general function except one major problem.
It does not wait for you to exit the menu before trying to initialize
bulb ramping (no 3-second countdown). I imagine I could add a check to
ensure !gui_menu_shown when bulb ramping is initialized but that seems
very sloppy. Suggestions?
Also, your suggestion about looking to a button handler to invoke
intervalometer_skip was fruitful and I was able to map it the the Q-
menu button. I believe I avoided all multi-tasks but I'm not positive.
I have no idea if it is of use to others but until I can figure out an
auto_repeat it will work. As for 50d and 5d2 users, I don't really
know which button would be most practical for this.
Now if only the weather would improve so I could get out and try some
of these things not in my backyard.
Francis Danforth
Feb 3, 2012, 10:54:41 PM2/3/12
to Magic Lantern firmware development
Please excuse my ramblings all, but I figure this is the development
group. Not every post should be a feature request.
Adding a check to ensure the menu was not still enabled settled my
previous problem. Now I'm on to taking these shots at 6400 ISO.
Calling lens_set_rawiso(6400) in the 180 rule function did not work.
Where should I look to figure out how lens_set_functions() work?
Give me 24hrs with no response and I'll probably find it but I
wouldn't mind some insight. Any developers out there other than Alex?
-FD
group. Not every post should be a feature request.
Adding a check to ensure the menu was not still enabled settled my
previous problem. Now I'm on to taking these shots at 6400 ISO.
Calling lens_set_rawiso(6400) in the 180 rule function did not work.
Where should I look to figure out how lens_set_functions() work?
Give me 24hrs with no response and I'll probably find it but I
wouldn't mind some insight. Any developers out there other than Alex?
-FD
Alex
Feb 4, 2012, 8:48:58 AM2/4/12
to Magic Lantern firmware development
lens_set_rawiso expects raw values, in 1/8 EV steps (look in lens.h
for a table with those values).
To use human-readable values, use lens_set_iso(6400).
But for bulb ramping, my recommended solution is to look at the 180
rule function and to do this:
1) request a very small shutter speed
2) remove the max ISO limit.
The shutter speed requested there is considered something nice to
have, but not mandatory (so if, for example, there's too much light
for ISO 6400, it will not screw up anything). And it's exactly what
you need - you only ask it to take faster exposures, so it will have
to raise the ISO.
-------
Another idea would be to look at shutter speed and consider your
changes as being exposure compensation for next shot. That way, if you
remove a ND filter of 1 stop, you will then slowdown the shutter speed
by 1 stop (two or three scrollwheel clicks, depending on your EV step
size).
In playback mode, you can access scrollwheel events directly (with
handlers); in shooting mode, you can't (you have to look at shutter
speed to get something meaningful). Look at shutter lock function to
see how it's implemented.
for a table with those values).
To use human-readable values, use lens_set_iso(6400).
But for bulb ramping, my recommended solution is to look at the 180
rule function and to do this:
1) request a very small shutter speed
2) remove the max ISO limit.
The shutter speed requested there is considered something nice to
have, but not mandatory (so if, for example, there's too much light
for ISO 6400, it will not screw up anything). And it's exactly what
you need - you only ask it to take faster exposures, so it will have
to raise the ISO.
-------
Another idea would be to look at shutter speed and consider your
changes as being exposure compensation for next shot. That way, if you
remove a ND filter of 1 stop, you will then slowdown the shutter speed
by 1 stop (two or three scrollwheel clicks, depending on your EV step
size).
In playback mode, you can access scrollwheel events directly (with
handlers); in shooting mode, you can't (you have to look at shutter
speed to get something meaningful). Look at shutter lock function to
see how it's implemented.
Alex
Feb 4, 2012, 3:11:03 PM2/4/12
to Magic Lantern firmware development
Here's an implementation of bulb ramping which lets you change exposure compensation for next shot - hope it helps with ND filters.
Some scenarios:
- You close the aperture of your manual lens by 1 stop. To compensate, you turn the scrollwheel to the left, as you would slowdown shutter speed by 1 stop.
- You remove a ND4 filter. To compensate, turn the scrollwheel to the right, as you would make the shutter speed faster by 3 stops.
- You change the aperture of your Canon lens. ML will compensate the exposure automatically (nothing else to do).
For interval ramping, there's another related feature request here: http://vimeo.com/groups/magiclantern/forumthread:251815
So, my idea would be to add a few variables to be incremented at each shot (or maybe every X shots), like:
- interval (example: increment by 1 second every 10 shots)
- focus (change focus by 1 step every shot, open-loop; you'll need to run rack/stack focus to figure out what parameters to enter)
- aperture (here, smallest step would be 1/8 EV on older cameras and a bit higher on newer ones... 1/3 with approximations, 1/2 with exact increments)
- exposure compensation (that would do a simple fading; probably not needed, since it's easy to do in post)
Or... enable scripting (Lua?) and let users implement advanced timelapse scenarios in a way similar to CHDK. What do you think?
------------
Bulb ramping is still not working on 600D. Still waiting for a reply to https://bitbucket.org/hudson/magic-lantern/issue/957/bulb-ramping-trouble-scene-to-dark - which would allow me to figure out what's wrong.
------------
Other important changes:
- You can select timings like 1 minute and 30 seconds (intervalometer + bulb timer)
- You can use LiveView tools (histograms, zebras, focus peaking etc) in image review mode, right after you take a picture. I find this very handy => enabled by default.
- RGB spotmeter
- Backend changes: should result in better stability when using display-related features (like powersaving, custom colors, saturation adjustments)
- When you use FPS override, sound is automatically disabled
- 5D fixes (especially regarding "Force LiveView" feature when used with powersaving enabled)
- Full list here: https://bitbucket.org/hudson/magic-lantern/changesets
As there are a few backend changes, it needs a bit of testing to make sure there are no surprises.
Some scenarios:
- You close the aperture of your manual lens by 1 stop. To compensate, you turn the scrollwheel to the left, as you would slowdown shutter speed by 1 stop.
- You remove a ND4 filter. To compensate, turn the scrollwheel to the right, as you would make the shutter speed faster by 3 stops.
- You change the aperture of your Canon lens. ML will compensate the exposure automatically (nothing else to do).
For interval ramping, there's another related feature request here: http://vimeo.com/groups/magiclantern/forumthread:251815
So, my idea would be to add a few variables to be incremented at each shot (or maybe every X shots), like:
- interval (example: increment by 1 second every 10 shots)
- focus (change focus by 1 step every shot, open-loop; you'll need to run rack/stack focus to figure out what parameters to enter)
- aperture (here, smallest step would be 1/8 EV on older cameras and a bit higher on newer ones... 1/3 with approximations, 1/2 with exact increments)
- exposure compensation (that would do a simple fading; probably not needed, since it's easy to do in post)
Or... enable scripting (Lua?) and let users implement advanced timelapse scenarios in a way similar to CHDK. What do you think?
------------
Bulb ramping is still not working on 600D. Still waiting for a reply to https://bitbucket.org/hudson/magic-lantern/issue/957/bulb-ramping-trouble-scene-to-dark - which would allow me to figure out what's wrong.
------------
Other important changes:
- You can select timings like 1 minute and 30 seconds (intervalometer + bulb timer)
- You can use LiveView tools (histograms, zebras, focus peaking etc) in image review mode, right after you take a picture. I find this very handy => enabled by default.
- RGB spotmeter
- Backend changes: should result in better stability when using display-related features (like powersaving, custom colors, saturation adjustments)
- When you use FPS override, sound is automatically disabled
- 5D fixes (especially regarding "Force LiveView" feature when used with powersaving enabled)
- Full list here: https://bitbucket.org/hudson/magic-lantern/changesets
As there are a few backend changes, it needs a bit of testing to make sure there are no surprises.
--
http://magiclantern.wikia.com/
To post to this group, send email to ml-d...@googlegroups.com
To unsubscribe from this group, send email to ml-devel+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/ml-devel?hl=en
Francis Danforth
Feb 5, 2012, 2:49:00 AM2/5/12
to Magic Lantern firmware development
The exposure adjustment is an excellent solution, a nice middle ground
between automated and manual.
As for your interval(and other variables)-ramping ideas, I think that
preprogrammed increments will yield the most predictable results.
There's going to be a learning curve no matter what the implementation
is. The possibility of scripting is not a bad idea either. The
scripting capabilities of CHDK is what led me to Magic Lantern.
Thank you for your interest and responses, Alex. Well done!
-FD
On Feb 4, 3:11 pm, Alex <broscutama...@gmail.com> wrote:
> Here's an implementation of bulb ramping which lets you change exposure
> compensation for next shot - hope it helps with ND filters.
>
> Some scenarios:
>
> - You close the aperture of your manual lens by 1 stop. To compensate, you
> turn the scrollwheel to the left, as you would slowdown shutter speed by 1
> stop.
> - You remove a ND4 filter. To compensate, turn the scrollwheel to the
> right, as you would make the shutter speed faster by 3 stops.
> - You change the aperture of your Canon lens. ML will compensate the
> exposure automatically (nothing else to do).
>
> For interval ramping, there's another related feature request here:http://vimeo.com/groups/magiclantern/forumthread:251815
>
> So, my idea would be to add a few variables to be incremented at each shot
> (or maybe every X shots), like:
>
> - interval (example: increment by 1 second every 10 shots)
> - focus (change focus by 1 step every shot, open-loop; you'll need to run
> rack/stack focus to figure out what parameters to enter)
> - aperture (here, smallest step would be 1/8 EV on older cameras and a bit
> higher on newer ones... 1/3 with approximations, 1/2 with exact increments)
> - exposure compensation (that would do a simple fading; probably not
> needed, since it's easy to do in post)
>
> Or... enable scripting (Lua?) and let users implement advanced timelapse
> scenarios in a way similar to CHDK. What do you think?
>
> ------------
>
> Bulb ramping is still not working on 600D. Still waiting for a reply tohttps://bitbucket.org/hudson/magic-lantern/issue/957/bulb-ramping-tro...
> ...
>
> read more »
>
> autoexec.bin
> 1793KViewDownload
between automated and manual.
As for your interval(and other variables)-ramping ideas, I think that
preprogrammed increments will yield the most predictable results.
There's going to be a learning curve no matter what the implementation
is. The possibility of scripting is not a bad idea either. The
scripting capabilities of CHDK is what led me to Magic Lantern.
Thank you for your interest and responses, Alex. Well done!
-FD
On Feb 4, 3:11 pm, Alex <broscutama...@gmail.com> wrote:
> Here's an implementation of bulb ramping which lets you change exposure
> compensation for next shot - hope it helps with ND filters.
>
> Some scenarios:
>
> - You close the aperture of your manual lens by 1 stop. To compensate, you
> turn the scrollwheel to the left, as you would slowdown shutter speed by 1
> stop.
> - You remove a ND4 filter. To compensate, turn the scrollwheel to the
> right, as you would make the shutter speed faster by 3 stops.
> - You change the aperture of your Canon lens. ML will compensate the
> exposure automatically (nothing else to do).
>
> For interval ramping, there's another related feature request here:http://vimeo.com/groups/magiclantern/forumthread:251815
>
> So, my idea would be to add a few variables to be incremented at each shot
> (or maybe every X shots), like:
>
> - interval (example: increment by 1 second every 10 shots)
> - focus (change focus by 1 step every shot, open-loop; you'll need to run
> rack/stack focus to figure out what parameters to enter)
> - aperture (here, smallest step would be 1/8 EV on older cameras and a bit
> higher on newer ones... 1/3 with approximations, 1/2 with exact increments)
> - exposure compensation (that would do a simple fading; probably not
> needed, since it's easy to do in post)
>
> Or... enable scripting (Lua?) and let users implement advanced timelapse
> scenarios in a way similar to CHDK. What do you think?
>
> ------------
>
>
> read more »
>
> autoexec.bin
> 1793KViewDownload
Ilya Terentyev
Feb 5, 2012, 7:17:35 AM2/5/12
to ml-d...@googlegroups.com
Hi! Great work, as usual!
I'd like to add several features to BRamping and intervalometer:
1. possibility to tell ML exactly how many stops ND filter is removed and let ML to adjust accordingly. It will let us get properly exposed shot, even if we have "non-standard" ND. For example, I have Hoya ND400, and it is claimed to be 9 stops. But in reality it's 8.4 stops. So, I see workflow like setting 1-2-3 ND filters in ML like 3 stops, 3.2, 3.1 and then assign a button, pressing which is telling ML the 3rd, then 2nd and then 1st filter is removed.
2. Removing limitation of "take shot every X seconds". For example, during a day I shot 10 sec intervals with 1 sec duration. But in the night time I need 30secs. I suggest just remove this limit. Yes, statistics will be not accurate - hard to predict the time, needed for timelapse, but at least it will be possible to shot it :)
3. To be able to specify Min and Max Exposure times, Apertures and ISO's and when to change between them.
5. Interval ramping, telling ML when is the sunset/sunrise, and how long it will last to increase/decrease frame rate to fully capture these events.
6. Specifying how much darker the night is to measured/calibrated exposure. So ML won't turn night into day. Obviously, this is connected to sunset/sunrise function, because ML should know, when night/days begins. I see this feature like in GBtimelapse. Night = 70% brightness of the day :). Combustible.
7. Intervalometer - please, add precise adjustments. 30secs -> 35secs are not good. 1 sec adjustments are really needed.
These are the things I came about testing ML on 5d2. Sorry, If something is already done and I didn't notice.
Thx!!!--
С уважением, Илья Терентьев
I'd like to add several features to BRamping and intervalometer:
1. possibility to tell ML exactly how many stops ND filter is removed and let ML to adjust accordingly. It will let us get properly exposed shot, even if we have "non-standard" ND. For example, I have Hoya ND400, and it is claimed to be 9 stops. But in reality it's 8.4 stops. So, I see workflow like setting 1-2-3 ND filters in ML like 3 stops, 3.2, 3.1 and then assign a button, pressing which is telling ML the 3rd, then 2nd and then 1st filter is removed.
2. Removing limitation of "take shot every X seconds". For example, during a day I shot 10 sec intervals with 1 sec duration. But in the night time I need 30secs. I suggest just remove this limit. Yes, statistics will be not accurate - hard to predict the time, needed for timelapse, but at least it will be possible to shot it :)
3. To be able to specify Min and Max Exposure times, Apertures and ISO's and when to change between them.
5. Interval ramping, telling ML when is the sunset/sunrise, and how long it will last to increase/decrease frame rate to fully capture these events.
6. Specifying how much darker the night is to measured/calibrated exposure. So ML won't turn night into day. Obviously, this is connected to sunset/sunrise function, because ML should know, when night/days begins. I see this feature like in GBtimelapse. Night = 70% brightness of the day :). Combustible.
7. Intervalometer - please, add precise adjustments. 30secs -> 35secs are not good. 1 sec adjustments are really needed.
These are the things I came about testing ML on 5d2. Sorry, If something is already done and I didn't notice.
Thx!!!
С уважением, Илья Терентьев
Francis Danforth
Feb 5, 2012, 1:08:23 PM2/5/12
to Magic Lantern firmware development
This newest build has at least incorporates at least one of your
requests. Although it might not be absolutely precise, you can
compensate for a change in exposure, such as removing a ND with the
scroll wheel. It allows adjustment in 1/3 stops, so as long as you
know the closest 1/3 stop to the actual value of your ND you should be
good to go. A minor exposure adjustment in post should help you get
the rest of the way there.
Requests #2 and 3 are the next steps. Maybe with scripting,
programming in nightfall would be possible.
The more I think about it, I really like the idea of shifting the
focus in steps throughout a time lapse. Could be interesting when used
with a macro scene. Great idea, Alex.
> >https://bitbucket.org/hudson/magic-lantern/issue/957/bulb-ramping-tro...which would allow me to figure out what's wrong.
> ...
>
> read more »
requests. Although it might not be absolutely precise, you can
compensate for a change in exposure, such as removing a ND with the
scroll wheel. It allows adjustment in 1/3 stops, so as long as you
know the closest 1/3 stop to the actual value of your ND you should be
good to go. A minor exposure adjustment in post should help you get
the rest of the way there.
Requests #2 and 3 are the next steps. Maybe with scripting,
programming in nightfall would be possible.
The more I think about it, I really like the idea of shifting the
focus in steps throughout a time lapse. Could be interesting when used
with a macro scene. Great idea, Alex.
>
> > ------------
>
> > Other important changes:
>
> > - You can select timings like 1 minute and 30 seconds (intervalometer +
> > bulb timer)
> > - You can use LiveView tools (histograms, zebras, focus peaking etc) in
> > image review mode, right after you take a picture. I find this very handy
> > => enabled by default.
> > - RGB spotmeter
> > - Backend changes: should result in better stability when using
> > display-related features (like powersaving, custom colors, saturation
> > adjustments)
> > - When you use FPS override, sound is automatically disabled
> > - 5D fixes (especially regarding "Force LiveView" feature when used with
> > powersaving enabled)
> > - Full list here:https://bitbucket.org/hudson/magic-lantern/changesets
>
> > As there are a few backend changes, it needs a bit of testing to make sure
> > there are no surprises.
>
> > ------------
>
> > Other important changes:
>
> > - You can select timings like 1 minute and 30 seconds (intervalometer +
> > bulb timer)
> > - You can use LiveView tools (histograms, zebras, focus peaking etc) in
> > image review mode, right after you take a picture. I find this very handy
> > => enabled by default.
> > - RGB spotmeter
> > - Backend changes: should result in better stability when using
> > display-related features (like powersaving, custom colors, saturation
> > adjustments)
> > - When you use FPS override, sound is automatically disabled
> > - 5D fixes (especially regarding "Force LiveView" feature when used with
> > powersaving enabled)
> > - Full list here:https://bitbucket.org/hudson/magic-lantern/changesets
>
> > As there are a few backend changes, it needs a bit of testing to make sure
> > there are no surprises.
>
>
> read more »
MagicBrick
Feb 6, 2012, 6:22:59 PM2/6/12
to Magic Lantern firmware development
... short bug report: display->saturation is applied even outside
quick review mode :-o ... I've set it to greyscale for LV, worked
fine, but starting with the Feb. 4 build even with manual PLAY all
pictures are greyscale - even with "LiveV tools in QR" set to OFF!
quick review mode :-o ... I've set it to greyscale for LV, worked
fine, but starting with the Feb. 4 build even with manual PLAY all
pictures are greyscale - even with "LiveV tools in QR" set to OFF!
Alex
Feb 7, 2012, 2:35:33 AM2/7/12
to ml-d...@googlegroups.com
This was a feature request... check the help text.
You can setup focus peaking to make the image in grayscale - in this case, the image will be grayscale only as long as focus peaking is active (and you can setup this in display presets).
You can setup focus peaking to make the image in grayscale - in this case, the image will be grayscale only as long as focus peaking is active (and you can setup this in display presets).
Francis Danforth
Feb 20, 2012, 2:04:50 AM2/20/12
to Magic Lantern firmware development
After a busy couple of weeks, I've been working today on trying to
implement these incremental changes. It seemed simplest to start with
the interval increment. Looking to the examples of other menu options
I think I've got a good handle on it but I'm coming across a fatal
error when trying to compile.
Here is the message:
../../src/shoot.c: In function 'wait_for_lv_err_msg':
../../src/shoot.c:4254:42: warning: comparison between pointer and
integer [enabled by default]
make: *** [shoot.o] Error 1
I had not made any changes to any code in this part of the source so
I'm unsure how to go about fixing this. Is it a problem with my
system? I'm compiling on a Mac, which has posed problems previously.
Separately, I am wondering if I am limited to whole second changes in
the interval, given the current algorithm for the intervalometer.
Syncing to the system clock seems to negate the possibility of smaller
changes in the interval (eg. 100ms every 10 shots instead of 1s every
100 shots) without some serious changes.
On Feb 4, 3:11 pm, Alex <broscutama...@gmail.com> wrote:
> Here's an implementation of bulb ramping which lets you change exposure
> compensation for next shot - hope it helps with ND filters.
>
> Some scenarios:
>
> - You close the aperture of your manual lens by 1 stop. To compensate, you
> turn the scrollwheel to the left, as you would slowdown shutter speed by 1
> stop.
> - You remove a ND4 filter. To compensate, turn the scrollwheel to the
> right, as you would make the shutter speed faster by 3 stops.
> - You change the aperture of your Canon lens. ML will compensate the
> exposure automatically (nothing else to do).
>
> For interval ramping, there's another related feature request here:http://vimeo.com/groups/magiclantern/forumthread:251815
>
> So, my idea would be to add a few variables to be incremented at each shot
> (or maybe every X shots), like:
>
> - interval (example: increment by 1 second every 10 shots)
> - focus (change focus by 1 step every shot, open-loop; you'll need to run
> rack/stack focus to figure out what parameters to enter)
> - aperture (here, smallest step would be 1/8 EV on older cameras and a bit
> higher on newer ones... 1/3 with approximations, 1/2 with exact increments)
> - exposure compensation (that would do a simple fading; probably not
> needed, since it's easy to do in post)
>
> Or... enable scripting (Lua?) and let users implement advanced timelapse
> scenarios in a way similar to CHDK. What do you think?
>
> ------------
>
> Bulb ramping is still not working on 600D. Still waiting for a reply tohttps://bitbucket.org/hudson/magic-lantern/issue/957/bulb-ramping-tro...
implement these incremental changes. It seemed simplest to start with
the interval increment. Looking to the examples of other menu options
I think I've got a good handle on it but I'm coming across a fatal
error when trying to compile.
Here is the message:
../../src/shoot.c: In function 'wait_for_lv_err_msg':
../../src/shoot.c:4254:42: warning: comparison between pointer and
integer [enabled by default]
make: *** [shoot.o] Error 1
I had not made any changes to any code in this part of the source so
I'm unsure how to go about fixing this. Is it a problem with my
system? I'm compiling on a Mac, which has posed problems previously.
Separately, I am wondering if I am limited to whole second changes in
the interval, given the current algorithm for the intervalometer.
Syncing to the system clock seems to negate the possibility of smaller
changes in the interval (eg. 100ms every 10 shots instead of 1s every
100 shots) without some serious changes.
On Feb 4, 3:11 pm, Alex <broscutama...@gmail.com> wrote:
> Here's an implementation of bulb ramping which lets you change exposure
> compensation for next shot - hope it helps with ND filters.
>
> Some scenarios:
>
> - You close the aperture of your manual lens by 1 stop. To compensate, you
> turn the scrollwheel to the left, as you would slowdown shutter speed by 1
> stop.
> - You remove a ND4 filter. To compensate, turn the scrollwheel to the
> right, as you would make the shutter speed faster by 3 stops.
> - You change the aperture of your Canon lens. ML will compensate the
> exposure automatically (nothing else to do).
>
> For interval ramping, there's another related feature request here:http://vimeo.com/groups/magiclantern/forumthread:251815
>
> So, my idea would be to add a few variables to be incremented at each shot
> (or maybe every X shots), like:
>
> - interval (example: increment by 1 second every 10 shots)
> - focus (change focus by 1 step every shot, open-loop; you'll need to run
> rack/stack focus to figure out what parameters to enter)
> - aperture (here, smallest step would be 1/8 EV on older cameras and a bit
> higher on newer ones... 1/3 with approximations, 1/2 with exact increments)
> - exposure compensation (that would do a simple fading; probably not
> needed, since it's easy to do in post)
>
> Or... enable scripting (Lua?) and let users implement advanced timelapse
> scenarios in a way similar to CHDK. What do you think?
>
> ------------
>
Ryan
Feb 28, 2012, 2:07:42 PM2/28/12
to Magic Lantern firmware development
Dear Alex, Francis, et al.
I have been testing the bramping feature quite extensively. There are
several problems with the automatic algorithm, and several people on
the Timescapes forum agree. Full automation would be great , and it
has been attempted numerous times, but without a bit of celestial
math, it is fatally flawed. I have yet to get consistent or
repeatable results with the current ML bramping algorithm. There is
just too much flicker, it is unpredictable, night usually looks like
day, and it is impossible to begin at night and bramp a sunrise. It
is a nice start at least.
I would love to help with developing this. I have not coded in years,
and would not know where to begin on the ML side; however, I could
help with the space math.
In the meantime, we should have manual bramping control without the
image analysis, like Little Bramper. With Little Bramper, you can
say: "Increase 2 stops every 10 minutes." This is great. However,
Little Bramper only has 3 presets and requires manual ISO stepping.
Basically, it requires someone to constantly babysit the camera. If
we know our exposure values ahead of time, we can have smooth as silk
bramps by manually setting up the timelapse.
Ideally we need to have either a user defined lookup table of time and
Ev, or the ability to set around 7 to 9 presets or waypoints for the
bramp.
Example 1:
05:00-08:00 increase 3 Ev, or .25 Ev/10 min
08:01-09:00 increase 8 Ev, or 1.3 Ev/10 min
09:01-13:00 increase 5Ev, or 0.2 Ev/10 min
13:01-15:00 no change, just intervalometer
15:01-19:00 decrease 5 Ev, or 0.2 Ev/10/min
etc...
Example 2:
exposure# 1-200 increase 3 Ev, or .25 Ev/10 min
exposure# 201-300 increase 8 Ev, or 1.3 Ev/10 min
exposure# 301-500 increase 5Ev, or 0.2 Ev/10 min
exposure# 501-800 no change, just intervalometer
exposure# 801-1000 decrease 5 Ev, or 0.2 Ev/10/min
etc…
The only manual adjustment on the camera is then adding or removing
Neutral Density filters. Which we already have the ability to
compensate for with the dial.
What would be the easiest solution for manual bramp control that you
can implement? A user defined lookup table, clock based presets, or
presets based on the number of exposures? This would be great until
we can improve the automated analysis algorithm. I know you are busy
with exploring the DIGIC registers at the moment, but if manual bramp
control is only a few lines of code, it would really, really rock!
Kind Regards,
Ryan
> ...
>
> read more »
I have been testing the bramping feature quite extensively. There are
several problems with the automatic algorithm, and several people on
the Timescapes forum agree. Full automation would be great , and it
has been attempted numerous times, but without a bit of celestial
math, it is fatally flawed. I have yet to get consistent or
repeatable results with the current ML bramping algorithm. There is
just too much flicker, it is unpredictable, night usually looks like
day, and it is impossible to begin at night and bramp a sunrise. It
is a nice start at least.
I would love to help with developing this. I have not coded in years,
and would not know where to begin on the ML side; however, I could
help with the space math.
In the meantime, we should have manual bramping control without the
image analysis, like Little Bramper. With Little Bramper, you can
say: "Increase 2 stops every 10 minutes." This is great. However,
Little Bramper only has 3 presets and requires manual ISO stepping.
Basically, it requires someone to constantly babysit the camera. If
we know our exposure values ahead of time, we can have smooth as silk
bramps by manually setting up the timelapse.
Ideally we need to have either a user defined lookup table of time and
Ev, or the ability to set around 7 to 9 presets or waypoints for the
bramp.
Example 1:
05:00-08:00 increase 3 Ev, or .25 Ev/10 min
08:01-09:00 increase 8 Ev, or 1.3 Ev/10 min
09:01-13:00 increase 5Ev, or 0.2 Ev/10 min
13:01-15:00 no change, just intervalometer
15:01-19:00 decrease 5 Ev, or 0.2 Ev/10/min
etc...
Example 2:
exposure# 1-200 increase 3 Ev, or .25 Ev/10 min
exposure# 201-300 increase 8 Ev, or 1.3 Ev/10 min
exposure# 301-500 increase 5Ev, or 0.2 Ev/10 min
exposure# 501-800 no change, just intervalometer
exposure# 801-1000 decrease 5 Ev, or 0.2 Ev/10/min
etc…
The only manual adjustment on the camera is then adding or removing
Neutral Density filters. Which we already have the ability to
compensate for with the dial.
What would be the easiest solution for manual bramp control that you
can implement? A user defined lookup table, clock based presets, or
presets based on the number of exposures? This would be great until
we can improve the automated analysis algorithm. I know you are busy
with exploring the DIGIC registers at the moment, but if manual bramp
control is only a few lines of code, it would really, really rock!
Kind Regards,
Ryan
>
> read more »
Reply all
Reply to author
Forward
0 new messages