[Insight-users] Problems with templated image
Jarek Sacha
galicjan at yahoo . com
Tue, 28 May 2002 20:42:51 -0700 (PDT)
Luis, Mark:
In the future, I should eat my dog food first.
After reading last Luis' e-mail things snapped into right place. Here is
the idea. If you have a pipeline that is dependent on the input image type
and that type is known only at runtime you can do following:
1) Enclose the pipeline into a class templated on input image pixel type
and possibly dimension. For instance:
template <class TPixel>
class MyPipeline {
public:
void SetFileName(const char* fileName) { ... }
void Update() {
...
ImageFileReader<Image<TPixel> >
reader = new ImageFileReader<Image<TPixel> >::new();
...
}
}
2) Detect image file type using only ImageIO and then allocate and execute
properly parametrized pipeline, for instance:
TiffImageIO::Pointer io = TiffImageIO::New();
io->SetFileName(inputFileName);
io->ReadImageInformation();
if(io->GetPixelType() == std::typeid(unsigned char) ) {
MyPipeline<unsigned char> myPipeline;
myPipeline.SetFileName(inputFileName);
myPipeline.Update();
}
else if(io->GetPixelType() == std::typeid(unsigned short) ) {
MyPipeline<unsigned short> myPipeline;
myPipeline.SetFileName(inputFileName);
myPipeline.Update();
}
... // and so on
Note that this should not lead to any image pixel type conversions and for
each image pixel type processing will be done on its original pixel type.
In particular class MyPipeline can implements an image file type converter
using different ImageIO for reader and writer (assuming that ImageIOs of
interest are already implemented :).
Louis, thank you very much for your suggestions and patients. I really
appreciate them.
Jarek
--- Luis Ibanez <luis.ibanez@kitware.com> wrote:
>
> 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
> >>
> >>
>
>
>
>
> _______________________________________________
> Insight-users mailing list
> Insight-users@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-users
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com