Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - grnbrg

#1
Scripting Corner / Re: Lua Scripting (lua.mo)
August 09, 2017, 04:05:56 AM
"3 frame bursts where a single exposure is correct" -> I expect a single shutter actuation and get three.

I have reproduced the issue with the June 24th and July 6th lua_fix builds -- Will test with the Oct 26, 2016 mainline beta tonight.

I reset the camera settings and ML settings to defaults, and while it did not fix the issue, I'm now (usually*) getting two exposures per camera.shoot(false) + LV + high speed continuous call.  Not really in a position to compile a binary.  Also, slow shutter speeds seem to work -- a 1 second shutter time didn't double or triple.  Will titrate this and report, if I can identify where the problem starts.

*.... usually?

I expanded the test script to shoot a series of -- 1/8000s, 1/4000s, 1/2000s and 1/1000s one after the other.  Usually, each call to camera.shoot(false) is producing two images, as though the function has been called twice.  But occasionally a run of the test script will produce 7 images, not 8.



Brian.

Edit:  Tested with the older mainline binary -- still getting double shutter activations.

When running the following test script:


-- 70D LV exposure test
-- If run in LV, high speed continuous mode, will trigger a burst of 3 frames.

menu.close()
console.show()

print("Click?")

key.wait()

camera.shutter.value = 1/25
camera.iso.value=100
camera.shoot(false)
camera.shutter.value = 1/10
camera.shoot(false)
camera.shutter.value = 1/5
camera.shoot(false)
camera.shutter.value = 1/4
camera.shoot(false)


key.wait()


the 1/25s call results in two images.  The subsequent three calls each reliably result in a single image.
#2
Scripting Corner / Re: Lua Scripting (lua.mo)
August 06, 2017, 01:00:08 AM
Key handling doesn't appear to be relevant -- I came across this in the middle of another script, and pared it down to a testable example.

Just confirmed that the basic intervalometer fires 3 frame bursts where a single exposure is correct, and camera.burst(1) fires 3 frames.  Advanced bracketing seems to work fine.


Brian.
#3
Scripting Corner / Re: Lua Scripting (lua.mo)
August 05, 2017, 11:59:06 PM
:sigh:  Hopefully this is actually a bug this time, and not something that seems pretty obvious in hindsight.


-- 70D LV exposure test
-- If run in LV, high speed continuous mode, will trigger a burst of 3 frames.

menu.close()
console.show()

print("Click?")

key.wait()

camera.shutter.value = 1/500
camera.iso.value=100
camera.shoot(false)

key.wait()


This script should fire a single frame, and does in most combinations.

However, in Live View, with the drive mode set to high speed (7fps), this script fires the shutter 3 times.



Brian.
#4
I was afraid the answer would be something like that.  I don't see a fix in the next 4 weeks.  Maybe for the next eclipse.  :)

Thanks.



grnbrg.

PS:  Sent some BTC your way.
#5
Apologies if this is an obvious answer.  :)

I'd like to be able to toggle image quality in my script, going from RAW to Fine JPG and back again.  However, this functionality doesn't appear to be exposed in the API.

Is there something I am missing, or even an ugly hack that can be suggested?

Thanks!



grnbrg 
#6
Scripting Corner / Re: Lua Scripting (lua.mo)
July 11, 2017, 04:29:05 AM
Quote from: a1ex on July 02, 2017, 01:08:47 AM
Quote from: grnbrg on July 02, 2017, 12:30:01 AM

Essentially, (on the 5DmkII) once LiveView has been activated, trying to set a shutter speed faster than 1/4000th of a second crashes the script with a complaint that "camera.shutter.value" (or whichever shutter field) can't be set.  Odd.

Same does the 5D3 when running this script in Movie mode (Canon limitation).


I found a solution!  At least for my needs...  The shutter speed limitation is only imposed in movie mode.  This (on the 5DmkII, at least) is controlled by a menu option:



If I set this to "Stills only", I get the full range of shutter speeds back.  I suspect the reason I had no issues with the 70D is that body selects movie mode via a hardware switch.

Thanks for your time and work!



Brian.
#7
Scripting Corner / Re: Lua Scripting (lua.mo)
July 02, 2017, 12:30:01 AM



how to post pictures online for free
Isolated the crash I was having last week, related to LiveView and shutter speed.  Running this against todays (Jul01) lua_fix build.


-- 5DmkII LiveView crash test
-- 5DmkII + LV + fast shutter speeds causes a crash.

menu.close()
console.show()

print ("This will work.")

key.wait()

task.yield(1000) -- wait for the key to be released

camera.shutter.value = (1/8000)

print ("Shutter value: ", camera.shutter.value)

lv.start()

print ("This will work.  (Sort of.  It also starts a recording?)")

key.wait()

task.yield(1000)

camera.shutter.value=(1/4000)

print ("Shutter value: ", camera.shutter.value)

print ("This will crash.")

key.wait()

task.yield(1000)

camera.shutter.value = (1/8000)

print ("Shutter value: ", camera.shutter.value)

key.wait()

print("Done.")


Interestingly, this only crashes on my 5DmkII.  My 70D runs it flawlessly.

Essentially, (on the 5DmkII) once LiveView has been activated, trying to set a shutter speed faster than 1/4000th of a second crashes the script with a complaint that "camera.shutter.value" (or whichever shutter field) can't be set.  Odd.


(Brian) grnbrg.
#8
Quote from: a1ex on June 21, 2017, 01:16:37 AM
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.
#9
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:



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...


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.  :)