IJ2’s Img supports images of signed integral type, for example,
ByteType and IntType (in contrast to UnsignedByteType and
UnsignedIntType). These images are not displayed correctly
ImageJFunctions.show (img, "title"); negative values
are rendered as zero.
This is presumably due to the fact that IJ1 integral-typed
images are all, in behavior, unsigned (even though the
underlying data types for the pixels are signed java primitives
such as byte and int).
While client code can convert such images to a FloatType Img
and then use ImageJFunctions.show to display the converted
images, this is inconvenient, and violates the principle of
Even more perverse is the fact that a ByteType Img is converted
to an IJ1 GRAY16 (bitdepth=16, with an underlying java short
pixel data type), which is, in behavior, unsigned. So you double
the image size (pixels go from 8 to 16 bits), but you only get 7
bits of actual pixel data (pixel values = 0, …, 127). (This
is just weird; in contrast, UnsignedByteType gets converted to
(remains as) GRAY8. It’s as if converting ByteType to GRAY16
was a failed attempt to deal with the sign issue.)
Perhaps the simplest resolution would be for ImageJFunctions.show
to convert signed integral Imgs to IJ1 GRAY32 images (underlying
pixel data type float).
If not, perhaps calling ImageJFunctions.show on signed integral
images should be disallowed.
Lastly, given that IJ2 relies upon IJ1 for displaying images
(assuming that my understanding of this is correct), the best
solution would be to add signed integral images (or at least
display functionality for them) to IJ1. (This would be a
non-breaking change as it would extend IJ1 functionality,
without modifying current behavior.)