Building a Photogrammetry scanner. Namielus needs help

[Likay]

I once built a canon stereocamera (still have it). The delayadjustment is not necessary if you use the same kind of cameras. I had a cd-disc spinning at 28000 rpm and took a stereoshot of it (with dual flash). There's no difference in discangle (nor doubled image) between the left and right eyeviews. This was by using sdm which uses the chdk for canons.

[geekmaster]

I once built a canon stereocamera (still have it). The delayadjustment is not necessary if you use the same kind of cameras. I had a cd-disc spinning at 28000 rpm and took a stereoshot of it (with dual flash). There's no difference in discangle (nor doubled image) between the left and right eyeviews. This was by using sdm which uses the chdk for canons.

Or it is possible that the disc angle is a multiple of 360-degrees. But probably unlikely.

CHDK provides a per-camera adjustable delay just in case you need it. Doing it with an external controller board means that any per-camera adjustments would require that you always connect the same cameras to the same connectors. Incorrect delays could be worse than no delays at all.

[Likay]

I took several pictures and also with different rpm's just in case. The disc was a cd or dvd spidered to a minidrill. The cameras are Ixus 970IS.
The camera before was two Olympus cameras with electrically hardwired triggers. That configuration, however, didn't syncronize too well though.
Anyway: Going the canonroute will probably save you any softwaresetup or timingmeasurements. There's only one issue that may occur when using chdk software: The camera crashes sometimes. With a lot of cameras that may be an issue.

[geekmaster]

... There's only one issue that may occur when using chdk software: The camera crashes sometimes. With a lot of cameras that may be an issue.

I have been using Magic Lantern firmware for years, with no issues at all (Canon EOS-550D). I just upgraded to the newer version with CHDK folded into it, so I will see how well it behaves. Different camera models may have different issues, or none at all.

[Likay]

Very true. It doesn't happen too often but when it does i have to remove the battery in order to make it reboot properly. An upgrade may help since both the chdk as well as sdm are old versions. I used the w3 ever since i got it because it's easier to handle and more discreet. The con is that the canons looks quite a deal better than the w3 though.

[Namielus]

I have all 7 triggerboards working now each with an arduino nano.



I got all the cables and just received 40 memory cards yesterday.
So tomorrow we are going to try to wire them all up and see.

[Likay]

Good luck!

[geekmaster]

CHDK controls shutter half press and full press on one or many cameras, using only shared power wires in USB cables, to an accuracy of a fraction of a millisend. As shown above, you just need a battery and switch, or with a computer even greater control. These guys are toggling the USB power wires to send morse code to scripts running in the cameras, to control all sorts of internal functions:
http://arch.ced.berkeley.edu/kap/discus ... via-usb/p1

The hardware approach looks like a nice technical exercise, but if that ends up with too many technical difficulties, you may want to try the software-only approach, as a fallback position.

And yes, I hope whatever way you choose to go works out well for you. It is nice to have alternative options though. Good luck!

[cybereality]

Awesome!

[Namielus]

Okay simple question; do you honestly think CHKD usb triggering is superior to the remote socket release, or just simpler to set up the system?
The reason I ask is that during testing, I set off 4 cameras using the remote socket release, and I know for sure the output had a delay of just a few microseconds.
Despite this, and despite the fact that the cameras had just been in half-press mode and ready to trigger with heightened "alertness" -
The difference from camera to camera was in the millisecond range. This was also inconsistent meaning each camera in the chain did not have the same latency.
There's only one way to fix that unless CHKD is actually much faster than the remote socket release is to set the cameras to a bulb function and fire off a couple of flashes
while the cameras are still exposing. Sync at the speed of light.

Would really like to hear your thoughts about CHKD vs remote socket release.

[geekmaster]

Okay simple question; do you honestly think CHKD usb triggering is superior to the remote socket release, or just simpler to set up the system?
The reason I ask is that during testing, I set off 4 cameras using the remote socket release, and I know for sure the output had a delay of just a few microseconds.
Despite this, and despite the fact that the cameras had just been in half-press mode and ready to trigger with heightened "alertness" -
The difference from camera to camera was in the millisecond range. This was also inconsistent meaning each camera in the chain did not have the same latency.
There's only one way to fix that unless CHKD is actually much faster than the remote socket release is to set the cameras to a bulb function and fire off a couple of flashes
while the cameras are still exposing. Sync at the speed of light.

