本文主要讲述dicom标准及dicom通讯的工作方式。dicom全称医学数字图像与通讯 其实嘛就两个方面 那就是“存储”跟“通讯”。 文件数据组织方式 网络数据组织方式。文件数据组织方式就是解析静态的dicom文件 在 《dicom格式文件解析器》一文中已经阐述过了 就不再说了。网络数据组织方式 ...
第二篇，前面都是闲扯 其实正文现在才开始，这次是把压箱底的东西都拿出来了。首先我们今天要干的事是实现一个echo响应测试工具 也就是echo 的scu，不是实现打印作业管理么。同学我告诉你还早着呢。本来标题取的就是《dicomviewer 第二弹 之 实现打印管理》名字多霸气，最后我又改回来了。首先你得把数据组织方式搞懂 那就是pdu 和dimse 元素
看标准 越看越糊，根本原因：dicom抽象得非常严重，是“专家”弄的。没办法。又是什么服务类 又是什么sop，相信你把dicom标准看到头大 都不知如何下手。 不就是 socket么 这有何难。 首先你得理解神马叫pdu，从pdu入门 ，我只能这么说了。pdu就是pdu protocol data unit 反
接下来可以进行消息传递了 ，也就是dimse ，再来复习下 什么是dimse 。n-set n-create c-echo 这些都是dimse 他们都是属于一种结构的pdu 那就是tf-pdu（传输数据和命令的都称之为tf-pdu 或者transfer pdu，协商连接的都称之为associcate pdu） 。dimse 由 许多tag组成，就像文件解析那篇博文一样。tf-pdu数据结构
Dicom全称是医学数字图像与通讯，这里讲的暂不涉及通讯那方面的问题 只讲*.dcm 也就是diocm格式文件的读取，读取本身是没啥难度的 无非就是字节码数据流处理。只不过确实比较繁琐。好了 正题 分析整体结构先是128字节所谓的导言部分，说俗点就是没啥意义的破数据 跳过就是了，然后是dataElement依次排列的方式 就是一个dataElement接一个dataElement的方式排到文件结尾 通俗的讲dataElement就是指tag 就是破Dicom标准里定义的数据字典。tag是4个字节表示的 前两字节是组号后两字节是偏移号 比如0008,0018。所有dataElement在文件中都
说到底无非几个事情 ：1传输语法确定 2数据元素读取 3 7fe0,0010元素 也就是图像数据处理。关于这整个过程已经不想多说了 在我的上上一篇博客里已经基本实现了。 当然还很有问题比如图像调窗就有bug 这个以后再说吧。众所周知dicom格式文件是由一个接一个连续的“数据元素”组成的。 这次我们只讲怎样去处理文件里一种特殊的数据元素：那就是VR为SQ类型的元素 还有delimited 也就是界定标识付 我们暂且把它归为一类。 为什么特殊呢？因为其他元素都很简单 ，根据传输语法：-> tag_有无显式VR_len_VF 这样的结构。 len是数据长度， VF是固定字节数的字节流数据。
在年初的时候做过一个dicom格式文件解析，当时只是提了下。看着跟别人的显示出来也差不多 其实是我想太简单了。整理了下思路 这里提供正确的调窗代码。 医学影像 说得挺高科技的 其实在这个过程中本身没太复杂的图像处理技术。窗值处理就算是比较“高深”的了 也就是调窗。网上都是啥基于 DCMTK的DICOM医学图像显示及其调窗方法研究 说得文绉绉的 没啥鸟用，dicom没你想象的那么复杂哈 咱这个全是自主代码 顶多看了点C++的源码 然后改成c#版本的 其实都一样的。这中间有几个 步骤， 1 字节序转换 2 保留有效位，使用&进行位运算截取有效位3 根据有无符号进行值转换4 针对CT影像的窗
这个本来没啥 不是什么算法 绝技。 都不值得一提。其实这个是医学影像胶片曝光时排版的一个逻辑。dicom标准第三部分 主要是讲IOD定义 在第166页有这样的描述：表C.13.5-1图象盒象素描述组件属性名称 标记 说明图象位置 (2020,0010) 基于图象显示格式(2010,0010)的胶片的图象位置。参阅C.13.5.1的规范。这个所谓的“基于图象显示格式(2010,0010)的胶片的图象位置”到底是啥意思呢 ？还是像往常一样拿个实例瞧瞧：20 20 10 00 ............ ..00000010 02 00 00 00 02 0020 20 10 00 .....
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
