[solved]VPBE Driver Usage Example -Confusion&Questions about image formats and sizes

Reply

Elric Posted: 21 Oct 2008 8:39 AM

rated by 0 users

Hi,

I am working on VPBE Driver Usage example (spraap3a) to understand it, but now I have a confusion about the image formats and the sizes.

Let me explain it,

(Although I practice on many background info, I am totally new to this, so my questions shall be a little awkward.)

Background Image:

Statement: displayed in VIDWIN0, video data stored as an array named BRIDGE30f, in images.lib.

--Question: In which format the video data is stored? Is it supposed to be the "raw data"? In the below statement, it says "30 frames YUV422 data", so can I say that data is stored as "YUV422" format, rather than stored in a raw-like format or bitmap data format and processed in YUV422 format?

Statement: consists of 30 frames YUV422 data in 180x120 resolution (4x zoomed to 720x480).

--Question: What does the "frame" here means? For other images in the same example, the word "frame" is not used, so I couldn't come up with something sensible.

Statement: size of valid data for each row is 360 bytes.

--Question: Is there a way to know or calculate the size of the valid data? How it is known that it is 360 bytes? For the RGB565 image (146x146) in the same example, size of the valid data is said 146*2 = 292 bytes and for the RGB888 image (146x146) in the same example, it is said 146*3 = 438 bytes. How it is calculated?

Stament: 24 bytes added to each row to make pitch 32 byte aligned, thus, total size of the array is 384x120x30.

The same questions goes for the RGB565 and RGB888 images in the same example, actually. For example, TIDSP Logo is displayed on OSDWIN0, as RGB 16 bit format. Is the "RGB565" only the display format, or is it both the storage and display format?

To be more generic, I wonder how I can process an image that I have. Should I first convert it to raw data or bitmap data or what is used as storage format, and then for example I make the drivers process it in the RGB565 format?

I will be very appreciated for any help,

Thank you,

A. Erman Kulunyar

Reply

Bernie Thompson replied on 21 Oct 2008 11:48 AM

rated by 0 users

Elric:

--Question: In which format the video data is stored? Is it supposed to be the "raw data"? In the below statement, it says "30 frames YUV422 data", so can I say that data is stored as "YUV422" format, rather than stored in a raw-like format or bitmap data format and processed in YUV422 format?

The data is stored in a YUV422 format (commonly YCbCr with a chroma subsampling ratio of 4:2:2) which is what the VIDWIN0 accepts; this format is something you will find commonly in video streams. You could consider it to be ‘raw data’ in that it is not compressed; it is direct 16 bits per pixel data, the same format that you would capture from a typical video stream. Essentially the format it is stored in memory in this case is the same format that the VPBE processes.

Elric:

--Question: What does the "frame" here means? For other images in the same example, the word "frame" is not used, so I couldn't come up with something sensible.

A frame is a single image in a stream of video (assuming progressive), so it means that the video in the library is 30 frames long where each frame is 180x120 resolution with a YUV422 color format, so if you display at 30 frames per second this means you have one second of video in the library. In an interlaced case the frame is the full resolution of the display, whereas a field is half of the resolution of the display which will be made of either the even or the odd lines of the frame. In this case I believe the data in memory can be thought of as progressive even though your display is interlaced.

Elric:

--Question: Is there a way to know or calculate the size of the valid data? How it is known that it is 360 bytes? For the RGB565 image (146x146) in the same example, size of the valid data is said 146*2 = 292 bytes and for the RGB888 image (146x146) in the same example, it is said 146*3 = 438 bytes. How it is calculated?

The amount of memory space that video data takes up depends on the resolution and the depth (defined in this case by YUV422 which is 2 bytes per pixel), in particular ‘height x width x depth’ gives you the space that is taken up by an individual frame, if you multiply this by the number of frames you would have the total space needed for the entire stream. So for this case since YUV422 implies two bytes per pixel you would have 180x2 bytes per line. RGB565 is also two bytes per pixel so it is essentially the same as the YUV422 from a space perspective; the RGB888 (a.k.a 24 bit RGB) is actually three bytes per pixel so you have the 146x3 calculation.

Elric:

The same questions goes for the RGB565 and RGB888 images in the same example, actually. For example, TIDSP Logo is displayed on OSDWIN0, as RGB 16 bit format. Is the "RGB565" only the display format, or is it both the storage and display format?

The OSDWIN0 accepts RGB as opposed to YCbCr, making it easier to display graphics like the logo which typically will be generated in RGB, generally RGB is common with PCs (and thus graphics) and YCbCr is common with video streams. The display format depends on how you have your display driver setup, regardless of what format you bring in with the OSDWIN and VIDWIN, the display will always be a particular format (i.e. the OSD hardware combines the windows and converts them into the proper format for your display). In the case of a composite output it is actually taking all the windows and combining them into a YUV image to display, if you were using a directly connected LCD output you could have everything combined into a RGB output.

