First of all, a big thank you to the ImageJ developers; this application has truly simplified a lot of things for me.
Now the issue.
Turns out I need ImageJ to losslessly process an unsigned 16-bit grayscale image, but whether the image has beforehand been converted to this format and loaded as such or not (thus leaving conversion to ImageJ itself), it makes no matter; ImageJ will automatically modify it in a way that would appear as if it were being corrected for better contrast, but this is NOT the desired behavior.
To better explain where I’m going, please take this deliberately washed out 512x512 raw 8-bit grayscale image. Load it into ImageJ, go to Image/Type and select either 16-bit or 32-bit; the original values are immediately lost and the image will be displayed with a modified contrast.
To the best of my understanding (which may not even be remotely close to acceptable), this isn’t something that naturally happens during this type of conversion (taking the 8-bit image, then going 32-bit and then back to 16-bit will effectually convert it to 16-bit), because I can do more or less the same thing in Photoshop losslessly, which’s a technical requirement in my case.
Can anything be done to rectify this behavior in ImageJ?
I do not believe that ImageJ is actually modifying the image
itself – that is, the values of the image pixels – but, rather,
how the image is displayed. (Further explanation, below.)
I will work (in Fiji) with a locally-created image, rather than your
File > New > Image...
Fill with: Ramp
(Size can be whatever – 512x512, if you will.)
This gives you a full-range, 0–255, 8-bit, grayscale image. Now
we wash it out:
Process > Math > Divide...
Process > Math > Add...
Now the image is somewhat washed out, with a range of pixel
values of 64–192. Do Image > Show Info... to see the
image info, and note that the display range is 0–255.
Now convert to 16-bit:
Image > Type > 16-bit
The displayed image no longer appears washed out. However,
if you run Image > Show Info... again, you will see a display
range of 64–192, the minimum and maximum of the pixel values
in the image. ImageJ did set this display range automatically,
but it didn’t actually modify the pixel values.
If you hover the cursor over a pixel in the image, Fiji’s status bar
will display its value. So if you move the cursor from left to right
over the ramp image (from darker to lighter) you will see in the
status bar pixel values running from 64 to 192, verifying that
you still have the original pixel values.
You can display the 16-bit image with a display range of 0–255
so that you can see that it is still washed out:
Image > Adjust > Brightness/Contrast...
Minimum displayed value: 0
Maximum displayed value: 255
Now the image displays in its original, washed-out form.
Running, again, Image > Show Info... shows that you have
indeed reset the display range to 0-255.
I believe that ImageJ’s 8-bit --> 16-bit conversion is, in fact,
lossless (as is its 8-bit -->32-bit conversion), but automatically
sets the display range.
Depending on your particular use case, you could either just
ignore the way the displayed image looks, and work with the
(losslessly-converted) pixels, or you could explicitly set the
display range back to 0–255 after the conversion.
This won’t help with what it sounds like Porsche is seeing.
The “Scale When Converting” setting doesn’t affect lossless
up-conversions (e.g., 8-bit -> 16-bit). Rather, it affects
the potentially lossy down-conversions, i.e.,
32-bit -> 16-bit
32-bit -> 8-bit
16-bit -> 8-bit
and, for down-conversions, turning it off will tell the conversion
process not to change the pixel values.
Regardless of this option’s setting, the 8-bit -> 16-bit
up-conversion will not change the pixel values, and will set
the display range, causing the appearance of displayed image