JDK-6395551 : Setting destination type to type specifier returned by redr.getImageTypes() throws exception for JPG
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.imageio
  • Affected Version: 1.4.2,6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-03-08
  • Updated: 2011-01-19
  • Resolved: 2006-03-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b77Fixed
Related Reports
Duplicate :  
JDK-6357444 - JPEG: setDestinationType() causes IOException in case of embedded ICC profile.
Relates :  
JDK-4893408 - JPEGReader throws IllegalArgException when setting the destination to BYTE_GRAY
Description
I am creating an IIS from the given jpg image and getting the corresponding reader from ImageIO. Calling ImageReader.getImageTypes(0) returns 4 ImageTypeSpecifiers (2 types of 3BYTE_BGR, 1 BYTE_GRAY and 1 TYPE_CUSTOM). I am setting the destination type to the first returned image type specifier by calling param.setDestinationType(typeSpecifier) and using this param to read the image. ImageReader throws IIOException saying the destination type specified in the param does not match. 

This is incorrect. The first type specifier returned by getImageTypes() is supposed to be the most appropriate destination type for the given image. Setting the destination type to the second type specifier in the returned array works fine (which is also 3BYTE_BGR). 

javax.imageio.IIOException: Destination type from ImageReadParam does not match!
at javax.imageio.ImageReader.getDestination(ImageReader.java:2862)
at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(JPEGImageReader.java:892)
at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(JPEGImageReader.java:864)
at KannanImageIOTest.<init>(KannanImageIOTest.java:53)
at KannanImageIOTest.main(KannanImageIOTest.java:116)

This is reproducible on all platforms atleast since 1.4.2. 

I have attached a sample test. Execute the sample test, passing the given image as an argument. You would see the original image loaded in the top (labelled 'Original'). This is read through Toolkit API. Below that, you are supposed to see a grid of 3x3 images (total 9 images). First image on the first row would be the output of setDestinationType, second one on the first row would be setDestination (typeSpecifier.createBufferedImage) and third image on the first row would be setDestination (new BufferedImage(x,y, type.getBufImageType())). The first image will not be loaded in this case because of the above exception. 

Second and third rows represents the second and third image type specifiers returned by getImageTypes(). TYPE_CUSTOM is skipped since it takes huge time to load the image.
Comments
EVALUATION The root of this problem is that we re-create new ColorSpace instance for embedded color profile each time when image header is read. In addition, we have no way for correct comparison of ColorSpace and ICC_Profile classes: they do not override the equals method. Due to this, we are unable to compare instances of ImageTypeSpecifier class: if color model used color space based on embedded profile, then specified type never be found in the list of destination types. Proposed workaround for this problem is as follow: we are trying to detect the case when existing iccCS instance contains same profile data as newly read. If so, we leave "old" instance, else (if profile data seems to be different) we create new color space instance for embedded color profile. Please note that regression test skips failure in case of GRAYSCALE type. It is because the bug 4893408 that is not fixed yet.
10-03-2006