testing sync among more cameras - page 9 - General Discussion and Assistance - CHDK Forum

testing sync among more cameras

  • 121 Replies
  • 67703 Views
Re: testing sync among more cameras
« Reply #80 on: 07 / December / 2012, 15:35:23 »
Advertisements
It has been found that some cameras introduced in 2011 and later have very poor synch and were not recommended for stereo or multi-camera shooting.
(for some reason, the A810 has very good synch).

The SX230hs and S100 are two such cameras.
The S100 has a CMOS sensor and DIGIC V processor.

The median synch value is 8 msec, or 1/125 sec.
50% of shots will be as good or better than that and 50% will be worse.
Quite ordinary shots like flowing water or flocks of pigeons in flight will show very obvious synch errors.

I have now added the precision-synch code to the S100.

Following synch tests  I can report median synch is now 0.5 msec, a 16x improvement.

The period-counter address used is 0c0f070c8 .


Re: testing sync among more cameras
« Reply #81 on: 08 / December / 2012, 07:11:24 »
I have now added the precision-synch code to the S100.

this is very interesting. I have the sx130is and have experimented the same delay values (about 8ms).
Do you think I could test your patch/fix on the sx130is? (as it would be very important for me)

thanks

Re: testing sync among more cameras
« Reply #82 on: 08 / December / 2012, 08:52:21 »
You certainly can and maybe we can find-out why SDM flash synch was not working.

Contact me with a suitable email address and the firmware version(s) of your cameras.


David

Re: testing sync among more cameras
« Reply #83 on: 22 / December / 2012, 05:44:21 »
It has been found that some cameras introduced in 2011 and later have very poor synch and were not recommended for stereo or multi-camera shooting.
(for some reason, the A810 has very good synch).

The SX230hs and S100 are two such cameras.
The S100 has a CMOS sensor and DIGIC V processor.

The median synch value is 8 msec, or 1/125 sec.
50% of shots will be as good or better than that and 50% will be worse.

Bad synch can be partially attributed to the fact that they both have CMOS sensors. If testers had them reversed (one camera upside-down), then you always get bad synch results in lower or upper parts of the picture. I would never use CMOS cameras in reversed orientation except if rolling shutter would be insanely fast (which probably isn't). I suppose that repeated test (with highly improved results) was certainly taken with parallely oriented cameras. Am I mistaken and both cameras use global shutter?!?

Re: testing sync among more cameras
« Reply #84 on: 12 / August / 2013, 20:08:09 »
This topic has continued to be interesting to the people with multi-camera bullet time rigs  (and those who wish to do stereo photography with CHDK).

In order to get this into the 1.3.0 trunk,  the patch needs to be generalized so that it can be activated on cameras that have been tested,   and so that it can be easily enabled for testing on cameras where the feature is requested.

To that end,  I've attached a patch file that shows how this might be done.   It assumes that

Code: [Select]
#define USB_PRECISION_SYNC 1is added to the platform_camera.h of any cameras where the feature is tested (or is to be tested).

There are four "register" values that need to be defined.  I stuck them in the usb_remote.c code for this example but they belong in either platform_camera.h or perhaps stubs_min.S or stubs_entry_2.S.   Obvious if they get added to the sigfinder they go in stubs_entry.S

Code: [Select]
// s90 values
#define USB_SYNC_REGISTER_1 0xC0F06000
#define USB_SYNC_REGISTER_2 0xC0F06014
#define USB_SYNC_REGISTER_3 0xC0F07008
#define USB_SYNC_PERIOD      0x00386014
Finding the first three of these seems to depend only on having a digicIV or digicV camera but its not clear that is always true.    The last one is apparently found by looking inside the EngDrvOut function.


I suppose I could have posted this in the 1.3.0 planning thread, but it seem to make more sense to put it here.


Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline srsa_4c

  • ******
  • 4451
Re: testing sync among more cameras
« Reply #85 on: 13 / August / 2013, 15:26:34 »
#define USB_SYNC_PERIOD      0x00386014
You don't need this if you use EngDrvRead on USB_SYNC_REGISTER_2. EngDrvRead is available on all cameras, and is found by the sigfinder (only for DryOS ATM). It will need a wrapper though.

Re: testing sync among more cameras
« Reply #86 on: 13 / August / 2013, 15:36:54 »
#define USB_SYNC_PERIOD      0x00386014
You don't need this if you use EngDrvRead on USB_SYNC_REGISTER_2. EngDrvRead is available on all cameras, and is found by the sigfinder (only for DryOS ATM). It will need a wrapper though.
Thanks!

I'm guessing that this patch will be almost exclusively for DryOS DigicIV & DigicV cameras released in the last couple of year.  That's when the older sync method started to get bad.  Also,  people building multicamera "bullet time" rigs are not likely to be able source 30 to 50 old cameras - so interest in implementing this patch will be mostly for currently available cameras.

Have I missed something obvious here?
Ported :   A1200    SD940   G10    Powershot N    G16

Re: testing sync among more cameras
« Reply #87 on: 13 / August / 2013, 15:37:38 »
Quote
#define USB_SYNC_REGISTER_3 0xC0F07008

Strangely, I am not convinced that applies to all DIGIC III and IV cameras.

For example, the A590, A800, IXUS105 and IXUS980.

Re: testing sync among more cameras
« Reply #88 on: 13 / August / 2013, 15:52:23 »
Quote
#define USB_SYNC_REGISTER_3 0xC0F07008

Strangely, I am not convinced that applies to all DIGIC III and IV cameras.

For example, the A590, A800, IXUS105 and IXUS980.
I am certainly open to any configuration information you have for tested cameras.
Ported :   A1200    SD940   G10    Powershot N    G16

Re: testing sync among more cameras
« Reply #89 on: 13 / August / 2013, 16:02:37 »
What I mean is that that code similar to this (in gui.c for example)

Code: [Select]
int* counter= (int*)0xC0F07008;
 sprintf(osd_buf,"Current count : %4d",*(counter) & 0xffff);
 draw_string(70,40,osd_buf,MAKE_COLOR(COLOR_BLUE,COLOR_WHITE));

displays a restricted range of values .
In addition, the maximum value of those does not correspond to the standard period.

Difficult to believe they would change the DIGIC location for current count.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal