JDK-6279846 : Pixel values are different when source and dest ColorSpace supplied to ColorConvertOp are same
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.1.2,5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_2000
  • CPU: generic,x86
  • Submitted: 2005-06-02
  • Updated: 2011-01-19
  • Resolved: 2006-07-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.
JDK 6
6 b92Fixed
Related Reports
Duplicate :  
JDK-6345228 - ColorConvert loses color information even between the same ColorModels
Description
If the source and destination ColorSpace supplied to ColorConvertOp is the same, pixel values are different between the color converted destination and the original source. The attached test case demonstrates this problem.
###@###.### 2005-06-02 22:17:54 GMT
Comments
EVALUATION Fixed by updating sRGB profile and creating fast track (without any color transforms) for CololorConvertOps representing color spaces equal to the source and destination ones
28-06-2006
EVALUATION Inaccuracy in sRGB color space mostly was caused by usage of the obsolete sRGB ICC profile that based on the lookup tables. Updating this profile with new one (based on tonal response curves) greatly improves precision of the color transformation. Also, to avoid unnecessary conversion (like we have in attached testcase) we are going to create fast track for ColorConverOps that consist of color spaces equal to the source and destination ones. So, there will be no color transforms just transfer of pixels.
27-06-2006
EVALUATION This problem could is not only related to the images. It's also could be illustrated using more simple test: ... ColorSpace srcColorSpace = ColorSpace.getInstance(ColorSpace.CS_sRGB); System.out.println("Color.RED components " + Color.RED.getRed() + ", " + Color.RED.getGreen() + ", " + Color.RED.getBlue()); float [] red = Color.RED.getColorComponents(srcColorSpace, null); Color newRed = new Color(srcColorSpace, red, 1.0f); System.out.println("Color.RED components " + newRed.getRed() + ", " + newRed.getGreen() + ", " + newRed.getBlue()); ... Result: Color.RED components 255, 0, 0 Color.RED components 249, 0, 5 This happens because of errors in convertations between float and internal color representation of our CMM library.
19-08-2005