JDK-4886732 : AffineTransformOp does not work properly for some of the rendering hints
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0,1.4.2,1.4.2_05,6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS:
    generic,linux,windows_nt,windows_2000,windows_xp generic,linux,windows_nt,windows_2000,windows_xp
  • CPU: generic,x86
  • Submitted: 2003-07-07
  • Updated: 2008-12-17
  • Resolved: 2008-12-17
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
I have written an application which constructs a buffered image and rotates it using an AffineTransformOp. It baiscally constructs buffered image of various types and filters it using AffTransformOp using all the rendering hints. For the following buffered image types, the colors in the filtered image returned by AffineTransformOp are inverted when any of the rendering hints given in this bug description are specified.
TYPE_INT_BGR
TYPE_USHORT_555_RGB
TYPE_USHORT_565_RGB

The above buffered images are not filtered properly when any of the following rendering hints are specified.
KEY_RENDERING, VALUE_RENDER_QUALITY
KEY_INTERPOLATION, VALUE_INTERPOLATION_BILINEAR
KEY_INTERPOLATION, VALUE_INTERPOLATION_BICUBIC

All the buffered image types specified above fail for all the rendering hints given above right from JDK1.4+ on Windows. Out of these, TYPE_INT_BGR fails for all these rendering hints right from JDK1.2.2 on Win32 platforms.
On Solaris, none of these failures are reproducible.

I have attached a sample code. Execute the sample code. Choose one of the buffered image types given above and the corresponding rendering hint specified in this bug. Click the scrollbar's block increment / unit increment. You will notice that the image gets rotated to the right and all the colors in the image are inverted (Choose interpolation / rendering from the rendering hints drop-down).

This is not happening for other buffered image types / rendering hints. 

Comments
EVALUATION I have attached a program ImageTypes.java which in turn draws each of the standard image types in to a 3BYTE_BGR image with a non-integral scale. It was principally a printing test but was modified to show the problem on screen If you run it on Windows JDK's up to and including mustang b09 it can be immediately seen that TYPE_INT_BGR, USHORT_555_RGB, USHORT_555_RGB, and USHORT_GRAY (less obvious but also wrong) are all incorrect. Now run on mustang b10 and its fine. The fix is 5051527 : Faster, more direct software transformation of images However 5051527 does not address the AffineTransformOp.filter() cases described in this bug. That test case is still reproducible in mustang. Note that for some non-integral scales, those very close to integral values, the problem was already resolved in 1.5 by the fix for 4990624: Image pipeline heuristics for choosing transform code are too strict
16-03-2006

EVALUATION Doesn't look like we'll have time for this in 1.6 either..
04-08-2005

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
01-08-2004

EVALUATION Name: abR10136 Date: 08/14/2003 Problem is in conversion between medialib internal representation and java buffered image (when source and destination image types mismatch). Medialib internal representation assumes that point color is stored as int. So, while passing data to medialib we assemble int from bytes and disassemble it to bytes when process result. Unfortunatelly, these assembling/disassembleng steps are implemented by direct extraction of byte components (relying on fixed byte order) that is vulnerable to difference in the int representations by hardware (i.e. Intel vs SPARC)). Proposed solution is change assembling/disassembling to not refer to byte components directly (i.e. extract them by shifting and masking). ====================================================================== We had to back out this fix because it caused a regression: 4994576: REGRESSION: affinetransform between 2 managed images causes pallete corruption Basically, the fix shifted the problem from 16-bit image formats to some others, notably the 1-bit transparent images, which we feel are more important. Here's a discussion about possible ways of addressing this bug in the future releases: http://sa.sfbay.sun.com/mail-archive/4994576/0001.html Unfortunately we didn't have time to fix it in 1.5. ###@###.### 2004-04-22
22-04-2004