RGB888 to RGB565 and vice versa causing loss of info?

Question

I have the following code to convert RGB565 to RGB888 and vice versa:

public static void main(String[] args) {
    // TODO code application logic here
    System.out.println(Integer.toHexString(RGB888ToRGB565(0x11ffffff)));
    System.out.println(Integer.toHexString(RGB565ToRGB888(RGB888ToRGB565(0x7FC9FF))));
}

static int RGB888ToRGB565(int red, int green, int blue) {
    final int B = (blue >>> 3) & 0x001F;
    final int G = ((green >>> 2) << 5) & 0x07E0;
    final int R = ((red >>> 3) << 11) & 0xF800;

    return (R | G | B);
}

static int RGB888ToRGB565(int aPixel) {
    //aPixel <<= 8;
    //System.out.println(Integer.toHexString(aPixel));
    final int red = (aPixel >> 16) & 0xFF;
    final int green = (aPixel >> 8) & 0xFF;
    final int blue = (aPixel) & 0xFF;
    return RGB888ToRGB565(red, green, blue);
}

static int RGB565ToRGB888(int aPixel) {
    final int b = (((aPixel) & 0x001F) << 3) & 0xFF;
    final int g = (((aPixel) & 0x07E0) >>> 2) & 0xFF;
    final int r = (((aPixel) & 0xF800) >>> 8) & 0xFF;
    // return RGBA
    return 0x000000ff | (r << 24) | (g << 16) | (b << 8);
}

Problem is in the second line when it gets transformed back to rgb888 I get a loss of color information. Can anyone who knows more about bitshifting and masking help me out?

Thanks in advance!

Have you checked http://stackoverflow.com/questions/2442576/how-does-one-convert-16-bit-rgb565-to-24-bit-rgb888 ? — Jakub Kotowski, Jan 14 '14 at 11:48
Yes i have and it didn't really help. I know there should be loss, but I don't expect there to be THAT much loss. — David Xu, Jan 14 '14 at 12:48
Is your problem 1) that the colors become less detailed or 2) that the colors are somehow corrupted by incorrect conversion? If the former, that's obvious and inevitable. (By converting from rgb888 to rgb565 and back, you are literally destroying one third of the data, slicing the amount of possible colors to 1/256th of what it originally was). It cannot be recovered by any means.) If the latter, can you provide an example of how it's corrupted? — BambooleanLogic, Jan 14 '14 at 14:46
No, the colors are actually completely corrupted, sometimes it returns values not even close to the original. — David Xu, Jan 14 '14 at 15:48

score 0 · Answer 1 · answered Jan 14 '14 at 14:46

0

Isn't this line wrong?

final int g = (((aPixel) & 0x07E0) >>> 2) & 0xFF;

should be:

final int g = (((aPixel) & 0x07E0) >>> 3) & 0xFF;

To my eyes the rest of your code looks OK. I don't know if that explains it. Otherwise you'd probably have to define what "that much loss" is according to what test.

answered Jan 14 '14 at 14:46

Sean Owen

66,182
23
141
173

Hmm, nope that just caused it to return an even more incorrect output. – David Xu Jan 14 '14 at 16:38
Well, the line was wrong, right? The value is at a +5 shift so you need it to shift -3 to start at the top of an 8-bit byte. You haven't said what the problem is. What output isn't matching what expected output. – Sean Owen Jan 14 '14 at 18:10

score 0 · Answer 2 · answered Apr 18 '18 at 10:53

In static int RGB888ToRGB565(int aPixel) you expect ARGB (or just RGB) as input

In static int RGB565ToRGB888(int aPixel) you return RGBA as output

Seems illogical to use ARGB and RGBA in the same code. My guess is you got this mixed up when comparing the colors afterwards?

Apart from this Sean Owens comment above is correct

RGB888 to RGB565 and vice versa causing loss of info?

2 Answers2