RFR: 8274735: javax.imageio.IIOException: Unsupported Image Type while processing a valid JPEG image

[ExE Boss]

On Thu, 17 Mar 2022 03:23:49 GMT, Phil Race <prr at openjdk.org> wrote:

> The JDK's built-in Image I/O JPEG plugin decodes JPEGs which are YCbCr and RGb and Grayscale but rejects CMYK and YCCK JPEGs.
> These would correspond to JFIF encapsulated JPEGs.
> 
> This was a reasonable decision to limit support to what was actually likely to be seen - CMYK JPEGs probably should just be created for direct to print devices and never seen on the internet as an interchange format.
> 
> Indeed this (below) RFC for mail suggests JFIF is what clients should transmit :
> 
> https://datatracker.ietf.org/doc/html/rfc2046 :  Multipurpose Internet Mail Extensions - Part 2
> 
> 
>    A media type of "image" indicates that the body contains an image.
>    The subtype names the specific image format.  These names are not
>    case sensitive. An initial subtype is "jpeg" for the JPEG format
>    using JFIF encoding [JPEG].
> 
> And for many years, browsers either failed to display CMYK JPEGs or displayed them incorrectly.
> 
> But alas they do crop up and when they do, Image I/O rejects them - to the surprise and
> consternation of some developer who knows little of JPEGs and arcane colour spaces.
> 
> Full support of CMYK JPEGs via the whole Image I/O API including proper handling as metadata
> will lead us down a path that might even extend into EXIF support for JPEG and likely will
> require the JPEG Metadata spec to be updated. 
> 
> So the goal here is to skirt that as much as possible by just 
> (1) not rejecting read of CMYK JPEGs and returning a BufferedImage with a suitable ColorModel
> (2) allowing the same BufferedImage with that ColorSpace to be written back out again as CMYK JPEGs 
> 
> Reading will preserve any embedded ICC Color Profile, but writing will not re-encode it since
> that requires work on metadata. That will have to be a follow-up fix, but at the very least it
> means that a re-written JPEG will benefit from a default treatment CMYK by any other client.
> 
> A test is provided which verifies that the colours are interpreted reasonably, both on initial read
> and on write and re-read. 
> 
> JPEGs with embedded profiles have been tested on read, but since there are licensing issues with those,
> the test uses JPEGs which have no embedded profile and depend on an internal implementation class.
> 
> That class has its hashCode() method updated because testing showed that toString() invoked hashCode()
> in a way that caused a StackOverflowError - so nothing per se to do with this fix but a necessary update.
> 
> Anyone who has trustworthy CMYK JPEGs that render properly in (eg) major web browsers but not with this
> code can submit those JPEGs so I can evaluate.
> 
> But all our automated tests pass as well as some manual testing and evaluation etc.

Note that [`gray_cmyk.jpg`] ([![gray_cmyk.jpg]][`gray_cmyk.jpg`]) looks more like a greyish brown (`#4A4642`) on my end.

[`gray_cmyk.jpg`]: https://github.com/openjdk/jdk/blob/2573ebdc1afe0c46b621c39195ffd49bf2f724a2/test/jdk/javax/imageio/plugins/jpeg/CMYK/gray_cmyk.jpg
[gray_cmyk.jpg]: https://raw.githubusercontent.com/openjdk/jdk/2573ebdc1afe0c46b621c39195ffd49bf2f724a2/test/jdk/javax/imageio/plugins/jpeg/CMYK/gray_cmyk.jpg

src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleCMYKColorSpace.java line 66:

> 64: 
> 65:     public int hashCode() {
> 66:         return getClass().hashCode()+7;

Alternatively, you could do:
Suggestion:

        return System.identityHashCode(theInstance);

which seems to have been the original intent.

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

PR: https://git.openjdk.java.net/jdk/pull/7849