[Insight-users] UnaryFunctorImageFilter and MetaDataDictionnary

[Luis Ibanez]

Julien,

One possible way to go about it is to add to the itkProcessObject
a method that will copy MetaDataDictionaries from one DataObject
to another.

As Bill pointed out, though, the challenge with the MetaData
Dictionary is that filters do not know how to update it.

For example:

Even for the simple case of the pixe-wise filter, imagine that someone
decides to store in the MetaDataDictionary the maximum and minimum
intensity values of the image. Users would tend to do this using some
arbitrary tag that is not necessarily an ITK standard.

Filters such as the IntensityWindowing, Sigmoid, and Normalize, that
change the intensity range of the image pixels will not properly update
the MetaDataDictionary in order to reflect the changes in the image
data.


Of course, there are other types of data that may still be valid when
passing through filters, but ... the bottom line is that the MetaData
Dictionary becomes a carrier of information that can not be certified
in a systematic way.

We can still pass the dictionary around, but with the disclaimer that
every application should use it at its own risk.

Another option that comes to mind, (since you mention that you
are deriving from the Image class), is to provide another virtual
method in the itkImageBase class, that you could overload in you
satellite image type. In this way, the action performed inside that
method is really left to your custom implementation.


    Luis


---------------------------------------------------------------------------------------------
On Tue, Oct 27, 2009 at 6:09 AM, Julien Michel <julien.michel at c-s.fr> wrote:
> Bill Lorensen a écrit :
>>
>> Luis,
>>
>> I think this change should be removed. Julien wants the
>> MetaDataDictionary copied through the pipeline. CopyInformation just
>> copies the "meta" information (spacing, origin, direction, regions,
>> etc.).
>>
>> We never provided the facility to pass the MetaDataDictionary through
>> the pipeline. I think we determined that the MetaDataDictionary could
>> get out of sync with the processed data as it passed through the
>> pipeline.
>>
>> The current change is causing CastImageFilter to fail if the
>> dimensions of the input and output do not match.
>
> Ok, instead of submitting possible fix, let me state our problem.
>
> We are developping an ITK based library to process remote sensing images
> (mainly from satellites).
>
> These data comes with a lot of geo-information such as sensor position
> and date, group control points or map projection parameters.
>
> We needed to store these information so as to be able to reproject the
> data in other geometry (one of the most useful feature is called
> orthorectification and reproject image from raw geometry to an image
> superimposable to a map).
>
> In our Image class deriving from itk::Image, we choosed to store these
> information in the MetaDataDictionnary for convenience but this is
> really not the main part of the problem.
>
> Now, UnaryFunctorImageFilter does only pixel-wise transformation, so all
> the geoinformation remains valid even at the end of a pipeline
> containing several filters deriving from UnaryFunctorImageFilter. But
> with the current implementation of this filter, there is no possible way
> to get these data passed through the pipeline.
>
> Of course, we could set these information by hand each time we use a
> UnaryFunctorImageFilter, but that makes really a lot of code
> (UnaryFunctorImageFilter subclasses are rather common, in ITK or in our
> own library).
>
> We could also rewrite every ITK subclasses of UnaryFunctorImageFilter
> (and constrain input and output dimension) but I think this is really
> not the point of using a powerful library like ITK.
>
> So we are looking for a way to make UnaryFunctorImageFilter pass trough
> some meta-information known to be still valid after pixel-wise operations.
>
> This might as well apply to other kind of data. Maybe medical imaging
> comes with information such as acquisition date, or physiological
> parameters from the patient that could be used later on by some filters.
>
> I understand that my solution is not perfect, and I would be glad to
> read any other suggestions (appart from the "by hand" thing).
>
> Thank you very much,
>
> Julien
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Julien MICHEL - Ingénieur d'études - Traitement d'images
> CS Systèmes d'Information - Division ESPACE
> Département Information Géographique & Image
> Téléphone : +33 561 17 64 27
> Email : julien.michel at c-s.fr
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>