[Insight-users] UnaryFunctorImageFilter and MetaDataDictionnary
Karthik Krishnan
karthik.krishnan at kitware.com
Tue Oct 27 13:00:36 EDT 2009
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
>
More information about the Insight-users
mailing list