RFR: 8351108: ImageIO.write(..) fails with exception when writing JPEG with IndexColorModel

[Jeremy]

On Tue, 4 Mar 2025 21:43:17 GMT, Phil Race <prr at openjdk.org> wrote:

>> Previously ImageTypeSpecifier treated all TYPE_BYTE_INDEXED as if they were opaque.
>> 
>> In this ticket's case: an ImageWriter received the wrong ImageTypeSpecifier and mistakenly indicated it *could* support a BufferedImage. But when the actual BufferedImage arrived (which was translucent), the ImageWriter threw an exception.
>> 
>> Instead:
>> Now the ImageTypeSpecifier accurately describes the given BufferedImage.
>
> src/java.desktop/share/classes/javax/imageio/ImageTypeSpecifier.java line 923:
> 
>> 921:             int bufferedImageType = ((BufferedImage)image).getType();
>> 922:             if (bufferedImageType != BufferedImage.TYPE_CUSTOM &&
>> 923:                   bufferedImageType != BufferedImage.TYPE_BYTE_INDEXED) {
> 
> So we'll no longer use a singleton IST for images with an ICM.
> I don't know how much that matters though. They probably aren't heavyweight compared to the image writing.
> The alternative - which I'll mention, which isn't the same as recommend - is to check if ColorModel.getTransparency() == OPAQUE before using the singleton, since we know that's the case it maps to.
> 
> The BYTE_INDEXED case code in getSpecifier(..) isn't dead code, because it is still used in
> public static  ImageTypeSpecifier createFromBufferedImageType(int bufferedImageType)
> In that case, there's not  enough information to do anything except "pick one", so it is caveat emptor for callers of  that API in such a case, and no need to do anything there.
> 
> I'll have to run this through our testing.

Right.

If we value cached singletons: it'd be easy to break this up into 3 basic cached ImageTypeSpecifiers (one for each Transparency constant: OPAQUE, BITMASK, TRANSLUCENT). That would also satisfy the attached unit test and the original TwelveMonkeys complaint. I started with what I thought was the simplest proposal (in this PR), but I'm happy to explore other options if we want.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1980403056