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

chdkptp - alternative ptp client

  • 1106 Replies
  • 517671 Views
*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #240 on: 16 / September / 2012, 13:47:08 »
Advertisements
I run chdkptp from an autohotkey script ( http://www.autohotkey.com ).

Sorry for my confused question but I have no experience with stdin/stdout (had to google what it was) but from what I can tell I can do stdout from autohotkey with this command:
http://www.autohotkey.com/docs/commands/FileAppend.htm

I don't understand how to get chdkptp to read that sent command, especially if I want to send commands to two cameras. Do I need to first load chdkptp and connect the cameras using some special command?

The reason I so far have used a script that reconnects to each camera for every command is that I couldn't find any other reliable way to get the two cameras to repeatedly shooting roughly at the same time. I set the script to wait until all chdkptp processes have closed which means that the shoot commands start at the same time for each new iteration. The A800 camera I have is a bit slower than the older A490 camera.
« Last Edit: 16 / September / 2012, 13:48:59 by tpont »

*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #241 on: 16 / September / 2012, 15:37:14 »
I run chdkptp from an autohotkey script ( http://www.autohotkey.com ).
OK, that clarifies things a bit, I assumed you had actually written program in some other language to run chdkptp.

Based on http://www.autohotkey.com/docs/Tutorial.htm#Send it looks you should be able to send keystrokes to a running copy of chdkptp, something like
Send =shoot()

From http://www.autohotkey.com/docs/Tutorial.htm#Activate you should be able to switch between windows.

So instead of starting chdkptp each time, you could
1) start two copies of chdkptp in interactive mode, with their respective connect strings but no shoot
C:\chdkptp-r291-win32\chdkptp -i -c"-p=____"
C:\chdkptp-r291-win32-copy\chdkptp -i -c"-p= _ _ _"
2) When you want to shoot, switch to each window and send "=shoot()". It looks like you should be able identify each window by it's path

---
Alternative way, using the multicam module. This uses one copy of chdkptp to control both cameras, and shots should be very close together. I've attached two cli command files. To use them, put the files in the same directory as chdkptp. The lines that start with # are comments.
Start chdkptp with
Code: [Select]
chdkptp -i -rmcinit.chdkptp
This makes chdkptp run all the commands in mcinit.chdkptp at startup.
The commands in the file
1) load the multicam module
2) connect to all cameras that are connected to your pc
3) start the multicam script all cameras
4) Initialize the time synchronization system
5) switch the cameras to shooting mode.

To shoot
Code: [Select]
source mcshoot.chdkptp
This will press half shoot, wait for the cameras to focus etc, and then send the shoot command.

