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

Reply via email to