从CT和MR图像都生成了DICOM文件(人造轴向切片)。聚合文件是否可以包含CT和MR DICOM标签?例如。 Echo Time (0x18, 0x81)
和KVP (0x18,0x60)
?带有CT和MR标签的DICOM文件
我无法找到任何信息,不管一个图像模态模块是否是另一个图像模式,并且想知道这样的人造图像是否可能会与其他供应商的软件碰到麻烦。任何帮助将不胜感激。
从CT和MR图像都生成了DICOM文件(人造轴向切片)。聚合文件是否可以包含CT和MR DICOM标签?例如。 Echo Time (0x18, 0x81)
和KVP (0x18,0x60)
?带有CT和MR标签的DICOM文件
我无法找到任何信息,不管一个图像模态模块是否是另一个图像模式,并且想知道这样的人造图像是否可能会与其他供应商的软件碰到麻烦。任何帮助将不胜感激。
属性SOP类UID(0008,0016)确定您拥有哪种“对象类型”,并由此确定所谓的信息对象定义(IOD)。 IOD告诉你,哪些属性是强制的,哪些属性是允许的(并且隐含地:哪些是不允许的)。
因此,合并关于来自两个不同IOD的采集过程的属性并不是一个好主意。 DICOM查看器中的这些对象的注释将会广泛地失败。大多数观看者都有一个SOP Class或Modality相关的配置,用于定义如何使用DICOM头信息对图像进行注释。 SOP Class UID和Modality必须提供一个完全正确的值。因此,您必须决定是否有其他应用程序将图像视为“仅限CT”或“仅限MR”。
因此,没有合并IOD表的方法,并且仍然声明生成此类图像的应用程序的DICOM一致性。
我知道很多系统只是将DICOM头视为“属性流”而不是正确性和一致性。只要您的像素数据和订购信息(患者姓名,ID,...,研究实例UID,系列实例UID)被正确编码,就可能发生您不会遇到严重问题。
但是,我绝不会建议任何人实施这样的事情。这只是一个时间问题,有人会根据DICOM标准验证您的对象,发现他们是公然错误的,并且认为没有人会比您更糟糕。
正如其他人所解释的,您需要遵循DICOM标准。基本上你需要实现你的SOP类实例的相关IOD中定义的内容。
正如其他人所解释的那样,您可以使用所谓的“标准扩展SOP类”。但是,请务必仔细阅读这样的类定义:
引用的一段话:
标准扩展SOP类应:
- 是一个适当的超一套标准SOP类;
- 不改变该标准SOP类的任何标准属性的语义;
- 不包含任何私有类型1,1C,2或2C属性,也不添加额外的标准类型1,1C,2或2C属性;
- 不会将任何标准类型3属性更改为类型1,1C,2或2C;
- 使用与其所基于的标准SOP类相同的UID。
因此,在总结,不,你肯定不能用剩下的kVp(0018,0060)属性创建一个MR例如,它不可能意味着在这种情况下要更改的语义的MR模式什么一个公共属性。
非常感谢您的信息!没有澄清:我的扩展类将基于CT SOP类,并且不会改变CT SOP类的语义。它会引入额外的类型3属性,例如Echo Time标签。你看到这样的设置有什么问题吗? –
基本上,我同意你的回答......除了你的陈述“所以,没有合并IOD表的方法,并且仍然要求生成这种图像的应用程序的DICOM一致性。”这是因为在某些条件下,它实际上是可能的。这种类型的SOP类被称为“标准扩展SOP类”:http://dicom.nema.org/medical/dicom/current/output/html/part02.html#sect_3.11.3 - 当然,还有也专门和私人SOP类:-) –
感谢您指出,这对我来说真的是新的。你有没有在实践中见过标准扩展SOP类? –
@ J.Riesmeier你忽略的一个重要观点是[7.3规则类型的SOP类](http://dicom.nema.org/medical/dicom/current/output/chtml/part02/sect_7.3.html): “不改变该标准SOP类的任何标准属性的语义”。那么请告诉我什么“kVp”对MR实例意味着什么? OP的答案显然是:不,毫无疑问。 – malat