CHDK PTP interface - page 74 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 69 70 71 72 73 [74] 75 76 77 78 79 ... 125   Go Down

CHDK PTP interface

  • 1241 Replies
  • 489806 Views
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: CHDK PTP interface
« Reply #730 on: 29 / February / 2012, 16:11:27 »
Advertisements
Quote from: asmodyne on 29 / February / 2012, 15:54:13
I'm pretty sure that passing a 320x240 P-buffer to and OpenGL's 640x480 viewport would make your card's OpenGL driver implementation do the interpolation automatically

The viewport image is 720x240 or 360x240 (3:2 aspect-ratio not the correct 4:3).

Quote
It's all INTEGERS magic ! No floating arithmetic here ! (^w^)

Yes, the thought of software floating point is what has put me off writing interpolation code.

I guess everything could be scaled-up by a 1000x or so.
Logged
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #731 on: 29 / February / 2012, 16:23:36 »
Quote from: Microfunguy on 29 / February / 2012, 16:11:27
The viewport image is 720x240 or 360x240 (3:2 aspect-ratio not the correct 4:3).

Viewport's dimension are irrelevant in this case, since you're working in windowed mode.
You can even use a 551 wide per 777 heigh viewport, FWIW, openGL won't care as long as you'r not in fullscreen mode.
Things made short : powers of two are only required in fullscreen.

Quote from: Microfunguy on 29 / February / 2012, 16:11:27
Yes, the thought of software floating point is what has put me off writing interpolation code.

I'm with you 100% on that. Whatever the CPU is. Only recent (less than 5 years I guess) GPUs can handle such floating-point workloads.

Quote from: Microfunguy on 29 / February / 2012, 16:11:27
I guess everything could be scaled-up by a 1000x or so.
Waddayamean ?  :blink:
Logged
*

Offline reyalp

  • ******
  • 14080
Re: CHDK PTP interface
« Reply #732 on: 29 / February / 2012, 16:26:30 »
Quote from: asmodyne on 29 / February / 2012, 16:23:36
Viewport's dimension are irrelevant in this case, since you're working in windowed mode.
You can even use a 551 wide per 777 heigh viewport, FWIW, openGL won't care as long as you'r not in fullscreen mode.
You aren't following. In CHDK, we call the camera live view (view finder image or display of selected jpeg/avi in playback mode) the "viewport". This has specific fixed dimensions, aspect ratio etc, and is completely unrelated to the opengl concept of a viewport.
Logged
Don't forget what the H stands for.
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: CHDK PTP interface
« Reply #733 on: 29 / February / 2012, 17:47:10 »
Quote from: asmodyne on 29 / February / 2012, 15:54:13
have a look at those hqNx filters

"The filter was not designed for photographs, but for images with clear sharp edges, like line graphics or cartoon sprites.
 It was also designed to be fast enough to process 256x256 images in real-time."
Logged
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #734 on: 29 / February / 2012, 19:19:28 »
Quote from: reyalp on 29 / February / 2012, 16:26:30
Quote from: asmodyne on 29 / February / 2012, 16:23:36
Viewport's dimension are irrelevant in this case, since you're working in windowed mode.
You can even use a 551 wide per 777 heigh viewport, FWIW, openGL won't care as long as you'r not in fullscreen mode.
You aren't following. In CHDK, we call the camera live view (view finder image or display of selected jpeg/avi in playback mode) the "viewport". This has specific fixed dimensions, aspect ratio etc, and is completely unrelated to the opengl concept of a viewport.
Sorry, I realize I wasn't explaining myself correctly.  :-X
My point is : OpenGL or DirectX device frame buffer can be instantiated with a 720x240 resolution, and recklessly be presented on a 333x999 surface (with deformation, that goes without saying). It's up to the graphic card's driver implementation to make it happen, or to OpenGL's software emulation, if your card's driver gives up on this kind of task (which should be quite rare these days).
Need an example : try some old DirectX 9.0c SDK tutorials : you can resize the presenting window without even having DirectX firing an event about frame buffer resizing.
But, if you present a pixel buffer directly to a rendering surface, that's another story : the presentation stage is no more transparent to you, since you affect the rendering surface directly, with your own pixel data.
Fwiw, as I said earlier in a post-scriptum, recent OpenGL developments added those "frame buffer objects", making the implementation of OpenGL client app totally device independent, unlike P-buffers.

