Signed integer Img is displayed incorrectly by



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
using (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 to display the converted
images, this is inconvenient, and violates the principle of
least surprise.

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
to convert signed integral Imgs to IJ1 GRAY32 images (underlying
pixel data type float).

If not, perhaps calling 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.)

Thanks, mm.

Is there a pure IJ2 mechanism for displaying images using stock Fiji?
Is there a pure IJ2 mechanism for displaying images using stock Fiji?

Would you mind opening an issue in imglib2-ij describing your observations?


Hello Stefan,


Signed integer Img is displayed incorrectly by #13

Thanks, mm