Faster Sync Triggering? - page 3 - General Help and Assistance on using CHDK stable releases - CHDK Forum supplierdeeply

Faster Sync Triggering?

  • 68 Replies
  • 20523 Views
Re: Faster Sync Triggering?
« Reply #20 on: 08 / February / 2015, 23:06:28 »
Advertisements
Thanks waterwingz and reyalp for the explanation of the variability.  That makes sense now.

@hokiespurs : I have your script setup so it works now with a sync'd shot rate of 1.75 seconds per shot (on my A1200  - an elcheapo Powershot) !  And no special builds or changes to CHDK were needed.

Awesome!! Thanks for the script.  I should have some free time tomorrow to give it a go, and will let you know how it does.

Re: Faster Sync Triggering?
« Reply #21 on: 09 / February / 2015, 00:30:50 »
Awesome!! Thanks for the script.  I should have some free time tomorrow to give it a go, and will let you know how it does.
Thanks - looking forward to hearing how it goes.

The script is a bit of a hack though using a somewhat undocumented "feature" of CHDK.   I posted a patch for the 1.4.0 version of CHDK that will make things cleaner based on your questions.  Only a one line change to the script required once the patch goes through so if it works for you now,  it should work for you (with that change) in the future.
Ported :   A1200    SD940   G10    Powershot N    G16

Re: Faster Sync Triggering?
« Reply #22 on: 09 / February / 2015, 19:17:29 »
It works nicely.
I'm looking at ~1.7 seconds per shot @ 1/500 and iso 100 with elph115is.

Thanks for the help!

Only a one line change to the script required once the patch goes through so if it works for you now,  it should work for you (with that change) in the future.

Great sounds good!

Re: Faster Sync Triggering?
« Reply #23 on: 10 / February / 2015, 16:29:36 »
I just began an edit of "usb_sync.lua" (attached) in order to investigate the quickest method of 2 frame capture - with the possibility of varying the exposure of the first frame using  "CloseMechaShutter".

Anyway, I was attempting to replace the script key presses with levents. These levents work fine in the normal chdkptp gui but not when used in the script.

I can't find much on the forum wrt this.

Should I be able to substitute the key presses / levents?

Testing is currently with a single cam connected to 7 port hub (per-port switch) and kbd.c usbremote/ptp hack in place.




my note: look at this again http://chdk.setepontos.com/index.php?topic=11078.msg111248#msg111248
« Last Edit: 10 / February / 2015, 17:16:31 by andrew.stephens.754365 »


*

Offline reyalp

  • ******
  • 13435
Re: Faster Sync Triggering?
« Reply #24 on: 10 / February / 2015, 17:33:53 »
I just began an edit of "usb_sync.lua" (attached) in order to investigate the quickest method of 2 frame capture - with the possibility of varying the exposure of the first frame using  "CloseMechaShutter".
I'm not clear why you are trying to do it this way, but it's almost certainly not a good idea. The mechanical shutter on these cameras is just used to block light while the sensor is being read out, and the timing you will get controlling it through script is going to be very uncertain. You can use the normal set_tv96_direct function to set the actual shutter time.

Quote
Anyway, I was attempting to replace the script key presses with levents. These levents work fine in the normal chdkptp gui but not when used in the script.
Again, I don't understand the point.

In general, there shouldn't be much difference, the chdkptp gui just sends script, so an levent from chdkptp is an levent from script. The only difference I can think is that some of the CHDK keyboard state is reset on each script invocation, and each chdkptp call is executed as a separate script. Off the top of my head, I don't think this would affect the behavior of levents unless you are also mixing in scripted key presses, but I haven't looked into it in detail.

from an earlier post
Quote
I've locally edited the kbd.c file to enable usbremote/ptp, is there a particular reason why you mention "usb_force_active" in my circumstances?
The reason usb_force_active is so people don't need custom builds of CHDK to do this kind of thing. You are free to use whatever custom hacks you want, but when we post our advice will tend to focus on what is available in the standard code.
Don't forget what the H stands for.

Re: Faster Sync Triggering?
« Reply #25 on: 10 / February / 2015, 18:27:00 »
I'm not clear why you are trying to do it this way, but it's almost certainly not a good idea. The mechanical shutter on these cameras is just used to block light while the sensor is being read out, and the timing you will get controlling it through script is going to be very uncertain. You can use the normal set_tv96_direct function to set the actual shutter time.

