Add auto-exposure bracketing feature

[jflalonde]

Using auto-exposure bracketing on the Mark iii allows the capture of multiple exposures extremely fast. For example, using the following script, the 7 exposures needed for the sky camera can be captured in 6 seconds, instead of 40+ seconds with the current setup.

gphoto2 --set-config /main/capturesettings/aeb="+/- 3" --set-config /main/capturesettings/aperture="16" --set-config /main/capturesettings/shutterspeed="1/1000" --set-config /main/actions/eosremoterelease=2 --wait-event=1s

gphoto2 --set-config /main/capturesettings/aperture="4" --set-config /main/capturesettings/shutterspeed="1/30" --set-config /main/actions/eosremoterelease=2 --wait-event=1s

gphoto2 --set-config /main/capturesettings/aeb=0 --set-config /main/capturesettings/shutterspeed="1" --capture-image

Let's talk about this soon!

[soravux]

I've previously handled this issue with gphoto in this bash script I gave to @jacenfox some time ago. In CameraNetwork, the delay could be handled in Python instead of specifying "--wait-event=1s", for instance.

But to make it robust, the _run_gphoto function should do a loop over its Popen to try multiples times (like 5, with a delay of 100ms between calls for example). This would be to prevent a call that would fail because the previous call still isn't done, which can happend quite often.

[jacenfox]

Using auto-exposure bracketing will greatly improve the capturing speed.
It is different from the normal capturing we are using now. In this model camera could capture mutiple exposure images just in one setting! Thanks to professor JF find this method, this allow us to capture 7 images in 6sec. This is faster than adjusting the "--wait-event" in normal capture model.

[soravux]

Sorry, after reading my post I realise I wasn't really clear on my intentions: I was proposing a method to get the 7 photos in even less than 6 seconds if we merge the two ideas together.

The bracketing trick is an awesome find for sure!

[jflalonde]

Thing is, I think the wait-event is necessary... More experiments necessary :)

Sent from my iPhone

On Nov 1, 2014, at 12:56, Yannick Hold notifications@github.com wrote:

Sorry, after reading my post I realise I wasn't really clear on my intentions: I was proposing a method to get the 7 photos in even less than 6 seconds if we merge the two ideas together.

The bracketing trick is an awesome find for sure!

—
Reply to this email directly or view it on GitHub.

[soravux]

I bet you a beer I can get the 7 exposures in less than 5 seconds!

Joking aside, the experiments I did a while ago worked when I discarded the wait-event (taking into account that there were no transfer in the request). The problem was subsequent requests to gphoto2: they crashed or weren't executed if the previous command was not completed. The cool thing about wait-event is that it'll wait for the delay after the command was issued, while issuing a sleep command asynchronously would begin before the command was even issued to the camera (because of gphoto2 handshake and delays). Hence, it's not because there is a sleep(0.5) in the code that a capture of 1/2s is done...

I just thought that if there was a way to either poll quickly the camera to ask it if it's busy, or call the gphoto2 anyway and check its return value (and re-issue the command if it crashed), we could improve even more the time footprint.

But I may be wrong, these details are dim in my memory... And I'm talking about ~30% gain, which is nowhere near the 85% gain of auto-exposure bracketing...

[jflalonde]

You're on for the beer :)

Sent from my iPhone

On Nov 1, 2014, at 19:22, Yannick Hold notifications@github.com wrote:

I bet you a beer I can get the 7 exposures in less than 5 seconds!

Joking aside, the experiments I did a while ago worked when I discarded the wait-event (taking into account that there were no transfer in the request). The problem was subsequent requests to gphoto2: they crashed or weren't executed if the previous command was not completed. The cool thing about wait-event is that it'll wait for the delay after the command was issued, while issuing a sleep command asynchronously would begin before the command was even issued to the camera (because of gphoto2 handshake and delays). Hence, it's not because there is a sleep(0.5) in the code that a capture of 1/2s is done...

