[Insight-users] Image pixel type safety

[Mathieu Malaterre]

On Tue, Nov 24, 2009 at 10:19 PM, Wagner Sales <wsales at gmail.com> wrote:
> Hi all,
>
> I'm working with DICOM images and I'm looking for a pixel type safety.
> I know are possible to use GDCMImageIO to ask about the pixel type of
> an image. May be that's are the better way to read, register or
> segment images. But in most cases ( registration are the most
> important ) I have two different pixel types. Commonly, DICOM are 12
> bit per pixel ( 4096 ), but I really don't know if are safe to read
> all images without ask, but using a double or float as pixel type.
> Many examples in ITK and others that's uses ITK simple define the
> pixel type as float, for example. But this examples, in most cases,
> expect a well known image to work (provided with the example). What's
> I'm asking are: can I assume a fixed pixel type ( of course, a large
> value, like double, and not a char, wish only supports 0-255 ) to read
> images and do registration/segmentation? For example
>
> typedef itk::Image<float,3> ImageType;
>
> or
>
> typedef itk::Image<double, 3>  ImageType;
>
> Because some float issues, I'll prefer the second option.
>
> If can I assume this, are implications? Of course, if I didn't my
> house work, please point me in a direction.

DICOM does not support floating point image. The only case where you
can have floating point image is when you have a Rescale Slope /
Intercept.
In which case the type used to describe the linear transformation ax +
b where a,b are of type VR:DS (see DICOM PS 3.5-2008 for
clarification) which is closely represented by a ieee double precision
floating point type.

So in summary: yes double will always work.

Now the second question is: in a templated framework such as ITK; do
you really want to process unsigned short image using double ?

HTH
-- 
Mathieu