DICOM 标记 0008,0018 SOPInstanceUID 变体

Question

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

0002,0003   MediaStorageSOPInstanceUID
0004,1511   ReferencedSOPInstanceUIDInFile
0008,0018   SOPInstanceUID
0008,0058   FailedSOPInstanceUIDList
0008,1155   ReferencedSOPInstanceUID

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

Answer 1

拥有两个具有相同 SOP 实例 UID 的不同 DICOM 文件是完全合法的。当无损仅压缩 DICOM 数据集时，这种情况经常发生。

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

只要像素数据的专业解释可能受到影响（例如有损压缩），就需要应用程序更改 SOP 实例 UID。

您可能会在 GDCM wiki 上找到关于什么是 DICOM 中的推导机制的最小解释：

http://gdcm.sourceforge.net/wiki/index.php/Writing_DICOM

但无论如何，如有疑问，您应该始终参考 DICOM 标准。

作为旁注，根据定义，媒体存储 SOP 实例 UID 和 SOP 实例 UID 是相同的。来自组 0x2 的信息只是从 DICOM 数据集派生而来，以生成有效的第 10 部分 DICOM 文件。

Also Referenced SOP Instance UID In File 有点特殊，因为它属于组 0x4。因此它可能只存在于 DICOMDIR 数据集中，这不是典型的 DICOM 数据集。 DICOMDIR 只需要索引媒体上的其他 DICOM 文件（例如 CDROM...）

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

而且很明显，引用的 SOP 实例 UID 不可能与 SOP 实例 UID 具有相同的值，因为它会在 DICOM 数据集中创建一个自引用循环。

DICOM 标记 0008,0018 SOPInstanceUID 变体

DICOM tag 0008,0018 SOPInstanceUID variants

dicom