On Fri, 18 Mar 2022 18:21:06 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. > > Phil Race has updated the pull request incrementally with one additional > commit since the last revision: > > 8274735: javax.imageio.IIOException: Unsupported Image Type while > processing a valid JPEG image src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleCMYKColorSpace.java line 66: > 64: > 65: public int hashCode() { > 66: return System.identityHashCode(theInstance); Is it just a cleanup or it has some other reason? src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java line 1740: > 1738: raster.setRect(sourceLine); > 1739: if (invertCMYK) { > 1740: byte[] data = > ((DataBufferByte)raster.getDataBuffer()).getData(); Is it known that the type of the raster here is always DataBufferByte? ------------- PR: https://git.openjdk.java.net/jdk/pull/7849