chdkptp - alternative ptp client

ricardo28

Hi, I have installed chdkptp in windows 7 x64
But when I connect the camera and try to connect I get this error:
http://ubuntuone.com/3uQDZsU7zOfdcDiXIzUAYW

Any help?

Thanks

srsa_4c

ricardo28
But when I connect the camera and try to connect I get this error:
http://ubuntuone.com/3uQDZsU7zOfdcDiXIzUAYW

You can get that error when CHDK is not running.

lyzby

On April 1, 2012, in conjunction with headless linux use of chdkptp, I reported a problem (not chdkptp-related) with the use of zoom with an SX40HS. I had successfully used chdkptp with an A590is, as documented here:

http://chdk.wikia.com/wiki/Chdkptp_in_headless_linux_Dockstar_-_remote_control

I just got back to the issue, and installed the latest chdk for the SX40HS on the SD card. I went back to the dockstar and connected to the SX40HS, with no change in chdkptp. Zoom now works, up to "lua set_zoom(250)" (although I haven't figured out how to focus at that zoom level--at a distance of only about a foot). At "lua set_zoom(80)" it auto-focuses and takes good photos. Sometimes the best thing to do is wait.

srsa_4c

I'm having a strange problem with my s1is.

File upload to the camera uses a protocol where the first chunk starts with
[4 bytes] filename length
[n bytes] filename
[...] file data, first chunk
The start of the file data is passed to fwrite(). This works for every other camera, but not for this one. I get semi-random data corruption when the address passed to fwrite() is odd. I have tried doing several things, but the only one which helped was to change the PTP client (chdkptp) to pad the filename with NULs for 32bit-alignment.
I'm wondering whether this is something that's good practice anyway, since neither ARMv5 nor the (possibly involved) DMA controller is able to do efficient work on unaligned addresses. I know of course that the firmware routines can deal with this situation (except on my camera).

reyalp

srsa_4c
I'm wondering whether this is something that's good practice anyway, since neither ARMv5 nor the (possibly involved) DMA controller is able to do efficient work on unaligned addresses. I know of course that the firmware routines can deal with this situation (except on my camera).

On most cameras, fwrite should be OK, because each FILE * has an uncached (and presumably aligned if required) buffer that is used for the actual write(). As far as I know, it would always go through this buffer.

srsa_4c

reyalp
On most cameras, fwrite should be OK, because each FILE * has an uncached (and presumably aligned if required) buffer that is used for the actual write(). As far as I know, it would always go through this buffer.

All other cameras should be ok, I've tried it on the Ixus30.
BTW, fwrite() is FWrite_Fut() on most cameras, except
ixus30, 40: fwrite(), there's no _Fut API.
s1is: fwrite() has horrible performance (~30kB/s, I have no idea how it could be that bad), so I've replaced all f* functions with wrapped open(), write() etc. The corruption is there, no matter fwrite() or write()...

reyalp

srsa_4c

reyalp
On most cameras, fwrite should be OK, because each FILE * has an uncached (and presumably aligned if required) buffer that is used for the actual write(). As far as I know, it would always go through this buffer.
All other cameras should be ok, I've tried it on the Ixus30.
BTW, fwrite() is FWrite_Fut() on most cameras, except
ixus30, 40: fwrite(), there's no _Fut API.
s1is: fwrite() has horrible performance (~30kB/s, I have no idea how it could be that bad), so I've replaced all f* functions with wrapped open(), write() etc. The corruption is there, no matter fwrite() or write()...

I don't think null padding and aligning the name should hurt anything.

This reminds me of this problem: https://chdk.setepontos.com/d/6730/16 ... in fact, my original workaround was to pad the filename data.

msl

Live view on older cameras like the ixus60:

It seems the live view would not work properly on older cameras. Tests with an ixus 60 shows that only the bitmap overlay works conditionally. I think it is missing a few things in the source code.

A screenshot of a overlay example shows an artefact of an older displaying after a 'draw_clear()' command (red marked).

It would be very nice if there is a possibility, make live view available for these older cameras.

msl

blackhole

It seems the live view would not work properly on older cameras. Tests with an ixus 60

To me on the A530 all work without a problem, it is a camera from the same era as the Ixus 60 , but I used an older version chdkptp client when I tried.

https://chdk.setepontos.com/d/6231/159

srsa_4c

msl
It seems the live view would not work properly on older cameras.

This is true for those models where nobody implemented the additional functions needed for live view. There are exceptions (the list below may not be complete and is VxWoks only):
a540 with probably the most complete support code,
a410-420-430-450-460
ixus65

platform/model/sub/{revision]/lib.c and/or platform/{model}/lib.c needs to be changed, the attached diff (for ixus60) shows which functions need to be implemented. The above ports usually give a hint where to find specific memory addresses in the firmware.
This kind of work doesn't require assembly skills, all what's needed is to locate the addresses in the reference disassembly, and find the equivalent places in the other disassembly. The routines usually do not differ substantially, they can be compared visually.

A screenshot of a overlay example shows an artefact of an older displaying after a 'draw_clear()' command (red marked).

If this is only happening when using ptp live view, the attached patch should help (I can't test it, need feedback).

Also note that from r2614 on, the use of memPartInfoGet has been enabled for every VxWorks model, which should speed up ptp transfers considerably. https://chdk.setepontos.com/d/650/1027

ixus60_ptp_liveview_support_and_more.diff

4.65KB

reyalp

srsa_4c
The start of the file data is passed to fwrite(). This works for every other camera, but not for this one. I get semi-random data corruption when the address passed to fwrite() is odd. I have tried doing several things, but the only one which helped was to change the PTP client (chdkptp) to pad the filename with NULs for 32bit-alignment.

A further question on this: Have you verified that it happens with regular fwrites outside of PTP? If so, I expect you could run into a lot of other problems too. If not, maybe there's something more subtle going on. If it does happen everywhere, it might be worth making a buffered version, although perhaps this would be as slow as canons fwrite...

srsa_4c

reyalp
A further question on this: Have you verified that it happens with regular fwrites outside of PTP?

Tried write(), acts the same. The issue is not ptp related. Guess they had forgotten to test this possibility. Even though the firmware doesn't do unaligned writes, they could have tested it with a script.

If so, I expect you could run into a lot of other problems too.

I haven't noticed corrupted files elsewhere (tests, dng, config), so this seems to be the only place that triggers it. As of now.

If it does happen everywhere, it might be worth making a buffered version, although perhaps this would be as slow as canons fwrite...

I've been thinking about using some BSD code (stdio routines), but currently I'm only using small parts of those (with the caching parts removed).

msl

srsa_4c
platform/model/sub/{revision]/lib.c and/or platform/{model}/lib.c needs to be changed, the attached diff (for ixus60) shows which functions need to be implemented. The above ports usually give a hint where to find specific memory addresses in the firmware.

Thanks for your work.

With this patch live view works fine for the ixus60.

msl

srsa_4c

mslWith this patch live view works fine for the ixus60.

Thanks, committed.

kosmarnik

Tried CHDKPTP r311 with a SX40HS (sx40hs-100f-1.2.0-2640).
It connects, I can sometimes get the live view, but only a static frame.
Can't trigger any buttons with CHDKPTP, but can view the camera filesystem and download files.

Are there any config files I could tweak or should I just wait for the camera to be fully supported?

srsa_4c

kosmarnik
Tried CHDKPTP r311 with a SX40HS (sx40hs-100f-1.2.0-2640).
It connects, I can sometimes get the live view, but only a static frame.
Can't trigger any buttons with CHDKPTP, but can view the camera filesystem and download files.

You need to switch the camera to rec mode (use chdkptp's "rec" button), the remote camera buttons will only start to work after you do that.
Remote live view can misbehave when a stopped movie is displayed on the camera LCD.

philmoz

Patch attached for the new palette transparency values found in the SX50HS.
https://chdk.setepontos.com/d/8306/18

Phil.

SX50_palette_type.patch

2.53KB

reyalp

philmoz
Patch attached for the new palette transparency values found in the SX50HS.
https://chdk.setepontos.com/d/8306/18

Thanks, added in chdkptp changeset 330

jer

For the record:

When trying to compile chdkptp-r311-Linux-x86_32 (nothing pre-compiled available) on debian testing, I got this:

chdkptp.c:40:17: fatal error: usb.h: No such file or directory

libusb-1.0-0-dev was available, however, this seems to be necessary as well:
libusb-dev (it contains usb.h).

tpont

Hi reyalp, I'm reviving a topic from earlier in the thread. I asked about ways to speed up the shoot cycles. The context is that I use the two cameras for book scanning. The ideal would be shoot cycles just under 2 seconds because that is roughly how long it takes to turn each page in the setup. By changing some camera settings (disabling preview, etc) I'm down to 3,5 seconds cycles. I use chdkptp on the command line from another script. (I've also tried sending the commands in interactive mode and through the GUI but didn't get noticeably faster cycles that way.) The script first sets up zoom and lock focus and then trigger shots on both cameras with this

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.

I can manually cycle shoot the cameras quicker, even in noncontinuous mode. Holding the button down gives 10 shots in 17 seconds.

reyalp
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]
=for i=1,10 do shoot() sleep(10) end
[/code]
takes 35 sec. ... Using the new remote shoot stuff, a jpeg (including download) takes 1.3 sec.

You 10 cycle DNG speed is similar to what I currently get for capturing JPG with two cameras simultaneously. Can you tell me more about the new remote shoot features? Can you shoot a number of cycles at around 2 seconds using that?

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?

« Previous Page Next Page »