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

CHDK PTP interface

  • 1240 Replies
  • 424793 Views
Re: CHDK PTP interface
« Reply #630 on: 11 / February / 2012, 16:41:33 »
Advertisements
http://chdk.wikia.com/wiki/Release_Strategy#Roadmap
This would be less embarrassing if my nick was not there in the revision history ...
Ported :   A1200    SD940   G10    Powershot N    G16

Re: CHDK PTP interface
« Reply #631 on: 11 / February / 2012, 18:03:01 »

The live view stuff is completely disabled in in the CHDK release branch, to avoid having an under development protocol "released". There is some of this code in the trunk, I don't know if it is compatible with whatever version of CHDKPTPRemote you are trying to use.


Thank you reyalp !

Okay, so if I understand it right, the device's code matching the expectations of CHDKPTPRemote is in the developper edition of CHDK, and should appear in the trunk once the two of them are merged, as it has recently been meant in this topic : http://chdk.setepontos.com/index.php?topic=7601.0

Excellent ! I'll wait a bit then, no need to reinvent the wheel.   :P

*

Offline reyalp

  • ******
  • 13792
Re: CHDK PTP interface
« Reply #632 on: 11 / February / 2012, 18:55:48 »
Okay, so if I understand it right, the device's code matching the expectations of CHDKPTPRemote is in the developper edition of CHDK,
I'm not sure, there was some back and forth. In any case, existing builds will probably not be compatible with the final live view protocol.
Quote
and should appear in the trunk once the two of them are merged, as it has recently been meant in this topic : http://chdk.setepontos.com/index.php?topic=7601.0
That thread is discussing merging CHDKDE and the CHDK trunk. It looks like that stuff never made it into CHDK, but I'm not sure. Unless someone continues development of CHDKPTPRemote, then it will probably not be compatible with any future version of CHDK. If you want, you can try building the trunk build with chdkshell and see if it works.

It is my intention to support live view in chdkptp. Actually, that's the first step for me to be able to get back to working on the CHDK side. The need to create and maintain a client is one of the things that has slowed down the development of this feature (another thing: my stubbornness and lack of time. Sorry :().

The bottom line is this feature isn't done. There is no "supported" build with live view and a matching client. If you are willing and able to do some hacking and digging through old threads, you may be able to get something working for your specific camera and desired use. Or not...
Don't forget what the H stands for.

Re: CHDK PTP interface
« Reply #633 on: 11 / February / 2012, 23:26:39 »
I'll build and transfer trunk1662 to the A430 I own right now then.

This camera answers quite well to ptpCam & chdkptp, and executes remote Lua flawlessly.
So far, I've used mweerden's C# code to do a step-by-step debug of the LibUsbDotNet calls : his "ptpUtils" class filters the devices by enumerating its ptp-class interface endpoints, and flags the device as "ptp-able" if and only if one of its usb endpoints presents a 512-bytes capacity.
Since the last trunk I tested (1652) didn't have such an endpoint, I came to the conclusion it lacked the specific "live view" handling CHDKPTPRemote was expecting.  ;)

So far, I've used an USB sniffing app to record some USB activity between CHDKPTP (which operates faster than ptpCam) and the A430.  I've done some device-side USB programming some years ago, and it shouldn't be long before I unravel the requests opcode & contents. (I just have to gather the courage to read through all theses journals I've recorded).

