United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-5051418 Grayscale TYPE_CUSTOM BufferedImages are rendered lighter than TYPE_BYTE_GRAY
JDK-5051418 : Grayscale TYPE_CUSTOM BufferedImages are rendered lighter than TYPE_BYTE_GRAY

Details
Type:
Bug
Submit Date:
2004-05-21
Status:
Open
Updated Date:
2014-03-14
Project Name:
JDK
Resolved Date:
Component:
client-libs
OS:
solaris_9,solaris_8,windows_xp,windows_2000
Sub-Component:
2d
CPU:
x86,sparc
Priority:
P3
Resolution:
Unresolved
Affected Versions:
1.3.1,1.4.1,1.4.2,5.0,6,6u10
Targeted Versions:
9

Related Reports
Backport:
Duplicate:
Duplicate:
Relates:

Sub Tasks

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
EVALUATION

Not for tiger.
###@###.### 2004-05-26
                                     
2004-05-26
PUBLIC COMMENTS

Grayscale TYPE_CUSTOM BufferedImages are rendered lighter than TYPE_BYTE_GRAY
                                     
2004-08-21
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.
                                     
2006-08-16
*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

                                     
2013-08-15
Converted "8-client-defer-candidate" label to "8-defer-request" by SQE' OK.
                                     
2013-08-15
These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. 
Kind regards,
Mathias
                                     
2013-08-29
These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. 
Kind regards,
Mathias
                                     
2013-08-29
These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. 
Kind regards,
Mathias
                                     
2013-08-29



Hardware and Software, Engineered to Work Together