CODEWITHSUNDEEP
c++qt
paulm
paulm

Reputation: 5892

Why does converting RGB888 to RGB565 many times cause loss of colour?

If I do the following using Qt:

  1. Load a bitmap in QImage::Format_RGB32.
  2. Convert its pixels to RGB565 (no Qt format for this so I must do it "by hand").
  3. Create a new bitmap the same size as the one loaded in step 1.
  4. Convert the RGB565 buffer pixels back to RGB88 in to the image created in step 3.
  5. The image created from step 4 looks like the image from step 1, however they're not exactly the same if you compare the RGB values.

Repeating steps 2 to 5 results in the final image losing colour - it seems to become darker and darker.

Here are my conversion functions:

qRgb RGB565ToRGB888( unsigned short int aTextel )
{
    unsigned char r = (((aTextel)&0x01F) <<3);
    unsigned char g = (((aTextel)&0x03E0) >>2);
    unsigned char b = (((aTextel)&0x7C00 )>>7);
    return qRgb( r, g, b, 255 );
}

unsigned short int RGB888ToRGB565( QRgb aPixel )
{
    int red = ( aPixel >> 16) & 0xFF;
    int green = ( aPixel >> 8 ) & 0xFF;
    int blue =  aPixel & 0xFF;

    unsigned short  B = (blue >> 3) & 0x001F;
    unsigned short  G = ((green >> 2) < 5) & 0x07E0;
    unsigned short  R = ((red >> 3) < 11) & 0xF800;

    return (unsigned short int) (R | G | B);
}

An example I found from my test image which doesn't convert properly is 4278192128 which gets converted back from RGB565 to RGB888 as 4278190080.

Edit: I should also mention that the original source data is RGB565 (which my test RGB888 image was created from). I am only converting to RGB888 for display purposes but would like to convert back to RGB565 afterwards rather than keeping two copies of the data.

Upvotes: 0

Views: 9572

Answers (1)

leemes
leemes

Reputation: 45715

Beforehand I want to mention that the component order in your two conversion functions aren't the same. In 565 -> 888 conversion, you assume that the red component uses the low order bits (0x001F), but when encoding the 5 bits of the red component, you put them at the high order bits (0xF800). Assuming that you want a component order analogous to 0xAARRGGBB (binary representation in RGB565 is then 0bRRRRRGGGGGGBBBBB), you need to change the variable names in your RGB565ToRGB888 method. I fixed this in the code below.

Your RGB565 to RGB888 conversion is buggy. For the green channel, you extract 5 bits, which gives you only 7 bit instead of 8 bit in the result. For the blue channel you take the following bits which is a consequential error. This should fix it:

QRgb RGB565ToRGB888( unsigned short int aTextel )
{
    // changed order of variable names
    unsigned char b = (((aTextel)&0x001F) << 3);
    unsigned char g = (((aTextel)&0x07E0) >> 3); // Fixed: shift >> 5 and << 2
    unsigned char r = (((aTextel)&0xF800) >> 8); // shift >> 11 and << 3
    return qRgb( r, g, b, 255 );
}

In the other function, you accidentally wrote less-than operators instead of left-shift operators. This should fix it:

unsigned short int RGB888ToRGB565( QRgb aPixel )
{
    int red   = ( aPixel >> 16) & 0xFF;  // why not qRed(aPixel) etc. ?
    int green = ( aPixel >> 8 ) & 0xFF;
    int blue  =   aPixel        & 0xFF;

    unsigned short  B =  (blue  >> 3)        & 0x001F;
    unsigned short  G = ((green >> 2) <<  5) & 0x07E0; // not <
    unsigned short  R = ((red   >> 3) << 11) & 0xF800; // not <

    return (unsigned short int) (R | G | B);
}

Note that you can use the already existing (inline) functions qRed, qGreen, qBlue for component extraction analogous to qRgb for color construction from components.

Also note that the final bit masks in RGB888ToRGB565 are optional, as the component values are in the 8-bit-range and you cropped them by first right-, then left-shifting the values.

Upvotes: 9

Related Questions