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.
RGB565彩色模式, 一个像素占两个字节, 其中:
第一个字节的前5位用来表示R(Red)
第一个字节的后三位+第二个字节的前三位用来表示G(Green)第二个字节的后5位用来表示B(Blue)
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]
How to read and write pixel data
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( "
Image buffer pixel format is eRGB565
" );
printf( "Pixel 1(RGB): %d %d %d
", ( pwImgData[iOffsUpperLeft] & eRGB565_R ) >> 11,
( pwImgData[iOffsUpperLeft] & eRGB565_G ) >> 5,
( pwImgData[iOffsUpperLeft] & eRGB565_B ) );
printf( "Pixel 2(RGB): %d %d %d
", ( 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:
