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

[Michael Halle]

Miller, James V (GE, Research) wrote:
> Hans,
>
 > ...
> 
> 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.

Thanks, Jim. I was thinking about this one, and I believe that whether 
or not a field gets passed is more likely a function of the filter, 
rather than the data or field.  A prefix-based system is solely 
data-based, so it might prove too limited.

It it turns out you want to do something less than pass everything, you 
might want a mechanism for filters to choose "pass all metadata fields" 
(default), "block all fields", "pass these specific fields" "block these 
specific fields", or "let me modify these specific fields".

Another possibility is to have broad categories of field types that you 
could choose to pass or block, but I don't know how that would be 
implemented.

> 
> 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.

What we need, and perhaps what other people need, are two things:
* The ability to carry along multiple coordinate systems through the 
pipeline,
* The ability to do so using code representations (e.g., object methods 
or functions) rather than data representations like direction cosines. 
The multiple map projects astronomers use are just too complex to 
reimplement in ITK, so we use a dedicated library to do the transforms. 
  Performance isn't an issue, because we aren't calling these functions 
in a tight loop (nor do we expect ITK to).


> 
> I'd like to discuss this on the ITK tcon this week.  Are you available?

I'll be there. Thanks again.

--Mike