[Insight-developers] ITK_Origin + MetaDataDictionaryArray + GDCM2

[Mathieu Malaterre]

On Mon, Oct 5, 2009 at 6:09 PM, Daniele E. Domenichelli
<daniele.domenichelli at gmail.com> wrote:
> 2009/10/3 Mathieu Malaterre <mathieu.malaterre at gmail.com>:
>>> Using GDCM 1 user can set origin of the image adding to the
>>> MetaDataDictionaryArray the entry (0020|0037) because there is a check:
>
>
> Sorry... this is a typo, should be  (0020|0032)
>
>
>>> <from itkGDCMImageIO.cxx>
>>>
>>>  if( !header->GetValEntry(0x0020,0x0032 ) )
>>>   {
>>>   [write origin in str]
>>>   header->InsertValEntry(str.str(),0x0020,0x0032);
>>>   }
>>>
>>>
>>> Using GDCM 2 origin are calculated and tags are created by gdcm::image
>>
>> I did not quite follow your bug description. What I'd like to know is:
>> Is there is a difference in behavior in between GDCM 1.x and GDCM 2.x
>
>
> Yes, there is a difference, but now I'm not sure if this is a bug in
> ITK or in GDCM... I'll try to explain better:
>
> GDCM 1) Setting tag (0020|0032), this tag is attached in the produced DICOM
> GDCM 2) Tag (0020|0032) is discarded due to this:
>
>
> ----
>
> <from itkGDCMImageIO.cxx>
> 1328 #ifdef GDCM_MAJOR_VERSION < 2
> 1329 void GDCMImageIO::Write(const void* buffer)
> 1330 {
>        [...]
> 1516 if( !header->GetValEntry(0x0020,0x0032 ) )
> 1517  {
>        [write origin in str]
> 1543  header->InsertValEntry(str.str(),0x0020,0x0032);
> 1544  }
>        [...]
> 1859 }
> 1860 #else
> 1861 void GDCMImageIO::Write(const void* buffer)
> 1862 {
>        [...]
> 2012 image.SetOrigin(0, m_Origin[0] );
> 2013 image.SetOrigin(1, m_Origin[1] );
> 2014 image.SetOrigin(2, m_Origin[2] );
>        [...]
> 2260 }
> 2261
> 2262 #endif
>
> ----
>
>
> So if tag (0020|0032) is set in MetaDataDictionary it should be passed
> to the image.
> But then if MediaStorage is SecondaryCaptureImageStorage (default for
> itk) this tag is removed from gdcm::ImageHelper
> Otherwise it is replaced with the value of origin set by
> gdcm::image::SetOrigin()
>
>
> ---
>
> <from GDCM2 gdcmImageHelper.cxx>
> 1256   if( ms == MediaStorage::SecondaryCaptureImageStorage )
> 1257     {
> 1258     Tag ipp(0x0020,0x0032);
> 1259     ds.Remove( ipp );
> 1260     }
>         [...]
> 1316   // Image Position (Patient)
> 1317   gdcm::Attribute<0x0020,0x0032> ipp = {{0,0,0}}; // default value
> 1318   ipp.SetValue( origin[0], 0);
> 1319   ipp.SetValue( origin[1], 1);
> 1320   ipp.SetValue( origin[2], 2);
> 1321
> 1322   ds.Replace( ipp.GetAsDataElement() );
>
> ---
>
>
> So, using GDCM 1 if user sets tag (0020|0032), this tag is in
> MetaDataDictionary and in the output DICOM files
> Using GDCM 2 this tag is always discarded and due to ImageSeriesWriter
> that doesn't set ITK_Origin tag if a MetaDataDictionaryArray is set,
> the third value of origin vector is always = 0.
> If no MetaDataDictionary Array is set, this value seems to be written
> correctly using ITK_Origin.
>
>
> I hope this time you can follow my description...

Ok. If you can write out a SC Image Storage with an IPP or IOP then
this is a bug in GDCM 1.x. I need to make sure people understand that
SC Image Storage (even the new Enhanced SC Image Storage) does not
have those attributes. The major issue that I can think of is that a
series of 2d SC objects will never be loaded as 3D volume on any PACS
out there.
I believe the behavior in GDCM 2.x is the proper one (dciodvfy should
also report no error on those attributes)

HTH
-- 
Mathieu