DICOMDIR文件结构: 格式: DICOMDIR文件遵照DICOM文件的存储格式,需要有128个无意义字节的前言(假如没有特殊要求,这些字节都为00H),紧接着是DICOM前缀(长度为4字节的“DICOM”字符串,判断是否为DICOM文件的唯一标准),再接着是group标签为:0x0002的elemnt,强制要求的有[0002,0000] [0002,0001] [0002,0002] [0002,0003] [0002,0010] [0002,0012]. 之后是目录信息(group为0x

转自:http://www.cnblogs.com/assassinx/archive/2013/05/18/3084854.html 说到底无非几个事情 :1传输语法确定 2数据元素读取 3 7fe0,0010元素 也就是图像数据处理.关于这整个过程已经不想多说了 在我的上上一篇博客里已经基本实现了. 当然还很有问题比如图像调窗就有bug 这个以后再说吧.众所周知dicom格式文件是由一个接一个连续的“数据元素”组成的. 这次我们只讲怎样去处理文件里一种特殊的数据元素:那就是VR为SQ类型的元

转自: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标准里

转载http://blog.sina.com.cn/s/blog_4bce5f4b01019ix5.html DICOM 文件内容在 Part 3 DICOM IOD 里定义.CT, MR, CR, DR, US, NM, PET, XA 等各有自己的内容定义,由共同的专有的部分 (IE 和 Modules) 组成. DICOMDIR 由 Part 10 定义.是一种 mini 可变长度数据库文件结构. 过去我手下一个学计算机的非常聪明的印度人问我:图像文件格式不是有 BMP, GIF, TIF

背景 前段时间博文DICOM:dcm4che工具包怎样压缩dcm文件探讨(前篇)提到了一个问题:"利用dcm4che工具包中的dcm2dcm来进行dcm文件的压缩和加压缩.即改变dcm文件里的Transfer Syntax,比如由1.2.840.10008.1.2(Implicit VR Little Endian)变成1.2.840.10008.1.2.4.70(JPEG LossLess,Non-Hierarchical,First_order Prediction Process 14).

背景: Orthanc是博主发现的一个很完美的DICOM和HTTP服务端开源软件,前几篇分别介绍了Orthanc的基本使用.Orthanc从0.8.0版本之后给出了Plugin SDK,通过该SDK可以利用Orthanc内建的REST API实现WADO服务,下面就参照官网给出的说明介绍一下如何使用SDK实现WADO服务,并且对官网的实例进行更新,采用最新的方式直接实现WADO服务. 官方说明中文翻译: 1)简介 DICOM标准定义了文件格式以及医学影像网络传输协议.WADO,即Web Acce

接下来可以进行消息传递了 ,也就是dimse ,再来复习下 什么是dimse .n-set  n-create c-echo 这些都是dimse  他们都是属于一种结构的pdu 那就是tf-pdu(传输数据和命令的都称之为tf-pdu 或者transfer pdu ,协商连接的都称之为associcate pdu) .dimse 由 许多tag组成,就像文件解析那篇博文一样.tf-pdu数据结构分析如下: 如果你又要问此图是怎么来的 ,dicom标准第八章 33页.你可能又要问 dimse又是什

详见:http://pan.baidu.com/s/1gfFLbJ9 DICOM医学图像窗口变换的加速算法* 张尤赛 ,陈福民 ( 同济大学计算中心, 上海 200092 ) (华东船舶工业学院电子与信息系,江苏 镇江 212003) E_mail:yszhang100@sina.com   摘 要:研究DICOM医学图像的显示技术,提出了一种图象窗口变换的加速算法,该算法简洁.实用.加速效果理想, 可以在动态连续调节图像窗值的情况下实时地显示DICOM医学图像. 关键词: DICOM: 医学图

背景: 从DICOM网络传输一文开始,相继介绍了C-ECHO.C-FIND.C-STORE.C-MOVE等DIMSE-C服务的简单实现,博文中的代码给出的实例都是基于fo-dicom库来实现的,原因只有一个:基于C#的fo-dicom库具有高封装性.对于初学者来说实现大多数的DIMSE-C.DIMSE-N服务几乎都是“傻瓜式”操作——构造C-XXX-RQ.N-XXX-RQ然后绑定相应的OnResponseReceived处理函数即可.本博文希望在前几篇预热的基础上,对比DCMTK.fo-dico

背景介绍: 近期项目需求,须要使用C#进行最新的UI和相关DICOM3.0医学图像模块的开发.在C++语言下,我使用的是应用最广泛的DCMTK开源库,在本专栏的起初阶段的大多数博文都是对DCMTK开源库的介绍和学习.眼下因为项目须要,现開始对mDCM开源库继续学习分析,因此本专栏接下来的文章会大多以mDCM开源库为例进行医学图像的解说,DCMTK因为是C++语言开发的,所以作为我学习和剖析mDCM开源库的原始根据,我们并未放弃对DCMTK开源库的学习,而是通过更加细致的研读和分析DCMTK的C+

