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

[Phil Race]

On Tue, 4 Mar 2025 23:13:02 GMT, Jeremy <duke at openjdk.org> wrote:

>> 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.

Unless someone has a performance-sensitive batch job encoding thousands of transparent GIFs, I don't see a problem.

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

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