sync'ing 3D video - page 2 - Creative Uses of CHDK - CHDK Forum  
« previous next »
Pages: 1 [2] 3 4 5 6 7 ... 11   Go Down

sync'ing 3D video

  • 103 Replies
  • 35412 Views
*

Offline ahull

  • *****
  • 634
Re: sync'ing 3D video
« Reply #10 on: 23 / June / 2013, 15:50:02 »
Advertisements
For what it is worth, in the case of the Ixus 60, the timing for image processing (i.e. the processing of the signal from the CCD) is handled by IC2002 - ( CDS A/D TG ) which is an Analog Devices AD9923BBCZ  this is according to the Device spec, a "CCD Signal Processor with V-Driver and Precision Timing™ Generator". Detailed schematics for the Ixus 60 and 65 exist, see http://chdk.setepontos.com/index.php?topic=7936.0

The S3 also uses the same signal processing chip, and as you can see from the diagrams, in every case, it feeds data directly in to the Digic II. To be precise it feeds data lines D2-D11 to the Digic II pins called CCDU [0-9] .
What the Digic II then does with that information is a bit of a mystery, but I suspect it simply copies it verbatim in to a RAM buffer, as the AD9923BBCZ has the ability to do things like attenuate and modify the input date (and thus alter colour palette etc) ( Think "My Colors" perhaps), and perhaps perform a number of other conversions on the data including cropping and altering the Window size from the CCD.

For video, it would most probably be the task of the Digic  to shift the data to the SD card, and I would imagine this is a task that the Arm core probably could cope with, given that the most obvious bottleneck is likely to be the SD card bus, rather than the processor. Compression however is a bit of a mystery, it *might* be done by the arm core, or more likely by dedicated hardware on the Digic die, for which we have no schematic.

The critical timing you are looking for, if you were using an Ixus 60 or similar,  would therefore depend on controlling the AD9923BBCZ, or at least getting a better understanding of how it is controlled. 

Whether other cameras follow the same design is debatable, but the basic idea will be similar.

I suspect that it should be possible to use the built in firmware routines on the two cameras to ensure that they stay in sync, by using some sort of once per frame handshake. The exact method I leave as an exercise for the reader.  ;)

EDIT: Updated link for AD9923BBZ
« Last Edit: 24 / June / 2013, 04:33:16 by ahull »
Logged
*

Offline Hardware_Hacker

  • ****
  • 322
Re: sync'ing 3D video
« Reply #11 on: 24 / June / 2013, 04:38:58 »
Hi All,

Re: CHDK-UNImote: Universal remote control for CHDK compatible cameras.

Reply #10 on: 30/October/2012,

---=== Sync-Mk1 ===---

So, have you given up on this, technical difficulties ?
 
Every "Sync" method will have, some, advantages and dis-advantages.

The IDEA! Sync-Mk2

---=== Sync-Mk2 ===---

The basic "Sync-Mk2" concept is simple and based on the BBC's Time pip's and the Talking Clock.
Just modify MetroNome-lua so that it is started by Canon's Time/Date clock at precisely 00x.000(s)
MetroNome-lua Mod-script will then Chime/Beep/Blink at some convenient rate on BOTH/ALL Cameras.
The Chime/Beep/Blink Interface, a Lm339 comparitor, and the Hardware is on a cheap RasberyPI, plugin, ProtoType PCB.

As the Interface Lm339 IC is a Quad device up to four cameras could be then be synced.
Alternativly Chime/Beep and/or Blink/Blink-Af could be done for twined cameras.

The Advance/Retard phase is measured against the master, high-speed "Clock" in the RasberyPi which then, continuously, calculates:-

The Advance/Retard phase period-#1 and the USB-Remote-Sync pulse for Camera #1.

The Advance/Retard phase period-#2 and the USB-Remote-Sync pulse for Camera #2.

The Advance/Retard phase period-#3 and the USB-Remote-Sync pulse for Camera #3.

The Advance/Retard phase period-#4 and the USB-Remote-Sync pulse for Camera #4.

Thus the USB-Remote-Sync pulse's are pre-calculated and just waiting for a a shoot command.

Other suitable Man in the Middle, Mips-based Controllers, running Basic or Pic32-Lua.

Develop, using Basic, the Sync-Prototype software on a Maximite:-

Here .... http://geoffg.net/maximite.html

In field use a Mini-Maximite:-

Here .... http://geoffg.net/mini-maximite.html


---=== Sync-Mk3 [etc.] ===---

