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

CHDK PTP interface

  • 1241 Replies
  • 488836 Views
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: CHDK PTP interface
« Reply #640 on: 12 / February / 2012, 15:17:19 »
Advertisements
Quote from: asmodyne on 12 / February / 2012, 15:12:16
process a large amount of raw data (YUV)

The raw data is not YUV, that is just the viewfinder image.
Logged
*

Offline asmodyne

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

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


Sorry, I almost forgot : I used the 15-days USBTrace trial.

Here : http://bit.ly/wTfIKf

Raw data, YUV, YCrBr, CMYN, whatever.... color matrix lad, co.lor.  maaa.trix .   :D
Here's what I'm talking about : http://www.fourcc.org/source/YUV420P-OpenGL-GLSLang.c
Do it with YUV, you also apply the same modus operandi once you know how to transform from one color space to another. Implement it in HSLS, the shader will do the rest.
« Last Edit: 12 / February / 2012, 15:23:46 by asmodyne »
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: CHDK PTP interface
« Reply #642 on: 12 / February / 2012, 15:32:28 »
So, what matrix will you use to convert raw data to a colour space, see line 219 here http://trac.assembla.com/chdk/browser/trunk/core/raw.c.

It is raw sensor data.
Logged
*

Offline reyalp

  • ******
  • 14080
Re: CHDK PTP interface
« Reply #643 on: 12 / February / 2012, 15:49:28 »
Quote from: Microfunguy 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'.
Luminance resolution is 720. U/V is 160!

Quote from: asmodyne on 12 / February / 2012, 15:19:43
Raw data, YUV, YCrBr, CMYN, whatever.... color matrix lad, co.lor.  maaa.trix .   :D
Raw data = bayer 10 or 12 bit RGB. Different animal. But you can't get that at any reasonable speed. Downloading a 18mb raw file from my D10
Code: [Select]
con 1> !cli.showtime=true
time 0.0000
con 1> d -nolua DCIM/100CANON/CRW_0714.CRW
time 4.4093
Taking the SD card out of the equation would help a bit, but not enough, I think...
Logged
Don't forget what the H stands for.
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #644 on: 12 / February / 2012, 16:19:16 »
Quote from: Microfunguy on 12 / February / 2012, 15:32:28
So, what matrix will you use to convert raw data to a colour space, see line 219 here http://trac.assembla.com/chdk/browser/trunk/core/raw.c.

It is raw sensor data.

I get a "Trac Error , No node /trunk/core/raw.c. at revision 1665".
Logged
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #645 on: 12 / February / 2012, 16:29:36 »
Quote from: reyalp on 12 / February / 2012, 15:49:28

Raw data = Bayer 10 or 12 bit RGB. Different animal. But you can't get that at any reasonable speed. Downloading a 18mb raw file from my D10
Code: [Select]
con 1> !cli.showtime=true
time 0.0000
con 1> d -nolua DCIM/100CANON/CRW_0714.CRW
time 4.4093
Taking the SD card out of the equation would help a bit, but not enough, I think...

Fact is, I'm not planning to retrieve RAW data, it was Microfunguy who brought it in the conversation.  :-X As long as I manage to get picture data, whatever the encoding is (being intertwined bayer or not) without relying on an extraneous jpg compression and file exchange, I'm good. The only interest we all find in Ptp is powerful chdk remote control, and high definition stills. 8)
 Real view is just gravy, don't you agree ? Although it's always interesting to have a realtime viewfinder somewhere in the client app's corner.  :P
Logged
*

Offline reyalp

  • ******
  • 14080
Re: CHDK PTP interface
« Reply #646 on: 12 / February / 2012, 16:48:04 »
Quote from: asmodyne on 12 / February / 2012, 16:29:36
Fact is, I'm not planning to retrieve RAW data, it was Microfunguy who brought it in the conversation.  :-X As long as I manage to get picture data, whatever the encoding is (being intertwined bayer or not) without relying on an extraneous jpg compression and file exchange, I'm good.
The only other data you can get easily is the live view, which as discussed is quite low resolution. Of course if you want to take an actual exposure, you can get a nice high res jpeg after a small delay ;)

srsa_4c has also done some work with the video buffers, and retrieving the jpeg before it's written to disk.

I highly recommend chdk.wikia.com/wiki/Frame_buffers
Logged
Don't forget what the H stands for.
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #647 on: 12 / February / 2012, 17:00:28 »

Now that you've mentioned it... Having a Bayer components layout would give us a fantastic amount of information for grayscale processing, over RGB .  :-* I love it !
You may know that most edge detection filters (Sobel, Canny) uses grayscale inputs when implemented in the simplest and easyest fashion. And since the BT709 grayscale algorithm I like to use take 71% of its luminance output from the GREEN channel, a Bayer input would be great !

I have to make my generic .Net ptp client DLL work, based on the trunk.

Getting the fresh jpeg out the memory would be great too. But as you said, the file exchange would not make a big difference in the capture duration. We all know the bottleneck is the data exchange here. I wonder how long it takes for the firmware's JPEG codec to compress the raw pic into .jpg .
That's a conundrum :
  • Should we wait for the firmware to encode the jpeg, which, being smaller, is faster to retrieve.
  • Should we grab the frame buffer once the camera has processed its sensor data, if it ever exist sometime in its RAM (the jpeg encoder may process the Bayer data directly, I dunno, that your expertise domain.  :P
  • Should we grab the sensor's data shallow copy directly, having to deal with looooooong transfer time, but lossless pics.

I'll be in touch.
Logged
*

Offline reyalp

  • ******
  • 14080
Re: CHDK PTP interface
« Reply #648 on: 12 / February / 2012, 18:02:23 »
Quote from: asmodyne on 12 / February / 2012, 17:00:28
Should we grab the frame buffer once the camera has processed its sensor data, if it ever exist sometime in its RAM (the jpeg encoder may process the Bayer data directly, I dunno, that your expertise domain.  :P
I'm pretty sure this is the case, I don't think there is a de-bayered version of the image outside of jpeg, with the probable exception of the half res high ISO/fast modes and video.

What exactly the high ISO modes do is unknown (to me at least...) but they don't seem to have a normal bayered raw in the first place. This makes sense, because the reason they are fast is presumably some kind of binning going on early in the pipeline but I don't know what (if any) intermediate format they go into before jpeg.

You could potentially return a sub-sampled version of the raw buffer (e.g. every Nth element) but the CPU is quite slow and you have to do some bit fiddling to extract specific pixels, so depending how much of the buffer you wanted, that might not end up much better than just returning the whole thing.

Quote from: asmodyne on 12 / February / 2012, 16:19:16
I get a "Trac Error , No node /trunk/core/raw.c. at revision 1665".
Try without the period on the end:
http://trac.assembla.com/chdk/browser/trunk/core/raw.c
Logged
Don't forget what the H stands for.
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: CHDK PTP interface
« Reply #649 on: 12 / February / 2012, 18:30:10 »
Quote from: reyalp on 12 / February / 2012, 16:48:04
I'm not planning to retrieve RAW data, it was Microfunguy who brought it in the conversation.  :-X

I rather think you are, unless you prefer the distortion-corrected,nicely colour-rendered JPG's.
Only drawback is white-balance has already been applied.

Before you get too carried away with this can I ask for technical details of the proposed application ?

Based on what existing PTP clients can do (including my own) I cannot see that you need anything special, bearing in mind the constraints mentioned.
Logged
Pages: 1 ... 60 61 62 63 64 [65] 66 67 68 69 70 ... 125   Go Up
« previous next »
 

Related Topics