CHDK PTP interface - page 111 - General Discussion and Assistance - CHDK Forum supplierdeeply

CHDK PTP interface

  • 1227 Replies
  • 317488 Views
*

Offline srsa_4c

  • ******
  • 4285
Re: CHDK PTP interface
« Reply #1100 on: 07 / September / 2014, 18:57:34 »
Advertisements
New patch for "multipass" cameras. Should allow remote shooting when drive mode is not continuous and custom timer is not active. (I did not test custom timer mode on other cameras, but I suspect that it will only cause trouble in connection with remote shooting.)
I have renamed OFLAG_APPEND to OFLAG_NOFLUSH because the latter seems closer to the flag's real purpose. I am also specifically disallowing remote shooting for affected cameras when drive mode is not single (see remotecap_set_target()). I could only test this on my a3200. The other 2 cams that will probably also work with this patch are the a490 and 495 (these were tested with the previous patch which was functionally the same except for the drive mode check).
The patch is not meant to be committed as-is, needs to be tested on each affected model:
We could just apply it to cameras known to suffer from the problem.
The patch includes support for these cams: a2200, a3200, a490, a495, ixus1000_sd4500, ixus200_sd980, ixus230_elph310, s90, sx220, sx230, sx30.

*

Offline reyalp

  • ******
  • 12728
Re: CHDK PTP interface
« Reply #1101 on: 07 / September / 2014, 20:35:22 »
This seems reasonable to me.

When I suggested this, I was only really thinking about rs -cont, but of course it will affect anyone who happens to leave their camera in continuous mode, even if they are only trying to take single shots. Nothing we can do about that, and still better than having it fail completely.

Other thoughts:
Should remotecap_set_target only fail if they requested jpeg? Presumably CHDK raw should be fine, but I guess the jpeg would have to be written to the card and filewrite might get more complicated. I haven't seen too many people interested in remoteshoot with raw, so maybe a non-issue.

Another question is if it should affect the return value of remotecap_get_target_support. I'm not sure, currently it's returns what the port is capable of regardless of the current state (e.g if you are in playback or movie mode it returns the supported formats)
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4285
Re: CHDK PTP interface
« Reply #1102 on: 08 / September / 2014, 18:15:01 »
it will affect anyone who happens to leave their camera in continuous mode, even if they are only trying to take single shots. Nothing we can do about that, and still better than having it fail completely.
We might be able to switch drive mode with UI properties - once/if the necessary research is done.
Quote
Should remotecap_set_target only fail if they requested jpeg? Presumably CHDK raw should be fine, but I guess the jpeg would have to be written to the card and filewrite might get more complicated.
I did not try, but I think the current approach of suppressing JPEG may fail to work in continuous mode for multipass cams. So, IMHO all targets should fail.
Quote
Another question is if it should affect the return value of remotecap_get_target_support. I'm not sure, currently it's returns what the port is capable of regardless of the current state (e.g if you are in playback or movie mode it returns the supported formats)
The code could be reorganized by moving the "possibilities" check from the beginning of remotecap_set_target() to remotecap_get_target_support() and making the latter function accept a parameter. remotecap_get_target_support() could then be used for querying both "what does the cam support" and "what does the cam support right now".

*

Offline nafraf

  • *****
  • 1308
Re: CHDK PTP interface
« Reply #1103 on: 08 / September / 2014, 20:15:24 »
it will affect anyone who happens to leave their camera in continuous mode, even if they are only trying to take single shots. Nothing we can do about that, and still better than having it fail completely.
We might be able to switch drive mode with UI properties - once/if the necessary research is done.
Code: [Select]
A495        - Propset 3   - 0x8009
A810/SX160  - Propset 5   - 0x800D
A1400       - Propset 6   - 0x800D
SX170/SX510 - Propset 6?  - 0x800E
0=Single,
1=Continuous,
2=Continuos shooting AF (valid on some models)

« Last Edit: 08 / September / 2014, 20:18:07 by nafraf »


*

Offline reyalp

  • ******
  • 12728
Re: CHDK PTP interface
« Reply #1104 on: 08 / September / 2014, 23:49:26 »
We might be able to switch drive mode with UI properties - once/if the necessary research is done.
That would be useful in a lots of other situations too.

Quote
I did not try, but I think the current approach of suppressing JPEG may fail to work in continuous mode for multipass cams. So, IMHO all targets should fail.
Yeah, makes sense.
Quote
The code could be reorganized by moving the "possibilities" check from the beginning of remotecap_set_target() to remotecap_get_target_support() and making the latter function accept a parameter. remotecap_get_target_support() could then be used for querying both "what does the cam support" and "what does the cam support right now".
Hmm. That could work. Somewhat tempting just stick with your original patch to keep it simple, but allowing the client to distinguish between not implemented and something that just needs a mode change would be more user friendly. The Lua function could just return both bitmasks, like
available, supported = get_usb_capture_support()

remotecap_set_target() should still do all the checks anyway (because you don't know if the client checked or what changed in between), but it could just call the "what does the cam support right now" variant.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4285
Re: CHDK PTP interface
« Reply #1105 on: 09 / September / 2014, 17:35:59 »
Somewhat tempting just stick with your original patch to keep it simple
That would be my intention for now, the code reorganization can be done later. The check will then have to be extended to disallow rs when custom timer is active - on all cameras.

@nafraf
If you still have the a495 and some time, can you recheck remote shooting with the latest patch (just to be sure)? I think the models which get CAM_FILEWRITETASK_MULTIPASS are the a3200, a490 and a495 initially. The rest will be added when camera owners report rs failure (i.e. maybe never). If cameras from the DryOS r39..r49 range get filewritetask support from now on, multipass will have to be considered and tested for.
And we should start collecting those UI properties somewhere...

*

Offline nafraf

  • *****
  • 1308
Re: CHDK PTP interface
« Reply #1106 on: 09 / September / 2014, 19:51:45 »
A495 patch tests.  If you need more tests, just let me know. 

*

Offline srsa_4c

  • ******
  • 4285
Re: CHDK PTP interface
« Reply #1107 on: 09 / September / 2014, 20:02:03 »
A495 patch tests.
Pretty big files for a 10MP cam and many small chunks. Do small picture sizes / higher compression also work? Are the files OK (including their exif)?


*

Offline nafraf

  • *****
  • 1308
Re: CHDK PTP interface
« Reply #1108 on: 10 / September / 2014, 08:08:24 »
A495 tests: L, M2 and S size.  Fine and Superfine quality.
JPGs are fine. Logs and exif data in attachment.

*

Offline srsa_4c

  • ******
  • 4285
Re: CHDK PTP interface
« Reply #1109 on: 10 / September / 2014, 19:07:22 »
A495 tests: L, M2 and S size.  Fine and Superfine quality.
JPGs are fine. Logs and exif data in attachment.
Thanks. Unless there's objection, I'll check in the above patch (limited to a3200, a490, a495 for now) in a few days.

 

Related Topics