相关疑难解决方法(0)

根据DICOM规范,UID由以下内容定义:9.1 UID编码规则.换句话说,以下是有效的DICOM UID:

• "1.2.3.4.5"
• "1.3.6.1.4.35045.103501438824148998807202626810206788999"
• "1.2.826.0.1.3680043.2.1143.5028470438645158236649541857909059554"

而以下是非法的DICOM UID:

• " .1.2.3.4.5"
• "1..2.3.4.5"
• "1.2.3.4.5."
• "1.2.3.4.05"
• "12345"
• "1.2.826.0.1.3680043.2.1143.50284704386451582366495418579090595540"

因此我知道该字符串最多为64个字节,并且应该与以下正则表达式匹配[0-9\.]+.然而,这个正则表达式实际上是一个超集,因为(10+1)^64 (=4457915684525902395869512133369841539490161434991526715513934826241L)可能性要少得多.

如何精确计算尊重DICOM UID规则的可能性数量？

读取组织根/后缀规则清楚地表明我至少需要一个点('.').在这种情况下,组合至少为3个字节(字符),格式为:[0-9].[0-9].在这种情况下10x10=100,UID的长度可能为3.

看一下第一个答案,似乎有些不清楚:

除非组件是单个数字,否则每个组件的第一个数字不应为零.

这意味着:

• "0.0"有效
• "00.0"或"1.01"无效

因此,我会说一个正确的表达方式是:

(([1-9][0-9]*)|0)(\.([1-9][0-9]*|0))+

使用简单的C代码,我发现:

• f(0)= 0
• f(1)= 0
• f(2)= 0
• f(3)= 100
• f(4)= 1800
• f(5)= 27100
• f(6)= 369000
• f(7)= 4753000
• f(8)= 59049000

Root UID部分的验证超出了本问题的范围.第二个验证步骤可以处理拒绝一些不可能注册的OID(例如,有些人提到对第一和第二弧的限制).为简单起见,我们将接受所有可能的(有效)Root UID.

如何将 UUID/GUID 值8348d2c5-0a65-4560-bb24-f4f6bcba601d（我用uuid v4 进行分类）转换为 OID/DICOM UID 2.25.174506987738820548334170905323706671133？我更喜欢 JavaScript 的解决方案。请参阅维基百科）。

我用这个在线生成器转换的示例。

我正在研究DICOM门控(PET)数据.
我想人工创建一个包含门控数据的DICOM图像系列.我正在询问SOPInstanceUID的增量值,它标记每个阶段或门中的每个图像切片.

它们对于门中的每个切片具有不同的值,并且在门之间递增,但是我无法找到如何选择该值的逻辑.

是否有关于这些值的写入位置和方式的参考？

我是DICOM世界的新手,我想将修改后的DICOM文件(从PACS服务器查询的DICOM副本创建)发送回同一台服务器,作为同一患者的新系列+研究.

修改后的DICOM将是一个新的单个系列,我将最后一个子编号增加+1.我为SOPUID做同样的事情.但是,我担心在同一SUID中添加新系列的可能性在此期间被添加并被拒绝.

将新的DICOM图像发送到PACS服务器时,可接受的编号方式是什么？增加SOPUID和SUID是否足够？