CHDK PTP interface

asmodyne

50

Re: CHDK PTP interface

« Reply #740 on: 13 / March / 2012, 22:20:08 »

Advertisements

Okay. Perfect then, it will give me time to catch up with your work.
So far, I've implemented every PTP command from the PIMA15740-2000 white papers.
The only things remaining are the events on the interrupt pipe I'll have to encapsulate somehow (I cannot leave tens of those firing raw PTP events to users, it have to be coherent to the "Device" object I implemented).

As soon as this is done, I'll dig into your C code in order to understand the structure of the raw frame's header, and how you use it in you decoding function. Everything is in your sources, so I wouldn't have any problem finding it.
I'll test in with the A430 first, and then switch to the A2000IS (I've replaced the optics, it's working now, yay !

) for further "high" fps tests.

Logged

reyalp

14080

Re: CHDK PTP interface

« Reply #741 on: 13 / March / 2012, 22:54:49 »

Quote from: asmodyne on 13 / March / 2012, 22:20:08

Okay. Perfect then, it will give me time to catch up with your work.
So far, I've implemented every PTP command from the PIMA15740-2000 white papers.
The only things remaining are the events on the interrupt pipe I'll have to encapsulate somehow (I cannot leave tens of those firing raw PTP events to users, it have to be coherent to the "Device" object I implemented).

Note that for CHDK, you don't need most of this. We don't use events (don't know how to do them on the camera end), and we don't rely on any non-CHDK commands outside of those needed to set up a session. Having the standard PTP could be useful of course, just saying they aren't required.

Quote

As soon as this is done, I'll dig into your C code in order to understand the structure of the raw frame's header, and how you use it in you decoding function. Everything is in your sources, so I wouldn't have any problem finding it.

The header is currently defined in live_view.h in my branch of the chdk source. The decoding stuff is in liveimg.c in chdkptp. Various header fields are also used in several places in the lua code, since it is responsible for figuring out the final dimensions to render.

Logged

Don't forget what the H stands for.

asmodyne

50

Re: CHDK PTP interface

« Reply #742 on: 14 / March / 2012, 10:02:13 »

Quote from: reyalp on 13 / March / 2012, 22:54:49

Quote from: asmodyne on 13 / March / 2012, 22:20:08
The only things remaining are the events on the interrupt pipe I'll have to encapsulate somehow...
Note that for CHDK, you don't need most of this. We don't use events (don't know how to do them on the camera end), and we don't rely on any non-CHDK commands outside of those needed to set up a session. Having the standard PTP could be useful of course, just saying they aren't required.

I know they aren't used by the CHDK extension.
I simply though that having some events like "Object Added" (after you called the "Shoot()" script) , "Canceltransaction" (for committing the cancellation of a large transfer) or "DevicePropchanged" (when modifying the capture size) would be a great asset, even for applications relying on CHDK extensions.
Fact is, those events aren't mandatory in the PTP conformance section of PIMA15740, but It appears Canon implemented them on cameras as "primitive" as the A430.
Thus, I'm implementing their reception.

Logged

asmodyne

50

Re: CHDK PTP interface

« Reply #743 on: 14 / March / 2012, 10:15:03 »

Oh, I've just stumbled on this article about Bayer mosaics and pixel shaders.
It's very relevant to what live view requires (and what we're looking for). Here :

http://openendedgroup.com/field/wiki/GigECamerasAndField

Logged

philmoz

3450

Re: CHDK PTP interface

« Reply #744 on: 14 / March / 2012, 15:42:27 »

Quote from: asmodyne on 14 / March / 2012, 10:15:03

Oh, I've just stumbled on this article about Bayer mosaics and pixel shaders.
It's very relevant to what live view requires (and what we're looking for). Here :

http://openendedgroup.com/field/wiki/GigECamerasAndField

Live view uses the viewport frame buffer which is generated from the sensor data by the camera, not the raw sensor data itself.
This is much lower resolution (e.g. 720x240) and in a YUV encoded format - so bayer de-mosaicing is not needed. See http://en.wikipedia.org/wiki/YUV.

Even if you could transfer the the raw sensor data you would be lucky to get 1 frame every 5 seconds over USB.

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

asmodyne

50

Re: CHDK PTP interface

« Reply #745 on: 15 / March / 2012, 12:44:23 »

Quote from: philmoz on 14 / March / 2012, 15:42:27

Even if you could transfer the the raw sensor data you would be lucky to get 1 frame every 5 seconds over USB.
Phil.

