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')()]
--[[
@title levent Sync
--]]
post_levent_to_ui('PressSwOne')
repeat
sleep(50)
until get_shooting() == trueresults in "attempt to call a nil value"
this, run from the chdkptp gui console
> 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
lua f=1;loadfile(''A/CHDK/SCRIPTS/HDR.LUA")()
Edit3:
http://chdk.setepontos.com/index.php?topic=11082.msg108531#msg108531
