CHDK PTP interface - page 84 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 79 80 81 82 83 [84] 85 86 87 88 89 ... 125   Go Down

CHDK PTP interface

  • 1241 Replies
  • 491420 Views
*

Offline reyalp

  • ******
  • 14082
Re: CHDK PTP interface
« Reply #830 on: 29 / August / 2012, 16:50:27 »
Advertisements
From Sticks thread http://chdk.setepontos.com/index.php?topic=8585.msg90041#msg90041
Quote from: srsa_4c on 29 / August / 2012, 14:10:58
but I'm concerned about the chdkptp-side implementation. Especially now that there's a brand new shoot command, I'm not sure how mine should be implemented.
As long as the individual steps are available to lua (which as I said, I can add) and a scripted shoot will honor the remote capture settings, this doesn't seem like it should be much of a problem.

The client will have to know not to use a blocking call for a shoot script if it expects to get remote data.

Would it be useful to be able to set the remote capture parameters in lua, (equivalent to PTP_CHDK_RemoteCaptureInit) or is this redundant ? I'm not sure...

From an efficiency point of view, it would be preferable to add the remote capture data available flag to PTP_CHDK_ScriptStatus rather than giving it a unique command (PTP_CHDK_RemoteCaptureIsReady). That way, the existing wait_status command in chdkptp would be extended to work on that value, without the overhead of polling multiple different commands. This seems like the way to go to me. (Ultimately, there should be a way to combine all the status bits with the live view polling, but that's another project)

How chdkptp side Lua should deal with getting the individual chunks so something of a question, since in some cases you'd want to write directly to disk (for low memory systems, you might want to not even store a whole raw) and in others you might want the data as an lbuf in Lua. I think this shouldn't really influence the protocol though.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #831 on: 30 / August / 2012, 21:05:30 »
Quote from: reyalp on 29 / August / 2012, 16:50:27
As long as the individual steps are available to lua (which as I said, I can add)
OK :)
Are these steps similar to what those (unfinished/untested) functions in ptp.c (in the v2 patch) are supposed to do? (ptp_chdk_rcinit, ptp_chdk_rcisready, ptp_chdk_rcgetname, ptp_chdk_rcgetfile)
Quote
and a scripted shoot will honor the remote capture settings, this doesn't seem like it should be much of a problem.

The client will have to know not to use a blocking call for a shoot script if it expects to get remote data.

Would it be useful to be able to set the remote capture parameters in lua, (equivalent to PTP_CHDK_RemoteCaptureInit) or is this redundant ? I'm not sure...
You mean setting file type(s), crop parameters independently of initing / uniniting the remote file target mode?

I've been thinking about a use case where the camera runs a motion detection script, and the client fetches the pictures (continuously) as they become available. In this case the camera would stay in remote file target mode for a while. Maybe this could be considered.
Quote
From an efficiency point of view, it would be preferable to add the remote capture data available flag to PTP_CHDK_ScriptStatus rather than giving it a unique command (PTP_CHDK_RemoteCaptureIsReady). That way, the existing wait_status command in chdkptp would be extended to work on that value, without the overhead of polling multiple different commands.
OK, but the return value of PTP_CHDK_RemoteCaptureIsReady will need to be placed somewhere (param2?)
Quote
This seems like the way to go to me. (Ultimately, there should be a way to combine all the status bits with the live view polling, but that's another project)

How chdkptp side Lua should deal with getting the individual chunks so something of a question, since in some cases you'd want to write directly to disk (for low memory systems, you might want to not even store a whole raw) and in others you might want the data as an lbuf in Lua.
Guess you mean something like you did with ptp_chdk_download(). I'll leave that to you  :D

I'll also need help getting the DNG exif, as that code seems to be mixed into the DNG creation process which my current code avoids (there's no point in stressing the camera with byteswapping).

