医学图像之DICOM格式解析

医学影像学

  • 医学影像学Medical Imaging,是研究借助于某种介质(如X射线、电磁场、超声波等)与人体相互作用,把人体内部组织器官结构、密度以影像方式表现出来,供诊断医师根据影像提供的信息进行判断,从而对人体健康状况进行评价的一门科学,包括医学成像系统和医学图像处理两方面相对独立的研究方向。
  • 仪器主要包括X光成像仪器、CT(普通CT、螺旋CT)、正子扫描(PET)、超声(分B超、彩色多普勒超声、心脏彩超、三维彩超)、核磁共振成像(MRI)、心电图仪器、脑电图仪器等

DICOM简介

  • DICOM(Digital Imaging and Communications in Medicine)即医学数字成像和通信,是医学图像和相关信息的国际标准(ISO 12052)。它定义了质量能满足临床需要的可用于数据交换的医学图像格式。DICOM被广泛应用于放射医疗,心血管成像以及放射诊疗诊断设备(X射线,CT,核磁共振,超声等),并且在眼科和牙科等其它医学领域得到越来越深入广泛的应用。在数以万计的在用医学成像设备中,DICOM是部署最为广泛的医疗信息标准之一。当前大约有百亿级符合DICOM标准的医学图像用于临床使用。
  • 目前采用的标准是DICOM3.0,其组成如下图:
    第一部分:概述
    第二部分:兼容性

    第四部分:

    服务类说明

    第三部分:信息对象 第十一部分:介质存储应用
    第五部分:数据结构和定义
    第六部分:数据字典
    第七部分:信息交换网络操作 第八部分:网络支持TCP/IP 第九部分:点对点通信
    第十部分:介质存储和文件格式
    其余部分:特殊媒质格式和物理介质、打印、安全机制

DICOM文件

  • DICOM文件是指按照DICOM标准而存储的医学文件,一般由一个DICOM文件头和一个DICOM数据集合组成,结构图如下图
  • DICOM文件头包含了标识数据集合的相关信息,每个DICOM文件都必须包括一个文件头:
  1. 文件导言,由128个字节组成。
  2. DICOM前缀,可根据这长为4个字节的字符串是否等于“DICM”来判断该文件是不是DICOM文件。
  3. 文件信息元素
  • DICOM文件的主要组成部分是数据集,它是由DICOM数据元素按照指定的顺序依次排列组成的。对于DICOM文件,一般采用显式传输,数据元素按照标签Tag从小到大顺序排列。最基本的单元是数据元,数据元主要由4个部分组成:
  1. 标签Tag:一个16位的无符号整数的有序对,前8位表示组号,后8位表示元素号。
  2. 值表示:指明该数据元素中的数据是哪种数据类型。
  3. 值长度:一个16位或者32位的无符号整数,表示了数据域的长度。
  4. 数据域:存在这个字段的值的数据类型由这个数据元素的值表示决定,且它的存储长度为偶数个字节。

标签Tag

每个数据元素从前到后可以简单分段:文件元tag,普通tag,像素tag。

  • 文件元tag(组号+0000):不受传输语法影响,总是以显示VR方式表示,因为它里面就定义了传输语法;文件元tag的dataElement,并没有多大的意义,它的VF数值是整个组所有dataElement的字节长度,一个dicom中可以只有一个文件元tag,也可以有多个文件元tag。
  • 普通tag:除了文件元tag和像素tag,其余的都是普tag数据。包括:图像宽,高,数据传输格式,病人姓名,病人生日,病历医院,病历科室,病情的描述等等数据。
  • 像素tag(7fe0,0010):表示dataElement存储的是病历的图像数据。比如tag(0002,0010)决定普通tag的读取方式 little字节序还是big字节序,隐式VR还是显示VR。由它的值决定。tag(7fe0,0010)像素数据开始处。其他部分重要tag如下图。

DCM文件

  • 符合DICOM标准的文件通常后缀为.dcm。当选择一个DICOM文件进行显示时,DICOM文件的后缀名是DCM或dcm,对文件名的后缀名检查后就可以初步判定文件是否为DICOM文件,但是后缀名满足要求并不代表是标准的DICOM文件,需要打开文件,跳过128字节的文件导言,然后读取四个字节,检查这四个字节的数据是否为“DICM”。当满足要求时,可以判断该文件时一个DICOM文件。

解析DICOM文件

可以利用Sante DICOM Viewer查看DICOM数据

  • 跳过128字节的文件导言,读取“DICM“四个字节,确认是DICOM格式的文件
  • 读取重要的数据元素,如传输语法等。0010组号描述患者信息,0008组号描述特征参数。
  • 读取普通的tag,直到ttag(7fe0,0010),即像素数据开始处。像素数据的存储顺序,从左到右,从上到下。

原文地址:https://www.cnblogs.com/XDU-Lakers/p/9863114.html

时间: 2024-10-14 03:30:36

医学图像之DICOM格式解析的相关文章

Dicom格式文件解析器

