@tmccombs

Thank you for your work and the PR!

I think I understand your use case, and unfortunately transparency in BMPs is a feature that seems to be a bit of an afterthought. Causing different implementations, which doesn't adhere to spec... I guess the fact that formats like Microsofts own ICO will put alpha values in the BMP (DIB) structure just like this "fake" alpha, without writing BI_BITFIELDS or BI_ALPHA_BITFIELDS doesn't help either...

Anyway, I think that q/rgb32fakealpha.bmp in the bmp suite is currently decoded as it should according to the spec. Changing the behavior, like using a heuristic, might just cause unexpected results for other samples which might have rubbish data in the extra bits.

However, the extra bits (alpha values) are kept in the data, even if they aren't displayed as transparency. They are just ignored. You can convert it back to transparency like this (quick and dirty implementation, will only work for 32 bit packed with the normal channel ordering);

int[] rgba = ((DataBufferInt) image.getRaster().getDataBuffer()).getData();

BufferedImage tmp = new BufferedImage(image.getWidth(), image.getHeight(), BufferedImage.TYPE_INT_ARGB);
tmp.setRGB(0, 0, image.getWidth(), image.getHeight(), rgba, 0, image.getWidth());

image = tmp;

I think the best/cleanest way to implement a way to "force" the decoder to treat the extra bits as transparency would be to do it using the ImageReadParam, either by an explicit force32BitTransparency setting (preferably with a better name 😉 ), or looking at the destination/destination type, and treating the data as transparency if the destination contains transparency.

Is there a way to determine if the original BMP used 32 bpp?

Is there a way to determine if the original BMP used 32 bpp?

Yes. If the bitmap info header says the bit count is 32, then... it's 32 bits/pixel. If that's what you mean?

If the bit count is 24, then there is obviously no ambiguity. And if the bit count is 32 and masks are present (ie. BI_BITFIELDS or BI_ALPHA_BITFIELDS) there is no ambiguity; masks decide. However, when the bit count is 32 and there are no masks, the pixel format is supposed to be RGBx, where x must be 0 for all pixels.

The ambiguity starts when we have 32 bits/pixel, no masks and an x > 0... This is BMP "fake alpha". And the problem is that we (the decoder) can't know the intention of the values (could be alpha channel, could be garbage from an uninitialized buffer or just random noise of some sort).

Of course, if you are also "the encoder" of this file or know its origin, you could know what the intention is, and then force the values to become transparency if you like. So I think it makes the most sense to allow that as an option.

Sorry, I should have been more clear. I meant, is there a way to get that information from the final BufferedImage returned by ImageIO.read?

I think that

image.getType() == BufferedImage.TYPE_INT_RGB

would probably work?
Or is there another case where that would be true?

This is what I ended up with:

if (image.getType() == BufferedImage.TYPE_INT_RGB) {
  int[] bandMasks = {0xff0000, 0xff00, 0xff, 0xff000000};
  WritableRaster raster = Raster.createPackedRaster(
      image.getRaster().getDataBuffer(),
      image.getWidth(),
      image.getHeight(),
      image.getWidth(),
      bandMasks,
      null
      );
    image = new BufferedImage(ColorModel.getRGBdefault(), raster, false, null);
}

👍🏻That should be fairly safe. It’s also much faster than my initial suggestion, as you don’t duplicate the data buffer/copy pixel values.

If you want to be really sure, you could also scan the pixels for non-zero alpha values as you outlined above in the initial request, to avoid a completely transparent image.