On Tue, 4 Mar 2025 06:51:54 GMT, Jeremy <d...@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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1980278512
