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

chdkptp - alternative ptp client

  • 1106 Replies
  • 517278 Views
*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #470 on: 17 / December / 2013, 22:06:43 »
Advertisements
In a best case scenario I want a cycle time of 2 seconds for roughly parallel shots with two cameras. With roughly parallel I mean that the cameras can be up to 500 milisecs out of sync without any problem.
How are you controlling the cameras?

Quote
What I get in practice is a cycle time average a bit over 4 seconds. The test I calculated this average from included a few errors. With errors I mean when one of the cameras doesn't react to a shoot command because the camera hasn't finished its previous cycle yet. The errors appear because the cycle time of each camera appears to vary in practice so it is hard to know exactly when then next photo can be taken.
This seems like a problem with your specific control setup, not a general problem with shooting rate.

Quote
A manually shot sequence of photos in continous mode with a single camera (button held down) in the same conditions takes on average 1.9 seconds per shot when saving to the SD card in the camera.
In my testing, chdkptp remoteshoot in continuous mode was roughly equivalent to continuous mode to the card.

A single shot without continuous mode should be fairly similar to a single shot on the camera. If it's not, doing some timing results might be helpful.

I haven't tested multiple cameras doing remoteshoot in different instances of chdkptp. If you are running them in parallel, it's possibly there isn't enough USB throughput to transfer from both at full speed.
Don't forget what the H stands for.

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #471 on: 18 / December / 2013, 05:16:50 »
How are you controlling the cameras?
From the command line. I use two separate instances of chdkptp, one for each camera. I first start the cameras, set the zoom and lock focus. Then I run this command when space is pressed on the keyboard.
Code: [Select]
chdkptp -c"-p=#######" -e"rs 'C:\test\somefilename' -jpg"I then have another script monitor the output folder every 50 miliseconds for matching filenames. If the files are found a test is done to see if the files are corrupted because every now and then chdkptp saves a jpg file that is only partial. I check if the last byte of the jpg is correct. If the files are ok the shoot script will accept space key input to run again. After the file has been verified as successfully written to the harddrive the cameras are usually ready for another shot. But every now and then one of the cameras still fail to shoot in that situation. That is what makes me think there is some issue with the cycle time. Basically the camera now and then seem to, after the jpg from the previous shot is successfully saved, spend time doing something that blocks a new remote shoot command from having effect.

This seems like a problem with your specific control setup, not a general problem with shooting rate.
Do you see anything specific in my description of the setup above that might be the problem?

I haven't tested multiple cameras doing remoteshoot in different instances of chdkptp. If you are running them in parallel, it's possibly there isn't enough USB throughput to transfer from both at full speed.
Ok, I will test if there is a speed difference when using two different computers, one for each camera.
« Last Edit: 18 / December / 2013, 05:24:57 by tpont »

*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #472 on: 18 / December / 2013, 21:28:30 »
If the files are found a test is done to see if the files are corrupted because every now and then chdkptp saves a jpg file that is only partial.
That's the first I have heard of this, and it is not expected behavior. If you can find a way to reproduce it, I'd certainly like to hear it.
Quote
But every now and then one of the cameras still fail to shoot in that situation.
What specifically happens when when it fails to shoot?
Does chdkptp connect?
Does the rs command get issued?
Is there any output after the rs command is issued?
Does anything happen on the camera display?

If you put
-e"set cli_verbose=2"
in your chdkptp command, the remoteshoot process will produce more verbose output, which may help identify where it is failing.

you can use
set cli_time=true
to show how long the actual rs command takes.
Quote
That is what makes me think there is some issue with the cycle time. Basically the camera now and then seem to, after the jpg from the previous shot is successfully saved, spend time doing something that blocks a new remote shoot command from having effect.
After the jpeg is downloaded, it should be done. It is possible for shoot to fail. It's also possible you could be encountering this issue: http://chdk.setepontos.com/index.php?topic=11035.0

Try putting the cameras into alt mode before you start any shooting.

