I’m using the following code to load a grayscale JPG image, and query a single pixel’s value from it:
Raster data;
data = ImageIO.read (file).getData();
int [] buf = new int[1];
data.getPixel(0, 0, buf);
The image I’m using for test purposes is this one:
When I open this image in Photoshop, and extract the colour information from the top left pixel, it tells me it is pure black (RGB 0,0,0). As far as I can see, there is no colour profile attached to the image, so it should be loaded identically by ImageIO. However, the result of the above code is that buf[0] contains 1. As my intended application is sensitive to this change (I am processing map elevation data with 0 indicating sea level or lower) I am wondering if either
- I can rely on it always happening, and can rely on RGB 1,1,1 not also being decoded as value 1 (testing this, I get ‘3’ out), or
- there is any way of preventing the change?
Preventing the change would clearly be preferable — if black is coming out as 1, and having tested white and seeing it come out as 250, this must mean that some values in the middle are going to be compressed so multiple source values come out with the same output value, so I am clearly losing information here. I’d ideally want to avoid information loss (and, yes, I’m aware that information was lost in the conversion of the map data to JPG, but this is how it was supplied to me by the original data provider, so it is impossible for me to recover that data… I’d like to avoid losing any more of it, though).
What’s probably happening is that the JPEG does not have an embedded colorspace, and Photoshop’s default colorspace is different from Java’s default, resulting in slightly different pixel values. For example, Java could be assuming sRGB while Photoshop might be using AdobeRGB. You should verify that you’re using the same colorspace in both Photoshop and Java.
EDIT:
I examined the image you included in your post with Photoshop, and found the following interesting info:
<exif:ColorSpace>65535</exif:ColorSpace>Whatever is giving you (0,0,0) for the top-left corner and (255,255,255) for the bottom-right is applying some conversion function to the raw data, which is most definitely not pure black and pure white in this file.
Here’s the entire XMP raw data set: