[Insight-developers] NIfTI orientation issue

kent williams norman-k-williams at uiowa.edu
Tue Oct 27 11:53:24 EDT 2009


Unfortunately, the MetaData idea has not been consistently implemented, and
understanding why it's there, and why in particular there is support for it
in the NIfTI reader/writer means understanding the history.

Hans Johnson did the original addition of Metadata before there was any sort
of orientation information stored as part of an image. The first reason for
it being included was to add a way to store orientation as 'out of band'
data with images.

Now, obviously, having a general metadata infrastructure was valuable from
the standpoint of, e.g. keeping DICOM tags with an image.

But for the Metadata infrastructure to be consistently implemented, it would
have to be propogated down pipelines, but it has never been consistently
implemented.  And it raises issues that aren't easy to definitively settle,
like what to do when a particular filter makes changes in its output that
might conflict with the metadata.

Once ITK added orientation information to Images, it made storing
orientation in the metadata obsolete; and in fact it never was globally
implemented, so it could never be depended on anyway.

It would be nice if we did a comprehensive review of how metadata is
actually used, and what it would require to ensure that it's propogation was
consistent.  But as always, we're all prioritizing available time and
Metadata keeps getting pushed down.  ITK enhancement and maintainence, at
least at organizations not directly funded for ITK work, is driven by the
needs of actually funded research.

On 10/27/09 10:36 AM, "Mathieu Coursolle" <mathieu at rogue-research.com>
wrote:

> Hi,
> 
> I am not sure I understand that issue... Is the metadata currently
> copied in the pipeline ?
> I also noticed that the metadata in the itkNiftiImageIO has predefined
> keys starting with ITK_.
> Is that a standard to follow if I had the metadata from the NIfTI
> header ? I think that the GDCM reader
> just uses the DICOM tags as the keys.
> 
> Thanks,
> 
> Mathieu
> 
> On 2009-10-27, at 11:22 AM, Luis Ibanez wrote:
> 
>> Mathieu,
>> 
>> No objection from my corner...
>> 
>> But, please note the related thread regarding the subsequent
>> passing of the MetaDataDictionary through the pipeline:
>> http://www.itk.org/pipermail/insight-users/2009-October/033423.html
>> 
>> 
>>    Regards,
>> 
>>            Luis
>> 
>> 
>> -------------------------------------------------------------
>> On Tue, Oct 27, 2009 at 9:26 AM, Mathieu Coursolle
>> <mathieu at rogue-research.com> wrote:
>>> Hi,
>>> On the same topic, the itkNiftiImageIO has a function called
>>> DumpNiftiHeader
>>> used to output
>>> the header information.
>>> Any objection on all this header information being added to the
>>> metadata
>>> dictionary ?
>>> Thanks,
>>> Mathieu
>>> On 2009-10-26, at 1:59 PM, Mathieu Coursolle wrote:
>>> 
>>> Hi ITK developers,
>>> I am using the itkNiftiImageIO to load NIfTI image data. The NIfTI
>>> file
>>> format defines 2 different methods to map voxels
>>> to physical coordinates. One of those methods is using a quaternion
>>> and is
>>> defined when the qform_code > 0. The other
>>> method is using a linear transform and is defined when the
>>> sform_code > 0.
>>> Looking at the code which sets the orientation based on the NIfTI
>>> header, it
>>> seems to prioritize the qform over the sform.
>>> (See void NiftiImageIO:: SetImageIOOrientationFromNIfTI(unsigned
>>> short int
>>> dims))
>>> However, there are some cases where I would need both the qform and
>>> the
>>> sform transforms once the data is loaded.
>>> I guess one option would be to add them as part of the metadata ?
>>> Could we do something like:
>>> EncapsulateMetaData<std::vector<std::vector<double>
>>>>> (this->GetMetaDataDictionary(),"qform", myQForm);
>>> EncapsulateMetaData<std::vector<std::vector<double>
>>>>> (this->GetMetaDataDictionary(),"sform", mySForm);
>>> Any other suggestions ?
>>> Thanks,
>>> Mathieu
>>> _________________________
>>> Mathieu Coursolle, ing.jr., M.Ing.
>>> Rogue Research Inc.
>>> www.rogue-research.com
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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://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-developers
>>> 
>>> 
>> 
> 
> _______________________________________________
> 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://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-developers



More information about the Insight-developers mailing list