fixing tuple issue and adding meta data independence option

[smichi23]

I fixed the tuple issue and added an optional argument which uses the SOPInstanceUID and SOPClassUID to refer to the CT images instead of the MediaStorageSOPInstanceUID and MediaStorageSOPClassUID.

The test case I added simply shows that the code still does its job even using the other uids. I wanted to add a real test case verifying the values added in the contour sequence, but unfortunately, the test case Dicom files all have the same SOPInstanceUID and MediaStorageSOPInstanceUID (which is not the case in almost all my clinical cases).

[asim-shrestha]

Hi @smichi23, I'm not sure the exact reason why the MediaStorage versions were used. We initially used the Pydicom CLI tool that generated code to create a given RTStruct and so the MediaStorage values may have just been a byproduct of that. I will look into whether we can just use SOPInstanceUID and SOPClassUID as is which should help simplify things.

[asim-shrestha]

So from some quick searching, it looks like the "MediaStorage" versions of these attributes are defined to have the exact same values as their counterparts but exist in the file meta information header for quicker access. We should be able to just swap to using SOPInstanceUID and SOPClassUID instead.

Links

• https://forum.dcmtk.org/viewtopic.php?t=3405
• https://stackoverflow.com/questions/32689446/is-it-true-that-dicom-media-storage-sop-instance-uid-sop-instance-uid-why

[asim-shrestha]

@smichi23 i pulled these changes and updated your changes to simply use SOPInstanceId everywhere. You can find this here https://github.com/qurit/rt-utils/pull/37. Thanks for the fixes!