Maybe if the "live view" becomes a trunk's asset, I'll look into implementing a unified DLL (.Net and Mono) for everyone to control them easily via C# or VB code. I need it for automation vision anyway  :P, so me making it "generic" would be a good idea. I'd love to feed a GPU's pixel shader with a kick-arse bitmap freshly grabbed from a Canon camera.
Digital camera are way much more adequate for vision purposes than crappy 768p webcams and their recurring pixel noise  :(, always requiring their lenses seriously hacked in the "aperture" department  :haha.

« Last Edit: 11 / February / 2012, 23:30:13 by asmodyne »


*

Offline reyalp

  • ******
  • 13792
Re: CHDK PTP interface
« Reply #634 on: 12 / February / 2012, 00:14:20 »
So far, I've used mweerden's C# code to do a step-by-step debug of the LibUsbDotNet calls : his "ptpUtils" class filters the devices by enumerating its ptp-class interface endpoints, and flags the device as "ptp-able" if and only if one of its usb endpoints presents a 512-bytes capacity.
This sounds to me like it's unrelated to CHDK protocol issues. It may be that mweerden just assumed all cameras would support that. CHDK doesn't see or change that kind of stuff on the camera, it just responds to certain a specific PTP commands. Setting up the endpoints would all be done by the Canon firmware. I'd suggest just changing his code to skip that check...

Quote
Maybe if the "live view" becomes a trunk's asset, I'll look into implementing a unified DLL (.Net and Mono) for everyone to control them easily via C# or VB code. I need it for automation vision anyway  :P, so me making it "generic" would be a good idea. I'd love to feed a GPU's pixel shader with a kick-arse bitmap freshly grabbed from a Canon camera.
If you can come up with shaders that efficiently transform the live view YUV format and paletted bitmap into something suitable to display, that could be very useful.
Don't forget what the H stands for.

Re: CHDK PTP interface
« Reply #635 on: 12 / February / 2012, 09:50:30 »

This sounds to me like it's unrelated to CHDK protocol issues. It may be that mweerden just assumed all cameras would support that. CHDK doesn't see or change that kind of stuff on the camera, it just responds to certain a specific PTP commands. Setting up the endpoints would all be done by the Canon firmware. I'd suggest just changing his code to skip that check...


Obviously, I didn't start from the right angle with mweerden's code.
So I'lll stick to chdkptp's implementation (even though it's a mix of C and Lua, which confuses me a lot  :-X ).
I should to rethink my approach an start from a PTP standard implementation, just as you did whith ChdkPtp.

Re: CHDK PTP interface
« Reply #636 on: 12 / February / 2012, 11:37:01 »
I've used an USB sniffing app to record some USB activity

Can you give more details of that, I need it to solve a problem ?

Quote
Digital camera are way much more adequate for vision purposes than crappy 768p webcams

Well, LiveView is 320x240.

Quote
I'd love to feed a GPU's pixel shader with a kick-arse bitmap freshly grabbed from a Canon camera.

You cannot grab a bitmap, just the low-resolution YUV viewfinder image or a raw image (at far slower frame-rate) that needs converting to bitmap.
The raw image (especially at wide angle) has very large lens distortions, not exactly suitable for machine vision unless individually calibrated.

I convert the viewfinder YUV image to bitmap for capture and display.







*

Offline srsa_4c

  • ******
  • 4450
Re: CHDK PTP interface
« Reply #637 on: 12 / February / 2012, 14:41:52 »
For clarification.
Digital camera are way much more adequate for vision purposes than crappy 768p webcams

Well, LiveView is 320x240.
No. :) 360x240 is the resolution CHDK works with (at least this was the case a few months ago).
Liveview's real resolution depends on many factors. The real resolution you usually get is 720x240. If you plug something into the TV-out socket, it will be reduced to 704x240.
At least a few DIGIC II cameras supply much greater vertical resolution when in VGA movie mode (the A430 for example provides 720x568 at a framerate of 10fps). The S80 is the only DIGIC II model with greater-than-SD movie resolution, don't know what happens there (but that port is lost anyway). I also have no idea what happens in new models where a HDMI connection is available. When not in record mode, the YUV buffers usually provide greater vertical resolution (at least when TV-out is used).

http://chdk.wikia.com/wiki/Frame_buffers
« Last Edit: 12 / February / 2012, 14:49:09 by srsa_4c »


Re: CHDK PTP interface
« Reply #638 on: 12 / February / 2012, 15:12:16 »

Quote
Digital camera are way much more adequate for vision purposes than crappy 768p webcams

Well, LiveView is 320x240.

My point is : 240p 5/4r is perfect for live feed vision processing BUT you can snap a shot anytime in a much, much higher resolution, then pass it to a more advanced processing stage, when you vision app needs it.


Quote
I'd love to feed a GPU's pixel shader with a kick-arse bitmap freshly grabbed from a Canon camera.

You cannot grab a bitmap, just the low-resolution YUV viewfinder image or a raw image (at far slower framerate) that needs converting to bitmap.
The raw image (especially at wide angle) has very large lens distortions, not exactly suitable for machine vision unless individually calibrated.

I convert the viewfinder YUV image to bitmap for capture and display.

Yes, that's exactly the point of using a pixel shader here : process a large amount of raw data (YUV), apply some color matrix transformation using the GPU, and, if the lens's artifacts requires it, use a geometric matrix transformation to obtain a corrected picture.

As regards the framerate : the point is to have a high-resolution RAW or DNG snapshot on-demand, without using jpeg files (and more artifacts), but nothing like some live 30fps Utra-HD feed that would melt our GPU down. By the way, I doubt any baseline GPU could process a 10MP picture without us having to split it into smaller parts beforehand, and reassemble the output once processed.
My hopes, initially, were to achieve a 1fps or 2fps framerate. Let's face it : doing so with an off-the-shelf deprecated camera and an open-source hack would be a feat in itself.
« Last Edit: 12 / February / 2012, 15:13:49 by asmodyne »

Re: CHDK PTP interface
« Reply #639 on: 12 / February / 2012, 15:14:27 »
The real resolution you usually get is 720x240.
that has been the case from the earliest days, GrAnd even posted an image showing it was expanded 2x in width.
It was suggested this might be to give better results when interpolated to 360x240.
It is not really 'resolution'.

 

Related Topics