views:

47

answers:

2

I am using a image processing library in java to manipulate images.The first step I do is I read an image and create a java.awt.Image.BufferedImage object. I do it in this way,

BufferedImage sourceImage = ImageIO.read( new File( filePath ) );

The above code creates a BufferedImage ojbect with a DirectColorModel: rmask=ff0000 gmask=ff00 bmask=ff amask=0. This is what happens when I run the above code on my macbook.

But when I run this same code on a linux machine (hosted server), this creates a BufferedImage object with ColorModel: #pixelBits = 24 numComponents = 3 color space = java.awt.color.ICC_ColorSpace@c39a20 transparency = 1 has alpha = false isAlphaPre = false.

And I use the same jpg image in both the cases. I don't know why the color model on the same image is different when run on mac and linux. The colormodel for mac has 4 components and the colormodel for linux has 3 components.There is a problem arising because of this, the image processing library that I use always assumes that there are always 4 components in the colormodel of the image passed, and it throws array out of bounds exception when run on linux box. But on macbook, it runs fine.

I am not sure if I am doing something wrong or there is a problem with the library. Please let me know your thoughts. Also ask me any questions if I am not making sense!

+1  A: 

I don't know exactly why you're getting two different color models although I believe they're quite the same. The DirectColorModel has 4 components but the alpha mask is 0, so in fact it only has 3 components just like the other one.

I suggest to write a simple helper function which makes sure the image has the right color model before you pass it to this image library. The helper function could make use of http://java.sun.com/j2se/1.4.2/docs/api/java/awt/image/ColorConvertOp.html or use something like the following code (untested):

private static BufferedImage makeCompatible(BufferedImage image) {
  int w = image.getWidth();
  int h = image.getHeight();

  BufferedImage result = new BufferedImage(w, h, BufferedImage.TYPE_4BYTE_ABGR);
  Graphics2D g = result.createGraphics();
  g.drawRenderedImage(image, new AffineTransform()); //or some other drawImage function
  g.dispose();

  return result;
}

Assuming that the library is able to handle BufferedImage.TYPE_4BYTE_ABGR. Otherwise you will have to put something else here. And of course, you could check if the original image already has the right format before converting it.

Michel Krämer
A: 

Adding a little more info, Once the image is read, I printed out image.getType()

  • On mac -> it returns TYPE_INT_RGB (a value of 1)
  • On linux -> it returns TYPE_3BYTE_BGR (a value of 5)
plspl