RGB555
RGB555
RGB555 is a 16 bit color format. Every pixel is represented by two bytes. The characters 555 stand for the number of bits used for every color value. In this case, 5 bits are used for every color value, so only 15 bits are needed. The last bit (most significant bit) is unused. The organization of the pixels in the image buffer is from left to right and bottom up.
Memory Layout
此处为图1
As illustrated above, the 5 least significant bits of the WORD correspond to the blue value, bits 5 - 9 correspond to the green value and bits 10 to 14 correspond to the red value. Bit 15 is unused in this case. 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.
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 RGB555 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 eRGB555
" );
printf( "Pixel 1(RGB): %d %d %d
", ( pwImgData[iOffsUpperLeft] & eRGB555_R ) >> 10 ,
( pwImgData[iOffsUpperLeft] & eRGB555_G ) >> 5,
( pwImgData[iOffsUpperLeft] & eRGB555_B ) );
printf( "Pixel 2(RGB): %d %d %d
", ( pwImgData[iOffsUpperLeft+1] & eRGB555_R ) >> 10 ,
( pwImgData[iOffsUpperLeft+1] & eRGB555_G ) >> 5,
( pwImgData[iOffsUpperLeft+1] & eRGB555_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 1024 (32 times too large)).
Manipulating Image Data
Shifting is also important when assigning values. For example, if 7 is assigned to the red value, it must be shifted 10 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 << 10;
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] &= ~eRGB555_R;
// Assign 7 to the red value without overwriting green and blue values
pwImgData[iOffsUpperLeft] |= 7 << 10;
Please note that all bits of the appropriate color should be set to 0, as does the code above. 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 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 << 10; // Assign the value for red
// set the second pixel to GREEN
pwImgData[iOffsUpperLeft+1] = 0; // clear the pixel
pwImgData[iOffsUpperLeft+1] |= 31 << 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( "RGB555.bmp" );
To check the result, just open the saved image and examine the upper left hand pixels. They should look as follows:
此处为图2