BULB ramping

[GoogleCodeExporter]

Please, describe the enhancement of feature requested below:
http://www.thewhippersnapper.com/LittleBramper/Site/Home.html

Original issue reported on code.google.com by eduardo....@gmail.com on 16 Jan 2012 at 8:26

[GoogleCodeExporter]

Original comment by eduardo....@gmail.com on 20 Mar 2012 at 1:07

• Added labels: Milestone-M2

[GoogleCodeExporter]

Yes, I would very much like to see this.

Original comment by tomking...@gmail.com on 24 Mar 2012 at 11:16

[GoogleCodeExporter]

This has been scheduled for the release after the next release (Milestone 2). 
In the meantime I'd like to discuss, with those who have a need for this 
feature, how should it work from their point of view; you have now the 
possibility to help design your ideal intervalometer... please, stand up and 
ask!

Original comment by eduardo....@gmail.com on 24 Mar 2012 at 11:34

[GoogleCodeExporter]

I would love to see this feature! Unfortunately I think it will be difficult to 
implement. I think the main problem will be how to control the exposure 
ramping. With a product like the little bramper you can use it as a remote 
control and manually change the exposure as deemed necessary. While just being 
able to ramp up the exposure manually using a script for 400plus would be great 
(with options to control both exposure length and ISO), touching the camera 
body may introduce shaking into the time lapse sequence. I think this feature 
would need an "auto" ramping mode as well as the manual mode.

The "easier for the developer, but harder for the user" option would be to set 
a number of endpoints (i.e. 2 endpoints for simple day-night shots, but more 
endpoints for complex sequences) that would allow users to set the desired 
exposure after a specified time or number of exposures. The "harder for 
developers, but easier for users" option would be to have the ramping totally 
automated. This could work by allowing the camera to "auto-expose" (adjusting 
ISO and/or exposure no more than the smallest possible step 1/3?) every X 
number of exposures or time. This X could be set manually or perhaps 
predetermined to avoid flickering. Similarly, some type of "moving-average" 
exposure could be developed but again may be difficult to implement.

Anyway, I'd be happy to discuss any of these ideas but I have no experience 
with programming... Keep up the good work! I hope to see this feature soon! 

Original comment by daigler...@gmail.com on 22 Apr 2012 at 12:35

[GoogleCodeExporter]

Thanks for the input; your comments are very valuable. You do not have to worry 
about the development if you do not have experience with programming, others 
will take care of that; personally, right now I prefer to receive ideas from 
experienced photographers. Let's talk first about an "ideal bulb ramping", 
we'll discuss later about what is possible and what isn't possible.

Original comment by eduardo....@gmail.com on 22 Apr 2012 at 8:13

• Changed state: Accepted

[GoogleCodeExporter]

I've explored the world of bulb ramping a little more and given it some more 
thought. As I said before it should have and automatic mode and a manual mode. 

The automatic mode would maintain constant exposure value (EV) as if you were 
to shoot an entire timelapse in Auto or Av mode, but without the flickering! 
Users would simply set the interval time, the desired EV and possibly some type 
of deflickering parameter which would alter the degree to which the sequence is 
deflickered (i.e. if you set it very high, the bulb length never changes... set 
it to 0 and you get the same as if you were to use auto or Av mode).

The deflickering in auto mode could be achieved by only allowing the script to 
re-evaluate the bulb ramping parameter every so often (X amount exposures or 
time). I don't know what kind of sophistication can be achieved from these 
scripts but the bulb ramping parameter could be derived from a linear 
extrapolation of the change in light from the previous set of frames.

In the manual mode users would need to tinker with the bulb ramping parameter 
(e.g. +1ms/exposure) while they are shooting their sequences.

Earlier I expressed concerns about touching the camera body while shooting a 
sequence and the IR remote may be the solution to that problem! I have the RC-1 
and it can send 2 presumably different signals, the regular and the 2s delay 
signal. Could you "reprogram" the input of the IR remote to allow to increase 
or decrease the bulb ramping parameter?

Another useful setting would be a max bulb duration (i.e. if your exposure gets 
too long relative to your interval, the script uses photographic reciprocity to 
decrease exposure length 1 step and increase ISO 1 step to maintain constant 
exposure).

I hope this helps!

Original comment by daigler...@gmail.com on 22 Apr 2012 at 5:44

[GoogleCodeExporter]

I just read that Magic Lantern supports bulb ramping, I haven't tried it out 
because I don't own a compatible camera, but it seems like a pretty good 
implementation! It might be easier to modify their implementation to make it 
compatible with the 400plus? Here's what they say about it:
"Bulb Ramping: ON/OFF

Bulb Ramping allows the capture of a timelapse that gradually changes exposure, 
compensating for the transition from day to night.
This option will adjust shutter and ISO automatically, using the 180 degree 
rule.
Quick start:
1. Take a picture of your scene. You will use it to say: "I want my timelapse 
to be exposed like this picture".
2. Enable Bulb Ramping and Intervalometer.
3. Leave the camera still while ML runs a calibration step:
Make sure you have a static and well-lit scene (any static scene which does not 
require long exposure should be fine).
After calibration, you should get a nice S-curve on the screen.
4. Now you will have to say what tone range to meter for (i.e. highlights, 
midtones...). Follow the wizard:
Use arrow keys to select your reference picture (which you just took).
Use the main dial to select the tone range to meter for. You can't perfectly 
match two images just by varying one parameter (exposure), so you have to 
choose what's important for you in this picture.
For lowest flicker, meter for midtones (choose the 50th percentile, i.e. 
median). Leave some headroom for highlights (underexpose a bit).
If highlights are important, meter for them (choose 80th percentile for 
example). You will get more flicker; shoot RAW to remove it easier in post.
The algorithm works best when brightness is close to 50% (try not to choose 
extreme values for it).
When you are ready to start, press SET.
5. Sit back and relax :)
Limits:

