我有一个关于跟随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数据集中创建自引用循环.