Elric:

To be more generic, I wonder how I can process an image that I have. Should I first convert it to raw data or bitmap data or what is used as storage format, and then for example I make the drivers process it in the RGB565 format?

For your image you would need to convert it into a format that the drivers can understand, typically YCbCr 4:2:2 (VIDWIN) or RGB 5:6:5 (OSDWIN) for it to be displayed, which format is appropriate depends on your source, it is probably easiest to keep with the color space you are already using for your image. What format is your image in now?

Reply

Elric replied on 21 Oct 2008 2:30 PM

rated by 0 users

Thank you for your time and answers.

So, what I know now is:

- The image format that is stored in memory is the format that is processed by the VPBE. (So I assume there is no format conversion done by the VPBE.)

- Frame is a single image in a video stream. You really gave a brief and good explanation. But one point I don't understand is why this application uses an image as a video stream, since the background image is a single image, not a video. What should be the difference if the image is not consisted of 30 frames but a single frame?

- The amount of valid data is calculated by multiplying bytes per pixel and the image width. (aligning to 32 bit should be requiered)

- The display format is not the same thing with the format that is processed in VPBE. It is configured in VENC according to the output display device.

I am taking the VPBE document (spru952a), 2.2 Digital Display Interface as reference now. It says there are three different digital display modes. I suppose these modes are the "display formats" we are talking about. YCC16, YCC8 and PRGB. To use RGB565 image format, I understand that, OSD module produces YUV444 signal and overlaids onto YUV442 output. VENC module, which takes that signal from OSD, generates the YCC16 or YCC8 output depending on the configuration (or selection). In PRGB, I understand that, again, OSD modules processes RGB565 image format (say RGB565 is our case now) and produces an output of YUV442 signal to be given to VENC. Then VENC module converts or produces a signal of PRGB, -RGB565 in our case, I suppose- to be given to digital output display. Please correct me If I am wrong.

Also another thing I wonder now is if I can take the display format of the RGB565 in three different ways and all digital, which one should I choose? I mean, what is the difference between them, by the means of a user?

Bernie Thompson:

For your image you would need to convert it into a format that the drivers can understand, typically YCbCr 4:2:2 (VIDWIN) or RGB 5:6:5 (OSDWIN) for it to be displayed, which format is appropriate depends on your source, it is probably easiest to keep with the color space you are already using for your image. What format is your image in now?

I don't have a specific format in mind right now, to try it. But in the project, we are thinking to use RGB565 format, with digital output to a LCD. Guess I can convert a .jpeg to RGB565 and try if it works. Do you know any specific image converter applications that I can use?

While asking; do you know that, is the source codes of the libraries that are used in the examples are valid anywhere? As far as I know, for example FVID functions are driver functions from the libraries. Can I find the source codes of these? Even the images are in a .lib file name images.lib.

Thank you again, your answers cleared it much.

Reply

Bernie Thompson replied on 21 Oct 2008 8:19 PM

rated by 0 users

-The image that is stored in memory must be in the format that the VPBE accepts, the VPBE can and does do format conversions depending on what display you are using (i.e. if you use a RGB based LCD the VIDWIN0 can still be YCbCr 422).

-I have not tried out the application note you are referencing so I am not entirely sure, but if it is not video than you can display a single frame repeatedly.

-The data format that the VPBE outputs is not dependent on the format of the data in memory, the VPBE does a colorspace conversion as necessary so that the display shows the right image, the format in internal memory is just defined by the OSD window you use (and its configuration), i.e. VIDWIN or OSDWIN.

-You certainly could convert a .jpg image into RGB565 and display it using a OSDWIN. You could convert the jpg into a .bmp format and than use a utility that was put together with the application note here to get it into the RGB565 format the OSD supports, unfortunately this is a Linux utility so if you only have a Windows machine you may have to seek out another option.

-The drivers you reference with the FVID APIs are sourced within the PSP directory of your DVSDK install, the FVID functions are actually abstracted through a BIOS driver layer, so the functions you see in the PSP code will be labeled differently (unfortunately I am not on my work PC at the moment so I do not have the exact path to the source).

Reply

Elric replied on 22 Oct 2008 2:35 AM

rated by 0 users

Thank you very much, Mr. Thompson. I appreciate it much.

Reply

Elric replied on 22 Oct 2008 3:14 PM

rated by 0 users

By the way, 24 bit bmp to rgb565 conversion can be done using the application (along with source code) at http://focus.ti.com/lit/an/spraad7/spraad7.pdf . For conversion application, it  doesn't matter if you are using Windows or Linux. But for the rest -of document- you need Linux. I spent a good deal of time today writing a conversion application myself (actually it is easy, but first time you know..) but later I discovered the application and the source code at the link is not for only Linux. If I looked at the beginning...