[Insight-developers] viewing nifti files with 3.2 release

[kent williams]

Going back through the source, here's what happens:

Internal to itk::NiftiImageIO, the rescale/slope is being applied.

InsightApplications/ImageViewer always requests an image of floats.

Since the datatype of the file on disk is a scalar, and a scalar is
requested as the image pixel type, a Grey-to-Grey pixel conversion is
specified. The grey to grey conversion is just a static cast, so in this
case, unsigned chars in the range 0...255 are converted to floats in the
range 0.0...255.0

The ImageViewer app uses FLTK, and OpenGL, and draws slices by using the 2D
slice data as a texture on a polygon in the view window.

If you can send me (or send me a web link or ftp link) to one of these
Images I can have a look at the header to try and see what's going on.

What I think SHOULD go on is that if the offset is non-zero, or the slope is
greater than 1.0, narrow pixel types should be reported back to
itk::ImageFileReader as wider types, so that the scaling operation doesn't
overflow. I thought at one point I had done this to itk::NiftiImageIO, but
apparently I either dreamed I did, or someone removed what I coded from the
code.

The thing that might be happening is that the slope is 1/255, and the result
is supposed to be in the range 0.0...1.0.  In that case, since the pixel
scaling is happening in the native pixel type, only pixels of 100%
probability will be non-zero.

None of the code involved -- the viewer, NiftiImageIO, ImageFileReader,
niftilib -- have changed substantially any time in the past year or so, so I
don't know what version of the code you were using that had substantially
different behavior.


On 9/11/07 7:35 PM, "Richard Beare" <richard.beare at gmail.com> wrote:

> Hi Everyone,
> 
> It is a little while since I updated, to this change may have been
> around for a while without me noticing. I'm not sure what the best way
> of dealing with this is.
> 
> The issue arose for me looking at nifti image tissue probability maps
> generated by spm5. These images are stored as unsigned char along with
> a scaling factor. Previously the ITK nifti reader ignored the scaling
> factor, but it now seems to honor it. The problem arises when
> software, such as ImageViewer, needs to attempt to guess the
> appropriate voxel type to use.
> 
> Currently, I presume, it probes the reader reported pixel type using
> something like:
> reader->GetImageIO()->GetComponentTypeInfo();
> and determines that the underlying type is an unsigned 8 bit integer.
> The appropriate part of the ImageViewer is then called. However the
> reader is then required to apply the scale transform such that the
> output is an integer type which, in the case of a probability map,
> results in an image of mostly zeros with the occasional 1.
> 
> Naturally enough, seeing blank images is a bit disconcerting. I'm not
> sure if there is a better way of dealing with this problem - I
> certainly don't see a solution that will work for every situation. Is
> there some way of checking the reader for scaling, or
> enabling/disabling it?
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers