1

The following code shows a part of my code. When I delete the part between '// start of color extraction & composing' and '// end of color extraction & composing' I always get the same color image back in tmpBmp. But if I insert the part, then I always get a grey-level image displayed (whereas I'm expecting the same color image). Is there any reason that the code between '// start of color extraction & composing' and '// end of color extraction & composing' returns a grey-scaled image?

int width = captureBmp.getWidth();
int height = captureBmp.getHeight();
int red, green, blue, alpha;

Bitmap tmpBmp = captureBmp.copy(Bitmap.Config.ARGB_8888, true);

for (int y = 0; y < height; y++) {
  for (int x = 0; x < width; x++) {
     int value = captureBmp.getPixel(x, y);

 //  start of color extraction & composing
   alpha = value & 0xFF000000 >> 24;         
       red = value & 0x00FF0000 >> 16;
   green = value & 0x0000FF00 >> 8;
   blue = value & 0x000000FF;

   value = ( (alpha << 24) & 0xFF000000) |
          ( (red << 16) & 0x00FF0000) |
          ((green << 8) & 0x0000FF00) |
      (blue & 0x000000FF);
   //  end of color extraction & composing


              tmpBmp.setPixel(x, y, value);
                }
            }
ImageView imgView = (ImageView) findViewById(R.id.imageview);
imgView.setImageBitmap(tmpBmp);
Sukho Lee
  • 15
  • 2
  • What are the actual `alpha`, `red`, `green`, and `blue` values? – Ben M. Sep 15 '15 at 19:41
  • They correspond to the alpha, red, green and blue components of the color pixel in ARGB format. After fixing the code as answered below I got the corresponding components. – Sukho Lee Sep 15 '15 at 20:01
  • I know, but I was asking what their actual values are. It's okay, it looks like your problem is solved. – Ben M. Sep 15 '15 at 20:03

2 Answers2

1

The problem is that this code:

alpha = value & 0xFF000000 >> 24;         
       red = value & 0x00FF0000 >> 16;
   green = value & 0x0000FF00 >> 8;
   blue = value & 0x000000FF;

First masks with bitwise mask and then shifts, try the opposite. Shift then, bitmask with 0xFF.

It probabbly has to do with byte formats and unsigned integers and unsigned right shift in java.

As already noted by @Paul Boddington operator precedence plays a major part.

Community
  • 1
  • 1
Nikos M.
  • 8,033
  • 4
  • 36
  • 43
  • Thank you very much Nikos M. Your answer helped me to find the error. Actually the error was that I first shifted and then masked. When I changed the code as follows, the code worked as I expected. I got the hint from your answer : alpha = (value & 0xFF000000) >> 24; red = (value & 0x00FF0000) >> 16; green = (value & 0x0000FF00) >> 8; blue = value & 0x000000FF; – Sukho Lee Sep 15 '15 at 19:48
  • @SukhoLee, nice to hear, you can also accept if it helped you – Nikos M. Sep 15 '15 at 19:49
1

The line

red = value & 0x00FF0000 >> 16

is the same as

red = value & (0x00FF0000 >> 16)

Note that (0x00FF0000 >> 16) is just 0x000000FF. The same happens for green and blue, so you get the same value three times. Hence it's grey.

The alpha value is different because 0xFF000000 >> 24 is 0xFFFFFFFF due to the way the signed right shift works.

The solution is to rebracket. (I'd also use >>> for this, but it actually makes no difference because alpha gets shifted back 24 places left anyway).

alpha = (value & 0xFF000000) >>> 24;
red = (value & 0x00FF0000) >>> 16;
green = (value & 0x0000FF00) >>> 8;
blue = value & 0x000000FF;
Paul Boddington
  • 37,127
  • 10
  • 65
  • 116