chdkptp - alternative ptp client - page 33 - General Discussion and Assistance - CHDK Forum  

chdkptp - alternative ptp client

  • 1106 Replies
  • 513091 Views
*

Offline reyalp

  • ******
  • 14079
Re: alternative ptp client
« Reply #320 on: 31 / March / 2013, 14:32:09 »
Advertisements
The script first sets up zoom and lock focus and then trigger shots on both cameras with this
Code: [Select]
chdkptp -c "-p=[cameraid]" -e"luar shoot()"then wait 3000 miliseconds, redo the shoot command, wait, and so on. If I decrease the wait time then one commands often fails and only one camera is triggered. I don't download the photos during the shoot cycles.
You can get an idea of the time required for each step using the
Code: [Select]
set cli_time=true
On my D10
Code: [Select]
___> c
time 0.0130
connected: Canon PowerShot D10, max packet size 512
con> rec
time 0.2720
con 1> shoot
time 4.0832
This shot was ISO 800, flash fired, scene was bad for AF
Code: [Select]
con 2> shoot
time 1.6731
con 3> =shoot()
time 1.8661
Above changed to ISO 80, disabled flash, better scene. =shoot() might wait a little more compared to cli shoot, but could just be normal variation.
Code: [Select]
con 1> shoot
time 2.6462
con 2> shoot
time 2.6111
con 3> shoot
time 1.8601
Some more shots, same settings as above, variation due to scene.
Code: [Select]
con 4> dis
time 0.2040
Note there is some overhead for connecting/disconnecting.

Quote
You 10 cycle DNG speed is similar to what I currently get for capturing JPG with two cameras simultaneously.
Try the time commands and see how long each shot takes.

Quote
Can you tell me more about the new remote shoot features? Can you shoot a number of cycles at around 2 seconds using that?
See the discussion in the PTP thread. This is still under development, allows you to save jpeg and / or DNG directly over USB without going to the SD card. The code is in  http://trac.assembla.com/chdk/browser/branches/ptp-remote-capture-test2

To use it, you also need to build chdkptp yourself with the ptp headers from that branch.
Quote
Both my cameras have DIGIC III. Do you know if DIGIC IV compact canon cameras in general would cycle faster? Or does that depend more on the individual camera?
A540 is Digic II, but only 6MP, D10 is Digic 4, 12 MP.

Speed should depend on
* camera hardware (processor, RAM speed etc)
* image size
* SD card
* shooting settings
* scene.

I don't know how your cameras will compare, but canon published specs should give you a relative measure. E.g. if official specs for a Digic 4 camera are 2x faster than your camera, it would probably be faster, even if you don't get the shot rate given in the specs.
Don't forget what the H stands for.

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #321 on: 31 / March / 2013, 16:54:01 »
Thanks, very helpful! Through
Code: [Select]
set cli_time=trueI see that my cameras have 3.2 seconds and 2.6 seconds respectively in average shoot time. So that is where the big time sink is.
Quote
if official specs for a Digic 4 camera are 2x faster than your camera, it would probably be faster, even if you don't get the shot rate given in the specs.
When I take shots directly on the camera (using the physical button) the cycles are faster. So the chdkptp/camera communication takes some time. I take it there is no difference in speed in chdkptp itself when connecting to DIGIC 4 rather than 3 cameras then?

*

Offline reyalp

  • ******
  • 14079
Re: alternative ptp client
« Reply #322 on: 31 / March / 2013, 20:04:16 »
So the chdkptp/camera communication takes some time.
Unless you are using a USB 1 interface, the actual communication time should be negligible. For example
Code: [Select]
con 4> =return 1
time 0.0590
5:return:1
You can check how long shoot takes on the camera with something like
Code: [Select]
con 6> =t0=get_tick_count();shoot();return get_tick_count()-t0
time 2.1501
7:return:2020
Here you can see the shot took 2.02 seconds, while the time for the full PTP round trip was 2.1501

What cameras are you using?
Don't forget what the H stands for.

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #323 on: 01 / April / 2013, 05:21:45 »
The slow camera is a powershot A800 and it gives times like these with focus locked through set_aflock
Quote
con 2> =t0=get_tick_count();shoot();return get_tick_count()-t0
time 2.4251
3:return:2170
On average 250ms spent on the communication. With USB2. I tested both through a usb hub connection and directly to the computer. I'll try to borrow a never camera with DIGIC 4 and compare speeds.


*

Offline reyalp

  • ******
  • 14079
Re: alternative ptp client
« Reply #324 on: 01 / April / 2013, 16:12:28 »
The slow camera is a powershot A800 and it gives times like these with focus locked through set_aflock
Have you checked whether there is actually a difference with / without aflock?
You can measure how much time is spent in pre-shoot vs shoot:
Code: [Select]
con 4> =t0=get_tick_count();press('shoot_half');repeat sleep(10) until get_shooting();t1=get_tick_count();click('shoot_full');repeat sleep(10) until not get_shooting(); t2=get_tick_count();return t1-t0,t2-t1
time 2.9792
5:return:700
5:return:1840
This is from my a540, pre-shoot took 700 ms, shoot took 1840, total time was 2979 (= ~400ms of overhead)
Quote
Quote
con 2> =t0=get_tick_count();shoot();return get_tick_count()-t0
time 2.4251
3:return:2170
On average 250ms spent on the communication. With USB2. I tested both through a usb hub connection and directly to the computer.
Given my results with digic II above, this may be normal. I'm a bit surprised by this, I knew chdkptp is not optimised to minimize USB transactions but that seems a bit excessive. A single =shoot() involves several round trips over usb and sends a non-trivial amount of support code. This could be streamlined a bit if you are willing to sacrifice some of the safety and convenience code.

