GH1 Stereoscopic Rig Collaboration

Ah.... some potentially important information that I haven't shared yet:

1 - sync problem SEEMS to be independent of the firmware hack. We reverted back to stock and still had sync error.

2 - there MAY be a correlation between sync error and time between power-up and starting record. We're not doing a great job of multi-variant tracking yet, and this may be a real issue or it may be voodoo.

3 - sync problems seems to be independent of codec used, however, more testing is needed.

4 - we have started with a freshly formatted card in both cams and this does not seem to help (but, it is a good prophylactic measure until we eliminate all the variables)

5 - there may be some correlation between sync and the length of time that the cameras have been powered-off. Perhaps some residual capacitance is powering the clock for a period of time after the DC power is cut?? Needs more testing.

I'll start a list of variables to track and post for review.
 
tonpole said:
... I believe it took them a million dollars and a number of years to build that.
Click to expand...

But, they shot Ghosts of the Abyss with the prototype.

Seriously, I'm pretty sure that if Scarlet were shipping and gang-controllers were available for it, a GH1 rig would be less appealing. But, that aint where we are now, is it?

There are pros out there now trying to build and use 5D rigs (just saw one in a heli-mount). What else are they going to use?

- SI 2K rig is $70K and probably comparable quality to GH13,
- 2 REDs are more, HUGE and may have sync issues,
- EX3's are costly and not exactly early in their product cycle,

And most of the rigs out there do not offer well-integrated controls for focus, zoom, convergence, etc. The for-hire rigs from Pace, 3ality and others do... but you probably aren't gonna hire one of those rigs to shoot a 3D doc for Discovery 3D.
 
David Cole said:
It's a pleasure.

By the way, if we get sync working, Aquavideo has committed to building a very flexible GH1 rig. They are developing a mini mirrorbox that can fit into an underwater housing, on a shouldermount or on a steadycam mount. I'll ask Mike Hastings at AquaVideo to chime in and drop some details.
Click to expand...

Getting a red1 housing reconfigured for Birger control of canon ef lenses so a little busy for a few days, but I'm following the discussion.

Btw Birger already has stereo control of their canon ef mounts (which gives synchronized focus and iris) and these could be adapted (mechanically) to the micro4/3 fairly easy for full electronic control of canon ef lenses. I know that a four thirds controller is on their timeline as well, but no idea when.

The Birger mount is a hardware/software unit ($1295) that let's you use canon lenses on a variety of industrial, scientific and digital cinema cameras. Www.Birger.com

We have a Haas VF1 CNC machining center and I'll be working with Dave on the compact mirror rig - not just for underwater.
 
Last edited:
David Cole said:
1 - sync problem SEEMS to be independent of the firmware hack. We reverted back to stock and still had sync error.

2 - there MAY be a correlation between sync error and time between power-up and starting record. We're not doing a great job of multi-variant tracking yet, and this may be a real issue or it may be voodoo.

3 - sync problems seems to be independent of codec used, however, more testing is needed.

4 - we have started with a freshly formatted card in both cams and this does not seem to help (but, it is a good prophylactic measure until we eliminate all the variables)

5 - there may be some correlation between sync and the length of time that the cameras have been powered-off. Perhaps some residual capacitance is powering the clock for a period of time after the DC power is cut?? Needs more testing.

I'll start a list of variables to track and post for review.
Click to expand...

Just in case, can you also check synch when using "shoot" button (with oscilloscope)?
I suppose that synch for stills is much better than synch in video mode?
 
I propose to do the following.
Replace current switches with microcontroller and good relays.
After pressing buttton microcontroller with predeterminated delays will switch power for cameras, after it'll wait for x1 and x2 ticks and switch recording button via remote for both cameras.
Arduino (or any knockoff) is that you want.

Here is what you need:
1) Compensate for relay diffrencies to have prefect power on match.
2) Know best possible time to press record button. As you need to press it exactly before key polling interval.
3) Again, compensate for differencies.
4) Both cameras must be set to exactly same custom mode settings (so you don't need to check all each time).
5) SD Cards must be exactly the same, empty, with low level format (not simple format!) made each time. But, may be having core AVCHD folders can help make better synch.
 
Hey V, good to have your input,

After pressing buttton microcontroller with predeterminated delays will switch power for cameras, after it'll wait for x1 and x2 ticks and switch recording button via remote for both cameras.
Arduino (or any knockoff) is that you want.
Click to expand...
So you are suggesting recording immediately after power-up? That's rarely practical, exposure may have changed, focus might need adjusting, shot might need to be reframed etc.

David also found that the lenses cycle their focus on powerup, that would need to be avoided.

2) Know best possible time to press record button. As you need to press it exactly before key polling interval.
Click to expand...
There is a theory that the frame capture timer is initialised at boot-time, and then never changes. If true, it doesn't matter when you press record as capture will wait until the next frame interval. Is there any way you can confirm that?

5) SD Cards must be exactly the same, empty, with low level format (not simple format!) made each time. But, may be having core AVCHD folders can help make better synch.
Click to expand...
Again this is very impractical, you can't use low-level formatted cards for every take.


You could really help us track this down:

1) Do you know the order different camera components are initialised at boot time? This will help up isolate why David can only achieve good sync from synchronised powerups 70% of the time. Something in the boot up sequence seems to be causing an occasional delay.

2) Do you believe frame capture uses a global, running frame timer, or do you think this is (re)set every time the sensor is initialised, ie. for each take? If so, could the firmware provide a way to synchronize capture start precisely from a signal (eg. the remote signal, or something more accurate)?

3) If shutter-release polling frequency actually does affect timing, is there any way to increase the polling rate (or priority) in the firmware?
 
Last edited:
g.l said:
So you are suggesting recording immediately after power-up? That's rarely practical, exposure may have changed, focus might need adjusting, shot might need to be reframed etc.
Click to expand...

No, I suggest to start recording after specific interval after power up.

David also found that the lenses cycle their focus on powerup, that would need to be avoided.
Click to expand...

I really suggest to use manual lenses as it removes very significant random variables.

There is a theory that the frame capture timer is initialised at boot-time, and then never changes. If true, it doesn't matter when you press record as capture will wait until the next frame interval. Is there any way you can confirm that?
Click to expand...

I don't know about any "frame capture timer".
It don't work this way.
As I understand special LSI part work with RAW data.
Scaler transform this data to predefined debayered data.

Again this is very impractical, you can't use low-level formatted cards for every take.
Click to expand...

I don't see any big problem here.

1) Do you know the order different camera components are initialised at boot time? This will help up isolate why David can only achieve good sync from synchronised powerups 70% of the time. Something in the boot up sequence seems to be causing an occasional delay.
Click to expand...

Even having full source it'll require big amount of time to precisely answer this question. Plus you need many other documents.

2) Do you believe frame capture use a global, running frame timer, or do you think this is (re)set every time the sensor is initialised, ie. for each take? If so, could the firmware provide a way to synchronize capture start precisely from a signal (eg. the remote signal, or something more accurate)?
Click to expand...

I think that sensor is initialized after each mode change.

3) If shutter-release polling frequency actually does affect timing, is there any way to increase the polling rate in the firmware?
Click to expand...

I don't know. From my current POV, special thread check keys and copy it to special structure later used by other low level things. Understanding how this thread works from system POV requires complete OS and LSI documentation.


I suggest to try my suggestion first. As all it requires - cheap controller and few relays, plus tuning few numbers.
 
I don't know about any "frame capture timer". It don't work this way. As I understand special LSI part work with RAW data. Scaler transform this data to predefined debayered data.
Click to expand...
The question is, how is the start of the capturing timed? Is it started immediately when the code gets the start trigger, or does it have to wait for the next 'frame interval' (based on a global running timer)?

In the first scenario, there is no reason to powerup the cameras together, as the crucial thing is the capture trigger (and so polling frequency matters).

In the second, the start trigger doesn't matter, as the sync difference between frames only depends on the boot time of each camera (and then never changes, apart from minor drift).

Remember we are only interested in reducing the (up to) 1/2 frame delay. It doesn't matter if one camera starts 10 frames later than the other (this can be corrected in post), as long as individual frames start at precisely the same time.


