[Insight-users] DicomImageReadChangeHeaderWrite---0002|0003

[x0_y0_0]

Thank you very much,Todd Jensen. I overwrite gdcmFileHelper.cxx as followed:
                 std::string sop = "1.2.86.755.4.2.4.24.1.3.201";
                 CopyMandatoryEntry(0x0002,0x0003,sop);
and then rebuilt ITK(InsightToolkit-3.8.0),but  the SOP Instance UID become wrong:
     (0002|0003) Media Storage SOP Instance UID = 1.2.826.0.1.3680043.2.1125.1.78291920758156013450636231478551699
I don't know what's wrong with it?
 
regards,
                                                                                mexiao




在2009-05-08 20:56:07，"Todd Jensen" <todd.jensen at ieee.org> 写道：

> 
> I used the example DicomImageReadChangeHeaderWrite.cxx to change the dicom file,when I wrote it as followed:
>              std::string entryId( "0002|0003" );
>              std::string value( "1.2.86.755.4.2.2.24.1.3.201");
>                itk::EncapsulateMetaData<std::string>( dictionary, entryId, value );
>and the result is "(0002|0003) Media Storage SOP Instance UID = 1.2.826.0.1.3680043.2.1143.68351427
>608.2009050811121070158". Why? How can I change it ?Could anyone help me ?thanks.

The underlying GDCM library bundled with ITK overwrites this element with a UID it generates. You have to walk the code and you will find in Utilities/gdcm/gdcmFileHelper.cxx->CheckMandatoryElements():

  :
std::string sop =  Util::CreateUniqueUID();
  :
CopyMandatoryEntry(0x0002,0x0003,sop);
CheckMandatoryEntry(0x0008,0x0018,sop);
  :

This overwrites your value.

If it was made CheckMandatoryEntry(0x0002,0x0003,sop), that would solve your issue.

Also, the code as is allows the two SOP Instance UIDs to be different when they should be the same.

Todd Jensen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090511/482a26f5/attachment-0001.htm>