What OS is the PC running?
Quote
I'll try to borrow a never camera with DIGIC 4 and compare speeds.
Can you try
Code: [Select]
con 12> !con:exec('return 1',{nodefaultlib=true,clobber=true,flushmsgs=false})
time 0.0750
con 13> getm
time 0.0220
13:return:1
on both cameras. Above is from a540, below is d10
Code: [Select]
con 2> !con:exec('return 1',{nodefaultlib=true,clobber=true,flushmsgs=false})
time 0.0260
con 3> getm
time 0.0060
3:return:1
Don't forget what the H stands for.

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #325 on: 03 / April / 2013, 16:02:33 »
Some representative measurements:
Code: [Select]
con> =t0=get_tick_count();press('shoot_half');repeat sleep(10) until get_shooting();t1=get_tick_count();click('shoot_full');repeat sleep(10) until not get_sho oting(); t2=get_tick_count();return t1-t0,t2-t1A800:
Code: [Select]
time 3.9282
2:return:1030
2:return:2780
A800 with luar set_aflock(1):
Code: [Select]
time 3.1782
4:return:260
4:return:2750
A800 with and without set_aflock(1):
Code: [Select]
con 3> !con:exec('return 1',{nodefaultlib=true,clobber=true,flushmsgs=false})
time 0.0310
con 4> getm
time 0.0080
4:return:1
I'm testing this on a Windows 7 computer.

*

Offline reyalp

  • ******
  • 14079
Re: alternative ptp client
« Reply #326 on: 03 / April / 2013, 16:40:30 »
Thanks. Some observations:
1) actual shooting time is ~3 seconds (including pre-shoot with aflock), so you won't go much below this no matter what. If you want to shoot significantly faster, you'll either need to find faster cameras settings, or use a faster camera.
2) USB speed (the return 1 test) may be a bit slower than digic 4, but significantly faster than digic II. This is what we would expect for Digic III, and upgrading to a faster camera isn't going to make a huge difference.
3) USB overhead for a shot is ~100-200ms. You could reduce this a bit with customized shoot code, but it's probably not worth it.

Regarding #1
* Base ISO (100) may be faster than higher settings, since there may be less time spent on noise reduction.
* If the camera does lens distortion correction at certain zoom levels, it may be faster if you use one that doesn't.
* If you don't need full resolution, the "low light" or "blur reduction" scene modes should be substantially faster. You can use CHDK to override the ISO back to a low value.
* Other reduced resolution modes might be faster, but on some cameras they are slower than full res.
* If you are using a slow card, a fast one might help. A supposedly fast, name brand card could be counterfeit.
* edit: experimenting with other shooting settings might be productive too, the above are just off the top of my head.
« Last Edit: 03 / April / 2013, 16:43:03 by reyalp »
Don't forget what the H stands for.

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #327 on: 03 / April / 2013, 17:55:50 »
I do want full res. I was at ISO100. I tested other values (using "shoot -sv=80") but didn't see a substantial decrease in total speed.

But changing compression from "fine" to "normal" did bring total time down from ~3.100 to ~2.700. I have to check more how that affects image quality but so far it looks worth it.

How well  lit the target is also affects the total time a lot. With bright enough light I get ~1.700 which is fast enough for me.

I'll test the combination of better lighting and normal compression some more before I get any new cameras. Thank you again, your feedback is very helpful!
« Last Edit: 03 / April / 2013, 17:57:22 by tpont »


*

Offline reyalp

  • ******
  • 14079
Re: alternative ptp client
« Reply #328 on: 04 / April / 2013, 01:18:33 »
I do want full res. I was at ISO100. I tested other values (using "shoot -sv=80") but didn't see a substantial decrease in total speed.
Yes, I would expect high values (400, 800 or more) to potentially be slower. According to the Canon specs, I think 100 is as low as your camera goes. -sv works in "real" ISO which is not equal to the ISO value the Canon firmware displays.

Quote
But changing compression from "fine" to "normal" did bring total time down from ~3.100 to ~2.700.
That's good to know.

Quote
With bright enough light I get ~1.700 which is fast enough for me.
What sort of exposure times are you getting? It would be good to know if  the change just due to less actual exposure time (e.g going from 1 sec to 0.5 sec), or something else in the shooting process. AF can be slow in low light, but one would expect AF lock to prevent that from being a factor.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14079
Re: alternative ptp client
« Reply #329 on: 07 / April / 2013, 01:38:08 »
I've uploaded a snapshot build of r330 to the files area https://www.assembla.com/spaces/chdkptp/documents

The main change is sx50 palette support.
Don't forget what the H stands for.

 

Related Topics