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

CHDK PTP interface

  • 1244 Replies
  • 517900 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #820 on: 05 / August / 2012, 15:57:27 »
Advertisements
@reyalp
I'd like to start implementing remote capture with remote target (i.e. PC). Some months ago I did some research, as you may remember http://chdk.setepontos.com/index.php?topic=7366.0 .
I need some help/advice on how this should be done in CHDK and in the reference client (chdkptp).
Remote capture formats could include:
- JPEG (via a hook in FileWriteTask), with or without Exif
- the uncompressed YUV source of the JPEG (which should be available at the same time as the JPEG)
- RAW (via the existing RAW save hook)

What I don't know is the PTP part of all this, and how should scripting be involved. Do you have an idea?
Thanks.

*

Offline reyalp

  • ******
  • 14110
Re: CHDK PTP interface
« Reply #821 on: 05 / August / 2012, 16:39:19 »
I'd like to start implementing remote capture with remote target (i.e. PC). Some months ago I did some research, as you may remember
Question: Is this actually worthwhile compared to letting the camera save to disk and downloading the file ? It could be faster, but what is the use case where saving to disk is too slow, and this isn't ?

I'm not against it, just wondering if you have a specific application in mind.
Quote
What I don't know is the PTP part of all this, and how should scripting be involved. Do you have an idea?
To capture raw (and presumably the other options) you will need to do something like the how the raw hook in capt_seq blocks and waits for spytask. Since PTP transfers can only be initiated by the PC side, I think it will have to go like this (for raw, if you hook some other place the sequence should be similar):

1) Before shot, PC sends a command to tell the camera it wants to transfer the next image over PTP. This just sets a flag for cap_seq_task
2) The raw hook (or spytask raw code) sees the flag, sets another other flag to say raw is available, and waits
3) in the meantime, the PC polls waiting for the raw available flag
4) when the PC sees the raw available, it initiates a command that has a camera->pc data phase to transfer the data
5) when the transfer is complete, it clears the flag that has been blocking the raw hook, and everything continues as normal.

Some additional notes:
1) In my experience, sending uncached data is much faster than cached. So if you send the raw buffer, you should use the uncached address.
2) For the options other than jpeg, it could be useful to be able to request only a sub-image. Practically, the overhead of individual send calls is such that you'd probably send entire lines.
3) Should think about error cases, e.g. if the client requests a remote capture but fails to load the data... so #2 in the preceding list should maybe time out eventually.
4) The "flags" above should probably just be one state variable.