"Sync-Mk3" Concept and More-To-Post's:-
Sync-Still's:- Camera Clock & "Set"/"Reset" sync concept.
Sync-Video's:-  Links to 3D Sync concept.
Sync-Continous:- Based on a modified Lapsers-Build & CHDK-script.
LibCeC Software:- Windows link, RasberyPi link
Canon HDMI-CeC:- Cec-Tx & Cec-Rx in Ixus 125 ROM Dump.
Canon CeC-Script?:- In Newer Canon ROM Dumps.
Canon Serial:- Discovery
HDMI-Hardware-Hack:- Link/Concept
Ext-Usb-Hardware-Hack:-  Link/Concept
Multi-Cam Unique Drivers:- Now working for Win-Xp, Vista, Win-7, Win-8.
Experimental Parts List:-
Google Home Work:-"Sync-Seperator" Patents [and Pic-TV Link]

Happy-Hacking By  H-H
« Last Edit: 24 / June / 2013, 05:03:59 by Hardware_Hacker »
Logged
*

Offline ahull

  • *****
  • 634
Re: sync'ing 3D video
« Reply #12 on: 24 / June / 2013, 16:24:28 »
I know this is completely off topic, but has anybody any clue what this string refers to?

SENSITIVEHARLEYDAVIDSONDEFECTPROG  :haha

I wonder if the "Harley Davidson" in question refers to an in house chip name, or part of the Digic.

I was looking through the Stings for clues about CCD timing (specifically strings related to camera adjustments, i.e. ending in ADJDATA) when I stumbled on it.

