Author Topic: Eclipse exposure sequence generator.  (Read 3283 times)

grnbrg

  • New to the forum
  • *
  • Posts: 9
Eclipse exposure sequence generator.
« on: June 20, 2017, 07:54:07 PM »
If you haven't heard of it yet, you will soon.  There will be a total solar eclipse visible to most of North America on August 21st this year.  I am making the road trip to the path of totality, and have written a script to take a series of exposures over the ~3 hours of the eclipse, with heavy coverage during the 2 and a half minutes of totality.

Notable features:

  • Calculates the intervals to take an arbitrary number of partial phase images, both in the C1-C2 and C3-C4 periods.
  • Includes a configurable "margin" time, so that the first and last interval images are "interesting".
  • Allows for exposure bracketing of the partial phase images.  Configurable number of brackets and f-stops.
  • Fires a configurable "burst" of images at C2 and C3.  Depending on your camera's buffer, you can adjust how far before C2 and C3 this burst starts, so that you can be sure of coverage.
  • During totality, will run through a configurable range of exposures as many times as possible.  Minimum and maximum shutter speed, as well as the f-stop step size can be specified.
  • Image times are calculated based on clock time, not by intervals between shots, which means that if you need to restart the camera (to change a battery, late setup, or other issue) the sequence will begin to execute at whatever image is appropriate for the current time.
  • Has a test mode, which will run through a given sequence (starting at 00:00:00 when the camera powers on) without activating the shutter.

Download (from pastebin, as I can't be bothered to put it into git):  https://pastebin.com/kbewPDjf

Comments are welcome.  (My first lua script, although I have been hacking in various languages for years.)

Two questions:

Code: [Select]

tick_time = 0 -- global
tick_offset = 0 -- global

event.seconds_clock = function (ignore)
   
    local cur_time = dryos.date
    local cur_secs = (cur_time.hour * 3600 + cur_time.min * 60 + cur_time.sec)

    tick_time = cur_secs
    tick_offset = dryos.ms_clock
   
    return true
   
end

function wait_until (done_waiting) -- done_waiting is a future time, in seconds.
 
    local counter = tick_time
    local next_sec = 0
   
    repeat
 
        task.yield (1000) -- Let the camera do other tasks for a second.
   
        counter = tick_time
                   
    until (counter >= (done_waiting - 1))
           
    if ( counter < done_waiting)   
    then

        next_sec = (1000 - (dryos.ms_clock - tick_offset))     
   
        msleep (next_sec)
       
    end
               
end

The script spends a lot of time waiting for the appropriate time to take the next image, and these two functions should (I think) pause until the target time arrives, and exit as close as possible to the beginning of the target clock time second.  Any suggested improvements? 

And...

Code: [Select]
function take_shot(iso, speed, dobkt, bktstep, bktcount)

   camera.iso.value = iso

   for bktnum = PartialBktCount,(-1 * PartialBktCount),-1 do
 
        bktspeed = PartialShutterSpeed * (2.0^(bktnum * PartialBktStep))
           
        camera.shutter.value = bktspeed
       
        camera.shoot(false)

        task.yield(10) -- Give other stuff a chance to run
   
   end

end

This is takes a bracketed exposure, with $bkcount brackets, and an f-stop change of $bktstep per bracket.  Is there a more sensible way to do this?

Thanks!



grnbrg.

PS:  If a lua build for the 70D that supports camera.burst() were to show up before August 21st, I'd be really pleased.  :)

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12171
  • Maintenance mode
Re: Eclipse exposure sequence generator.
« Reply #1 on: June 21, 2017, 01:16:37 AM »
Very cool - I've seen it earlier, it was linked from this thread, also eclipse-related.

My first lua script, although I have been hacking in various languages for years.

I actually like this coding style very much.

Quote
The script spends a lot of time waiting for the appropriate time to take the next image, and these two functions should (I think) pause until the target time arrives, and exit as close as possible to the beginning of the target clock time second.  Any suggested improvements?

Looks fine to me.

Currently, this event handler is done by sleeping for 200ms and checking the internal microsecond timer (which is different from RTC and they are not in sync, to my knowledge). So, there is probably a bit of jitter.

For a more precise sync to integer seconds, you could poll the RTC (dryos.date) with a tighter interval. For syncing to shorter intervals, you could use dryos.ms_clock, which is derived from the internal microsecond timer (we call it "digic timer"), but that one will probably drift from the RTC a little (didn't test).

Also, since multitasking is quite tricky in our Lua implementation (and that's because of my very limited understanding of Lua internals), I prefer to keep the scripts single-threaded. From my limited tests (read: api_test.lua), event handlers appear to be working fine though.

Quote
This is takes a bracketed exposure, with $bkcount brackets, and an f-stop change of $bktstep per bracket.  Is there a more sensible way to do this?

An alternative would be to enable Advanced Bracket menu (with the menu API from Lua) and then take the first picture. Not sure if it would be any better; didn't try.

If you want to take a burst of full-size images, and you have (or can borrow) a 5D3, my suggestion would be the 4K branch, as it can also record full-res frames (with rolling shutter) at about 4-5 FPS continuously, without shutter actuation. Otherwise, if you are OK with a 1:1 crop, the 48/50/60 fps video modes might also be useful. Per-frame bracketing in LiveView is also doable (just not implemented, but the backend support is there - see e.g. HDR video). Or maybe this.

BTW, noticed this in the script:
Quote
-- I have tried replacing this with multiple calls to "camera.shoot()", but it is still considerably
-- slower than "camera.burst()", and can also crash the camera

Can you prepare a minimal example that crashes the camera?

And I also have a question: how do you know what MinShutterSpeed and MaxShutterSpeed will give a reasonably good exposure during the eclipse?

Side note: the Intervalometer Ramping module is probably capable of something similar (by ramping interval time according to real-time clock, and by enabling Advanced Bracketing with auto exposure range). Have you considered it?

grnbrg

  • New to the forum
  • *
  • Posts: 9
Re: Eclipse exposure sequence generator.
« Reply #2 on: June 21, 2017, 07:56:04 PM »
For a more precise sync to integer seconds, you could poll the RTC (dryos.date) with a tighter interval. For syncing to shorter intervals, you could use dryos.ms_clock, which is derived from the internal microsecond timer (we call it "digic timer"), but that one will probably drift from the RTC a little (didn't test).

Also, since multitasking is quite tricky in our Lua implementation (and that's because of my very limited understanding of Lua internals), I prefer to keep the scripts single-threaded. From my limited tests (read: api_test.lua), event handlers appear to be working fine though.

I made some changes (new version) last night -- leaving the event.seconds_clock() function active was leading to semaphore errors.  I'm now doing a timing loop at the beginning, and building a X.00 seconds offset from the average of 10 reads of dryos.ms_clock, and then setting event.seconds_clock() to nil.  I think I'm getting more consistent results with that approach, and the semaphore errors made me nervous.

Quote
If you want to take a burst of full-size images, and you have (or can borrow) a 5D3, my suggestion would be the 4K branch, as it can also record full-res frames

Heh.  I bought a used 5DmkII body last week, as a full-frame sensor is a better match to the telescope I will be using.  I don't think I could have convinced the wife that a mkIII was a good idea.  As it is, I will likely sell it again in September -- my 70D is superior in most other ways that are important to me.

Quote
BTW, noticed this in the script:
Can you prepare a minimal example that crashes the camera?

I will see about reproducing the errors I am finding, and will post some example scripts.  Right now I'm too focused on getting the results I'd like.  :)

Quote
And I also have a question: how do you know what MinShutterSpeed and MaxShutterSpeed will give a reasonably good exposure during the eclipse?

The internet is amazing.  :)  For virtually any need you might have, someone has already done the heavy lifting.  From 3rd party camera software to solar eclipse exposure calculations...  Living in the future is cool.

Quote
Side note: the Intervalometer Ramping module is probably capable of something similar (by ramping interval time according to real-time clock, and by enabling Advanced Bracketing with auto exposure range). Have you considered it?

I am looking to spend as little time fiddling with the camera during the eclipse, and during totality in particular.  A standard intervalometer might work for each of the 3 segments, but the requirements for capturing the totality segment are vastly different than the other two.  With the approach I'm taking, I can set up an hour before the eclipse starts, launch the script, and then not touch the camera again until 3 hours later.

I'll have a look.  It might well make more sense to reduce the script to a series of timed calls to the hard coded intervalometer.

And another incoming bugs that I will provide some sample scripts for in a couple of days....  Some of the reading I've done in the last couple of days pointed out that vibration caused by mirror slap could be largely reduced by shooting in LiveView.  So I tried that last night, and  ran into a number of issues.  Flooding the camera with single shots with Live View active caused a crash.   Also, while lv.start() seems to work as advertised, lv.stop() doesn't seem to disable it.  These bugs were with the current May 01 5Dmkii lua_fix build -- the offhand comment from yesterday may have been from the 70d beta build, not sure.

I think I may be uncovering issues because I am hammering the camera hard.  Totality in August will be around 2 minutes and 30 seconds, so that has been what I have been testing.  I'm triggering a 14 frame camera.burst(14), then doing a tight loop of setting a new shutter speed, calling camera.shoot(false), then at the end of totality, another burst.  So in that 150 seconds, I have been (in testing) taking upwards of 250 exposures.

Very much appreciate the ML software.

Thanks for your time.




Brian.

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12171
  • Maintenance mode
Re: Eclipse exposure sequence generator.
« Reply #3 on: June 23, 2017, 07:33:09 PM »
Quote
leaving the event.seconds_clock() function active was leading to semaphore errors.

That's the current state of multitasking in Lua, unfortunately. The event handlers cannot run while the main task is busy.

vibration caused by mirror slap could be largely reduced by shooting in LiveView.

ML also has a tool to address this, though I have no idea whether it works on 70D (don't remember any reports - looks like it's disabled on this camera). Apparently nobody used this feature in the last 3 years (on the cameras where it's enabled).

Quote
I think I may be uncovering issues because I am hammering the camera hard.

That's probably the best way to test, and proper bug reports are always appreciated here.


steveastrouk

  • New to the forum
  • *
  • Posts: 1
Re: Eclipse exposure sequence generator.
« Reply #4 on: July 02, 2017, 07:34:40 PM »
Hi,
First post !
I've joined the forum specifically to find out the best way to sequence and prepare my camera for the eclipse.

What would be a good way to test out the script, and get familiar with it ? I'm intending to mount my camera on an Iopton equatorial mount for a couple of hours around the event - is it worth it ?

Last time I saw an eclipse, we used film :-0
Love the work you guys have done. Thanks a lot

Steve

astronomer

  • New to the forum
  • *
  • Posts: 3
Re: Eclipse exposure sequence generator.
« Reply #5 on: July 27, 2017, 06:40:22 PM »
Hi there,

Amazing work. I made some modification to the script. You could enter liveview between c2 and c3 so it is using electronic first curtain to reduce vibration.

However, I ran into a problem with the scripting on camera.burst(count)

LUA interpreter raised an error message
"attempt to call a nil value (field 'burst')"

Is this associated with version of magic lantern? I'm using the latest nightly build for my 6D

SpcCb

  • Member
  • ***
  • Posts: 207
Re: Eclipse exposure sequence generator.
« Reply #6 on: July 28, 2017, 05:26:16 AM »
Nice ! I think there will be a couple of ML camera in this Solar eclipse ;)

If you plan to sync sequences on time and use liveview, take care to not burn your sensor. Specially if the camera is at the prime focus of a telescope, in seconds you can reach several hundreds of °C on the focus plane.
And it is very hard to calculate the precise time of C* (w/ second accurate), even if you know your precise location.

DeafEyeJedi

  • Hero Member
  • *****
  • Posts: 3171
  • 5D3 / M1 / 7D / 70D / SL1 / M2
Re: Eclipse exposure sequence generator.
« Reply #7 on: July 28, 2017, 08:55:04 PM »
ML also has a tool to address this, though I have no idea whether it works on 70D (don't remember any reports - looks like it's disabled on this camera). Apparently nobody used this feature in the last 3 years (on the cameras where it's enabled).

What a nice hidden gem...  :o
5D3.113 • 5D3.123 • EOSM.203 • 7D.203 • 70D.112 • 100D.101 • EOSM2.*

tukr

  • New to the forum
  • *
  • Posts: 3
Re: Eclipse exposure sequence generator.
« Reply #8 on: August 20, 2017, 11:35:02 PM »
Hey, so i have an EOS rebel T5 and i loaded your script, under test settings (testbeepnoshutter = 1) the script runs through entirety. If it is set to real world use(testbeepnoshutter = 0) my camera shutters once, then the red indicator stays on and nothing more, unresponsive. battery removal is the only way to get a response. Any help would be appreciated.
 
Update, I used live view to see if anything changed, This time it called out a memory error and wrote a log before rebooting.
Code: [Select]
ASSERT: FALSE
at Memory\Memory.c:188, task ShootPreDevelop
lv:0 mode:3


Magic Lantern version : Nightly.2016Jul30.1200D101
Mercurial changeset   : a1fa773fa8d7+ (1200D)
Built on 2016-07-30 15:13:22 UFree Memory  : 64K + 525K

anyway to correct this? I also have a canon SL1 but have not put magic lantern on it.  Thanks