So I see this as at least 3 additional PTP commands (or 1 command with 3 sub commands, but I prefer to separate things that have data phases from ones that don't), something like
RemoteCaptureInit - called before exposure, tells CHDK we want the data over PTP. No data phase, may specify type (e.g. jpeg, raw, yuv) and sub-image.
RemoteCaptureIsReady - Polled after above, no data phase, just tells if data is available.
RemoteCaptureGetData - called after the preceding, has a cam->pc data phase

Re scripting:
We could put the functionality of RemoteCaptureInit and RemoteCaptureIsReady in script, but this just seems like added complexity to me.

Other questions:
Should the transferred data include meta data ? If so, how much in what form ? For raw, it might make sense to send the whole DNG exif ?
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #822 on: 05 / August / 2012, 18:50:08 »
Thanks for the suggestions!
Question: Is this actually worthwhile compared to letting the camera save to disk and downloading the file ? It could be faster, but what is the use case where saving to disk is too slow, and this isn't ?
For me, the current remote capture solution feels like a workaround (it is a workaround, actually). Canon's "remote control" capability always included (AFAIK) a shooting option where the destination of the capture is the "PC". I would like to restore this functionality. My other concern is: why write to the card (causing wear) when the pictures should end up on the connected host anyway? And yes, it can be a little faster.
Quote
Practically, the overhead of individual send calls is such that you'd probably send entire lines.
I don't quite get what you mean here.
Quote
Should the transferred data include meta data ? If so, how much in what form ? For raw, it might make sense to send the whole DNG exif ?
It could be an option to send metadata or not. For JPEG, exif is available at the same time (it's stored in a separate buffer and is intended to be written first), for raw, probably the DNG exif-generator routine should be reused somehow.

*

Offline reyalp

  • ******
  • 14110
Re: CHDK PTP interface
« Reply #823 on: 05 / August / 2012, 19:25:40 »
Quote
Practically, the overhead of individual send calls is such that you'd probably send entire lines.
I don't quite get what you mean here.
If you want to send the whole buffer, you can do it with one call to data->send_data. Same if your subimage is full width but reduced height: you just adjust the start and total size. Live view does this for modes where the viewport isn't full height (e.g. 16:9 on a 4:5 screen)

If the subimage is narrower than the full image you have to call send_data for each line. I tried this for live view, because some cameras have unused borders (e.g. stitch window) but it was significantly slower than just sending the whole buffer. You could copy it into a new buffer, but that would take time and you wouldn't have enough RAM to do it all at once unless the subimage is very small.
Quote
It could be an option to send metadata or not. For JPEG, exif is available at the same time (it's stored in a separate buffer and is intended to be written first), for raw, probably the DNG exif-generator routine should be reused somehow.
Questions to think about:
Is there some minimum amount of data you need (dimensions, bayer pattern, bit depth) ? Or do you require the user to obtain or know those separately.
If you require them to get it separately, is it available via script ? Currently essential stuff like raw size and bayer are not.
If you need some data, is it really worthwhile to make the rest optional ? With a 20mb raw, or even a 1mb jpeg, adding a few kb of exif isn't going to have a significant impact. It may be better to send it all the time and let the client discard it if they don't care.
Don't forget what the H stands for.


*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #824 on: 05 / August / 2012, 19:42:22 »
If the subimage is narrower than the full image you have to call send_data for each line. I tried this for live view, because some cameras have unused borders (e.g. stitch window) but it was significantly slower than just sending the whole buffer.
OK, now I get it. Don't break up data into tiny pieces because the USB DMA doesn't like it.
Quote
If you need some data, is it really worthwhile to make the rest optional ? With a 20mb raw, or even a 1mb jpeg, adding a few kb of exif isn't going to have a significant impact. It may be better to send it all the time and let the client discard it if they don't care.
Good point.

*

Offline c10ud

  • ***
  • 245
Re: CHDK PTP interface
« Reply #825 on: 06 / August / 2012, 08:17:15 »
@srsa_4c: I once tried doing this, i found the camera (DryOS, i don't remember the exact model) was keeping a pointer to the last jpg buffer (iirc there also was some offset due to exif data, but it doesn't matter) but i couldn't prevent it from writing data to the SD card, i reached the point where it was writing 0b files, but still ugly, then i gave up (iirc i had to add quite a lot of code...probably now that i think of it there was some simpler solution like overriding the save jump or something like that)

all of this to say, if you simply want to get the job done (if you want to hack it badly then it's another story):
- send lua shoot()
- wait a bit
- download from the SD card with standard ptp commands (or chdk data dl)
- ???
- profit!

A standard SD card will be fast enough when saving and its life will be ~yrs

*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #826 on: 06 / August / 2012, 09:43:12 »
to get the job done
Job?
Challenge!  :)
BTW, read the link I posted here

*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #827 on: 22 / August / 2012, 21:22:34 »
Attached to this post are preliminary patches implementing remote shooting with remote target via ptp.
Problems, issues, notes (list is not complete...)
  • it's only for A410 and A470 (reference implementations), I can provide a _few_ other examples if needed, but the structure used by FileWriteTask will need to be investigated before use. Some information about that structure is here: http://chdk.setepontos.com/index.php?topic=7366.msg80301#msg80301
  • code is ugly and imperfect (suggestions / improvements are welcome)
  • the new FileWriteTask hooks need more assembly glue code than usual
  • the FileWriteTask hook is only used to accomplish remote shooting, the task could be used for more (see: http://chdk.wikia.com/wiki/User:Srsa_4c/FileWriteTask_possible_uses)
  • uncompressed YUV as image format is not implemented yet
  • RAW doesn't include any metadata
  • the new hooks don't time out on camera, power interruption or ptp remote shoot command is required in case of malfunction
  • used terms (text) are not always appropriate, improvements are welcome, again
  • the new chdkptp command is only available on command line
  • the modified chdkptp has only been tested on Linux
  • the chdkptp patch includes a not related workaround for the A410
  • remote shooting only supports taking a single picture at the moment with the current camera settings
  • it's not known how cameras with native RAW support work
  • the camera notes every picture taken, the ones that haven't been saved locally show up as "unidentified image" in play mode, this could become an issue because of its memory consumption
  • manually erasing these phantom pictures hasn't caused any trouble on the A470
  • the phantom pictures show up as files in a regular (not chdk) ptp session, downloading these results in files consisting of 0 bytes
  • erasing the phantoms over regular ptp took as much time as erasing real files, but still no sign of filesystem trouble
  • tested up to 400 pictures / session on A470
  • currently developed for CHDK 1.1 (1.2 is changing too fast at the moment)


*

Offline reyalp

  • ******
  • 14110
Re: CHDK PTP interface
« Reply #828 on: 22 / August / 2012, 23:41:54 »
Thanks for working on this srsa_4c. I probably won't get a chance to look at it in detail before the the weekend.

Some initial thoughts.
- Adding a hook to all the cameras is a big job. Since raw doesn't require the while file write hook task, the final version should do raw for all cams, and the ifdef should just apply to the parts that require the filewritetask hook. This implies some way of checking which are available, preferably without trying to take a shot.
- the chdkptp side should expose the individual steps to lua. I can certainly understand doing it the way you are now for testing though, and assuming the CHDK code gets added, I can work on that part.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #829 on: 23 / August / 2012, 14:32:16 »
I probably won't get a chance to look at it in detail before the the weekend.
No problem. There is no hurry.
Quote
the final version should do raw for all cams, and the ifdef should just apply to the parts that require the filewritetask hook.
Good idea.
Quote
This implies some way of checking which are available, preferably without trying to take a shot.
Perhaps it could be part of some sort of "capabilities" request.
Quote
- the chdkptp side should expose the individual steps to lua. I can certainly understand doing it the way you are now for testing though, and assuming the CHDK code gets added, I can work on that part.
Well, I had the feeling that the huge ptp_chdk_remoteshoot() in ptp.c is not really appropriate :)

update2: v2 patches, support for RAW retrieval over PTP on cameras without the FileWriteTask hook (cam saves local jpeg, RAW still doesn't contain metadata)
chdkptp side: started to implement those "individual steps", top level lua logic is missing
RemoteCaptureInit now signals success or failure (needed because of cameras with partial support)
« Last Edit: 26 / August / 2012, 12:42:37 by srsa_4c »

 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal