Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Grayscale PNG conversion increase brightness #437
Original issue 326 created by peacech on 2012-04-27T06:35:20.000Z:
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
I fixed the problem using this snippet (note: messy code, I'm not a java programmer) in method decode in Res9patchStreamDecoder class:
BufferedImage im2 = new BufferedImage(w + 2, h + 2, BufferedImage.TYPE_4BYTE_ABGR);
Comment #1 originally posted by yyjdelete on 2012-05-16T05:53:42.000Z:
Comment #2 originally posted by connor.tumbleson on 2012-11-16T13:19:59.000Z:
Comment #4 originally posted by hackermiww on 2013-03-20T12:08:57.000Z:
is there a method to avoid the problem?
Comment #5 originally posted by connor.tumbleson on 2013-03-26T15:25:03.000Z:
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:
The root of problem can be reduced to he question
There are three ways to access image pixel data (data buffer):
a) use setRGB/getRGB
The difference between these approaches shows up when image uses color
At the moment our implementation is following:
Note that if pixel data are used by paired methods only (e.g. setRGB/getRGB
Fortunately this inconsistency has limited impact because it is
As the result the custom image will be look brighter then
Note that similar problem theoretically may happen with other color
Also note that generic blits use setRGB/getRGB so for custom images
It seems that solution is to add conversion logic to blits (because it
For instance at the moment it seems we only have to worry about "gamma
Solution is to use the ImageTypeSpecifier class, with this class a new BufferedImage with the same parameters as the original can be created, even if the returned type is unknown!
Comment #7 originally posted by connor.tumbleson on 2013-07-08T16:19:47.000Z:
It passed all my testing so far and seems to work great. I will run a few more tests and pass it to some testers and then merge it in.
I see no color changes on multiple decodes and rebuilds.