Open selkovjr opened 8 years ago
Making progress. I tried to work around this issue by replacing the mapper input value by a locally sourced image and got the same result with default arguments to imread. What finally worked was this combination of options:
value = makeFloatImage3(Highgui.imread(
fname,
Highgui.CV_LOAD_IMAGE_COLOR | Highgui.CV_LOAD_IMAGE_ANYDEPTH
));
Contrary to popular advice, CV_LOAD_IMAGE_COLOR is required to read color images and it does not limit their depth to 8 bits.
Now the problem is to track down the equivalent spot in the HIB import chain.
It goes like this (in ImageCodec.java):
BufferedImage javaImage = ImageIO.read(dis);
pixel = javaImage.getRGB(i,j);
int red = (pixel >> 16) & 0xff;
int grn = (pixel >> 8) & 0xff;
int blu = (pixel ) & 0xff;
Since pixel comes out 8-bit-encoded, and the input stream appears to be an intact copy of the source image, the trouble is either in ImageIO.read() or in getRGB(). I also see a couple places where BufferedImage is created with the hard-coded depth of 8 (BufferedImage.TYPE_INT_RGB), but I don't know if I hit those cases or not.
I am troubleshooting a variant of OpenCV pipeline I have set up with HIPI. It does all the same things, but results do not match. I haven't figured out an easy way to examine pixel data in a bundle (just eyeballing the codec, it appears the bytes should be stored intact), but on the user end, the FloatImage my mapper receives as input has only 256 levels between 0 and 1. The LSB fell through the cracks somewhere.
Attached is one of the images I import into the bundle. It specifies an sRGB colorspace, but I don't care and hope it does not matter. I just want linear 16-bit values out of it.