Quote from: Microfunguy on 29 / February / 2012, 17:47:10
"The filter was not designed for photographs, but for images with clear sharp edges, like line graphics or cartoon sprites.
 It was also designed to be fast enough to process 256x256 images in real-time."
Aaaawww... Too bad then. It was a good alternative to nearest-neighbor scaling, without having to use floating-point arithmetic though.
« Last Edit: 29 / February / 2012, 19:21:48 by asmodyne »
Logged
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #735 on: 29 / February / 2012, 22:42:04 »
Quote from: Microfunguy on 29 / February / 2012, 17:47:10
"The filter was not designed for photographs, but for images with clear sharp edges, like line graphics or cartoon sprites.
 It was also designed to be fast enough to process 256x256 images in real-time."

I tested hq2x against nearest neighbor using nstatic's short videoclip (post 81548 of this very topic).

The result is more than crappy. Luminance gradients gets blocky, while chroma is shifted in unpredictable directions.  :o I almost had the impression to watch early days NTSC.
*sigh*
I had good hope this algorithm would give good result when resizing small frames in real time...
Oh well...There's plenty of other fishes in the sea.
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #736 on: 29 / February / 2012, 23:23:21 »
Quote from: reyalp on 29 / February / 2012, 15:45:24
However, to get nice video you'd also have to somehow synchronize the frame grabs with the camera refresh, or you get tearing.
You may want to look at sub_ffc95b68 in A540. This function is used by MovieRecordTask to install and remove (frame notification and information) hooks into the liveview code.
LiveImageTool.Pause / LiveImageTool.Resume may also help to fight tearing (don't know what happens when these are called many times per second) when the USB transfer is not fast enough.
Of course LiveView will probably stop in review/play mode.
edit:
Some notes / comments related to the routine(s) I wrote about above, in the A420: http://chdk.setepontos.com/index.php?topic=7067.msg76126#msg76126
edit2:
During my experiments with saving uncompressed/compressed images from the live buffers I haven't used any synchronization. By choosing the buffer address vid_get_viewport_live_fb() provided I got tearing in a relatively high % of the pictures. When I chose another buffer address (by subtracting 2 instead of 1 from buff), the tearing disappeared. This was on the A420 in its 10fps video mode, pictures were saved to the SD card.
Models with USB 1.1: Ixus30/SD200, Ixus40/SD300, A410 ... A470 (As USB is handled directly by the DIGIC, this is a configuration issue...)
All other CHDK-supported cameras are hi-speed USB 2.0 .
« Last Edit: 03 / March / 2012, 21:04:29 by srsa_4c »
Logged
*

Offline reyalp

  • ******
  • 14080
Re: CHDK PTP interface
« Reply #737 on: 29 / February / 2012, 23:49:15 »
Quote from: asmodyne on 29 / February / 2012, 22:42:04
I had good hope this algorithm would give good result when resizing small frames in real time...
Honestly, I don't think this is anything that we have to worry about for any vaguely recent PC.

Getting back to some more CHDK specific stuff, a couple more observations
- On a540 and d10 digital zoom changes the height of the viewport buffer, more zoom=less lines.
- On a540, the width doesn't change, while on d10, the highest zoom is half width
- I've confirmed with both cameras that recreview mode uses the wrong viewport addresses, as reported by webguy here http://chdk.setepontos.com/index.php?topic=6231.msg81993#msg81993
Logged
Don't forget what the H stands for.
*

Offline asmodyne

  • **
  • 50
CHDK PTP interface - lightweight frame descriptor
« Reply #738 on: 11 / March / 2012, 18:51:20 »
So reyalp...

Do you have any news about the way you transfer frames buffer descriptors in your modified trunk, or are those still included in each frame ?

« Last Edit: 11 / March / 2012, 18:53:33 by asmodyne »
Logged
*

Offline reyalp

  • ******
  • 14080
Re: CHDK PTP interface
« Reply #739 on: 11 / March / 2012, 18:58:34 »
Quote from: asmodyne on 11 / March / 2012, 18:51:20
Do you have any new about the way you transfer frames buffer descriptors in your modified trunk, or are those still included in each frame ?
I have not changed that yet. You can see all changes in that branch here: http://trac.assembla.com/chdk/log/branches/reyalp-ptp-live

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'm at a point where the client is working well enough to get into that, I just need a large block of free time to work on it. I didn't end up having that this weekend, maybe the next one...
Logged
Don't forget what the H stands for.
Pages: 1 ... 69 70 71 72 73 [74] 75 76 77 78 79 ... 125   Go Up
« previous next »
 

Related Topics