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

chdkptp - alternative ptp client

  • 1106 Replies
  • 434291 Views
*

Offline blackhole

  • *****
  • 862
  • A590IS 101b
    • Planetary astrophotography
Re: alternative ptp client
« Reply #640 on: 26 / April / 2014, 04:22:16 »
Advertisements
Quote
As I've already told you several times, CHDK isn't involved in the AF process at all, it's just pressing the buttons. ptpCamGUI does exactly the same thing.

The only vaguely plausible mechanism I can think of is that the live view is hogging so much CPU it interferes with AF somehow. You should be able to test that by turning off the live view, but IMO it's far more likely the behavior is just unpredictable.

There is really no chance that the CHDK build matters. The key press code has worked the same way since the very early days of CHDK.

... but what do I know
OK, I understand what you're saying, it was just my curiosity.

*

Offline reyalp

  • ******
  • 13714
Re: alternative ptp client
« Reply #641 on: 26 / April / 2014, 16:55:57 »
OK, I understand what you're saying, it was just my curiosity.
To be clear, if it is really reproducible and you are certain it isn't just the camera behaving unpredictably in situations where AF doesn't work well, then it's worth investigating. In my experience though, Canon AF can behave pretty randomly if conditions aren't ideal, and when something is random like this, it's pretty easy to convince yourself something you changed made a difference.

Things that seem plausible:
* Live view interfering in some way.
* Some difference between doing it with USB connected vs not connected (regardless of whether you use camera buttons). The USB mode switch is hacky, but it's hard to see why it would only affect macro.
* Some difference in the logic of how long the button is held down.

Less  plausible:
* CHDK version making any difference, as long as you aren't doing anything with overrides at the same time.
* PTP client program. A half press is a half press, the camera doesn't know the difference (except for differences in how long the button is held).
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13714
Re: alternative ptp client
« Reply #642 on: 27 / April / 2014, 01:05:46 »
I uploaded build 547 for the files area https://www.assembla.com/spaces/chdkptp/documents

The main change is that the -tv etc options rsint actually work instead of being ignored  :-[

Additionally, I added options to the shoot commands (shoot, rs, rsint):

-sd: set sd override distance. The usual CHDK sd override caveats apply. In particular, if your camera needs to be in aflock or mf mode, you need to set that first using =set_mf() etc.
The value for -sd is dist[unit string], so -sd=10.5in means 10.5 inches. The default unit is meters.

-svm: Sets the ISO in "market" units.  Requires CHDK 1.3
Don't forget what the H stands for.

*

Offline blackhole

  • *****
  • 862
  • A590IS 101b
    • Planetary astrophotography
Re: alternative ptp client
« Reply #643 on: 27 / April / 2014, 02:25:34 »
Quote
To be clear, if it is really reproducible and you are certain it isn't just the camera behaving unpredictably in situations where AF doesn't work well, then it's worth investigating. In my experience though, Canon AF can behave pretty randomly if conditions aren't ideal, and when something is random like this, it's pretty easy to convince yourself something you changed made a difference.
I do not know what to say, the same behavior can be repeated countless times, I was rehearsing and different lighting conditions, more contrastive object, I turned off  live view, nothing changes. Does not include any overrides, pure P mode, the only requirement is that the subject is somewhat closer than the minimum SD values for Macro mode. I tried it with two different cameras, A590 and A530, the problem is the same, both cameras also focus normally using chdkptp if used mentioned build. If one of the users has this camera and want to try the same, I can send him a mentioned build.
Quote
* Some difference in the logic of how long the button is held down.
This seems most likely, but I do not know, you're more familiar with these problems.


Re: alternative ptp client
« Reply #644 on: 27 / April / 2014, 11:46:55 »
Old tsvstar-uitest branch,1.2.0-r2198 works without problems,I don't know why. :D
Time required varies depending on conditions, nothing to do with the CHDK build. I really doubt the CHDK build actually matters, there is no plausible mechanism. As I said before CHDK isn't involved in the actual focusing process at all, it just holds the key down.
At the risk of "trying to shed light where there is no darkness",  I'd point out that tsvstar did a lot of funky things in his builds to make the camera work the way he wanted to.   I have not waded through all those changes (the ones I have looked at were enough fun decoding as it is) but I'd rate the possability that shot timing changed in his versions pretty high.   Which fits reyalp's comments about variable timing.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 13714
Re: alternative ptp client
« Reply #645 on: 27 / April / 2014, 15:01:50 »
At the risk of "trying to shed light where there is no darkness",  I'd point out that tsvstar did a lot of funky things in his builds to make the camera work the way he wanted to.
Well, like I've been saying, there really isn't much to be different. As I've said a bunch of times, CHDK really isn't doing much in this process. It's just fiddling with the physw_status bit for the half press button, which
to the canon firmware should be indistinguishable from the physical button.

My comment on timing was mostly about differences between chdkptp, ptpcamgui and pressing the button manually. As mentioned earlier chdkptp, waits for the the get_shooting, and then releases the button immediately. I don't know what ptpcamgui does.

It's very difficult to see how the CHDK build would make a consistent difference in timing, although I guess it might have changed by 1 kbd_task cycle somewhere along the line. That seems like a real stretch to explain what's going on though.

I would be extremely surprised if CHDK build was actually the relevant factor. From my understanding of CHDK it seems basically impossible.

@blackhole:
Have you tried the latest chdkptp version? This changes the half shoot delay to 3 seconds.
Another thing you could try is putting some delay after get_shooting goes true.
Don't forget what the H stands for.

*

Offline blackhole

  • *****
  • 862
  • A590IS 101b
    • Planetary astrophotography
Re: alternative ptp client
« Reply #646 on: 27 / April / 2014, 16:14:55 »
Just now I tried chdkptp r547 and everything works well. The camera is focusing well at a distance of 25 mm. Thank you for your efforts.

*

Offline reyalp

  • ******
  • 13714
Re: alternative ptp client
« Reply #647 on: 28 / April / 2014, 16:53:46 »
A note for anyone building their own chdkptp from SVN

I started a long overdue re-work of how errors are handled, with destabilizing changes starting at r550. I try to keep the trunk reasonably usable, but there are likely to be bugs.

Additionally, while this is in progress error output and Lua APIs are likely to be incompatible from version to version, so anyone parsing chdkptp output or running custom Lua code may want to stick to an earlier version for a while.

Once complete, this should be a significant improve. In particular
* The C code won't randomly spit error messages out to stderr
* Error messages will be more descriptive
* Specific PTP errors will be available to Lua code, so it can distinguish between things like a connection failure and cameras that don't support the CHDK extension.
* The APIs will be simpler overall, avoid the need for long chains of returning status, message up the call stack.
Don't forget what the H stands for.


*

Offline adong

  • **
  • 66
Re: alternative ptp client
« Reply #648 on: 05 / May / 2014, 06:24:50 »
Hello,

I've made a simple patch to rename some functions in chdkptp, so that lua can import them as libraries (eg require('chdkptp'))

This is pretty much a blind patch, as I do not have devices to test it with, but it should hopefully work

made against chdkptp r571.

EDIT:
The patch is missing libusb initialization.
Edit chdkptp.c function luaopen_chdkptp, insert "usb_init();" as the first command, remove "usb_init()" from main() to get it working.
« Last Edit: 06 / May / 2014, 08:56:45 by adong »

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #649 on: 05 / May / 2014, 09:25:04 »
reyalp, can you post a working example for connecting over command line with the -d (device) syntax. I can't get it to work. The device string has several backslashes in its path which I've tried to escape but I still get errors.

 

Related Topics