RGB565

The RGB565 color format is the same as the RGB555 color format, except that 6 bits are used for the green value instead of 5. Therefore, all 16 bits are in use. The organization of the pixels in the image buffer is from left to right and bottom up.

, 其中:

低位元組的前5位用來表示B(BLUE)

低位元組的后三位+高位元組的前三位用來表示G(Green)

高位元組的后5位用來表示R(RED)

Memory Layout

圖1

As illustrated above, the 5 least significant bits of the WORD correspond to the blue value, bits 5 - 10 correspond to the green value and bits 11 to 15 correspond to the red value. Please note that on the x86 architecture WORDs are stored in little-endian order, which means the LOW BYTE is saved first. This is important when accessing the image data with a byte pointer.

總而言之, 對於RGB565來說, 一個像素在x86計算機中以一個字(WORD)的形式來存儲

然而X86內存組織中, 低位位元組的地址要小於高位位元組, 也就是, 一個像素在X86內存中是這麼存的:

低位位元組: 前三位G[2:0] 后五位B

高位位元組: 前五位R 后三位 G[5:3]

A video capture device, video format, FrameHandlerSink with a MemBufferCollection, which defines the image data color format must first have been setup. The following code fragments show step-by-step how to access and manipulate the pixel data of RGB555.

First of all, we have to capture an image. Otherwise, the image buffer would be empty. To do so, we start live mode and call Grabber::snapImages.

Accessing the buffer

The following code retrieves a pointer to the image data. Please note, that getPtr() returns a BYTE pointer, which will be type-casted to a WORD pointer. This makes it much easier to access the pixel data since RGB565 is a 16 bit color format.

WORD* pwImgData = (WORD*) pActiveBuf->getPtr();

In this example, we want to output the first (upper left hand) pixel of the image and manipulate the first 3. As previously mentioned, the image data is stored bottom up. Therefore, pwImgData points to the first byte of the first pixel of the last line in the buffer. To get access to this first byte, the following calculation has to be performed:

// Calculate the index of the upper left pixel

// Images are stored upside down in the image buffer

// * 1: a pixel is 2 byte, but since we have a WORD pointer (which is also 2 bytes)

// we count in pixel not in bytes

SIZE dim = pActiveBuf->getFrameType().dim;

int iOffsUpperLeft = (dim.cy-1) * dim.cx * 1;

At first, we retrieve the width and height of the image in terms of pixels. Then, the offset to the upper left pixel is calculated. Please note that we multiply with Width * 1 and not Width * 2. This is because we use a WORD pointer to access the image data. Of course, the multiplication by 1 is just for illustration and can be left out.

(Height-1) * Width

Now that we have the offset to the the first pixel, we can read it out:

// Please note: RGB values are stored within a WORD in the following order: R,G,B

// A binary AND operation is done with the color mask to extract the specific color.

// After the AND operation, a right shift is done so that the output is displayed correctly.

printf( "\nImage buffer pixel format is eRGB565\n" );

printf( "Pixel 1(RGB): %d %d %d\n", ( pwImgData[iOffsUpperLeft] & eRGB565_R ) >> 11,

( pwImgData[iOffsUpperLeft] & eRGB565_G ) >> 5,

( pwImgData[iOffsUpperLeft] & eRGB565_B ) );

printf( "Pixel 2(RGB): %d %d %d\n", ( pwImgData[iOffsUpperLeft+1] & eRGB565_R ) >> 11 ,

( pwImgData[iOffsUpperLeft+1] & eRGB565_G ) >> 5,

( pwImgData[iOffsUpperLeft+1] & eRGB565_B ) );

As seen in the code above, we perform a binary AND operation with the appropriate pixel mask on the current pixel to extract the color value. After that, the values for red and green must be shifted to the right to get the correct value (otherwise the value would be 2048 (32 times too big)).

Manipulating Image Data

Shifting is also important when assigning values. For example, if 7 is assigned to the red value, it must be shifted 11 times to the left. Instead of writing:

// Assign 7 to the red value

pwImgData[iOffsUpperLeft] = 7; // this is WRONG

which assigns 7 to the blue value, the following code should be used:

// Assign 7 to the red value

pwImgData[iOffsUpperLeft] = 7 << 11;

Another important thing to note is that the assignment above will overwrite the values for green and blue. To prevent this, the value must be ORed to the pixel data as the following code will show:

// Clear the red value (set all bits to 0)

pwImgData[iOffsUpperLeft] &= ~eRGB565_R;

// Assign 7 to the red value without overwriting green and blue values

pwImgData[iOffsUpperLeft] |= 7 << 11;

Please note that all bits of the appropriate color should be set to 0, as the code above does. Consider, for example, that the previous red value could have been 16 (or 10000 binary). If we then perform a binary OR operation with 7 (or 111 binary), the result will be 23 (or 10111 binary). Therefore, it is better to set all bits of the appropriate channel to 0.

Now we set the upper left hand pixel to red, the next to green and the third to blue.

// overwrite the first 3 pixels and save image to disk

// set the first pixel to RED

pwImgData[iOffsUpperLeft] = 0; // clear the pixel

pwImgData[iOffsUpperLeft] |= 31 << 11; // Assign the value for red

// set the second pixel to GREEN

pwImgData[iOffsUpperLeft+1] = 0; // clear the pixel

pwImgData[iOffsUpperLeft+1] |= 63 << 5; // Assign the value for green

// set the third pixel to BLUE

pwImgData[iOffsUpperLeft+2] = 0; // clear the pixel

pwImgData[iOffsUpperLeft+2] |= 31; // Assign the value for blue

pActiveBuf->save( "RGB565.bmp" );

To check the result, just open the saved image and examine the upper left hand pixels. They should look as follows: