CHDK PTP interface

Microfunguy

I am using SDM which behaves rather differently to CHDK.

After the shutter has been pressed the raw data and a header file are immediately sent to the PC without saving on the camera.

That process is quite fast depending on file size and card speed.

The memory card should have been low-level formatted in the camera beforehand, as recommended by Canon.

On the PC, they are converted to a DNG file.

The JPG left on the camera is tiny, only about 10k (!) and is instantly deleted.

I do not know how the other PTP clients deal with this.

David

andyroo

I have a question about getting the Lua console to run on ptpcamgui. I have tried on two computers (Win7x32 and Win7x64) with two cameras (SX220HS and SX30) to run the lua console, and it freezes ptpcamgui. I resorted to using CHDKPTP to communicate in lua with the cameras and it works fine, but I would like to have the functionality in ptpcamgui since it's so useful for everything else.

After the freeze (spinny wheel, prog not responding) if I close ptpcamgui then ptpcam is still working in task manager. I am wondering if I missed something as far as how it works. Here's my info from the PTPCAM console:

** init() start ...
>> version << ptpcam: 2.0
camera: 2.1 (Length: 24)
>> script-support << script-support:0x1 lua=yes (Length: 26)
>> luar not(os.stat("A/CHDK/LUALIB/lptpgui.lua")==nil) << script:15
15:ret:true (Length: 22)
>> luar require("lptpgui").version << script:16
16:ret:113 (71) (Length: 26)
>> luar get_buildinfo() << script:17
17:ret:'platformid	12816
platform	sx30
version	CHDK
platsub	100p
build_number	0.9.9-1487
os	dryos
build_date	Dec 15 2011
build_time	10:13:08
' (Length: 161)
is DryOS=True
CHDK-DE=False
>> luar get_config_value(67) << script:18
18:ret:1 (1) (Length: 23)
current powersave mode: 1
>> luar get_raw() << script:19
19:ret:0 (0) (Length: 23)
>> help << q quit                         quit program
h help                         list commands
r reset                        reconnect to camera
  version                      get CHDK PTP version (ptpcam and camera)
  shutdown                     shutdown camera (soft)
  reboot                       reboot camera
  reboot <filename>            reboot camera using specified firmware update
  reboot-fi2                   reboot camera using default firmware update
m memory <address>             get byte at address
m memory <address>-<address>   get bytes at given range
m memory <address> <num>       get num bytes at given address
  set <address> <long>         set long value at address
c call <address> <arg1> ...    call function at address with given arguments
  upload <local> <remote>      upload local file to camera
  download <remote> <local>    download file from camera
  mode <val>                   set mode (0=playback,1=record)
  lua <code>                   execute lua code
  luar <code>                  execute "return <code>" and retreive result
  script-support               show supported script interfaces
  script-status                show script execution and message status
  getm                         get messages / return values from script
  putm <message>               send <message> to running script (Length: 1359)
* enable keys for GUI control: >> lua post_levent_to_ui(4484) << script:20 (Length: 9)
>> script-status << script-status:0x0 run=no msg=no (Length: 31)
** init() successful

msl

Btw,

is there any reason why we not activate the PTP support for all cameras in camera.h?

msl

reyalp

msl
Btw,

is there any reason why we not activate the PTP support for all cameras in camera.h?

It is in CHDK.

msl

reyalp
It is in CHDK.

Thx.

You're right. Sorry, I haven't seen the entry. So we can delete all entries in the platform_camera.h files for a better overview.

msl

reyalp

msl
You're right. Sorry, I haven't seen the entry. So we can delete all entries in the platform_camera.h files for a better overview.

Yes 😀

asmodyne

Hello lads !

Knowing we've just hit trunk1654, may I ask if the ptp handlers & usb descriptors are implemented generically, or does each platform (already ported) needs its own implementation of the CHDK ptp extension to enable live preview with mweerden's .Net app ?

I'm trying to establish some communication between mweerden's CHDKPTPRemote and an A430 (which is currently-ish being ported), but since the app seems to be designed for overlaid previews, it asks for a 512-bytes-capable PTP-class endpoint, which clearly isn't implemented in the current A430 port [1] ...hence my previous question. 😳

Since I'm a newbie of the most blueish kind, I guess the implementations I'm talking about may be a CHDK-DE "exclusivity"... aren't they ? ???

Thanks, and best regards. 😀

[1] I haven't seen anything like it when enumerating the A430's PTP interface descriptors. 😉

reyalp

asmodyne
Hello lads !

Knowing we've just hit trunk1654, may I ask if the ptp handlers & usb descriptors are implemented generically, or does each platform (already ported) needs its own implementation of the CHDK ptp extension to enable live preview with mweerden's .Net app ?

This question doesn't really make sense to me.

CHDK PTP protocol has certain commands. These are supported generically in CHDK code. A build for any camera should be compatible with with any CHDK PTP client implementing the matching protocol version. You don't need to worry about handlers and descriptors... although I suppose it's possible that the a430 is old enough that it's weird in some way. If you can upload/download with chdkptp or ptpcamgui, then CHDK PTP is implemented and working properly. Neither one will give you live view however.

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.

Properly supporting live view is on the list for the next release, but is not finished. The protocol will likely change from whats in the trunk. I keep meaning to do some work on this Real Soon Now. Maybe this weekend...

waterwingz

reyalp
Properly supporting live view is on the list for the next release ...

List ? There's a list ?

reyalp

waterwingz

reyalp
Properly supporting live view is on the list for the next release ...

List ? There's a list ?

http://chdk.wikia.com/wiki/Release_Strategy#Roadmap

waterwingz

reyalp
http://chdk.wikia.com/wiki/Release_Strategy#Roadmap

This would be less embarrassing if my nick was not there in the revision history ...

asmodyne

reyalp

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 : https://chdk.setepontos.com/d/7601

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

reyalp

asmodyne
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.

and should appear in the trunk once the two of them are merged, as it has recently been meant in this topic : https://chdk.setepontos.com/d/7601

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

asmodyne

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 😛, 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 🤣.

reyalp

asmodyne
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...

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 😛, 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.

asmodyne

reyalp

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 😖 ).
I should to rethink my approach an start from a PTP standard implementation, just as you did whith ChdkPtp.

Microfunguy

asmodyne
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 ?

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

Well, LiveView is 320x240.

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.

srsa_4c

For clarification.

Microfunguy

asmodyne
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

asmodyne

Microfunguy

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.

Microfunguy

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.

Microfunguy

srsa_4c
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'.

« Previous Page Next Page »