chdkptp - alternative ptp client

reyalp

msl
I have played a little bit around the GUI. It's my first try to design some icons for IUP.Lua. All icons were converted with the program iupview.

Nice work. My only comment on the buttons is I'm not sure the half shoot and shoot are very clear. If they had a tooltip, that could solve it.

- added function for shoot+download with selection of a destination (user request from German forum)

I don't know if you saw, but yesterday I added some download options to the the 'shoot' cli command http://trac.assembla.com/chdkptp/changeset/347/trunk Not finished yet, still need to allow specifying the destination directory and name(s). It's a little complicated because there might be more than one file.

For the gui, I'd like to have a "shoot options" somewhere, which would have controls like
raw [dropdown <none>,dng,chdk]
download [] jpeg [] raw
delete [] jpeg [] raw
[folder button] [c:\selected\path...]
tv [....] av [...] sv [...]
This could go in a non-modal popup window maybe. Most of the actual work could be done with the shoot cli command.

msl

reyalp
My only comment on the buttons is I'm not sure the half shoot and shoot are very clear.

You're right. But I had no better idea: a green rectangle (focus ready) for 'half shoot' & a stylized shutter for 'shoot'. A tooltip is a good idea.

reyalp
I don't know if you saw, but yesterday I added some download options to the the 'shoot' cli command

Yes, I saw it. But the 'shoot&download' function was already finished. Your suggestion is good.

Maybe we need an additional tab for user defined functions. I have read about a HDR GUI function in any post, don't remember where. Also a kind of .ini file would be interesting.

msl

reyalp

msl
Also a kind of .ini file would be interesting.

Yes, some way to save settings would be good. This is on my todo list... but as you can see my progress is slow. My original intention for the "prefs" is that they could be saved and loaded.

If you want to load customization at startup, you can use the "rc file" functionality.

.chdkptprc is run when you start the cli, .chdkptpguirc is used for the gui. On windows, _ is used instead of a . because windows explorer doesn't let you name files .foo

You can run any chdkptp commands there, so you could load your own lua addons with

!require'mymodule'

in your startup file

For additions to the gui, this might be tricky because the rc file is run before the main gui is fully created. Possibly the gui startup should have a hook of some kind to call user functions.

frojnd

Hi reyalp,

I think a few posts are missing...

I was trying to put my camera into record mode with LUA script but I had no luck. It works if I run script from camera but if I try to run it with chdkptp nothing happens and it's stuck. If I try anything afterwards I get: ERROR: a script is already running. The only thing I'm left with is to press on power button on camera to shut it down and start it again.

if (get_mode()==false) then
    sleep(1000)
    set_record(1)
    while (get_mode()==false) do
        sleep(100)
    end
    sleep(1000)
end

shoot()

This code works if I run it directly on a camera, but in chdkptp it won't. Any ideas how to put camera into record mode when running script on chdkptp?

reyalp

frojnd
Hi reyalp,

I think a few posts are missing...

It does look that way 😐:

I was trying to put my camera into record mode with LUA script but I had no luck.

You need to use switch_mode_usb() rather than set_record (this is a historical artifact, different calls are needed when the camera is connected via ptp, but really chdk should detect do the right thing). You can look at the source of the rec and play cli commands for examples:
http://trac.assembla.com/chdkptp/browser/trunk/lua/cli.lua#L1402

The code inside the call to con:execwait is what is sent to the camera.

If you are going to do something immediately after switching, you should wait until the switch completes, as in the code you posted. It's a good idea to not call switch_mode_usb() if you are already in the desired mode.

http://chdk.wikia.com/wiki/Lua/PTP_Scripting describes a lot of the ptp specific issues.

frojnd

Thank you reyalp 😀

Time to rewrite a few lines 😀 Much appreciated!

ant_thomas

I'm currently have an inconsistent problem with downloading photos from my camera using chdkptp and the mdl command.

My setup is basically this a Raspberry Pi + Canon Ixus 110 IS (SD960IS) + stepper motor.

The motor turns the camera and a photo is taken at each position (usually at least 13), then all the photos should be downloaded then sent to another system to do the panorama stitching.

