dicom

DICOM设备Raw Data与重建 现在的医疗影像设备基本都已DICOM为标准。但现在许多医院的技术人员都以为只要支持DICOM就一切OK，其实不然。DICOM中有Storage、Print、Worklist、Storage Commitment等很多部分。影像传输其实只用到了Storage部分。 分清楚了不同DICOM功能，每一个功能中还分SCU/SCP。U是User，P是Provider。某项功能动作的发起者就是User，反之是Provider。例如：Storage。设备要往其他服务器传输图像，那么设备就是SCU，存储图像的服务器就是Provider。所以现在所有的影像设备都支持Storage SCU，但不一定支持Storage SCP。再如：所有的激光相机必须支持Print SCP，但都不支持Print SCU。 DICOM虽是标准，但它也不是万能的。其中影像设备Raw Data的问题就容易让人迷惑不解。记得五年前，有一家医院的第三方厂商要给医院做PACS软件，但调试后接收失败也不知道原因，就对医院说需要直接读取硬盘中的Raw Data。结果医院把我们的工程师关了一晚，只是因为工程师也不知道怎么拿出来。后来经过沟通和解释，医院才知道这样拿数据的缺点，也才把工程师放了。 这里说的是另一件事。有一家医院的医生要做64排CT的薄层重建，但因为时间相隔较长

一 概述 DICOM标准是要解决在不同的地点、不同设备制造商、不同国家等复杂的网络环境下的医学图像存储和传输的问题。要在这样复杂的情况下能够实现准确的无歧义的信息交换，当然存在许多技术问题，基本问题有语法和语义两大类。 所谓语义的问题就是指交换信息的具体含义。通常人们都是用自己的语言(称自然语言)进行交流，但世界上使用的自然语言种类繁多，还存在二义性问题，表达的意思存在多种含义，使得计算机处理有困难，这在医疗技术方面更是要解决的问题。因此DICOM中专门定义了自己的“语法”和“词汇”。DICOM的“词汇”是用一对整数表示的，称为标记(Tag)，用数据字典给出详细的定义和解释。另外用UID的方法给出唯一标识。 语法则是指信息组成的规则。在DICOM中，数据种类相当多，被分成各个层次，有信息对象定义(IOD)、消息(Message)、命令集、数据集、数据元素、传输语法等。只有通信双方按约定的统一的方法组织数据，才可能准确获得对方传输的信息。 下面就DICOM标准中数据定义、表示，以及组织所涉及到的概念和方法加以介绍，并通过一些具体实例帮助理解。 二 数据组织形式 1. 唯一标识符UID 这个标识可被用在世界上不同地点的多制造商环境中。为保证每个标识的全球的唯一性，使用了下面的字符串(称为唯一标识符或UID)产生机制: <根>.<后缀> 根部分是由权威部门支持的

国外开源的PACS服务器 罗朝辉（ http://www.cnblogs.com/kesalin/ ） 本文遵循“ 署名-非商业用途-保持一致 ”创作公用协议 名称： Dcm4che 评级：★★★★★ 开源许可：GPL LGPL MPL 功能： 影像处理，影像归档，影像管理，影像传输，Worklist支持 标准：DICOM，HL7，IHE，MPPS，WADO 语言：英语 客户端： 桌面，基于web 平台：跨平台 编程语言：Java 数据库：MySQL，Postgre SQL，Firebird 官方网站： http://www.dcm4che.org/ 名称： DCMTK-DICOM Toolkit 评级：★★★★★ 开源许可：BSD 功能： 影像处理，影像归档，影像管理，影像传输 标准：DICOM 语言：英语 客户端： 桌面 平台：跨平台 编程语言：C/C++ 官方网站： http://dicom.offis.de/ 名称： CDMEDIC PACS WEB 开源许可：GPL 功能： 影像处理，影像归档，影像管理，影像传输 标准：DICOM 语言：英语，西班牙语 客户端： 基于web 平台：Unix，Mac OS 官方网站： http://cdmedicpacsweb.sourceforge.net/ 名称： Conquest DICOM software 开源许可：Public

附录C 图像格式 译者： Synge 发表时间：2012-05-03浏览量：1604评论数：0挑错数：0 翻译：xiaoqiao 在fMRI的早期，由于大多数据都用不同研究脉冲序列采集，然后离线大量重建，而且各研究中心文件格式各不相同、大多数的分析软件也都是各研究单位内部编写运用。如果这些数据不同其他中心交流，数据的格式不影响他们的使用。因此图像格式就像巴别塔似的多式多样。随着fMRI领域的不断发展，几种标准的文件格式逐渐得到了应用，数据分析软件包的使用促进了这些文件格式在不同研究中心和实验室的广泛运用，直到近期仍有多种形式的文件格式存在。这种境况在过去的10年里随着公认的NIfTI格式的发展和广泛认可而优化。该附录就fMRI资料存储的常见问题以及重要的文件格式做一概述， 3.1 数据存储 正如第2章所述，MRI数据的存储常采用二进制数据格式，如8位或16位。因此，磁盘上数据文件的大小就是数据图像的大小和维度，如保存维度128 ×128×96的16位图像需要25,165,824位 (3 兆字节)。为了保存图像的更多信息，我们希望保存原始数据，即元数据。元数据包含了图像的各种信息，如图像维度及数据类型等。这点很重要，因为可以获得二进制数据所不知道的信息，例如，图像是128 ×128×96维度的16位图像采集还是128 ×128×192维度的8位图像采集

Meta Element Group Length (0002,0000) 1 UL File Meta Information Version (0002,0001) 1 OB Media Storage SOP Class UID (0002,0002) 1 UI Media Storage SOP Instance UID (0002,0003) 1 UI Transfer Syntax UID (0002,0010) 1 UI Implementation Class UID (0002,0012) 1 UI Implementation Version Name (0002,0013) 1 SH Source Applica... Entity Title (0002,0016) 1 AE Identifying Group Length (0008,0000) 1 UL Specific Character Set(0008,0005) 1 CS 特殊字符集 Image Type (0008,0008) 1-n CS 图像类型 AXIAL = 确定一个CT轴图像 LOCALIZER = 确定一个CT定位器图像 SOP Class UID (0008,0016) 1 UI SOP类UID SOP Instance UID (0008,0018) 1 UI SOP实例UID