United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6395551 : Setting destination type to type specifier returned by redr.getImageTypes() throws exception for JPG

Details
Type:
Bug
Submit Date:
2006-03-08
Status:
Closed
Updated Date:
2011-01-19
Project Name:
JDK
Resolved Date:
2006-03-22
Component:
client-libs
OS:
generic
Sub-Component:
javax.imageio
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2,6
Fixed Versions:

Related Reports
Duplicate:
Relates:

Sub Tasks

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.
                                     
2006-03-10



Hardware and Software, Engineered to Work Together