Sometimes all the photos download absolutely fine off the camera but other times there's some errors after around about 10 photos. I get this...

unexpected return code 0x2ff
ERROR: download failed
unexpected return code 0x2ff
ERROR: ptp error
ERROR: Could not close session!

Sometimes it seems to stall at about 10 photos but then manages to carry on and complete the download without error.

I've tried adding the -batchsize=n option in case that made a difference (using either 1 or 10 for n) but it doesn't seem to make any difference. What does "batchsize" refer to anyway? What is one batch?

I've never had any SD card issues with my Raspberry Pi even though it is only a Class 2 2GB card, but could the card speed be an issue here?

Currently using CHDK version 2904 and chdkptp r330.

reyalp

ant_thomas
[code]unexpected return code 0x2ff
ERROR: download failed
[/code]

This is just a generic error that means the connection is gone or not working, so it doesn't really tell us much. Is the camera crashed when this happens?

If the camera is crashed, try to get a romlog: http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29

If it isn't crashed, try to describe what state the camera is in: can you reconnect chdkptp, can you interact with it using the physical buttons etc.

Is the shoot and download automated by some process? Having the download too close to the shoot can cause crashes. This will produce a distinct romlog.

I've tried adding the -batchsize=n option in case that made a difference (using either 1 or 10 for n) but it doesn't seem to make any difference. What does "batchsize" refer to anyway? What is one batch?

batchsize controls how the directory listing information is sent. This is used to limit the amount of memory used on the camera. It should not be an issue if there are only a few files on the card. -dbgmem should print some memory info, but it appears to be broken in the current svn.

edit:
I fixed the dbgmem option in changeset 377.

ant_thomas

When the error occurs I am able to reconnect with chdkptp right away and issue commands.

The camera doesn't crash and still responds to button presses that are available whilst plugged in via USB, Menu, Power.

I already have a 2 second delay in to allow any commands to finish, as well as that I've tried closing the connection after taking the photos then opening a new session to download them. This doesn't improve things.

For the time being I could add a few lines to my script to check how many photos have been downloaded and if it's not the right amount to try again until I get them all.

reyalp

ant_thomas
When the error occurs I am able to reconnect with chdkptp right away and issue commands.

OK, that doesn't sound like any of the problems I had in mind.

This could happen if some other program grabbed the USB connection. You could try looking in the kernal log (dmesg output) to see of something particular happens at the times you lose connection.

It could also be the USB connection being flaky I guess. Do you have any other USB devices plugged into the pi? Are you using a powered hub? The camera itself should be fine on USB, but other devices that expect to get a significant amount of power can cause problems if you aren't using a powered hub.

I already have a 2 second delay in to allow any commands to finish, as well as that I've tried closing the connection after taking the photos then opening a new session to download them. This doesn't improve things.

Yeah, if the camera doesn't crash, it's not the timing thing.

For the time being I could add a few lines to my script to check how many photos have been downloaded and if it's not the right amount to try again until I get them all.

You could also use chdkptp side lua or modify the mdownload cli command to reconnect if there is an error.

When you get the error, do you get an incomplete file?

ant_thomas

reyalp
OK, that doesn't sound like any of the problems I had in mind.

This could happen if some other program grabbed the USB connection. You could try looking in the kernal log (dmesg output) to see of something particular happens at the times you lose connection.

It could also be the USB connection being flaky I guess. Do you have any other USB devices plugged into the pi? Are you using a powered hub? The camera itself should be fine on USB, but other devices that expect to get a significant amount of power can cause problems if you aren't using a powered hub.

Thanks for the replies.

