[Insight-users] Image access philosophy

[Luis Ibanez]

Hi Neil,

It may be worth to make a distintion between the itk::Image
class and the itk::ImageIO classes.

The itk::Image class is a templated class intended to serve
as DataCarrier. No processing at all is performed by this
class. You have quite a lot of flexibility on how you want
to define the class. Any pixel type and any dimension can
be used for instantiating an image in itk.

On the other hand, ITK has ImageIO objects. Those are service
classes intended to read specific file formats.

The ImageIO base class defines an interface for which most
of the methods are overloaded in derived classes. The individual
ImageIO classes are capable of recognizing specific file formats.

The reading mechanism works by registering factories of ImageIO
classes in the ImageFileReader and ImageFileWriter. When you provide
a name for the file you want to read the ImageFileReader queries
all the registered factories looking for one that will recognize
its file format. Specific instances of ImageIO classes are for
example: RawImageIO, MetaImageIO, DicomImageIO, PNGImageIO.

There is not really a "native" ITK file format. All of the ImageIO
classes are born equal.

---

The current programs in the Application directory are quite diverse.
some of them are capable of reading PNG, some expect MetaImages,
some expect Raw images. This is something that cannot be managed
at the toolkit level, it is rather an application design issue.

Among the current ImageIO classes, the fileformat that provides
more flexibility is the MetaImage format. It support any dimension
and any of the basic C++ types as pixel types.

The architecture for IO in ITK was designed to be modular and
extensible. This means that you can always implement your own
ImageIO reader for your favorite image fileformat and register
its factory with ITK.

Currently, ImageIO objects for reading Analyze and Gipl format
are being added to the toolkit.



Please let us know if you have further questions.


   Thanks


     Luis


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

Neil Killeen wrote:

> Hi all
> 
> A small question regarding the Image class interface so
> that I get my expectations matched to reality...
> 
> You have an abstract class defining your interface for images.
>>From this a number of other classes are derived to handle
> a range of physical file formats - raw image, meta image, dicom image
> etc.  This is very elegant.
> 
> Now in principle this means that any itk application that accesses
> an image can auto-detect the format of the specified file
> and automatically use the appropriate class to read it.  The application
> just uses a pointer to the base class of course.
> 
> To do this requires static functions that can figure out
> what format a file is in (of course for raw image this would not
> work as you still need the dimensionality) and this is not always
> a totally trivial exercise.  This all then gets packaged up
> so the application programmer just calls one function and
> get back a pointer which has created the correct derived class
> object.
> 
> So there are three basic models for accessing images
> 
> . Transparent native access to all supported file formats
>   for all applications
> 
> . There is a native itk format, and foreign formats are filled or
>   converted to this format in an extra step. All
>   applications then operate  on the native format.
> 
> . Each application reads a specific format only which has
>   to be documented.
> 
> 
> So my question is, what model does itk follow (or perhaps another ?) ?
> 
> The reason i ask really is that i downloaded some BrainWeb
> data (meta image and raw image) and tried a couple  of the
> example programs on it.   They failed with a variety
> of i/o errors or segmentation failures (urk).   Really, all
> i want to be able to do to start with is read an image and
> print out some numbers or display it (but i haven't got vtk to build yet...)
> to make sure things are working.  The test programs ran ok, and the example
> program MetaImageReadWrite happily did its thing.
> 
> A second question is, if there is a native itk image storage
> format, is it tiled for efficiency ?
> 
> 
> thanks
> Neil
> 
> 
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-users
> 
>