Quote
Do you see anything specific in my description of the setup above that might be the problem?
No. I will try to test with two cameras as you have described.
Don't forget what the H stands for.

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #473 on: 19 / December / 2013, 12:52:50 »
What specifically happens when when it fails to shoot?
Does chdkptp connect?
Does the rs command get issued?
Is there any output after the rs command is issued?
Does anything happen on the camera display?
I did some tests with the A2300. After a script has verified that the jpg is saved and after the text "BUSY" has disappeared from the camera gui and after the command line window has produced a prompt for new input there is still a period of time, at least a half second but sometimes longer, when a new shoot command produces this error message:
Code: [Select]
ERROR: no matching devices found
ERROR: not connected

When I deliberately wait a bit after the file is verified then the shoot goes through without error. Doing so I get on average 4 seconds per cycle in practical use with only the A2300 camera. I estimate that the speed of the A2300 in solo shooting is about the same as for the A2300 running in parallell with another camera. So I don't think the USB bandwidth is a slow down in dual camera use. But there could still be some other USB related issue when using the two cameras. The A490 is a second or so slower than the A2300.

Quote from: tpont
    If the files are found a test is done to see if the files are corrupted because every now and then chdkptp saves a jpg file that is only partial.
That's the first I have heard of this, and it is not expected behavior. If you can find a way to reproduce it, I'd certainly like to hear it.
It happens rarely so I haven't been able to pin down a cause yet.  And I haven't seen it happen with the two latest chdkptp version since I haven't used them much yet.
« Last Edit: 19 / December / 2013, 13:04:33 by tpont »


*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #474 on: 19 / December / 2013, 16:15:27 »
I did some tests with the A2300. After a script has verified that the jpg is saved and after the text "BUSY" has disappeared from the camera gui and after the command line window has produced a prompt for new input there is still a period of time, at least a half second but sometimes longer, when a new shoot command produces this error message:
Code: [Select]
ERROR: no matching devices found
ERROR: not connected
OK,  I expect this happens because the chdkptp code resets the camera USB on disconnect (on windows you can hear the device disconnect / reconnect sound when this happens). So after disconnecting there is a short period when the device is not available. This is something I inherited from the ptpcam code, so it's quite possible it isn't needed. It is on my list of things to look at some day.

That said if you are interested in speed, you would be much better off just starting chdkptp once and sending the remoteshoot commands to it's standard input. This will avoid the reset and connect/disconnect overhead.

Another option would be to add a retry count to the connect command. This should be fairly easy and useful in other situations, so I will probably do that.
Quote
It happens rarely so I haven't been able to pin down a cause yet.  And I haven't seen it happen with the two latest chdkptp version since I haven't used them much yet.
There was a bug in versions before r440 (snapshot 461) which would cause corrupt jpegs if the camera produced too many chunks. This did happen occasionally on my elph130.
Don't forget what the H stands for.

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #475 on: 19 / December / 2013, 17:19:50 »
Thank you very much for the helpful replies.

That said if you are interested in speed, you would be much better off just starting chdkptp once and sending the remoteshoot commands to it's standard input. This will avoid the reset and connect/disconnect overhead.
I have to admit I have never gotten the hang of how standard input/output commands work on windows. I tried to read up on it now here http://stackoverflow.com/questions/15994824/faking-standard-input-on-the-windows-command-line but I'm still uncertain how to translate that to the chdkptp case at hand. Could you post an example?

There was a bug in versions before r440 (snapshot 461) which would cause corrupt jpegs if the camera produced too many chunks. This did happen occasionally on my elph130.
That could very well be it. I will run some more tests with the latest version (r468) and see if I can reproduce the issue now. Hopefully not.