Attached is a list of all of the "Adjustables" from the A3000 (58 in total) A quick grep -r "HARLEY" shows that the same "Harley Davidson" reference appears in the A3100/A3150 and A3200 firmware strings too (and presumably others, but I didn't check), so I assume it is not an in house name for the A3000.

« Last Edit: 24 / June / 2013, 16:30:30 by ahull »
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: sync'ing 3D video
« Reply #13 on: 24 / June / 2013, 16:37:34 »
Quote from: ahull on 24 / June / 2013, 16:24:28
SENSITIVEHARLEYDAVIDSONDEFECTPROG  :haha

Maybe it is a 'jokey' way of referring to SHDDP.

Problem is, I have no idea what SHDDP would be !
Logged
*

Offline ahull

  • *****
  • 634
Re: sync'ing 3D video
« Reply #14 on: 24 / June / 2013, 16:50:04 »
Quote from: Microfunguy on 24 / June / 2013, 16:37:34
Quote from: ahull on 24 / June / 2013, 16:24:28
SENSITIVEHARLEYDAVIDSONDEFECTPROG  :haha

Maybe it is a 'jokey' way of referring to SHDDP.

Problem is, I have no idea what SHDDP would be !

DDP might be on the right lines, (http://en.wikipedia.org/wiki/DDP) trouble is it could also be a complete red herring, perhaps we need to drill in to the associated code, see if it plays with anything we already understand.
Logged
*

Offline ahull

  • *****
  • 634
Re: sync'ing 3D video
« Reply #15 on: 24 / June / 2013, 17:07:27 »
Looking for context, things get even more interesting..

A3200IS/a3200/sub/100d/PRIMARY.BIN.strings-ffc2a7c9 EVFDEFECTPROGADJDATA
A3200IS/a3200/sub/100d/PRIMARY.BIN.strings-ffc2a7de SENSITIVEROADKINGDEFECTPROGADJDATA
A3200IS/a3200/sub/100d/PRIMARY.BIN.strings:ffc2a801 SENSITIVEHARLEYDAVIDSONDEFECTPROGADJDATA
A3200IS/a3200/sub/100d/PRIMARY.BIN.strings-ffc2a82a SENSITIVEULTRAGHOSTQDEFECTPROGADJDATA
A3200IS/a3200/sub/100d/PRIMARY.BIN.strings-ffc2a850 FOCUSDEFECTPROGADJDATA

Looks like someone at Canon likes their motorbikes... "Road King" is another Harley ref.  and "Ultra G" has a touch of the Ultra Glide about it... I read that as UltraG Host Q Defect...


« Last Edit: 24 / June / 2013, 17:11:01 by ahull »
Logged
*

Offline waterwingz

  • ******
  • 12139
    • Waterwingz
Re: sync'ing 3D video
« Reply #16 on: 24 / June / 2013, 18:50:50 »
Quote from: Hardware_Hacker on 24 / June / 2013, 04:38:58
Hi All,
---=== Sync-Mk1 ===---
---=== Sync-Mk2 ===---
---=== Sync-Mk3 [etc.] ===---
Based on your descriptions, you do not seem to understand the  problem we are trying to solve here.   The problem is to have two cameras shooting in video mode,  but each video frame must be precisely sync'd between the cameras within 1 mSec at most.   So each video frame on one camera has an exact corresponding frame taken at exactly the same time on the other camera. 
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Hardware_Hacker

  • ****
  • 322
Re: sync'ing 3D video
« Reply #17 on: 25 / June / 2013, 05:26:45 »
Hi All,

---=== Sync-Mk2 ===---

Attempts ONLY to Pesudo-Genlock the Cameras System Clocks.

Only one step in a much more complicated process.


---=== Sync-Mk3 ===---


Attempts to sync/initalise the Cmos/Ccd sensors.

For still shots, a work in progress, and a later post.


For Videos Re:- "Sync-Video's:-  Links to 3D Sync concept."


The original Concept; "Genlock Canon 5D's & Shoot 3D"
 
http://3dfilmfactory.com/index.php?option=com_content&view=article&id=93:gen-lock-canon-5d-mark-ii-cameras-and-shoot-3d

This appears to work on some of My Canon P&S Cameras, but with a slightly Diffrent, and modified, method.

However it is not, as yet, fully tested, and a later post.

Happy-Hacking By  H-H

Every "Sync" method will have, some, advantages and dis-advantages.
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: sync'ing 3D video
« Reply #18 on: 25 / June / 2013, 06:26:30 »
Quote from: Hardware_Hacker on 25 / June / 2013, 05:26:45
The original Concept; "Genlock Canon 5D's & Shoot 3D"
 
http://3dfilmfactory.com/index.php?option=com_content&view=article&id=93:gen-lock-canon-5d-mark-ii-cameras-and-shoot-3d

Yes, I know this method.

It says  "The theory here is - that the act of taking a still photo while video is rolling "resets" the sensors and begins them scanning at the same pixel line."

I wonder why that is true, if it is ?

If that works, why are you investigating other methods ?

See line 79 here http://trac.assembla.com/chdk/browser/trunk/include/camera.h

I assume that does not necesarrily mean that you can capture a still image while actually video recording ?


David
« Last Edit: 25 / June / 2013, 07:13:48 by Microfunguy »
Logged
*

Offline ahull

  • *****
  • 634
Re: sync'ing 3D video
« Reply #19 on: 25 / June / 2013, 08:40:53 »
Quote from: Microfunguy on 25 / June / 2013, 06:26:30
Quote from: Hardware_Hacker on 25 / June / 2013, 05:26:45
The original Concept; "Genlock Canon 5D's & Shoot 3D"
 
http://3dfilmfactory.com/index.php?option=com_content&view=article&id=93:gen-lock-canon-5d-mark-ii-cameras-and-shoot-3d

Yes, I know this method.

It says  "The theory here is - that the act of taking a still photo while video is rolling "resets" the sensors and begins them scanning at the same pixel line."

I wonder why that is true, if it is ?

If that works, why are you investigating other methods ?

See line 79 here http://trac.assembla.com/chdk/browser/trunk/include/camera.h

I assume that does not necesarrily mean that you can capture a still image while actually video recording ?


David

If this works, then presumably it does so by restarting the ccd scan, but *without* changing the current CCD window.

We really need to break down the picture taking logic a little further to find out which routines are called when taking an image. Somewhere in the process it must start a CCD scan event, and at the start of that process it must write the relevant values to the CCD scanning chip. I suspect that picture taking and video work in a similar manner something like...

Take picture logic...

Setup image size. (Handled outwith the actual taking loop)

Take picture. Loops one or more times over....
Setup ccd scanner and let it run. Read data out of resulting buffer, compress(?!) and write to SSD. ( rinse and repeat... ;))


Take video

Set up image size.. (Handled outwith the actual taking loop)

Take pictures. Loop until stop pressed or SSD full over...
Setup CCD scanner, wait (framescan ms), grab image, compress(?!) and write to SSD. (repeat...)


The CCD scanner chip (whatever the AD9923 equivalent is for camera X) would in this case be responsible for the exact timing of the scanning of each frame, but the Digic would be responsible for grabbing them and adding to the current file on disk.

This may be an over simplification of the process, there *may* be interrupts and/or DMA involved here, but it may not be necessary to understand exactly how it works to achieve our goal. All we need to do is control the Start CCD scan event, by synchronising restarting the scan simultaneously at the same point in each frame flyback period. 



« Last Edit: 25 / June / 2013, 09:02:20 by ahull »
Logged
Pages: 1 [2] 3 4 5 6 7 ... 11   Go Up
« previous next »
 

Related Topics