[Insight-users] Problems with templated image

[Luis Ibanez]

Hi Jarek,

I see your point better now,

You're right about the ImageFileReader, the image type
of the output has to be selected at compile time.

Let's consider your application in which two types of
MRI images can be introduced as input (16 and 32 bits).

Can we assume that the lower dynamic range of 16bits is
good enough for the particular processing you are applying ?
and that the interest in accepting 32 bits in only motivated
for compatibility ?

We could in that case say that as soon as the data is read
into your program it can be safely converted to 16 bits.

This can be done in (at least) two ways:

1) declaring a ImageFileReader< ImageType16Bits >
and relying on the default casting that RAWImageIO,
MetaImageIO, (or another customized reader) performs
during reading.

2) declare two ImageFileReaders,
   one templated over  ImageType16bits, the other
  templated over ImageType32bits.

The output of both will be converted to a common
ImageType (that you can decide to be either 16 bits
32 bits, or for example "float" or "double").

The conversion to this 'common' image type can
be done by using the ShiftScaleImageFilter or the
RescaleIntensityImageFilter.

Once with this common image type your application
can proceed with a pipeline that applies the appropriated
operations on your data.

In order to decide which reader to use, you can made
a selection at run time from a GU I, or you may want
to create your own customized ImageIO class.

Note that the ImageFileReader can register as many
ImageIO variants as you want. Each one of these ImageIO
classes should provide a method returning a boolean
that indicates if it is able to read a particular image file
or not.

In both cases, you may want to write two classes :

1) MRI16bitsImageIO
2) MRI32bitsImageIO

Each one of them should reimplement the "CanReadFile()"
virtual method defined in the ImageIO base class.

You can then instantiate factories for each one of these
readers and register the factories with the ImageFileReader.

In this way, when you pass a filename to the ImageFileReader,
the currently registered ImageIO variants will be called
sequentialy in order to determine which one could be capable
of reading the file *and* convert it to the ImageType of the
ImageFileReader<>.

In the future you can go on adding more variants of MRIImageIO
for various formats. (and you can customize inside them how
do you want the conversion to be done from the pixel type on
the file to the pixel type on the template argument of
ImageFileReader)


We will be glad to help you implement a new ImageIO class
if you are interested in following this path.


Please let us know if any of those could be an acceptable
solution for the application you are considering.


   Thanks


      Luis



================================

Jarek Sacha wrote:

>Luis:
>
>I absolutely agree with you. For medical applications in particular, image
>type should not be changed and pixel values should not be scaled.
>
>The problem is that type input of input data may vary. A simple example, I
>am getting data from an MRI scanner, it is 16 bit or 32 bit, depending how
>an operator sets it up. I would like to have single program that handles
>both cases without image conversion.
>
>My knowledge of ITK is limited, so I may be mistaken, but it looks to me
>that you have to specify image type when you declare image reader. At
>runtime, if the input image has different type then it is converted to the
>type of image reader. And you really do not have any control over that
>conversion. ITK forces image conversion on input since there is no
>suitable mechanism to handle various image types at runtime (without
>conversion).
>
>What I would like to have functionality in ITK that allows writing
>pr
>
>ograms able to perform processing that matches input image type, no
>conversion. Of course that program should handle any input image type
>(within some conceivable bounds). I mean here variable pixel type as a
>minimum and also variable image dimension. To enable this the inheritance
>hierarch should be extended for templated data representation objects. For
>instance, an abstract non-templated image class (derived from DataObject)
>should be added.  Templated image classes should be derived from that
>abstract image class. Pointer to that abstract image class could be passed
>down the pipeline. Processing objects could use information obtained
>through that pointer to allocate at runtime filters templated by type of
>image they are operating on. To make it clear both templated and 'dynamic'
>code should be possible.
>
>I will try to write another email later today, maybe in new thread, that
>would show an example and explain in some more detail h
>
>ow I see it. If you
>see some mistakes in my reasoning so far please let me know.
>
>Jarek
>
>--- Luis Ibanez <luis.ibanez@kitware.com> <mailto:luis.ibanez@kitware.com> wrote:
>
>>About the difficulty for managing image types
>>at run time in ITK: I'm affraid to disagree
>>with Jarek on this point.
>>
>>My personal opinion (which probably is not shared
>>by other ITK developers) is that medical image
>>operations should NOT make types transparent for
>>developer nor users.
>>
>>Pixel-type transparency is probably Ok for
>>"Photoshop-kind" of turn-key applications where
>>you want to make things very easy for users and
>>provide rapid results.
>>
>>ITK is intended to be used in clinical practice
>>for managing real medical images that a doctor
>>can use for finding a tumor or guiding a surgery.
>>
>>The pixel type in a medical image makes the difference
>>between detecting an early tumor or not, and that is
>>a *huge* difference !
>>
>>Once you connect a series of filters in a type-transparent
>>pipeline it is very hard to keep track of the intermediate
>>losses and therefore is not easy to be confident in the
>>reliability of the final output.
>>
>>Pixel type transparency will result in careless
>>and irresponsible management of medical information.
>>It will probably produce nice pictures but is not
>>what we may want to be used by clinicians.
>>
>>
>>(Sorry for being dogmatic on this).
>>
>>
>>
>>      Luis
>>
>>