转自:http://www.cnblogs.com/assassinx/archive/2013/01/09/dicomViewer.html Dicom全称是医学数字图像与通讯,这里讲的暂不涉及通讯那方面的问题 只讲*.dcm 也就是diocm格式文件的读取,读取本身是没啥难度的 无非就是字节码数据流处理.只不过确实比较繁琐. 分析: 整体结构先是128字节所谓的导言部分,说俗点就是没啥意义的破数据 跳过就是了,然后是dataElement依次排列的方式 就是一个dataElement接一个d

Dicom文件解析

Dicom全称是医学数字图像与通讯,这里讲的暂不涉及通讯那方面的问题 只讲*.dcm 也就是diocm格式文件的读取,读取本身是没啥难度的 无非就是字节码数据流处理.只不过确实比较繁琐. 好了 正题 分析 整体结构先是128字节所谓的导言部分,说俗点就是没啥意义的破数据 跳过就是了,然后是dataElement依次排列的方式 就是一个dataElement接一个dataElement的方式排到文件结尾 通俗的讲dataElement就是指tag 就是破Dicom标准里定义的数据字典.tag是4个

开源项目OkHttpPlus——支持GET、POST、UI线程回调、JSON格式解析、链式调用、文件上传下载

OkHttpPlus介绍 项目地址:https://github.com/ZhaoKaiQiang/OkHttpPlus 主要功能:OkHttp封装,支持GET.POST.UI线程回调.JSON格式解析.链式调用.小文件上传下载及进度监听等功能 为什么要写这么一个库呢? 首先,是因为OkHttp在4.4之后已经作为底层的Http实现了,所以OkHttp这个库很强大,值得我们学习. 其次,在我看来,OkHttp使用起来不如Volley方便,OkHttp的回调都是在工作线程,所以如果在回调里面操作V

Python pyc格式解析

简书链接:http://www.jianshu.com/p/03d81eb9ac9b 这篇文章只是纯粹分析python pyc文件格式,主要是关于pyc在文件中的存储方式进行了解析.pyc是python字节码在文件中存储的方式,而在虚拟机运行时环境中对应PyCodeObject对象.关于PyFrameObject以及PyFunctionObject等运行时结构,后续希望学习透彻了能够一并分析. 1.示例文件 源文件test.py s = "hello" def func(): a =

ELF格式解析库之抽象数据类型

抽象?抽谁的象? ELF是一种链接执行格式,它规定了对于一个ELF文件的基本数据类型是什么样的.可是,要解析一个ELF文件,而这个ELF文件或者是32Bits 或者是 64Bits,反正字长是未定的,怎么办?难道我们要定义两套解析的接口,以对应不同的字长的ELF文件吗?如果要这样做,不是不可以,只是那样做为接口的设计增加了太大的负担.这里我们采用"抽象"的方式,将已有的两套基础数据结构封装成一个兼容的数据结构.这样,我们设计解析接口时,可以做到尽量的简化,大大的减轻了工作量. 因此,这

视音频数据处理入门:FLV封装格式解析

===================================================== 视音频数据处理入门系列文章: 视音频数据处理入门:RGB.YUV像素数据处理 视音频数据处理入门:PCM音频采样数据处理 视音频数据处理入门:H.264视频码流解析 视音频数据处理入门:AAC音频码流解析 视音频数据处理入门:FLV封装格式解析 视音频数据处理入门:UDP-RTP协议解析 ===================================================

TS格式解析

1.TS格式介绍 TS:全称为MPEG2-TS.TS即"Transport Stream"的缩写.它是分包发送的,每一个包长为188字节(还有192和204个字节的包).包的结构为,包头为4个字节(第一个字节为0x47),负载为184个字节.在TS流里可以填入很多类型的数据,如视频.音频.自定义信息等.MPEG2-TS主要应用于实时传送的节目,比如实时广播的电视节目.MPEG2-TS格式的特点就是要求从视频流的任一片段开始都是可以独立解码的.简单地说,将DVD上的VOB文件的前面一截c

ELF格式解析库之提取信息

看,宝藏就在那儿 在上一篇文章中,我们提到用按图索骥比喻库的初始化过程,那么现在有了地图,接下来的事情就是去寻找我们感兴趣的宝藏了.这个宝藏可能是一个ELF文件的程序文本段,也有可能是程序的某个不知名的代码段,这些都取决于你想要什么信息.我建议你去阅读ELF 的官方标准,那里边讲的比较清楚. 我这里只是实现了几个提取诸如:程序的大小端,能执行的CPU位数,程序的入口点,以及获得程序的所有节的编号和根据节的编号获取该节的详细信息. 提取信息:程序的大小端 1: long ELF_GetELFEnd

PES,TS,PS,RTP等流的打包格式解析之PES流

PES,TS,PS,RTP等流的打包格式解析之PES流 版权声明:本文为博主原创文章,未经博主允许不得转载. 因为工作接触到了各种不同的音视频封装格式,常见的国标PS流,onvif的RTP流和TS流等,都说好记性不如烂笔头,抽空总结下,也好在以后能随时查阅,因水平问题,可能会有地方有疏漏和问题,还请指教 一.PES流 PES流是对原始ES流进行的第一层封装,PES流的基本单位是PES包,由包头和payload组成,ES流即音视频裸流,是从编码器里面出来的原始视频音频流:ES流只包含一种内容,里面