The general idea is, with controllable lighting (but different between the first capture and second) - how to minimize the capture time of 2 consecutive frames

i.e. http://chdk.setepontos.com/index.php?topic=11667.msg120122#msg120122


"The mechanical shutter on these cameras is just used to block light while the sensor is being read out" - if that means controllable Tv then good.

"the timing you will get controlling it through script is going to be very uncertain." - that's my biggest concern.

"You can use the normal set_tv96_direct function to set the actual shutter time." - on 2 consecutive frames on the same cam? (i'm actually trying to get away without overrides ;))

Thanks for your comment - i'll try and update more soon.
« Last Edit: 10 / February / 2015, 19:24:24 by andrew.stephens.754365 »

*

Offline reyalp

  • ******
  • 13435
Re: Faster Sync Triggering?
« Reply #26 on: 10 / February / 2015, 22:07:07 »
The general idea is, with controllable lighting (but different between the first capture and second) - how to minimize the capture time of 2 consecutive frames
Messing with the mecha shutter won't do this for you. The electronic exposure length (from the sensor being cleared to readout) is set in advance. If you manage to close the mecha shutter during the exposure, the camera will still do the same exposure, some fraction of it will just be blocked by the shutter.

Even if you could control the actual exposure, script timing is limited to ~10ms at best, which would be totally unsuitable for controlling exposure in normal lighting.

Quote
"You can use the normal set_tv96_direct function to set the actual shutter time." - on 2 consecutive frames on the same cam?
Yes, just set the shutter speed before each shot. You can use the raw shooting hook or the exposure counter to know when the first shot is finished.

Quote
(i'm actually trying to get away without overrides ;))
Again, I don't understand. Even if it could work, what do you gain by using CloseMechaShutter rather than normal overrides?

All of this seems very far from hokiespurs original question. I'd split it into a new thread but I don't even know what the subject is.
Don't forget what the H stands for.

Re: Faster Sync Triggering?
« Reply #27 on: 11 / February / 2015, 11:32:45 »
All of this seems very far from hokiespurs original question.
I don't think it's that different - the problem is more likely my lack of understanding/description.

My edit of the original query in post#1 would be:

"I was hoping someone would have some advice on increasing the rate at which I can acquire sync’d imagery from multiple cameras for a 360degree type of rig.  I want the cameras to be sync’d as accurately as possible so fast moving subjects are acquired at the same time a first frame can be captured in bright controlled LED lighting followed asap by a second frame in which the bright LED has been substantially moderated (the purpose of which is to enable a projected pattern to become "visible" on the subject)"

I'd split it into a new thread but I don't even know what the subject is.
I thought it may be useful to have both subjects in the same thread as they seem similar (to me). If it needs split then
Title = "Two sequential frames - Fastest Sync"? perhaps

Messing with the mecha shutter won't do this for you. The electronic exposure length (from the sensor being cleared to readout) is set in advance. If you manage to close the mecha shutter during the exposure, the camera will still do the same exposure, some fraction of it will just be blocked by the shutter.
It is:
  • limiting the length of time that light falls on the sensor in the first image that I am interested in controlling (compared to the second image)
  • minimizing the overall time between light starting to fall on the sensor of the first image and stopping to fall on the sensor of the second image
The mecha shutter seemed like a possible tool for part of the job. 

Even if you could control the actual exposure, script timing is limited to ~10ms at best, which would be totally unsuitable for controlling exposure in normal lighting.
That's that then !

Yes, just set the shutter speed before each shot. You can use the raw shooting hook or the exposure counter to know when the first shot is finished.
A wheel back on my wagon - thanks. I had this idea that when the shutter was half-pressed that av/tv/iso could not be adjusted  ::) - hence mecha shutter idea.

Again, I don't understand. Even if it could work, what do you gain by using CloseMechaShutter rather than normal overrides?
Until now I had been thinking to control the sx150is in a similar way to that which the 3d point cloud folk use their DSLR's. This has the benefit of being able to talk to them about their workflows when I get round to that & perhaps EXIF data says what it means.

Further, until now, I had only considered "noise projection" by dividing the camera set in half - one set for texture capture (zero noise projection) the other for geometry capture (with noise projection). 

Although a second between images will be of no benefit for moving subjects I wonder if mphx or rick could be interested to migrate from ptp triggering (having said that, I haven't yet investigated what could be possible with mutticam.lua http://chdk.setepontos.com/index.php?topic=11667.msg118929#msg118929

levent update:

This script [run using .loadfile('A/CHDK/SCRIPTS/usb_sync_levent.lua')()]

Code: [Select]
--[[
@title levent Sync
--]]
    post_levent_to_ui('PressSwOne')
repeat
        sleep(50)
    until get_shooting() == true

results in "attempt to call a nil value"

this, run from the chdkptp gui console
Code: [Select]
> luar post_levent_to_ui('PressSwOne')works fine


Edit:
for my memory http://chdk.setepontos.com/index.php?topic=8810.msg118533#msg118533

"...The resolution of all these questions & mysteries about accuracy of USB pulse width measurements turned out to be the difference between measuring in shooting mode vs measuring in playback mode.  I had done my detailed testing in playback mode and the jitter and variation in pulse width measurement proved to be minimal.   Once I finally realized that camera CPU loading goes through the roof in shooting mode,  it was clear that the CHDK hooked tasks do not reliably run at 10 mSec intervals in shooting mode - it is frequently much longer.  Which explained why the pulse width measurement accuracy on some cameras was so bad (in shooting mode).

And incidentally, it also explains why there is no hope of getting under 10 mSec sync without USB sync enabled, regardless of what the processors on Canon DSLR's are purported to do.
"


Edit2: http://chdk.setepontos.com/index.php?topic=9507.msg97370#msg97370
"The error
Quote

    Attempting to perform arithmetic on global 'f' (a nil value).

Is probably due to not having set the global variables the script expects from the script menu. The @ commands used to define the menu parameters are ignored unless you run the script form the menu, so all the a-z variables will be undefined.

To set them over chdkptp, you could do something like
Code: [Select]
lua f=1;loadfile(''A/CHDK/SCRIPTS/HDR.LUA")()
Edit3: http://chdk.setepontos.com/index.php?topic=11082.msg108531#msg108531
« Last Edit: 12 / February / 2015, 11:42:33 by andrew.stephens.754365 »


*

Offline reyalp

  • ******
  • 13435
Re: Faster Sync Triggering?
« Reply #28 on: 11 / February / 2015, 16:08:50 »
A wheel back on my wagon - thanks. I had this idea that when the shutter was half-pressed that av/tv/iso could not be adjusted  ::) - hence mecha shutter idea.
OK, that makes sense. There was a time when you don't do this using the normal set_* functions in half shoot, but this has been fixed for several releases of CHDK.

Quote
perhaps EXIF data says what it means.
We tell people not to use exif to verify if overrides work, because it can be wrong, but there is a good chance the exif will be correct with CHDK overrides if the values aren't far outside the normal Canon ranges. If there is something that doesn't get recorded correctly on your camera, let us know, it may be fixable.

Quote
results in "attempt to call a nil value"
That means you tried to call something as function that wasn't a function. I don't see any obvious errors in your script (but I haven't tried it and might have missed something), so I would guess the loadfile('A/CHDK/SCRIPTS/usb_sync_levent.lua') failed.

In general, you should check error status, like
Code: [Select]
f,err=loadfile('A/CHDK/SCRIPTS/usb_sync_levent.lua')
if not f then
 error(err)
end
f()

Note that some cameras have problems with long file names.
Don't forget what the H stands for.

Re: Faster Sync Triggering?
« Reply #29 on: 12 / February / 2015, 13:35:23 »
Thanks for the pointer - i've more reading to do.

Anyway, for the record, I saved this file to 'A/CHDK/SCRIPTS/LEVMAIN.LUA':
Code: [Select]
--[[
@title levent main
]]
  f=loadfile('A/CHDK/SCRIPTS/LEV.LUA')
  if not f then
    print("loadfile failed.")
  else
    f()
  end
this to 'A/CHDK/SCRIPTS/LEV.LUA':
Code: [Select]
--[[
@title levent halfpress
--]]
    post_levent_to_ui('PressSwOne')
repeat
        sleep(50)
    until get_shooting() == true

ran LEVMAIN.LUA using a shutter press and all worked fine.

using chdkptp I then ran

Code: [Select]
> .loadfile('A/CHDK/SCRIPTS/LEV.LUA')()

and all worked fine.

So, i'm not sure if the shorter filename made the difference or if I made a mistake in the first place...no retest of that planned though.

Other
I'm not aware of an levent for press("shoot_full") - it may be useful some time (so as not to mix).

 

Related Topics