JDK-5051418 : Grayscale TYPE_CUSTOM BufferedImages are rendered lighter than TYPE_BYTE_GRAY
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.3.1,1.4.1,1.4.2,5.0,6,6u10,8,9
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS:
    solaris_8,solaris_9,windows_2000,windows_xp solaris_8,solaris_9,windows_2000,windows_xp
  • CPU: x86,sparc
  • Submitted: 2004-05-21
  • Updated: 2015-08-26
  • Resolved: 2015-08-26
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 9
9Resolved
Related Reports
Duplicate :  
JDK-4904494 - Gray BufferedImage is too bright
Duplicate :  
JDK-6467250 - BufferedImage getRGB(x,y) problem
Relates :  
JDK-6430958 - ColorConvertOp converts too dark with gray ICC_Profile
Description
A TYPE_CUSTOM BufferedImage with the same SampleModel, ColorModel and pixel data as a TYPE_BYTE_GRAY BufferedImage is rendered differently (it shows up a lighter gray). A test case that demonstrates this is attached.

The Java Advanced Imaging API (JAI) uses a custom subclass of WritableRaster in some instances, which when converted to a BufferedImage, results in a TYPE_CUSTOM BufferedImage, causing lighter rendering to be noticed by customers. This issue was reported by a JAI customer:

http://archives.java.sun.com/cgi-bin/wa?A2=ind0405&L=jai-interest&F=&S=&P=1121
Comments
If you use ColorSpace.CS_GRAY then you end up with a linear color space. The default color space of most images and monitors would be CS_sRGB which has gamma. The BufferedImage TYPE_BYTE_GRAY also specifies ColorSpace.CS_GRAY, but we internally recognize those images and optimize their use and just treat them internally as sRGB (in other words we take the single gray value and replicate it as r, g, and b, and then do the same thing we'd do as if we had an INT_RGB image, which is sRGB) which is not quite correct. Arguably we should be converting those images from linear to gamma corrected response curves, but that would slow them down a bit. On the other hand, when faced with a totally custom image that we don't recognize, we probably go through a loop or pipe that fully color corrects the image - which does the linear-to-gamma translation. Essentially, your custom image is doing what the TYPE_BYTE_GRAY image should be doing, but we internally usher that TYPE_BYTE_GRAY image in through a back door and let it bypass lots of important processing that is specified by its attributes. Implementing this would suddenly change how regular grayscale images draw impacting user functionality so closing this as not to fix.
26-08-2015
The problem is still applicable to jdk9, because of gamma difference between rgb and grays color spaces.
03-04-2015
- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014
These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. Kind regards, Mathias
29-08-2013
These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. Kind regards, Mathias
29-08-2013
These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. Kind regards, Mathias
29-08-2013
Converted "8-client-defer-candidate" label to "8-defer-request" by SQE' OK.
15-08-2013
*This is anti-deferral criteria list*: - P2 -------------- Engineering's Criteria ------------------------------------- - tck-red labeled - conformance labeled - P3 regressions reported/labeled against jdk8 - findbugs, parfait, eht labeled bugs - CAP <1 year reported - netbeans <1 year reported Victor ----------------- SQE's OK --------------------------------- Yes, we are ok with that thanks, Mikhail
15-08-2013
EVALUATION The root of problem can be reduced to he question "What kind of data is supposed to be stored in data buffer? Is it always sRGB or native representation for used color space?" There are three ways to access image pixel data (data buffer): a) use setRGB/getRGB b) use optimized blits c) direct access to the data buffer. The difference between these approaches shows up when image uses color model based on non-sRGB color space (e.g. grayscale images). At the moment our implementation is following: - In a) case colors are actually converted from sRGB to image color space and vice versa. - In case b) results depend on implementation of the blit. Generic blits (e.g. AnyToIntArgb and IntArgbToAny) are implemented using setRGB/getRGB and therefore colors are stored in "native" form. However, other blits (e.g. ByteGrayToIntArgb and IntArgbToByteGray) do not perform any conversion and therefore we may have sRGB data in the buffer. - In case of c) no convertion is performed and raw data is used. Note that if pixel data are used by paired methods only (e.g. setRGB/getRGB or set with blit and get with blit) we end up with same output as input. However, if blit without conversion is used to set data and then data are accessed with getRGB() result is different from original data. Fortunately this inconsistency has limited impact because it is applicable to non sRGB color spaces only. Still it is easy to reproduce with grayscale images. E.g. - create TYPE_BYTE_GRAY and corresponding custom image. - fill the data buffer directly with same data. - draw image to some sRGB destination. As the result the custom image will be look brighter then TYPE_BYTE_GRAY. It is because the TYPE_BYTE_GRAY is drawn by optimized blits (without "gamma correction") whereas custom image is draw by using getRGB method (with "gamma correction"). Note that similar problem theoretically may happen with other color spaces like linear RGB. It is not easily reproducible now because we have no predefined image types based on linear RGB color space. Also note that generic blits use setRGB/getRGB so for custom images results are always consistent. It seems that solution is to add conversion logic to blits (because it seems reasonable to expect that raw data buffer contains converted data). It certainly will have performance hit and have to be done carefully. For instance at the moment it seems we only have to worry about "gamma correction" and can probably use something similar to LUT-based approach that was added to ComponentColorModel in 1.3.x.
16-08-2006
PUBLIC COMMENTS Grayscale TYPE_CUSTOM BufferedImages are rendered lighter than TYPE_BYTE_GRAY
21-08-2004
EVALUATION Not for tiger. ###@###.### 2004-05-26
26-05-2004