On Thu, 17 Mar 2022 03:23:49 GMT, Phil Race <p...@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