I just thought that if there was a way to either poll quickly the camera to ask it if it's busy, or call the gphoto2 anyway and check its return value (and re-issue the command if it crashed), we could improve even more the time footprint.

But I may be wrong, these details are dim in my memory... And I'm talking about ~30% gain, which is nowhere near the 85% gain of auto-exposure bracketing...

—
Reply to this email directly or view it on GitHub.

[jacenfox]

You owe a beer to our Professor :) haha
Yes, both of you are exactl right! We need to keep the wait-event. Maybe this is the reason why we lost one CR2 file at 15:11-20141022.

[jflalonde]

Tell you what: I owe you both beers if you can integrate the exposure bracketing feature in the cam network :)

Sent from my iPhone

On Nov 1, 2014, at 22:13, jacenfox notifications@github.com wrote:

You owe a beer to our Professor :) haha
Yes, both of you are exactl right! We need to keep the wait-event. Maybe this is the reason why we lost one CR2 file at 15:11-20141022.

—
Reply to this email directly or view it on GitHub.

[soravux]

I'm on in this week, probably Tuesday or Wednesday!

[MathGaron]

Any idea how to implement it without breaking compatibility with other device that dont support this feature? Unless we feel that hdr may be done only with auto-bracketing... If there is a way to check if gphoto can set the mode it would be a good start. And do we have to physically turn on a switch?

For the timing, I remember stumbling on a feature about wait-event, and waiting on events instead of time, I tried some things but did not understand what gphoto was capturing as "event", it was not acting like i wanted so I made it wait on time instead. But if we understand it and if it is stable, maybe it will be the most efficient way, if we know exactly the quantity of event after a shot?

But in fact like soravux said, it is little optimisation vs the bracketting feature, and these can be implemented easily as 2 different features.

[soravux]

@jacenfox : There seems to be problems with the auto exposure bracketing in recent versions that were published around 2013 (see here and here). Maybe it's the same problem you experienced when trying the feature? If so, updating to the latest nightly build or newer stable release (if there is) should fix the problem.

@MathGaron : It's possible to probe the camera abilities (--abilities) before performing the --set-config. I'm not sure whether aeb is in the probed abilities, though. There's no switch to turn on physically on the camera.

I share your wariness about the event catching of gphoto. I saw multiple problems of people trying to use that to trigger something on various forums. I tried to use the shell version of gphoto2 to display all the triggers and I wasn't really sure that everything that should be happening was really happening. We could give it another shot, but I doubt it will lead to something stable... Actually, I think the goal is to wait for a specific event to trigger and not a quantity of events after a shot.

[soravux]

I just realized that using the shell version of gphoto more than halves the execution time of every command issued. This is because loading the gphoto executable image in memory (and all its libraries) takes a long time on my system (and very probably even more on the pi).

Something along the lines of :

time gphoto2 --shell <<< '
set-config f-number=13
set-config shutterspeed=0,0002
capture-image wait-event=0s
'

is actually more than twice as fast as issuing the commands separately. (Sorry for the Nikon config, I don't have a Canon at home :p ). Another bonus feature: it doesn't probe for the camera for each command.

[jflalonde]

Keep working hard, that beer is coming! :)

On Nov 5, 2014, at 12:18 , Yannick Hold notifications@github.com wrote:

I just realized that using the shell version of gphoto more than halves the execution time of every command issued. This is because loading the gphoto executable image in memory (and all its libraries) takes a long time on my system (and very probably even more on the pi).

Something along the lines of :

time gphoto2 --shell <<< '
set-config f-number=13
set-config shutterspeed=0,0002
capture-image wait-event=0s
'
is actually more than twice as fast as issuing the commands separately. (Sorry for the Nikon config, I don't have a Canon at home :p ). Another bonus feature: it doesn't probe for the camera for each command.

—
Reply to this email directly or view it on GitHub #12 (comment).