背景: 预告了好久的几篇专栏博文一直没有整理好,主要原因是早前希望搭建的WML服务器计划遇到了问题.起初以为参照DCMTK的官方文档wwwapp.txt结合前两天搭建的WAMP服务器可以顺利的实现WML服务,借此就可以同时完成WEB PACS系列以及搭建Dicom WML服务器的两篇博文.可是在实际部署过程中发现了几个严重的问题,一时无法解决.但是在搜索解决方案的时候,偶然间找到了在DCMTK论坛上贴出来的用PHP对DCMTK工具包封装的文章.因此此篇博文在记录搭建WML遇到的问题的同时,主要想

医疗图像解析 Dicom 后缀: .dcm..DCM Dicom中规定的坐标系是以人坐标系为绝对坐标系的,规定X轴正向指向病人的左侧,Y轴正向指向病人的背部,Z轴正向指向病人的头部.但是,坐标点的位置,每个厂商都有自己的看法 下图展示了成像过程中对应的坐标系 成像坐标系 三视图 图片信息中的Tag说明 在DICOM中,是通过Image Position和Image Orientation来描述当前的图像和人体坐标系的相对位置的. 解析举例 import dicom import pylab im

最近导师给安排了新任务,由于刚进入实验室,对于医学图像这一块还一知半解,所以就想分享一下有关医学常见影像的学习(尤其是dicom后缀的图像文件),欢迎大家一起交流. 目录 1.医学影像学的介绍 2.DICOM信息的简介 3.DICOM内部信息详解(DICOM Tag与VR) 4.利用python+pydicom这个库解析DICOM文件 5.DICOM的三个切面 1.医学影像学 (1).医学影像学Medical Imaging,是研究借助于某种介质(如X射线.电磁场.超声波等)与人体相互作用,把人

背景: 上一篇博文DICOM:DICOM万能编辑工具之Sante DICOM Editor介绍了DICOM万能编辑工具,在日常使用过程中发现,“只要Sante DICOM Editor打不开的数据,基本可以判定此DICOM文件格式错误(准确率达99.9999%^_^)”.在感叹Sante DICOM Editor神器牛掰的同时,想了解一下其底层是如何实现的.通过日常使用以及阅读软件帮助手册推断其底层依赖库很可能是dcmtk,就如同本人使用dcmtk.fo-dicom.dcm4che3等诸多DIC

转载:http://blog.csdn.net/zssureqh/article/details/41424027 背景: 此篇博文介绍一个开源的.基于WEB的DICOM Server软件.该开源软件完全使用C++编写,不依赖于第三方数据库(内置了SQLite数据库)或其他框架,支持RESTful API设计模式.官网上提供了源代码,同时也给出了编译后的Windows和Linux系统的二进制安装包.Orthanc是PACS领域的一种改革,提出了“解构PACS概念”,即Deconstructed

背景: 如前一篇专栏博文所述,借助于CGI或FastCGI技术转发浏览器发送过来的用户请求,启动本地的DCMTK和CxImage库响应.然后将处理结果转换成常规图像返回到浏览器来实现Web PACS.本博文通过实际的代码測试来验证这一模式的可行性,同一时候对C语言编写CGI脚本提出了一些问题. 难题: 计划參照DCMTK自带工具dcm2pnm.exe的源代码.通过DicomImage将DCM文件转换成BMP文件,然后利用CGI技术返回到浏览器.实现一次简单的WEB PACS的影像传输模拟.详细的

背景: 上一篇博文简单翻译了Orthanc官网给出的CodeProject上“利用Orthanc Plugin SDK开发WADO插件”的博文,其中提到了Orthanc从0.8.0版本之后支持快速查询,而原本的WADO请求需要是直接借助于Orthanc内部的REST API逐级定位.那么为什么之前的Orthanc必须要逐级来定位WADO请求的Instance呢?新版本中又是如何进行改进的呢?此篇博文通过分析Orthanc内嵌的SQLite数据库,来剖析Orthanc的RESTful API机制,

背景: 此篇博文介绍一个开源的.基于WEB的DICOM Server软件.该开源软件完全使用C++编写,不依赖于第三方数据库(内置了SQLite数据库)或其他框架,支持RESTful API设计模式.官网上提供了源代码,同时也给出了编译后的Windows和Linux系统的二进制安装包.Orthanc是PACS领域的一种改革,提出了“解构PACS概念”,即Deconstructed PACS,用户可以通过三种方式访问Orthanc:DICOM Server.Web Server和RESTful A

Dicom文件的默认字符集编码为ISO-IR6,这种字符集是不支持中文的,当使用Dicom工具修改病人姓名后,名字会成乱码而无法正常显示,如下图: 知道了原因就知道解决办法了,修改Dicom的字符集(0008,0005标签,名字叫SpecificCharacterSet),把该值改成支持中文的即可,如GB1830.ISO_IR 192,再把病人姓名改为中文,可正常显示,如下图: 具体代码如下: import pydicom ds = pydicom.dcmread(r'0015.dcm') pr