I don't see any big problem here.
Click to expand...
For testing, no. For practical shooting, absolutely. You can't be out in the field and take 50 or more low level formatted cards with you ;).

Even having full source it'll require big amount of time to precisely answer this question. Plus you need many other documents.
Click to expand...
OK, but if you happen to find out anything, even partial information, please let us know.

I think that sensor is initialized after each mode change.
Click to expand...
OK, but again, what about the capture timing of the sensor?

I don't know. From my current POV, special thread check keys and copy it to special structure later used by other low level things. Understanding how this thread works from system POV requires complete OS and LSI documentation.
Click to expand...
Right. A dual shutter-release cable reportedly gives very good sync for stills, but not for video. So it does seem that video frame capture start is clocking off a global timer, which is started running at boot time.
 
g.l said:
Right. A dual shutter-release cable reportedly gives very good sync for stills, but not for video. So it does seem that video frame capture start is clocking off a global timer, which is started running at boot time.
Click to expand...

Good still sync is possible to understand if you try to think about involved operations.
First. All still shooting do before starting is checking few predefined things (like SD card present, SD size remaining, etc). After it sensor is switched, screen goes blank and actual shot occures (all other occures afterwards).
Video do not work this way. First, it makes or modifies multiple files (for AVCHD), and any time difference in SD operation translates in sync problems.
Next, it initialises many involved firmware parts (many times more compared to stills) and hardware parts (including audio, etc). Afterwards it set new sensor mode and actual shooting begins (including buffering and writing in separate thread from this buffer).
To make real 3D sync of two cameras you need to design their firmware with such ability in mind.
 
Vitaliy Kiselev said:
Video do not work this way. First, it makes or modifies multiple files (for AVCHD), and any time difference in SD operation translates in sync problems.
Next, it initialises many involved firmware parts (many times more compared to stills) and hardware parts (including audio, etc). Afterwards it set new sensor mode and actual shooting begins (including buffering and writing in separate thread from this buffer).
Click to expand...

That makes sense. So a firmware-hack solution could be to have the camera wait for a 2nd shutter release after all the setup is done. Does that seem feasible?

However, it still depends if the actual 1st frame capture is slaved off a global running timer or not. If yes, then the actual triggering really doesn't matter. We need to find this out.
 
Generally this is not proper area to do any hacks :)
All you'll get will be bricked body :)
Better write to Panasonic with request to open necessary information.
Or wait for proper cam to be released.
 
Vitaliy Kiselev said:
...I really suggest to use manual lenses as it removes very significant random variables.
Click to expand...

Has anyone had any luck with insulating the lens to body electrical contacts to make a lens effectively manual? Mechanical clearance seems pretty tight.

Also, any suggestions for a wide-angle prime (approx. 20mm effective) that can be fitted via adapter?

Thanks.
 
Vitaliy Kiselev said:
I ...Replace current switches with microcontroller and good relays.
Click to expand...

Roger Wilco. Looking for a good SSR part now.

As far as controller, we have an engineer who has dedicated some nights and weekends to the project who prefers PICBasic Pro and a plain-ol PIC. However, since this will hopefully be a shared effort and it certainly needs to be accessible to anyone who wants to build one, let's ask...

What microcontroller platform do you prefer? Chime in now.
 
Vitaliy Kiselev said:
Generally this is not proper area to do any hacks :) All you'll get will be bricked body :)
Better write to Panasonic with request to open necessary information.
Or wait for proper cam to be released.
Click to expand...

Realistically neither is going to happen. Panasonic would rather sell 3D lenses than a way to genlock two non-pro cameras. We need a hacked solution (software or hardware).
 
David Cole said:
Do we know this for sure? We've never tested stills here. Can add to test queue.
Click to expand...

Yes, a Japanese user (inoue_k3D, also posts on 3dtv) uses GH1s and found excellent stills sync from a dual cable.

What microcontroller platform do you prefer? Chime in now.
Click to expand...
I personally only have experience with AVR controllers. Cheap + free GCC-based dev environment (C-based, though I'm sure there are other languages available, 's been a while since I played with this stuff). You can even build a simple programmer from an LTP (printer) port, though there are cheap USB ones on Ebay too.
 
You must log in or register to reply here.
Back
Top