Hi all,
It has been recently pointed out to me that converting an image from 8bit to 32bit (like with the image calculator) first converts the image to RGB in some cases...
If you run this code, you will see what I mean (courtesy of Peter Bankhead)
run("Blobs (25K)");
run("Grays");
run("Measure");
id1 = getImageID();
run("Duplicate...", " ");
setMinAndMax(50, 100);
run("Measure");
id2 = getImageID();
imageCalculator("Subtract create 32-bit", id1, id2);
rename("Should I not be zero?");
run("Measure");
He then showed me this snipped in the TypeConverter.java file
FloatProcessor convertByteToFloat(float[] cTable) {
if (!ip.isDefaultLut() && !ip.isColorLut() && !ip.isInvertedLut()) {
// apply custom LUT
ip = convertToRGB();
ip = convertRGBToByte();
return (FloatProcessor)convertByteToFloat(null);
}
...
so basically if an 8bit image has a non standard lookup table that is not a color LUT and that is not inverted, it will first run an RGB conversion... Why??
On top of that it is in no means affected by the "scale when converting" tag... Though it has not occurred to us yet, is this not a big problem? It makes no sense to do any kind of scaling on the pixel data like this...
If someone could shed some light as to why it is done like this, I would really appreciate it.
Best
Oli
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html
Locked