Also, for cameras with partial (RAW only) support, maybe the SDM method is the way to go (I haven't looked into that code, but I seem to recall that the RAW data is transferred over PTP and the JPEG - which is small - gets erased instantly). I think SDM fills the RAW buffer with some homogeneous value (0?) to achieve a really small JPEG.
Logged
*

Offline reyalp

  • ******
  • 14082
Re: CHDK PTP interface
« Reply #832 on: 30 / August / 2012, 21:48:12 »
Quote from: srsa_4c on 30 / August / 2012, 21:05:30
Are these steps similar to what those (unfinished/untested) functions in ptp.c (in the v2 patch) are supposed to do? (ptp_chdk_rcinit, ptp_chdk_rcisready, ptp_chdk_rcgetname, ptp_chdk_rcgetfile)
Yes, that's what I had in mind. I still haven't had a chance to really look at it, but next weekend is looking good.
Quote
You mean setting file type(s), crop parameters independently of initing / uniniting the remote file target mode?
Yes.
Quote
I've been thinking about a use case where the camera runs a motion detection script, and the client fetches the pictures (continuously) as they become available. In this case the camera would stay in remote file target mode for a while. Maybe this could be considered.
Yes, it seems like this might be more convenient under script control. Question:
Should we allow both (could lead to odd situation if client uses both, also code complexity) or require that it be done in lua ? I'd be tempted to only do it in lua if we are going to allow lua at all,  so  PTP_CHDK_RemoteCaptureInit would be replaced by a lua function.

Since shooting requires sending lua anyway, it doesn't seem like this would be a big handicap. If anything would make the client simpler.

Thoughts ?

Quote
OK, but the return value of PTP_CHDK_RemoteCaptureIsReady will need to be placed somewhere (param2?)
We have quite a few params and bits free. I also realized after posting that this would make it no longer really "script" status :-[

I wonder if it would make more sense to have this be a flag (remote capture chunk is available), and make PTP_CHDK_RemoteCaptureGetData just return the next chunk along with an ID of what it is ?

Quote
Also, for cameras with partial (RAW only) support, maybe the SDM method is the way to go (I haven't looked into that code, but I seem to recall that the RAW data is transferred over PTP and the JPEG - which is small - gets erased instantly). I think SDM fills the RAW buffer with some homogeneous value (0?) to achieve a really small JPEG.
I haven't looked at SDM, but if we go this way, it seems like it should be something you can set for script, could be useful in other situations beyond remote camera. e.g nuke_next_jpeg()
In some situations, keeping the all black jpeg could be useful, because it would still have the exif

Regarding development:
I understand you didn't want to use the trunk because it's moving too fast. What would you think about having this temporarily go in a branch of the current trunk ? I'd prefer to have it in svn somewhere to play with, and it's not going to go into the stable branch in the end.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #833 on: 30 / August / 2012, 22:08:05 »
-
« Last Edit: 31 / August / 2012, 16:09:27 by srsa_4c »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #834 on: 31 / August / 2012, 16:51:10 »
Quote from: reyalp on 30 / August / 2012, 21:48:12
Quote
I've been thinking about a use case where the camera runs a motion detection script, and the client fetches the pictures (continuously) as they become available. In this case the camera would stay in remote file target mode for a while. Maybe this could be considered.
Yes, it seems like this might be more convenient under script control. Question:
Should we allow both (could lead to odd situation if client uses both, also code complexity) or require that it be done in lua ? I'd be tempted to only do it in lua if we are going to allow lua at all,  so  PTP_CHDK_RemoteCaptureInit would be replaced by a lua function.

Since shooting requires sending lua anyway, it doesn't seem like this would be a big handicap. If anything would make the client simpler.
I'm sorry, but I don't follow. What does "both" mean here? If it's about the format + cropping settings, I think a single method of setting them would be preferred.

Quote
I wonder if it would make more sense to have this be a flag (remote capture chunk is available), and make PTP_CHDK_RemoteCaptureGetData just return the next chunk along with an ID of what it is ?
I'll think about this. It would require new logic on the client side too.

Quote
Quote
Also, for cameras with partial (RAW only) support, maybe the SDM method is the way to go (I haven't looked into that code, but I seem to recall that the RAW data is transferred over PTP and the JPEG - which is small - gets erased instantly). I think SDM fills the RAW buffer with some homogeneous value (0?) to achieve a really small JPEG.
I haven't looked at SDM, but if we go this way, it seems like it should be something you can set for script, could be useful in other situations beyond remote camera. e.g nuke_next_jpeg()
In some situations, keeping the all black jpeg could be useful, because it would still have the exif
A small step from here is to keep the full jpeg and transfer/erase it on demand :/ This would essentially do what current scripted solutions do. The number of possible options keeps growing...
Quote
Regarding development:
I understand you didn't want to use the trunk because it's moving too fast. What would you think about having this temporarily go in a branch of the current trunk ? I'd prefer to have it in svn somewhere to play with, and it's not going to go into the stable branch in the end.
I'm not against it. Tried my v2 patch, it still applies to current trunk code without change.
Do you plan to take over the chdkptp part?
Logged
*

Offline reyalp

  • ******
  • 14082
Re: CHDK PTP interface
« Reply #835 on: 31 / August / 2012, 17:23:04 »
Quote from: srsa_4c on 31 / August / 2012, 16:51:10
I'm sorry, but I don't follow. What does "both" mean here? If it's about the format + cropping settings, I think a single method of setting them would be preferred.
Yes, by "both" I meant  the current PTP_CHDK_RemoteCaptureInit + an equivalent script function. And I agree a single method seems better, and the more I think about it, I think script is the better option.
Quote
Quote
I wonder if it would make more sense to have this be a flag (remote capture chunk is available), and make PTP_CHDK_RemoteCaptureGetData just return the next chunk along with an ID of what it is ?
I'll think about this. It would require new logic on the client side too.
This was just thinking out loud, maybe it doesn't make sense don't put a lot of work into it.

Quote
A small step from here is to keep the full jpeg and transfer/erase it on demand :/ This would essentially do what current scripted solutions do. The number of possible options keeps growing...
If they keep the full file, then I don't think there's any need to use remote capture. They can download it as a file and decide what to do. Deleting can be done in script already.

Quote
Quote
Regarding development:...
I'm not against it. Tried my v2 patch, it still applies to current trunk code without change.
OK, I think I'll do this.
Quote
Do you plan to take over the chdkptp part?
I could put it under an ifdef and do some work on it at least.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14082
Re: CHDK PTP interface
« Reply #836 on: 02 / September / 2012, 15:11:28 »
I've created a branch for the remote capture stuff, with the patch from #829 above applied and the ptp minor version incremented.

As an aside, it would be nice to be able to identify development versions in the version command. We often end up making incompatible changes before the final protocol is nailed down, and it wouldn't make sense to update the major version for this. However from a practical point of view, when developing clients, it's nice to be able to check if you are talking to the corresponding development version.

I'm thinking either
- add a third parameter to PTP_CHDK_Version - 0 (which should be effectively returned by the versions that don't explicitly set it) means it's a release version, other values can be used to uniquely identify test versions.
- declare that a minor version greater than say 10000 is a flag for development.

edit:
I've added the chdkptp patch. It will automatically #ifdef in the remote capture code if you use the ptp.h from the ptp-remote-capture-test branch (set CHDK_SRC_DIR=/path/to/branch in config.mk)

I took out the a410 hack for now, but I would like to make chdkptp do the right thing for these cameras at some point.

edit:
Remote shoot with raw on a540 and d10 work. Transfer for full raw is reasonably quick, the entire rs command took 2 sec on a540, 3.8 sec on d10 (this includes pre-focus, shooting etc in addition to transfer)
« Last Edit: 02 / September / 2012, 21:51:13 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #837 on: 02 / September / 2012, 22:02:34 »
Quote from: reyalp on 02 / September / 2012, 15:11:28
I took out the a410 hack for now, but I would like to make chdkptp do the right thing for these cameras at some point.
I was too lazy to separate that.

About replacing PTP_CHDK_RemoteCaptureInit with script command(s):
Can this be bulletproof? Currently, PTP_CHDK_RemoteCaptureInit is independent of scripting, so it can be issued any time. I'm asking because of its "uninit" functionality.
If script execution breaks for some reason and the camera keeps reporting "script is already running", can an emergency uninitialization be executed? If not, hooks will continue to be blocked, until they time out (which is not currently implemented).

update:
Quote
Remote shoot with raw on a540 and d10 work. Transfer for full raw is reasonably quick, the entire rs command took 2 sec on a540, 3.8 sec on d10 (this includes pre-focus, shooting etc in addition to transfer)
What do you think about the jpeg? Should it be minimized / blacked out?
« Last Edit: 02 / September / 2012, 22:05:46 by srsa_4c »
Logged
*

Offline reyalp

  • ******
  • 14082
Re: CHDK PTP interface
« Reply #838 on: 03 / September / 2012, 01:51:07 »
Quote from: srsa_4c on 02 / September / 2012, 22:02:34
Quote from: reyalp on 02 / September / 2012, 15:11:28
I took out the a410 hack for now, but I would like to make chdkptp do the right thing for these cameras at some point.
I was too lazy to separate that.

About replacing PTP_CHDK_RemoteCaptureInit with script command(s):
Can this be bulletproof? Currently, PTP_CHDK_RemoteCaptureInit is independent of scripting, so it can be issued any time. I'm asking because of its "uninit" functionality.
If script execution breaks for some reason and the camera keeps reporting "script is already running", can an emergency uninitialization be executed? If not, hooks will continue to be blocked, until they time out (which is not currently implemented).
This is a good question. I think it's OK to have in script though:
1) Timeout should be implemented before release, so impact will not be so bad.
2) there's already lots of things you can do with script that leave the camera in a bad state, like shoot() in video mode...
3) We should at the capability to cleanly kill a running script. This shouldn't be hard, just need to set a flag for kbd_task that triggers the same code path as pressing shutter.

Quote
What do you think about the jpeg? Should it be minimized / blacked out?
Maybe nice to have, but I don't think it's a high priority.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14082
Re: CHDK PTP interface
« Reply #839 on: 03 / September / 2012, 17:58:24 »
I added filewritetask hook to a540. Seem to work as expected.

Some thoughts on the code:
Most of the stuff add to generic/capt_seq.c should be in thumb code somewhere.
It might make more sense to do most of the stuff in capt_seq_hook_raw_here() within the regular raw hook (or the same spytask loop where the raw hook is called)
get_next_chunk_data_for_ptp also looks like it doesn't need to be in capt_seq, but not sure where it goes.
Logged
Don't forget what the H stands for.
Pages: 1 ... 79 80 81 82 83 [84] 85 86 87 88 89 ... 125   Go Up
« previous next »
 

Related Topics