Eeeyup, but as I said somewhere in this thread, using shaders here isn't about framerate, it's for quick image data preparation, for futher use : One would appreciate from the client library to provide quick convolution filters on large stills. And GPU shaders are the faster way to achieve it nowadays.
That's why I plan on using GLSL for this: Shaders-processed filters for big stills. Using it to decode Bayer mosaic frames or translate YUV to RGB bitmaps is just gravy. But I love gravy.

By the way, since OpenGL is already usable to present the live view frames in CHDKPTP, having some minds to dig into the GLSL option isn't such a bad idea.

« Last Edit: 15 / March / 2012, 12:47:46 by asmodyne »

Logged

Microfunguy

4037

Re: CHDK PTP interface

« Reply #746 on: 15 / March / 2012, 12:56:49 »

Quote from: asmodyne on 15 / March / 2012, 12:44:23

One would appreciate from the client library to provide quick convolution filters on large stills. And GPU shaders are the faster way to achieve it nowadays.
That's why I plan on using GLSL for this: Shaders-processed filters for big stills.

So, your PC is connected (probably indoors) to a camera and via PTP and your code you have LiveView.

What then ?

I am just curious, is this an abstract programming excercise or does it have some practical use ?

Logged

asmodyne

50

Re: CHDK PTP interface

« Reply #747 on: 15 / March / 2012, 13:00:17 »

Quote from: reyalp on 11 / March / 2012, 18:58:34

Most information is transferred every frame, because it can (on some cameras at least) change at any time. Future versions will most likely put more (possibly everything) in the per frame information.

I know this will sound dumb (well, I am !), but I'm wondering... what's actually changing ?

Is it the color palette ? Or varying viewport offsets ?
And what is causing this change exactly ?

Logged

Microfunguy

4037

Re: CHDK PTP interface

« Reply #748 on: 15 / March / 2012, 13:17:23 »

Quote from: asmodyne on 15 / March / 2012, 13:00:17

I know this will sound dumb

Not really.

I have been dealing with older cameras and very little changes.
Camera can be in Record or Playback which will affect the palette.
On newer cameras, the bitmap overlay can have various formats and the displayed image can be in various resolutions.

In movie mode, on my A620 at least, the displayed image is just a distorted part of the full image.

« Last Edit: 15 / March / 2012, 14:42:21 by Microfunguy »

Logged

asmodyne

50

Re: CHDK PTP interface

« Reply #749 on: 15 / March / 2012, 13:39:56 »

Quote from: Microfunguy on 15 / March / 2012, 12:56:49

Quote from: asmodyne on 15 / March / 2012, 12:44:23
One would appreciate from the client library to provide quick convolution filters on large stills. And GPU shaders are the faster way to achieve it nowadays.
That's why I plan on using GLSL for this: Shaders-processed filters for big stills.

So, your PC is connected (probably indoors) to a camera and via PTP and your code you have LiveView.

What then ?

I am just curious, is this an abstract programming excercise or does it have some practical use ?

Hahaaaaaa ! At last, THE question.

me gusta !
The practical advanced uses of CHDK ptp extensions are, i.m.o. , in the still vision application.
It all relies on two functionalities :

Liveview, (or anything faster than a regular capture) is obviously used for human real-time control and scene preparation and/or rough alignment of the camera's target. It also can be used to achieve changes detection, in a quick integrator stage. The virtually low resolution and fast acquisitions are ideal for motion detection/scenery changes.
Full-resolution captures allows differentiators (such as Sobel/Canny edge detection) to operate on a much more detailed source than regular CCTV devices or highly-priced webcams.

That being said, having these two functionalities reunited in a single device makes CHDKPTP a perfect stepping stone in order to create the poor man's high-end vision solution.

I can envision multiple application to it for myself, such as defect search on a machined workpiece, PCB
analysis, SMD components placement, etc. And that's only my area of expertise.
A biologist could use it for microbial cultures analysis, when population growth rates / environment interactions would require a recent camera's high resolution, but a PC's workload to do the stats.

It's all about enthusiasm, my fair Microfunguy.

And CHDKPTP gives me aplenty !

Quote from: Microfunguy on 15 / March / 2012, 13:17:23

Camera can be in Record or Playback which will affect the palette.
In Playback, depending on the display option, you may only see a small image top left, you will not see shooting info or histograms.

On newer cameras, the bitmap overlay can have various formats and the displayed image can be in various resolutions.

In movie mode, on my A620 at least, the displayed image is just a distorted part of the full image.

Sooooo... you're saying the frames headers are only changing along with the camera's operating modes, or from one device to another. That's....pretty much expected, isn't it ?

Logged