CHDK PTP interface - page 64 - General Discussion and Assistance - CHDK Forum
supplierdeeply
« previous next »
Pages: 1 ... 59 60 61 62 63 [64] 65 66 67 68 69 ... 125   Go Down

CHDK PTP interface

  • 1241 Replies
  • 487557 Views
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: CHDK PTP interface
« Reply #630 on: 11 / February / 2012, 16:41:33 »
Advertisements
Quote from: reyalp on 11 / February / 2012, 16:09:45
http://chdk.wikia.com/wiki/Release_Strategy#Roadmap
This would be less embarrassing if my nick was not there in the revision history ...
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #631 on: 11 / February / 2012, 18:03:01 »
Quote from: reyalp on 11 / February / 2012, 00:35:20

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
Logged
*

Offline reyalp

  • ******
  • 14079
Re: CHDK PTP interface
« Reply #632 on: 11 / February / 2012, 18:55:48 »
Quote from: asmodyne on 11 / February / 2012, 18:03:01
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...
Logged
Don't forget what the H stands for.
*

Offline asmodyne

  • **
  • 50
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 »
Logged
*

Offline reyalp

  • ******
  • 14079
Re: CHDK PTP interface
« Reply #634 on: 12 / February / 2012, 00:14:20 »
Quote from: asmodyne on 11 / February / 2012, 23:26:39
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.
Logged
Don't forget what the H stands for.
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #635 on: 12 / February / 2012, 09:50:30 »
Quote from: reyalp on 12 / February / 2012, 00:14:20

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.
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: CHDK PTP interface
« Reply #636 on: 12 / February / 2012, 11:37:01 »
Quote from: asmodyne on 11 / February / 2012, 23:26:39
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.






Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #637 on: 12 / February / 2012, 14:41:52 »
For clarification.
Quote from: Microfunguy on 12 / February / 2012, 11:37:01
Quote from: asmodyne on 11 / February / 2012, 23:26:39
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 »
Logged
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #638 on: 12 / February / 2012, 15:12:16 »
Quote from: Microfunguy on 12 / February / 2012, 11:37:01

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 from: Microfunguy on 12 / February / 2012, 11:37:01

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 »
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: CHDK PTP interface
« Reply #639 on: 12 / February / 2012, 15:14:27 »
Quote from: srsa_4c on 12 / February / 2012, 14:41:52
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'.
Logged
Pages: 1 ... 59 60 61 62 63 [64] 65 66 67 68 69 ... 125   Go Up
« previous next »
 

Related Topics