when you are done, you should send
Code: [Select]
!mc:cmdwait('exit')
to end the multicam script on the cameras. If you disconnect without doing this (and don't restart the cameras), the next time you connect you'll get errors because the script is already. You will also need to use 'exit' if you want to download files with mdownload.

The whole mc module isn't really finished, but maybe you will find it useful.
Don't forget what the H stands for.

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #242 on: 16 / September / 2012, 16:34:16 »
Thanks! I tested out the multicam scripts. They work all right but the speed is about the same as in my previous autohotkey scripting method. 10 doubleshots took 59 seconds. My script method is actually a little faster but I think that's only because I have a step that locks the camera focus before starting the shooting loop. With that added to multicam the speed would be the same I suspect.

I'll test the other scripting method you mentioned later (send commands as textstring to open cmd windows). But if it ends up having roughly the same speed then do you think there is any other way to get a speed up? I've checked the CHDK settings and I've already tried tweaking shutter time and so on. But the largest time chunk for each cycle is spent on saving the image to the sdcard and perhaps getting ready for a new shot. You mentioned  work in progress on downloading directly over PTP. Would that, when done, speed up looped shooting of this kind? Or have I perhaps simply hit a hardware limit and have to look for faster cameras?

edit: the cameras can handle much faster shooting manually in continuous mode (one shot takes less than two seconds) so the camera hardware can clearly work faster. But there might still be some hardware limit to how fast it can be controlled from a PC.
« Last Edit: 16 / September / 2012, 16:45:53 by tpont »

*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #243 on: 16 / September / 2012, 16:50:04 »
Thanks! I tested out the multicam scripts. They work all right but the speed is about the same as in my previous autohotkey scripting method. 10 doubleshots took 59 seconds. My script method is actually a little faster but I think that's only because I have a step that locks the camera focus before starting the shooting loop. With that added to multicam the speed would be the same I suspect.
Probably. Multicam is optimized for making the cameras shoot as close as possible to the same instant, not minimum cycle time. You could adjust it, but I wouldn't expect big gains.
Quote
Would that, when done, speed up looped shooting of this kind? Or have I perhaps simply hit a hardware limit and have to look for faster cameras?
Not sure, probably depends on the relative speed of USB and SD. If you are doing shoot/save/download for each shot, then it would be quicker, but it sounds like you are taking a bunch of shots and then downloading, so a good SD card could be quicker than USB.

Connecting / disconnecting does have some overhead, so it should be possible to do a little better than invoking chdkptp for each shot.

In the canon firmware, the fastest way to shoot is using the continuous mode and holding the shutter down (which you could do from script) but using different cameras I expect they will drift apart pretty quickly. Making a "synchronized continuous mode" that shoots at the rate of the slowest camera might be possible, but it would probably take some hacking and add some overhead.
Don't forget what the H stands for.


*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #244 on: 14 / October / 2012, 08:20:31 »
In the canon firmware, the fastest way to shoot is using the continuous mode and holding the shutter down (which you could do from script) but using different cameras I expect they will drift apart pretty quickly. Making a "synchronized continuous mode" that shoots at the rate of the slowest camera might be possible, but it would probably take some hacking and add some overhead.

Is there presently some way to script the camera to go into continuous hardware mode but then inject some delay time between the shots? Maybe the drift can be avoided or greatly decreased by using two cameras of the same model and version and the same model of sd card.

*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #245 on: 14 / October / 2012, 15:20:32 »
Is there presently some way to script the camera to go into continuous hardware mode but then inject some delay time between the shots?
I don't think you could do this with stock chdk, but it should be theoretically possible. You can block the shooting process in the raw hook, but I'm not sure what you'd use to synchronize.
Don't forget what the H stands for.

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #246 on: 14 / October / 2012, 17:29:34 »
I was thinking that by using the same cameras and sd cards the sync drift would perhaps be small enough for two connected cameras to take perhaps 20 shot cycles (with a time delay between each) sufficiently in sync. If that saves at least 1 second per cycle compared to what I have now (6 second cycles) then I could add some sync step once every 20 cycles. Perhaps command the cameras to exit continuous mode, wait until both cameras have waited at least a second, and then enter continuous mode in sync and run the next 20 cycles. Even if the intermittent sync step would take as much as 10 seconds the new process would still save time all in all.
« Last Edit: 14 / October / 2012, 17:45:27 by tpont »

*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #247 on: 14 / October / 2012, 18:43:48 »
I was thinking that by using the same cameras and sd cards the sync drift would perhaps be small enough for two connected cameras to take perhaps 20 shot cycles (with a time delay between each) sufficiently in sync.
Sure, if you have two identical cameras, try it out. I don't have identical cameras, and I don't know what your sync requirements are. I would expect identical cameras and cards to behave quite well, although SD cards can be somewhat unpredictable due to underlying wear leveling, gc etc.
Quote
If that saves at least 1 second per cycle compared to what I have now (6 second cycles) then I could add some sync step once every 20 cycles.
6 second cycles seems quite excessive, are you shooting raw ? On my a540, using an old slow SD card
=shoot()
takes about 1.5 sec complete with jpeg. and DNG takes 3.5 sec. Shooting 10 DNG shots in a row with
Code: [Select]
=for i=1,10 do shoot() sleep(10) end
takes 35 sec.
All of the above is with AF and AE enabled.

Using the new remote shoot stuff, a jpeg (including download) takes 1.3 sec.
Don't forget what the H stands for.


*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #248 on: 14 / October / 2012, 22:50:32 »
I tried to reproduce the problems with long/odd filenames from http://chdk.setepontos.com/index.php?topic=4338.msg91363#msg91363 and http://chdk.setepontos.com/index.php?topic=8600.msg90093#msg90093 without success.

Some file names would fail on upload, but directly creating them on the card didn't cause listing to file. If someone knows a way to make a file that causes ls to silently fail, I'd like to fix it so it at least returns an error message.
Don't forget what the H stands for.

*

Offline dvip

  • ****
  • 451
Re: alternative ptp client
« Reply #249 on: 14 / October / 2012, 23:03:57 »
I can get chdkptp-r291-win32 to read/delete files from my A590IS-101b
but I can't the "Live" tab to display the live image. It seems to work only in "Play" mode.

I'm using branches_tsvstar-uitest-2215.zip.

Do I need something else to make it work?


 

Related Topics