DICOM标签0008,0018 SOPInstanceUID变体

twy*_*yly 2 dicom

我有一个关于跟随DICOM标签的问题

0002,0003   MediaStorageSOPInstanceUID
0004,1511   ReferencedSOPInstanceUIDInFile
0008,0018   SOPInstanceUID
0008,0058   FailedSOPInstanceUIDList
0008,1155   ReferencedSOPInstanceUID
Run Code Online (Sandbox Code Playgroud)

看起来都是一样的.我是如何获得新的0008,0018值的,并且两个文件具有相同的值是可能的?

mal*_*lat 15

这与具有相同SOP实例UID的两个不同DICOM 文件完全合法.当无损压缩DICOM数据集时,这种情况会发生很多.

由于压缩是无损的,因此包含像素数据的DICOM的专业解释不可能受到影响,因此保留完全相同的SOP实例UID是合法的.

每当像素数据的专业解释受到影响(例如,有损压缩)时,需要应用程序来改变SOP实例UID .

您可以在GDCM wiki中找到DICOM中派生机制的简要解释:

但无论如何,如果有疑问,你应该总是参考DICOM标准.

作为旁注,根据定义,媒体存储SOP实例UID和SOP实例UID是相同的.来自组0x2的信息仅从DICOM数据集导出,以生成有效的Part-10 DICOM文件.

另外引用SOP实例UID在文件中是特殊的,因为它属于组0x4.因此,它可能只存在于DICOMDIR数据集中,而不是典型的DICOM数据集.DICOMDIR只需要在媒体上索引其他DICOM文件(例如CDROM ......)

失败的SOP实例UID列表也不存在于典型的DICOM数据集中,因为它只应存在于C-STORE响应数据集中.

显然,引用的SOP实例UID不可能具有与SOP实例UID相同的值,因为它将在DICOM数据集中创建自引用循环.