ISO is chosen between 100 and maximum auto ISO value from Canon menu.
Shutter speed is chosen between 1/1000 (lower limit) and the delay between two 
shots minus two seconds (upper limit). Example: for 10-second intervals, 
shutter speed will be between 1/1000 and 8 seconds).
Aperture is fixed (you can change it manually).
Tips:
Don't adjust ISO and shutter before the timelapse, they are fully automatic.
You can use this option with a HDR timelapse. In this case, when configuring 
the exposure parameters, choose the brightest picture in the HDR sequence (the 
last one).
Use a ND filter to reduce flicker during daylight.
Reduce flicker in post. You may try VirtualDub with MSU Deflicker plugin (free, 
works with Windows and Wine). See also Timelapse workflow using free software 
tutorial.
The delay between two shots affects how ISO and shutter are chosen, according 
to 180 degree rule:
For example, let's say you set "Take pics every 40 seconds"
ML will try to set the shutter speed between 90 and 270 degrees. In our 
example, it will be chosen between 10 and 30 seconds if the light conditions 
allow it.
If the scene is too bright or too dark, shutter will be chosen between 1/1000 
(at ISO 100) and (d - 2) seconds (at max auto ISO, up to 6400), where d is the 
delay between two shots.

Techincal notes:
Exposure is adjusted using a condition like this (for example): 70% of pixels 
should be below 50% brightness.
Exposure for every shot is computed from previous shot only (camera will go to 
Play mode for one second to compute the exposure from the histogram).
ISO is chosen using the 180 degree rule, so the resulting shutter speed stays 
between 90 and 270 degrees (that is, between 1/4 and 3/4 of the delay between 
two shots).
Only native ISOs (100, 200, 400 etc) are used, for best dynamic range.
Shutter speed can be adjusted with a resolution of 10ms.
Frames with fast shutter speeds (less than 1 second in Rebel cameras, less 0.1 
seconds in 60D) are taken in Manual mode. You will get flicker.
It can go from 1/1000s @ ISO 100 (daylight) to several minutes of exposure time 
@ ISO 6400 (complete darkness).
Exposure algorithm is a P feedback controller, with gain equal to 0.8 (at each 
step, it performs 80% of the correction). Process model is a nonlinear gain 
with dead time (the S-curve you see on the screen, which is the relationship 
between luma and EV ).
If the lighting changes suddenly a few stops between two shots, the algorithm 
should recover completely after 2 or 3 shots."

Original comment by daigler...@gmail.com on 3 May 2012 at 1:30

[GoogleCodeExporter]

No, I do not think we can implement all that right now: in 400plus we still 
cannot see the pictures after they have been taken; we can automate the 
shooting process, but we cannot make it depend on the pixels from the image 
recorded.

Original comment by eduardo....@gmail.com on 3 May 2012 at 1:34

[GoogleCodeExporter]

Although I haven't tried it, I suppose that currently we can create a 
"poor-man" ramper by using a combination of Intervalometer script, AutoISO in 
AV mode, and Safety Shift. It won't achieve much of the ML implementation, but 
should do the basics i.e. adjust ISO and shutter to maintain a constant EV. We 
can't control min shutter after safety shift takes over, nor can we do any 
dynamic range adjustments as described.

Original comment by colinban...@gmail.com on 5 May 2012 at 3:33

[GoogleCodeExporter]

Alex made a very advanced bulb ramping functionality for ML, and as he said, 
since we found the Image VRAM (which can be used as temporary RAM) and the bmp 
stuff for drawing over the screen, we can port their bulb ramper. Worth to take 
a look later.

Original comment by fired...@gmail.com on 5 May 2012 at 3:45

[GoogleCodeExporter]

note:
https://bitbucket.org/hudson/magic-lantern/changeset/915338b093b7#chg_src/shoot.
c_newline3531

Original comment by fired...@gmail.com on 5 May 2012 at 3:46

[GoogleCodeExporter]

The Image VRAM revelation is indeed incredible!!!

Original comment by colinban...@gmail.com on 5 May 2012 at 4:35

[GoogleCodeExporter]

From the above ML description:

"After calibration, you should get a nice S-curve on the screen.
4. Now you will have to say what tone range to meter for (i.e. highlights, 
midtones...). "

Given that we ca now port the Bulb Ramping code,does this mean that we could 
use some of that code to implement Highlight Tone Priority in the 400D?

Original comment by colinban...@gmail.com on 5 May 2012 at 6:11

[GoogleCodeExporter]

it's too early to talk of this port.

Original comment by fired...@gmail.com on 5 May 2012 at 6:27

[GoogleCodeExporter]

This is very exciting news that 400plus is trying its best to incorporate bulb 
ramping for 400D users. 

Can I ask when is the end product expected ?

Original comment by vivek.ba...@gmail.com on 25 Aug 2012 at 9:08

[GoogleCodeExporter]

Sorry, there is no timeline; we work on this project on our free time.

Original comment by eduardo....@gmail.com on 27 Aug 2012 at 10:25

[GoogleCodeExporter]

Original comment by eduardo....@gmail.com on 7 Feb 2013 at 3:28

[GoogleCodeExporter]

Revisions r1714, r1715, r1724 add a "bulb ramping" script, that has also been 
documented in the #UserGuidePreview. It is quite primitive and completely 
manual, nothing fancy as has been commented here. But I prefer to consider this 
issue "finished" and close it, so we can move to other features and prepare the 
next release.

All ideas expressed here, and others that will surely come later, will be 
gathered as improvements in further issues. Thanks.

Original comment by eduardo....@gmail.com on 17 Feb 2013 at 10:08

• Changed state: Fixed