[Insight-users] UnaryFunctorImageFilter and MetaDataDictionnary
Luis Ibanez
luis.ibanez at kitware.com
Thu Mar 18 12:05:52 EDT 2010
Hi Gaetan,
I think this is still an open issue.
The solution will require that we identify a set of use cases,
and a set of tests that implement such cases, so that we
can experiment with reasonable solutions.
Probably the best way to go about it is to create a Wiki page
for this issue in the Proposals page:"
http://www.itk.org/Wiki/ITK_Oversight_Committee#2010
Would you like to do this ?
Thanks
Luis
---------------------------------------------------------------
2010/3/10 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>
> 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
>
>
More information about the Insight-users
mailing list