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

chdkptp - alternative ptp client

  • 1106 Replies
  • 434439 Views
*

Offline reyalp

  • ******
  • 13716
Re: alternative ptp client
« Reply #310 on: 10 / March / 2013, 16:05:03 »
Advertisements
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...
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4450
Re: alternative ptp client
« Reply #311 on: 10 / March / 2013, 17:47:51 »
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.
Quote
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.
Quote
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).

*

Offline msl

  • *****
  • 1276
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: alternative ptp client
« Reply #312 on: 12 / March / 2013, 08:17:27 »
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
CHDK-DE:  CHDK-DE links

*

Offline srsa_4c

  • ******
  • 4450
Re: alternative ptp client
« Reply #313 on: 12 / March / 2013, 19:29:25 »
With this patch live view works fine for the ixus60.
Thanks, committed.


Re: alternative ptp client
« Reply #314 on: 22 / March / 2013, 10:42:21 »
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?

*

Offline srsa_4c

  • ******
  • 4450
Re: alternative ptp client
« Reply #315 on: 22 / March / 2013, 12:17:30 »
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.

*

Offline philmoz

  • *****
  • 3411
    • Photos
Re: alternative ptp client
« Reply #316 on: 23 / March / 2013, 00:03:02 »
Patch attached for the new palette transparency values found in the SX50HS.
http://chdk.setepontos.com/index.php?topic=8306.msg98194#msg98194

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline reyalp

  • ******
  • 13716
Re: alternative ptp client
« Reply #317 on: 24 / March / 2013, 00:47:00 »
Patch attached for the new palette transparency values found in the SX50HS.
http://chdk.setepontos.com/index.php?topic=8306.msg98194#msg98194
Thanks, added in chdkptp changeset 330
Don't forget what the H stands for.


*

Offline jer

  • *
  • 10
Re: alternative ptp client
« Reply #318 on: 24 / March / 2013, 19:35:55 »
For the record:

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

Code: [Select]
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).
sx160is

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #319 on: 31 / March / 2013, 14:02:58 »
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
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.

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

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.    ...      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?
« Last Edit: 31 / March / 2013, 14:05:39 by tpont »

 

Related Topics