Would really like to hear your thoughts about CHKD vs remote socket release.

I have no experience with this issue other than what I read. The timing resolution in the CHDK firmware was claimed to need 10 mSec minimum pulse width (on or off time), which is the fastest that USB can be polled without losing events, but the camera shutter release delay is programmed in 100 uSec intervals.

So it is really not clear what the minimum timing is for the shutter full-press event other than the limit set in CHDK. This needs more investigation.

[Namielus]

I guess its down to the internal workings of the camera. My triggersystem is also in the microsecond range, yet differences was noticable when photographing a stopwatch (only tried with 3 cams due to lack of 2.5mm jacks at the time)
The question is If the CHKD firmware has some sort of shortcut to the actual trigger taking place compared to the remote release socket if we assume both get the signal at the same exact time.
I assume the 10microsecond delay is from when the signal is sent from the usb controller to the firmware?

[geekmaster]

I guess its down to the internal workings of the camera. My triggersystem is also in the microsecond range, yet differences was noticable when photographing a stopwatch (only tried with 3 cams due to lack of 2.5mm jacks at the time)
The question is If the CHKD firmware has some sort of shortcut to the actual trigger taking place compared to the remote release socket if we assume both get the signal at the same exact time.
I assume the 10microsecond delay is from when the signal is sent from the usb controller to the firmware?

I reworded that. See my previous post. I am extremely tired and my memory is drifting, and too tired to go look up the facts right now. Need sleep. TTYL.

The cameras run firmware, which supports multiple threads, and which may have an event loop that limits how fast it can read trigger events (meant to be human operated). If polled (not likely), subject to event loop periodicity. If interrupt driven (probably), subject to variable latency issues. I do not know enough about it. I just downloaded the Magic Lantern firmware and have barely begun to browse the firmware source code. I do know it is multi-threaded, which means it may very well have non-deterministic context switching delays, unless it is a deterministic RTOS.

Far too many unknowns until I study it more (when I have time). And too tired to think or write clearly...

I actually WANT to mod the Magic Lantern firmware (which supports live fisheye dewarp) to support Rift head tracker data for looking around inside a live fisheye view. I have a fisheye lens, which is just what the Rift needs for viewing through the center, but for looking around, need to de-fisheye first. I hope I can get USB HID support working (someday) but no time to add yet another project to my plate...

[Likay]

I can agree with everything geekmaster said above. I have practical experience where remote triggering by hardwiring the triggerbutton (halfpressed and fullpressed) do not sync well. The difference in timing is enough to ruin a stereophoto (somebody walking was enough). The timing was not consistent (sometimes the left camera was first, sometimes the right). This phenomena occured with relatively cheap olympus cameras (and as GM says above the timing will probably vary widely between different cameras).
With the Canons (ixus970is) loaded with the chdk software and stereodatamaker the sync was good enough to show no differencies when taking pictures of a disc spinning at 28000rpm (1 360 revolution~2miliseconds). Let's say that i couldn't see a difference within a 5° range of a total revolution, then the timing would have a better accuracy than ~30microseconds.
I haven't tried to hardwire the triggers on the canons so i can't tell how this method works with those.

[geekmaster]

I have practical experience where remote triggering by hardwiring the triggerbutton (halfpressed and fullpressed) do not sync well. ... With the Canons (ixus970is) loaded with the chdk software and stereodatamaker the sync was good enough to show no differencies when taking pictures of a disc spinning at 28000rpm (1 360 revolution~2miliseconds). Let's say that i couldn't see a difference within a 5° range of a total revolution, then the timing would have a better accuracy than ~30microseconds.
I haven't tried to hardwire the triggers on the canons so i can't tell how this method works with those.

It is possible that the firmware assigns higher priority and finer-grain (more precise) control over USB events, than to human finger-controlled shutter switch presses (either local or remote).

