[Insight-developers] Re: Meta data dictionary passing through the ITK pipeline

[Gordon Kindlmann]

hi-

Yes- it was a somewhat analogous situation.  What I decided was for  
the command-line tools (unu and tend) to pass the key/value pairs  
(describing the DWI gradients) by default, since that was a better  
fit for idiomatic usage, but the underlying libraries (nrrd and ten)  
by default still do not do so.

The general problem with these kinds of metadata is that it never has  
the same level of structure and semantics as the per-axis or per- 
image information that filters operate on explicitly, so it can get  
out-of-synch with the image data it supposedly describes.  If you  
never pass the meta-info, you'll wish you had it in cases where its  
still valid.  If you always pass the meta-info, you can be misled  
into thinking its meaningful even after operations (like slicing or  
resampling) where it is not.  The solution is either to lower your  
expectations, or bite the bullet and add the information directly to  
the image representation where it properly belongs.

my two cents,
Gordon

On May 15, 2007, at 10:28 AM, Steve Pieper wrote:

> Hi Guys -
>
> For what it's worth, there was a similar discussion in Teem (Gordon  
> Kindlmann's package) about how to treat the metadata describing DWI  
> gradients.  At first, he didn't pass metadata for the same reasons  
> ITK doesn't.  Then he added an environment variable to turn on  
> passing the metadata.  I believe he finally decided to make it the  
> default for the data to be passed, with it being the user's  
> responsibility to know if the metadata should be trusted or not.
>
> I'm cc'ing Gordon here in case he has additional comments.
>
> -Steve
>
>
> Miller, James V (GE, Research) wrote:
>> Hans,
>> Doug Alan and Mike Halle are using the meta data dictionary  
>> mechanism to pass coordinate frame mappings for astronomical data  
>> into ITK.  These coordinate frames are nonlinear.   They are  
>> hitting on an issue that the meta data dictionary is not passed  
>> through the ITK pipeline.
>> Historically, this data has not been passed through for several  
>> reasons:
>>     * A given filter may not understand the context of the meta data.
>>       Therefore, the filter is not in a position to know whether the
>>       meta data is still valid after the filter.  For instance,  
>> lets say
>>       one of the fields in the meta data encodes pixel size.  A
>>       resampling or scaling filter may not know to look for a  
>> particular
>>       tag to change its value when moving the dictionary from  
>> input to
>>       output.  Other more subtle examples are conceivable where  
>> filters
>>       ignore particular meta data fields and the fields get passed  
>> from
>>       input to output but are no longer valid for the data being  
>> processed.
>>     * Copying the meta data dictionary may be expensive.  It could  
>> be a
>>       lot of data.
>> I can see a few options here.
>> 1. Blindly copy the meta data dictionary from input to output and  
>> buyer beware.
>> 2. Put in a mode to the pipeline to turn on copying the meta data  
>> dictionary.  This would be off by default but could be turned on  
>> when people want the meta data dictionary to move through the  
>> pipeline.
>> 3. Devise a naming convention or other attribute mechanism to  
>> label fields in the dictionary to indicate which fields can be  
>> copied by a filter.  This could be a global approach where fields  
>> with a standard prefix are copied or could be more generic where  
>> people could say to copy fields with/ this/ prefix or/ that/  
>> prefix at runtime.
>> 4. Expand the list of image parameters (spacing, origin,  
>> orientation) stored in an itk::Image to include something that  
>> will work for what Doug and Mike need.
>> I'd like to discuss this on the ITK tcon this week.  Are you  
>> available?
>> Jim
>> *Jim Miller*
>> ***//**/_____________________________________/*//
>> /////Visualization & Computer Vision
>> GE Research
>> Bldg. KW, Room C223
>> 1 Research Circle, Niskayuna NY 12309-1027
>> _millerjv at research.ge.com <_//_mailto:millerjv at research.ge.com_//_>_/
>> /(518) 387-4005, Dial Comm: 8*833-4005/
>> /Cell: (518) 505-7065, Fax: (518) 387-6981/