*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #476 on: 19 / December / 2013, 22:56:00 »
I have to admit I have never gotten the hang of how standard input/output commands work on windows. I tried to read up on it now here http://stackoverflow.com/questions/15994824/faking-standard-input-on-the-windows-command-line but I'm still uncertain how to translate that to the chdkptp case at hand. Could you post an example?
Not without more details. I assume
Quote
From the command line. I use two separate instances of chdkptp, one for each camera. I first start the cameras, set the zoom and lock focus. Then I run this command when space is pressed on the keyboard.
Code: [Select]
chdkptp -c"-p=#######" -e"rs 'C:\test\somefilename' -jpg"
means you are running chdkptp from some other program. How you would send input would depend on the program. If I remember right, you were using autohotkey before? I don't know anything specifically about it, but it seems like you should be able to start chdkptp once and send the rs 'C:\test\somefilename' -jpg as key presses if nothing else.
Don't forget what the H stands for.

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #477 on: 20 / December / 2013, 12:57:26 »
If I remember right, you were using autohotkey before? I don't know anything specifically about it, but it seems like you should be able to start chdkptp once and send the rs 'C:\test\somefilename' -jpg as key presses if nothing else.
Yes autohotkey. I ran a test where the commands are sent as textstrings to two cmd windows where chdkptp was in interactive mode. I don't notice any difference in speed. For the A490 the whole cycle from the rs command to a fresh interactive mode prompt still takes between 4.5 and 5 seconds (10 mpx, jpg, normal quality). The a2300 and a490 are roughly equal in speed when doing a shoot command that saves to the SD through interactive mode, it takes 2.5 to 3 seconds. It is in the file download step that the A490 is slower.

Is it possible that chdkptp will some day be able to download "in the background" and shoot at the same time? Or does the camera hardware make that impossible?


*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #478 on: 20 / December / 2013, 17:22:55 »
Yes autohotkey. I ran a test where the commands are sent as textstrings to two cmd windows where chdkptp was in interactive mode. I don't notice any difference in speed.
If you do it this way, you shouldn't get the "no devices found" error, or need to add delays to avoid it. The time to launch chdkptp, connect and disconnect is also non-zero. On my windows system,
Code: [Select]
$ time chdkptp -c
connected: Canon PowerShot D10, max packet size 512

real    0m0.280s

Quote
For the A490 the whole cycle from the rs command to a fresh interactive mode prompt still takes between 4.5 and 5 seconds (10 mpx, jpg, normal quality).
If you set cli_time=true you will get the actual time the rs command takes.

With some modification to the code, you could measure how much time is spent in various steps.
Quote
The a2300 and a490 are roughly equal in speed when doing a shoot command that saves to the SD through interactive mode, it takes 2.5 to 3 seconds. It is in the file download step that the A490 is slower.
Older cameras seem to have slower USB, so this is no surprise.

Quote
Is it possible that chdkptp will some day be able to download "in the background" and shoot at the same time? Or does the camera hardware make that impossible?
I don't camera hardware makes it impossible. With the current remote shoot code, the previous download must finish before the raw hook can continue for the next shot. This means download can overlap with the pre-shoot and exposure, but not the jpeg creation for the next shot. This already happens if you shoot in continuous mode. It might be possible to do the same in non-continuous mode, but I think it would require some changes to the camera script and chdkptp lua.
Don't forget what the H stands for.

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #479 on: 21 / December / 2013, 06:53:56 »
Code: [Select]
[quote author=reyalp link=topic=6231.msg108135#msg108135 date=1387578175]
If you do it this way [interactive mode], you shouldn't get the "no devices found" error, or need to add delays to avoid it. The time to launch chdkptp, connect and disconnect is also non-zero.
Ok. I will keep using the interactive mode script.

Older cameras seem to have slower USB, so this is no surprise.
Yes, this is likely the biggest factor. I'll look around for a replacement to the A490 camera. Do you, or anyone else reading, know if some newer models like the powershot A2500 (in CHDK alpha I read) has the filewrite feature, meaning it is possible that they in the future may support remote shoot?

Quote from: tpont
Is it possible that chdkptp will some day be able to download "in the background" and shoot at the same time? Or does the camera hardware make that impossible?
I don't camera hardware makes it impossible. With the current remote shoot code, the previous download must finish before the raw hook can continue for the next shot. This means download can overlap with the pre-shoot and exposure, but not the jpeg creation for the next shot. This already happens if you shoot in continuous mode. It might be possible to do the same in non-continuous mode, but I think it would require some changes to the camera script and chdkptp lua.
Ok. In continous remote shooting ( rs -cont=20 ) the A490 cycle is around 1.8 seconds per shoot which is very good.
« Last Edit: 21 / December / 2013, 06:55:30 by tpont »

 

Related Topics