In the case of USB power loss (which triggers full press), the USB circuitry may actually be powered by USB, and a lost of power may cause a non-maskable interrupt (the highest prioirity event of all which preempts EVERYTHING, so that it can do whatever shutdown processing is needed while there is still sufficient energy stored in the filter capacitors.

So it makes sense that no matter WHAT the camera is busy doing, a USB "power loss" even may be the absolute fastest and lowest (and deterministic) latency event that the camera can do, perhaps vastly better than events designed for human finger activation.

Those statements are from a logical point of view, based on how I would design a camera and firmware personally. The actual camera may operate differently from that, but in my experience most (but certainly not all) firmware designers know what they are doing and WHY they are doing it, leading to the same conclusions. Only the lazy designers who do not study enough to learn all the alternative methods they can fine, and to evaluate and compare them, choose a poor solution for their design. But even so, there is a LOT of room for improvement in firmware. In the olden days, I learned to write useful programs on computers that only had 256-BYTES of memory for both program and data, when super-optimization of the BEST memory-saving algorithm was the ONLY way!

... I set off 4 cameras using the remote socket release, and I know for sure the output had a delay of just a few microseconds. ... The difference from camera to camera was in the millisecond range. This was also inconsistent meaning each camera in the chain did not have the same latency. ... Sync at the speed of light.

Would really like to hear your thoughts about CHKD vs remote socket release.

It is possible (but by no means proven) that the CHDK firmware and a simply USB power "hydra" (many headed) cable may actually be for more suited to your needs than you fancy "finger press emulation" hardware.

Now, it is good that you mentioned your "sync at the speed of light" comment, because that triggered a memory for me. I had my Magic Lantern firmware set to use the infrared sensor just under the optical viewfinder on my Canon EOS 550D, where waving a had past it would snap a photo. This allowed the camera to settle with no human contact, for rock solid stability for very long exposures, because no contact was needed to snap a photo. Exactly WHY this may be a good thing for you is that the IR sensor is a different input channel, subject to different firmware delays and latency, and might actually be faster than USB or shutter-switch inputs (both local and remote). It is always important to evaluate and compare all the alternatives before choosing the best solution for your design, so the more input methods for triggering full press shutter release the better, in my book at least. You learn these things with experience, and I have a lot of that...

[t0pquark]

Finally, an area where I might be able to give some meaningful input Even though photographers tend to be somewhat gear obsessed, they aren't all very technical individuals, and so the solutions you're are looking at would be beyond 99.9% of them. However, that doesn't mean photographers haven't found ways to do what you are tring to do, in a more practical fashion.

Since this is for taking pictures in a completely controlled environment, I don't see any reason this wouldn't work, but it'll be an easy test.

• Continue to use the multitap board to trigger the shutters.
  Setup the cameras to see nothing but black when they fire. (kill the ambient light in the exposure)
  Get a cheap hotshoe flash and radio trigger set from eBay (maybe $80 or less combined, unless you know someone with them)
  Put one radio trigger on one of the cameras and then one on the flash.
  Set the shutter speed on your cameras to the max xsync ( which on a Canon should be 1/200)
  When you trigger the cameras, and the flash goes off, that will be the only thing lighting the exposure, which depending on the flash setting would effectively be between a 1000th and a 20,000th of a second.
  Therefore, all cameras will have the same moment captured.

The individual microseconds of the shutters don't really matter in this case, as they can be open however long you can control the ambient light in the environment for. If you've ever seen a photo of a bullet frozen in time passing through an object (that wasn't from a high speed video camera) this is how it was done. This also means that you will be removing any motion blur when taking pictures of people doing almost any action. I photograph a lot of dancers and catch split leaps and no-hand cartwheels easily. It also means you don't have to subject your model to 1000s of watts of continuous lighting.

[Namielus]

tOpquark, thanks for the input!
Even lighting is also very important so I might get two studio flashes with diffuse box that can be triggered by the same circuit (they also have 2.5mm jacks)

[t0pquark]

Yeah, the "one flash" was just so you could see for yourself if it would work for you. In a studio setup, I would put a large flat white rectangle (two pieces of white foamcore stacked vertically would work) between each of your camera "trees". You would then bounce a flash off of each of these flats. WAY cheaper then softboxes and would be 360 of soft, even light. Also, the reason I suggested using hotshot flash instead of studio strobes is that internally they function differently. Studio strobes are setup to always give the same length of light pulse, so you wouldn't be able to be get quite the same level of freezing effect.

One other thing: whatever you end up going with for lighting, consider placing collor charts in the scene that can be seen by every camera. When you run the pictures through post, this will help make sure that everything lines up color temperature wise. Nothing worse then having to try and do it all by eyeball

[geekmaster]

Excellent "outside the box" solution. If you cannot control the camera shutters to the temporal resolution you need, then control the light source! Awesome suggestion!

And thanks for the color chart suggestion. There are too many panorama videos and photos that vary in color between cameras.

More fine tools to add to the toolbox of ideas...

[Namielus]

Tested out the camera rig today, just with cameras sitting on the desk.

It seems the delay is less than 1 millisecond. Do any of you have a good real world example of what happens in less than 1 millisecond?
Lets assume its 0.8 or something like that..

If you can try to give me a real world example of how much we move in 1 millisecond ranging from normal breathing to shaking your head or sneezing
I could get an idea of how well they would perform as they are even without flash sync.

[JDuncan]

If you can try to give me a real world example of how much we move in 1 millisecond ranging from normal breathing to shaking your head or sneezing
I could get an idea of how well they would perform as they are even without flash sync.

[youtube-hd][/youtube-HD]http://www.youtube.com/watch?v=vOvQCPLkPt4[youtube-HD][/youtube-hd]

http://www.youtube.com/watch?v=vOvQCPLkPt4

[geekmaster]

Tested out the camera rig today, just with cameras sitting on the desk.

It seems the delay is less than 1 millisecond. Do any of you have a good real world example of what happens in less than 1 millisecond?
Lets assume its 0.8 or something like that..

If you can try to give me a real world example of how much we move in 1 millisecond ranging from normal breathing to shaking your head or sneezing
I could get an idea of how well they would perform as they are even without flash sync.

Considering that 0.8 mSec is equivalent to the time difference between sequential video frames recorded at high speed 1250 FPS framerate, the amount of motion is what you see when single-stepping between frames. That is about 1/20th of the time period between sequential 60 FPS framerate, so something needs to be moving pretty fast to see the difference between sequential frames.

More than 10x the speed of 120Hz video. Another way to look at it is to compare to the speed of a bullet. Ammo for .22 calibre pistols has a velocity of about 1,000 feet/sec (more or less, depending on bullet and load). Calculating that out shows it would travel 9.6-inches in 0.8 mSec.

Mythbusters showed that sneezes travel less than 40 miles/hour (despite the 100 MPH myth):
http://dsc.discovery.com/tv-shows/mythb ... 00-mph.htm
40 MPH is about 690 inches/sec, or about 1/2-inch per 0.8 mSec.

But do you really need to digitize sneeze mist in flight?

[Likay]

I don't know how much 0.8ms difference practically can do. Anyway it's easy to test. Rig them as a stereocamera and take some stereophotos of different scenes and objects. Then view the shots using a decent lowghosting stereosetup (or x-eyed). That should be a good indication.
I know by experience that timeshifting one frame in a stereomovie effectively ruins an entire movie so even small times like 0.8ms may have some effect. Therefore i also guess that even a small miss in syncronization will give the digitizing software a very hard time. For a practical view: If the object is not moving too much during the take, then 0.8ms should be absolutely neglectable.

[geekmaster]

Here's a rough estimate. I can make four 180-degree movements of my head in about one second. That works out to about 720-degrees of total movement over the course of one second. Divide that number by 60 and you end up with 12-degrees per 1/60th of a second.

While my testing method was hardly precise, I think the resulting number ought to be pretty close. I already felt like I was going to hurt myself (or at least get dizzy) turning my head back-and-forth rapidly like that, so I have trouble believing people are going to be able to turn their heads much faster than that. ...

Even if your photogrammetry subject rotates her head quickly, it will not change all that much in 0.8 mSec. 720-deg/sec is about 1/2-degree of head rotation per 0.8 mSec, but that is hard work to achieve. Normal movements should be a lot slower than that.

You could just ask them to hold still and say "cheese", just as if you were only using a single camera.

[BOLL]

As said the high speed flash trigger method will work nicely with pretty much any setup, just with different amounts of hassle. With some effort you can have ambient lighting that is turned off before the cameras open their shutters. I saw this article when it was posted, but have not done anything like it as of yet

[geekmaster]

As said the high speed flash trigger method will work nicely with pretty much any setup, just with different amounts of hassle. With some effort you can have ambient lighting that is turned off before the cameras open their shutters. I saw this article when it was posted, but have not done anything like it as of yet

Excellent article. Here is a quick quote from it:

High Speed Photography is not about high shutter speeds. Au contraire. It is about shooting very long exposures in bulb mode, and using a strobe to freeze the action with a split second light.

There are some excellent reader comments following that short article too, one of which recommended free Photoduino software to control various camera processes (including this) with an arduino.

Here is the embedded video from that article:
http://www.youtube.com/watch?v=R8_dAgaBBdI

The key is that they are using a quick computer-controlled light strobe to sync the camera(s) and eliminate motion blur. Even if the cameras have variable shutter latency, a long shutter time where they all overlap will allow the flash to synchronize their captured images.

Other sites also say that precise camera timing is all about controlling the lighting (including flash "ambient" lighting), and not about the cameras.

Thanks BOLL, for bringing this to our attention!

[Namielus]

I was a fool. The stop watch only displays in hundreds of a second.
The thing that confused my mind is the fact that, at least around here its common to mistakenly read out the last digits as milliseconds.
So if all cameras recorded the image to 10:53 it will take 10 milliseconds to reach 10:54 am I right?
That means the maximum delay is 10 milliseconds not 1.

[geekmaster]

No matter how accurately you control the shutters, they are subject to variable mechanical latency from lubrication viscosity differences, temperature, and age and wear. Even though yours were purchased together, they might wear differently due to variations in the metal used in the shutter vanes. And of course, they are controlled by the camera firmware which probably has its own periodicity and/or variable latency.

I really do think that having one arduino shut off room lighting just before opening all shutters, then open all the shutters, then after a "variability debounce" period flash all the strobes (direct and ambient lighting), then close the shutters, then activate static room lighting again. This could all happen so fast you may not notice the momentary loss of static room lighting (or at least it would be no more annoying than all the simultaneous flashes).

Obviously, with synchronized lighting (how other people do precise camera shots), you can use as many cameras as you want, and even the USB "hydra" cable (power wires only) should work quite well, and can be controlled by the same Arduino that controls the room and flash lighting. Only one Arduino with three output pins needed (room lighting, camera shutters, strobe lighting).

[Infinite]

Just an FYI. You cannot synchronize the cameras mechanically. You have to flash the sensors. As I posted before to the Agisoft forums, it's great resource to save you the time trying to figure this out.

You're also restricted to exposure speed with certain Cameras when using more than 1. I don't have experience with Canon 1100D's but the 550D's are shockingly bad, they vary a huge amount from camera to camera. 600D's are better but even then you can't really go past 1/10th without getting black images on some cameras not syncing with the flash light. Nikon D800's (are incredible) or even the cheaper D3200's are super quick. I've synced 24x D3200's at 1/200th speed using a 1/10,000th speed flash. I've synced 8x D800's reliably at 1/250th speed taking 6x multiple shots per camera in under 4 seconds.

Don't forget you also have the MLU feature (custom function 8)

[Namielus]

Infinite, your insight is very valuable but I just cant afford that amount of d800's at the moment.
I am just hoping to achieve any result that can show the potential well enough to get some people interested.

I will just have to set a longer exposure and rely on the flashes. Even just standing still for tests.
The sync delay is less than 10 milliseconds, which is still much better than moving around a person with one cam.

I want to do a test tomorrow, but I need to know what would be the most feasible.
How many layers/towers of cameras, and what to focus on. face only, the entire head, head + torso,
or the entire body

[Infinite]

Infinite, your insight is very valuable but I just cant afford that amount of d800's at the moment.
I am just hoping to achieve any result that can show the potential well enough to get some people interested.

I will just have to set a longer exposure and rely on the flashes. Even just standing still for tests.
The sync delay is less than 10 milliseconds, which is still much better than moving around a person with one cam.

I want to do a test tomorrow, but I need to know what would be the most feasible.
How many layers/towers of cameras, and what to focus on. face only, the entire head, head + torso,
or the entire body

That was why I posted, for insight. As it's quite rare for anyone to have that many D800's or D3200's to test with in sync, the results are useful for people to analyze and learn from.

From further testing on the D3200's they really aren't that great actually at high speeds, I've also found with Nikon's the image output (when subjects are globally illuminated) is allot softer than compared to Canon.

Your Canon should do the trick nicely.

The best thing you can do is experiment, experiment! try every position possible. Stereo pairs, towers of 3 or 4. Knowledge is key from your own testing and experience