As it happens I've changed the USB hub since I last posted and I think the issue has gone. I've tried to replicate the issue with the new USB hub but all downloads seem to have been successful and without error so it looks like it could well be a Pi USB problem with the other hub (which wouldn't really be a surprise considering the known Pi USB issues).

If the issue occurs again I'll get whatever logs I can, but it's looking like an RPi USB issue rather than chdkptp problem.

reyalp

If you build your own chdkptp, it's very important that Lua be linked to exactly the same C runtime library as chdkptp itself. The lbuf file routines expect to be able to fread and fwrite on a FILE * opened by lua io.open()

This condition probably won't be met if you use a pre-compiled Lua dll on windows. I think it's probably OK with a shared lua in typical linux environments, but I could be wrong. If in doubt, build your own Lua with the same compiler you build chdkptp with.

You can use
!require'tests':runall()
to test some aspects of your chdkptp build. It should crash or fail if the runtimes aren't compatible.

reyalp

I've uploaded snapshot build r384 to the chdkptp files area:
https://www.assembla.com/spaces/chdkptp/documents

This includes remote capture support for the current trunk. This is available using the 'rs' command. Use
help rs
for details.

There are still some loose ends:
1) Exposure controls are not integrated in the rs command. rs should probably be integrated into the regular shoot command, or at least given equivalent options.
2) If you use rs without any options on a camera that does not have filewrite support, you will get an error "'unsupported format" because it defaults to jpeg, but jpeg is not supported. -raw or -dng should still work. In this case, the jpeg will be saved on the camera.
3) DNG does not currently create a thumbnail or patch badpixels
4) rs ~~(and shoot)~~ don't wait for the flash to be ready, so shooting is likely to fail if flash is enabled

The new protocol commands can also be accessed directly in lua using the chdk_connection api (documented in chdkptp.c). There are also helpers in chdku (documented in chdku.lua) to make it more convenient.

edit:
corrected above, the "shoot" cli command already used shoot()

reyalp

I switched the chdkptp 'rs' command to use shoot instead of a get_shooting() loop. This should avoid the timeouts when the flash isn't ready.

This only applies to single shot mode, continuous still uses a get_shooting() loop.

I haven't made an updated build yet, these are lua only changes, so you can just grab cli.lua and rlibs.lua from svn.

tpont

Hi reyalp. I'm testing chdkptp-r384-win32 on a A2300 camera using the latest trunk version of CHDK (a2300-100f-1.2.0-2954-full_ALPHA.zip ). I can't get remoteshoot (rs) past "usb capture not supported". I've tried rs , rs -raw , rs C:\test -raw and so on but always get the same error message (see previous sentence). Any ideas on what could be amiss here?

reyalp

tpont
Hi reyalp. I'm testing chdkptp-r384-win32 on a A2300 camera using the latest trunk version of CHDK (a2300-100f-1.2.0-2954-full_ALPHA.zip ). I can't get remoteshoot (rs) past "usb capture not supported". I've tried rs , rs -raw , rs C:\test -raw and so on but always get the same error message (see previous sentence). Any ideas on what could be amiss here?

Are you sure you have the right diskboot and modules on your camera?

"usb capture not supported" should only appear if the lua module doesn't have the "init_usb_capture" function.

What is the output of
vers -p
in chdkptp?

tpont

I get "unknown command 'vers' ".
If I run "version" in interactive command line mode I get: "host:2.5 cam:2.4"

msl

Use 'ver' instead of 'vers'. See also: http://trac.assembla.com/chdkptp/browser/trunk/USAGE.TXT#L187

msl

reyalp

tpont
I get "unknown command 'vers' ".

Oops, sorry about, it should have be 'ver' but 'version' is the same.

If I run "version" in interactive command line mode I get: "host:2.5 cam:2.4"

Your camera is not actually running a version that supports remote capture. If you are using a multi-partition card, you might not have updated the right partition.

You can use =return get_buildinfo() to see what build you are actually running.

tpont

Thanks. I had failed to overwrite some of the older files on the SD card. Working now.
I did some speed tests. When I run

rs C:\ -dng

the shot takes ~2.2 seconds. The camera doesn't support remoteshoot to jpg. using -raw and -dnghr takes about the same time as -dng.
When I do a regular shoot using

=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

the shot takes ~1.9 seconds (I got it down to that by setting jpeg quality override in the CHDK menu to "normal")

Is it to be expected that the remoteshoot will take longer time? Or do you see any ways to make it as fast as or even faster than the regular shoot?

« Previous Page Next Page »