JDK-4776576 : REG: ImageIO reader produces an incorrect image when read as a RenderedImage
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.imageio
  • Affected Version: 1.4.2
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2002-11-09
  • Updated: 2002-11-17
  • Resolved: 2002-11-17
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.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
JDK-4712797 - ImageIO fails to decode YCbCr JPEGs that do not have a JFIF marker
Description
The last known build with which the testcase worked was Mantis (1.4.2) b03

STEPS TO REPRODUCE:

1. Run  "java ReadWriteRasterTest"
2. Click on the Raster button. The image (flor2.jpg attached) is loaded and rendered.
3. Click on the RenderedImage button. The image is rendered but looks totally messed up with colors when compared to the image rendered using step 2.

The failure occurs on all platforms (tested with Win2K, Win98, Sparc 8, Sparc7).

We haven't verified with png images yet.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b08
14-06-2004
EVALUATION This regression was caused by the fix for 4712797, which was integrated into 1.4.2b04. The evaluation for that bug was partially correct in that some YCbCr images are not *horizontally* subsampled and also do not contain an APP0 marker. Taking a step back, the original sample image in question for 4712797 was indeed a YCbCr image. The original evaluation mentioned that it was not subsampled at all, but in fact the image has vertical subsampling factors of (2,1,1) and horizontal subsampling factors of (1,1,1). The original code (before the fix for 4712797 was put in place) had a comment that said: // Nobody does vertical without horizontal, so just check horiz[ontal] Obviously this is an invalid assumption, because the 4712797 sample image did have vertical subsampling, but not horizontal. The fix for 4712797 was to simply avoid the check of the horizontal subsampling factors and to always assume that images without a JFIF APP0 marker are in the YCbCr color space. But there are images (such as the flor2copy.jpg image generated (via the Image I/O JPEGImageWriter) by the attached testcase) that do not have an APP0 marker, but are actually RGB images. If you look at the subsampling factors for this type of image, you'll find both the horizontal and vertical factors to be (1,1,1); in other words, non-subsampled. This is exactly the kind of image that was being checked for in the original code. The problem with the original code, however, is that it only looked at the horizontal subsampling factors to determine whether it should be tagged as RGB. Perhaps this was just an assumption made to avoid four checks and instead do two. In any case, the optimal fix (that would solve both 4776576 and 4712797) would be to reinstate the original code that checks subsampling factors, but expand it so that it checks vertical as well as horizontal factors: if ((h_samp1 == h_samp0) && (h_samp2 == h_samp0) && (v_samp1 == v_samp0) && (v_samp2 == v_samp0)) { cinfo->jpeg_color_space = JCS_RGB; /* output is already RGB, so it stays the same */ } This is a tighter check that will retag the image as RGB iff there is no subsampling (in either direction). Note that the existing Toolkit JPEG decoder does not contain any of this special case code, so that decoder will continue to produce images with incorrect colors if it encounters non-subsampled images of this nature (it assumes they are YCbCr). It is not clear whether we should take the time to update that decoder, as I have a feeling that the Image I/O JPEGImageWriter is the only writer that produces these strange images. We can revisit this case at a later time. Also note that in the same block of code (setSource() in imageioJPEG.c) we make similar assumptions about CMYK/YCCK images based only on horizontal subsampling factors. We should probably check the vertical factors as well just to make certain that the retagging is appropriate. ###@###.### 2002-11-12
12-11-2002