Which Video card I can choose

[subbiah]

Hello Ribbit and Slougi

The data is coming in RGB Format. size 640x480 - 24 bit.

I have to zoom the data by factor 2 for one monitor and factor 1.28 for another monitor.

The Image Gamma, RGB value correction controls will be displayed in the rest of the area in the screen. According to the controlls, I have to do the image manipulation and display on the screen.

This seems to be complecated. My Professor has given this as project. So now I am little bit scared on the implementation.

Can I convert the 24 bit RGB to YUV and display?. But I wounder YUV is 16 bit?

[Ribbit]

Ouch, you've practically got a worst-case scenario there. I guess that's why they give you the big bucks, uh, marks for working with it. I assume you're writing the software yourself?

Converting RGB to YUV is going to be expensive, so I'd try to avoid doing it if possible.

I see four (theoretical - I'm no X coding wizard) approaches to the scaling problem (assuming you're working under X):

1 - Do it all in software

Pros - if you can make this work, it'll work on any hardware that's fast enough.

Cons - Finding hardware fast enough might be a problem. Most expensive in terms of CPU and bandwidth.


2 - Get the X server to do the scaling

X might (I'm speculating here) have a mechanism where you can put your image in a Pixmap or XImage and have the X server scale it to the screen. Ideally it would be hardware accelerated - the unscaled image would be stored in offscreen memory and scaled by the GPU.

Pros - uses less CPU and bandwidth (if it's accelerated).

Cons - No control over scaling quality. If it's not accelerated, it might use even more CPU/bandwidth than method 1. Might not be possible. If it is possible, it might be part of the XIE extension, which has recently been dropped by X.org.


3 - Use XVideo

Basically the same as method 2, but using the XVideo extension.

Pros - less CPU/bandwidth, scaling quality should be good.

Cons - Cards with RGB video scalers are rare, as are cards with two overlay ports, and you'll need both for this method.


4 - Use OpenGL

Use your image as a texture, and map it onto polygons the size of your image windows. Any 3D AGP card should be able to draw a couple of big textured polygons at 30Hz, even a G200. (Ignore what I said about OpenGL in my earlier post.)

Pros - As method 3, provided it's hardware accelerated.

Cons - The trick will be getting 3D acceleration working on both heads. It can be done on some cards (with limitations) - see http://dri.sourceforge.net/cgi-bin/moin.cgi/MergedFB


You'll have to do some research to see what the right method for you. You may even end up using a hybrid, e.g. OpenGL on first head, XIE on second head.

Hope this helps.

[subbiah]

Thanks Ribbit, I will try the XImage and OpenGL.

Can I display the 24 bit RGB data using XVideo?

I have to make prbe on this angle also.

[Ribbit]

Originally posted by subbiah
Can I display the 24 bit RGB data using XVideo?

Yes, but only if the card (and X driver) support it. I understand most cards don't support this with RGB, they only do it with YUV and similar formats.

[magician]

subbiah, you should check out DirectFB project, 'cause it may offer you solution.

DirectFB is a tiny library which lies over Linux (kernel's) frame buffer and provides hardware graphics acceleration through HAL (hardware abstraction layer).

DirectFB has it's own resource management for video memory and as they state "... provides abstraction for the different graphics targets like display layers, [X] windows and any general purpose surfaces".

Even better news is that DirectFB now has OpenGL extension (DirectFBGL) which provides hardware accelerated rendering through DRI (Direct Rendering Infrastructure).

The only flaw that DirectFB has is lack of graphics drivers, but if you have a Matrox Mystique/Millenium/G100/G200/G400/G450/G550 you are one lucky son of the ***** 'cause those are the best supported cards ever. Their's HW acceleration is rated as 90% only because it lacks 24bit support, which doesn't matter as 32bit works like charm. Bandwidth should not be a problem with AGP cards under any circumstances that relate to your application, so don't worry about wasting it on alpha channel.

Regarding gamma correction and color space conversion... that is usually done by renderer, at least for common pixel formats. YUV is a type of color space used in analog PAL video, but awkward enough industry oftenly and erroneously uses the same term referring to it's digital representation YCbCr.

There are many YCbCr (YUV) pixel formats (planar & packed) which can be generally considered as digital representation of 'yuv colorspace' and they all must be treated differently, namely supported by rendering device (hardware or software).

As digital representation of 4:2:2 subsampled YUV color space, YCbCr (usually) requires 16bit per pixel, but there are many other pixel formats, such as 9bit YUV9, 12bit BTYUV & YUY12, 16bit YUY2 and their variations YVU9, YUV8, CYUV, YUYV, UYVY, YU92...

Don't get me wrong, but if you ask this kind of questions how do you suppose to handle such a complex project?

Please elaborate on your project. To evade confusions use simple language and without any conclusions. (what a rhyme )

P.S. Dude, what school/university are you attend?

Edit: added clarifications and corrected grammar