[Insight-users] UnaryFunctorImageFilter and MetaDataDictionnary

Wed Mar 10 22:04:13 EST 2010

Hi,

What is the status of this problem?
The bug is closed, but the fix has been reverted…

I found another situation where I'd like to have the meta data  
propagated: the FFTW real to complex is loosing the real size of the  
image on the X axis, and so store the real size in the meta data  
dictionary. The inverse transform is able to reuse this information to  
produce the correct output.
So at this time, the pipeline

   FFTWRealToComplexConjugateImageFilter ->  
FFTWComplexConjugateToRealImageFilter

produce the right output, but any computation in between produce an  
output image which may be of the wrong size.

There is a method, SetActualXDimensionIsOdd(bool), to force it to  
produce an output of the expected size, but then we are almost in the  
same situation as Julien: we have to copy some data by hand.

For this particular problem, we can make  
FFTWRealToComplexConjugateImageFilter produce a second output which is  
the real X size, but that's not very elegant.
Meta data seems better suited for this task, if they are propagated by  
the intermediate filters.

Gaëtan

Le 27 oct. 09 à 18:08, Bill Lorensen a écrit :

> This would be implemented for all DataObjects.
>
> GDCMImageIO already produces a heavyweight image. Currently no one
> except IO readers/writers are using the meta data dictionary, although
> abuse is possible.
>
> Propagation would be the same as is dome for CopyInformation.
>
> And, this is still in the thought provoking, discussion stage.
>
> Bill
>
> On Tue, Oct 27, 2009 at 1:00 PM, Karthik Krishnan
> <karthik.krishnan at kitware.com> wrote:
>> Is this supported only for UnaryFunctorImageFilters or for all
>> ProcessObjects ? Is it an overridable method ?
>>
>> Mutli-input filters ? for instance a CT image masked by a mask. Does
>> it propagate from the first input ?
>> Is the API "PassMetaDataDictionaryFromNthInputToMthOutputOn( n, m )"
>> preferred to "PassMetaDataDictionaryOn()" ?
>>
>> If supported at the DataObject level, what happens in cases where the
>> objects aren't  images ? eg. processobjects that generate transforms
>> as outputs / other decorated DataObjects ?
>>
>> Will a DICOM reader produce a heavyweight dictionary and add bloat to
>> lightweight outputs ?
>>
>> One would worry that parameters from the metadatadic will by used by
>> users in lieu of an input parameter within the library because once
>> supported, there's room for misuse, lack of type safety.. ?
>>
>> thanks
>>
>>
>> On Tue, Oct 27, 2009 at 11:35 AM, Bill Lorensen <bill.lorensen at gmail.com 
>> > wrote:
>>> I don't think we need another dictionary. As Jim Miller noted in the
>>> original bug report
>>> http://public.kitware.com/Bug/view.php?id=4625
>>>
>>> we could copy the dictionary in the CopyInformation method in  
>>> ProcessObject.
>>>
>>> I just checked all of the itk Code/ directories. For the most part,
>>> only IO classes use or encapsulate meta data dictionary information.
>>>
>>> I think we can safely copy the meta data dictionary as Jim  
>>> suggested.
>>>
>>> I'll investigate further.
>>>
>>>
>>> On Tue, Oct 27, 2009 at 10:32 AM, Julien Michel <julien.michel at c-s.fr 
>>> > wrote:
>>>> Bill Lorensen a écrit :
>>>>>
>>>>> Another possibility is for the application to observe the  
>>>>> EndEvent of
>>>>> the filters and copy the input meta data dictionary to the  
>>>>> output of
>>>>> the filter. We might be able to package this into a helper class.
>>>>>
>>>>> I'll look into this one.
>>>>
>>>> Bill,
>>>>
>>>> Sometimes we want to have access to these meta-information even- 
>>>> though the
>>>> filter execution has not yet been triggered (for instance we do  
>>>> not need to
>>>> process the whole image just to access its ground control  
>>>> points). That is
>>>> why this solution seems incomplete to me (but I might be wrong).
>>>>
>>>> If you want to make it clear that the beyond the customization  
>>>> point it is
>>>> the user responsibility to ensure data consistency, why not add a  
>>>> second
>>>> metadata dictionnary (for instance m_UserDefinedDictionnary)  
>>>> along with its
>>>> methods (virtual void GenerateOutputUserDefinedDictionnary()),  
>>>> with a
>>>> default implementation copying from first input to outputs ?
>>>>
>>>> This way it is clear that these members are provided for  
>>>> customization and
>>>> that they are the users responsibility (and it does not modify  
>>>> any of the
>>>> existing ITK functionalities).
>>>>
>>>> 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
>>>>
>>>> ~ 
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>>
>>> _____________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://www.kitware.com/products/protraining.html
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-users
>>>
>>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100311/5652fc99/attachment.pgp>