只要踏出一步，路就在前方——zssure

一、背景：之前在知识星球介绍过clouddicom，是由国外Vasant Kearney博士发布的一款云端在线支持DICOM数据中目标结构勾画的工具，可以作为放射治疗领域学习前端靶区勾画的入门资料。官方网址是： www.clouddicom.com.（近期该网站不可访问，具体代码可移步我的github项目https://github.com/zssure-thu/clouddicom)。具体的clouddicom工具操作在youtube上也有视频介绍（ https://www.youtube.com/

题记：肿瘤放射治疗领域的研究是一个学习DICOM标准（尤其是DICOMRT）很好的实例，涵盖了：传统的医学图像存储（即我们通常讲的DICOM图像文件，其中包含pixel data标签，这个部分也是大多数人认为的DICOM的全部），肿瘤区域标记文件（RTSTRUCT，全称为Radiotherapy StructureSet，用闭合曲线坐标的形式记录医生勾画的肿瘤轮廓）、肿瘤治疗计划文件（RTPLAN，全称Radiotherapy Plan，用射束Beam、分次Fraction等来表述放射治疗设备实际

题记：记得某一堂课上，学数学的管理学老师讲过一句话，“科学就是分类”，通俗而易懂。此篇博文成文于三年前，当时作为初入某一个领域的调研资料，为了区分好诸多专业术语，因为只有从基础概念入手理清楚了才能逐步深入。现如今发上来供大家讨论与批评指正。一、背景介绍肿瘤放射治疗是肿瘤治疗的三大手段之一，放射治疗（没有特殊说明，这里的放射治疗专指外照射，external beam radiotherapy）主流的是适形放疗（conformal radiotherapy），主要包括调强放疗（IMRT，Intensity

0）题记：时间转瞬即逝，俗话说每四年一闰，近来近一闰的时间都在集中精力做一件事情，也是一段充满各种挑战的旅程，因此博客的打理频率也逐年降低，由每周一博、每月一博、每季一博，逐步堕落到了现在的每年一博。（汗、汗、汗-_-||）翻开马克飞象，文档栈里的《DICOM世界观》第二章：[3]像素操作之算法博文已经堆放了快一年了，一直没有出栈，务必在2019年的尾巴写出来。可惜闭关这么久，猛的出山，怎奈...

背景：时隔近半年，拖延癌晚期快犯了。然并卵，依然没有完全想好如何来编写这一章节，从哪一个维度来介绍。“合抱之木，九层之塔”，都是日积月累而成，思来想去还是先把之前积累下的资料整理写出来，后期的构想继续交给拖延癌吧。题记：像素Pixel：像素（Pixel）这个概念在不同的场景中会有不同的含义。如上一章所述，我们理清了数字图像中的像素Pixel与显示设备、打印机与相机领域的像素边界，后续没...

背景：原本该小节想直接套用上世纪一片著名论文《A Pixel Is Not A Little Square》作为标题，怎奈英文原文信息量较大，内部蕴含了很多关于采样定理的信息论知识，虽然通读数遍但依然感到些许迷茫，怕对读者有误导，所以直接简单一点以《像素Pixel》为题，从日常生活中浅显、通俗的概念入手，来引入未来在DICOM世界观中会频繁出现并占去大量篇幅的元概念——像素Pixel，……

背景：正如同笛卡尔定义了我们所生活在的三维世界和爱因斯坦定义了第四维度时间，在第一章中我们给出了统一的标定DICOM世界的坐标系，以及相关的变换理论，接下来我们要逐步走进DICOM世界内部，观察其内部的“真实景象”，探究其背后的“原理”。DICOM, 全称Digital Imaging and Communications in Medicine，是应用于医疗领域成像与通讯的约定（这里没有使用协议而

题记： DICOM世界观·第一章 坐标系统完成后，总感觉缺了点什么，大概有两个原因：第一，没有从基础概念说起，来形象的介绍坐标系间的各种变换；第二，没有深入到DICOM数据本身，来进行实例演示。这两方面的介绍都停留在半山腰，让读者似懂非懂或一知半解。为此近期重新翻阅了一下经典著作《Introduction to Linear Algebra, Fifth Edition(2016)》，……

前言：DICOM世界观·开篇中顺便提到了DICOM标准中提及的各类坐标系统。鉴于篇幅问题（CSDN博客的确不太适合写长学术类博文），对于坐标系统的偏理论部分放到本篇进行介绍。正如“DICOM世界观·开篇”中提到的，希望按照“科学”本身的方式——大量观察经验+理论推理——来介绍相关知识点。 本篇博文内容大致如下： 1.3. 坐标系变换 1.3.1 方向余弦 1.3.2 欧拉角

题记：何为科学？是人类观察、认识世界的一种理论——从最初的泛灵论、上帝论过度而来——是一种世界观**。感触颇多，遂想到了一个新题目**“DICOM世界观”，希望从更高的角度来理解和解释DICOM标准。在“DICOM世界观”系列博文中会打破标准原有章节次序，宏观整体抽象出一种方法，与此同时会补充相关理论知识（这里的理论指现阶段已经发现的并被大量观测实验证实过的自然定律），希望形成一套完整的理论。既是理论就有局限……

背景：DICOM标准委员会每年大约处理10个左右标准功能内容方面的增补（supplement），100 个左右的修改提议，并且每年数次发布更新的标准的正式英语版本，本博文对最新标准中DICOM Web Service的扩展进行了简单的介绍……

题记：DICOM专栏系列虽然写了多年，但是依然不能解决大家日常中遇到的种种问题，其实这恰恰就是程序员（码农）工作的最大乐趣所在。就像每个人的人生一样，所处的环境不同，所遭遇的事件不同，结果自然就不同。程序开发亦是如此，操作系统不同、软件版本不同，本地配置不同都会导致种种问题。 “授人以鱼不如授人以渔”，所以正常的解决之道是希望通过专栏的讲解，能够让大家真正理解每个问题出现的背后原因……

背景：近期由于收到博友咨询fo-dicom的兼容性和扩展性和自身Github的fo-dicom仓库更新等原因，发现fo-dicom官方主版本已经更新到了3.X系列，貌似完善了不少东西，不过还没有时间仔细研究。以后再抽时间试用并介绍吧。本篇博文由之前自己的fo-dicom版本库在解析不规范DICOM文件时弹出的【错误】：Requested xxxx bytes past end of file…引申

背景：DICOM-RT系列博文着眼于DICOM3.0中对放疗领域的补充标准，即DICOM-RT。为了方便后续对DICOM-RT中相关IOD、SOP概念的理解，专栏近期做了放疗相关知识点的普及。 PS：当然本人并非放疗专业人士，文中概念多整理来自国外文献书籍、google，以及wiki。文中不妥之处，欢迎大家邮件交流。

背景：放疗是一个复杂的过程，同时需要肿瘤医师、模拟定位技师、剂量师、物理师、治疗技师、护士等多重角色参与。整体流程涉及到成像系统、定位系统、计划系统、治疗系统、质控QA系统、信息管理系统等多个独立的子系统，相较于常规医疗信息系统（诸如HIS、RIS、LIS、PACS等）存在着“各子系统的整合程度低、传输数据量大、操作实时性差，以及学习成本高”等问题。

背景：继上一篇博文后，继续科普肿瘤放疗领域中的相关概念。文中的知识点都来自于相关的官方或相关企业文档，仅从相关行业从业者的角度来进行阐述，由于本人不是放疗医生和技师，因此可能与实际工作中的环节有出入，欢迎大家来邮交流，共同进步。 本博文开篇让我从最熟悉的DICOM文件格式说起，相较于普通的bmp图像而言，DCM是结合了患者、医院、设备等相关信息于像素数据之上的文件。但单单从像素数据来看，两者同样存

背景：专栏上一篇博文提到过，近期有博友对DICOM标准中的放疗部分（DICOM RT）比较感兴趣，因此决定后续几篇博文会由浅入深逐步介绍一下放疗领域的相关知识点。从一个工程技术人员角度给大家呈现放疗的全流程，介绍大致分为放疗综述与基本知识点、DICOM标准中DICOM RT的剖析、基于DICOM RT的放疗信息化建设三个系列，具体细节请浏览最新的专栏博文。

题记：进入2016金猴年以来，虽然工作一直处在忙碌的状态，但博客许久没有更新，主要是工作比较琐碎，相关性不大。但近期通过邮件咨询放疗相关信息的网友比较多，感觉大家可能比较关注DICOM标准中的放疗部分，DICOM-RT。因此计划2016上半年着重介绍一下DICOM RT的相关内容。相关博文暂时放到【DICOM医学图像处理】专栏中，待积累一段后再单独开栏，敬请期待。

背景：上篇博文介绍了dcm4chee中使用的Leader/Follower线程池模型，主要目的是节省上下文切换，提高运行效率。本博文同属【DICOM开源库多线程分析】系列，着重介绍fo-dicom中使用的ThreadPoolQueue线程池。

题记：临近农历年关（对国人来说，这个才叫新年嘛），工作琐事较多，因此本月发博数量锐减至①篇。虽不以博文数量为目标，但每月一篇的数量还是说不过去。博文数量锐减，总结下来有两个原因……

背景：马上跨年了，记得小时候元旦都不是事儿，怎么长大了长大了感觉越来越热闹了反而。各种饭局、各种party，有点hold不住。还是回来整理一下这一年的笔记比较舒服，比较有收获。看了看这个月竟然发文量还不足四篇，遂将Evernote中的一篇老文贴出来水一下，赶巧解决一下之前网友邮件中遇到的相关问题。

背景：由于docker技术能够实现最大化应用隔离、且自身对资源损耗极低，甚至可以等同于进程，遂催生了希望将docker应用到DICOM服务开发领域。上一篇博文DICOM：docker实现DICOM服务虚拟化作为开篇，介绍了如何在docker容器内部安装DICOM运行环境……

背景：docker，是一个开源的应用容器引擎，目前大多应用在部署和运维领域，然而由于完全使用沙箱机制，相互之间可以看做独立的主机，且自身对资源的需求也十分有限，远远低于虚拟机。甚至很多时候，可以直接把容器当做应用本身也没有任何问题。因此近期正在尝试将docker应用到传统DICOM服务领域。 本文作为该系列开篇，主要记录docker环境配置过程中遇到的奇葩问题，为后续更复杂、更全面的应用做准备。

背景：之前博文对比过多次C-MOVE与C-GET服务的区别，两者最大的区别在于C-GET是基于单个TCP连接的点对点的两方服务，而C-MOVE是基于两个TCP连接的三方服务（详情参见：《DICOM：C-GET与C-MOVE对比剖析》，以及DICOM：C-GET与C-MOVE对比剖析（续））。加之前一篇专栏博文DICOM：DICOM3.0网络通信协议之“开源库实现剖析”也已详细对比了dcm4che和f

背景：日前，通过对比fo-dicom与dcm4che两种开源库（也是C#与Java两大语言体系）的不同实现来实战学习了DICOM的网络传输，博文中列举了两大开源库各自的实现特点，以及使用的语言特性。本篇继续对比两大开源库，从宏观整体来分析各自DICOM Protocol的实现，聚焦各自使用的线程池，以及管理方式……

背景：专栏对于DICOM网络传输介绍过多次，例如DICOM：DICOM3.0网络通信协议（续）、DICOM医学图像处理：DICOM网络传输、DICOM医学图像处理：全面分析DICOM3.0标准中的通讯服务模块。此次通过对比fo-dicom与dcm4che两种开源库（也是C#与Java两大语言体系）的不同实现来实战学习一下DICOM网络传输的实现。

背景：专栏之前剖析过DICOM协议的C-GET服务与C-MOVE服务，两者最大的区别在于C-GET是基于单个TCP连接的点对点的两方服务，而C-MOVE是基于两个TCP连接的三方服务，详情参见之前的专栏博文DICOM：C-GET与C-MOVE对比剖析。 近期在将相关DICOM服务，例如CStoreSCP、CMoveSCP，MppsSCP等，Docker化并Web发布时又遇到了一个问题，大致情形如下

背景：还记得博客中很久之前写过一篇Windows环境下试玩Docker的水文，当时自然是出于好奇心态，对Docker略知一二。近两年随着dotCloud公司推出Docker并围绕之创建了生态体系，Docker容器虚拟化技术已经火遍了整个互联网。加之近期邮箱收到了多封诸如灵雀云、时速云的推广邮件，又重新燃起了试玩Docker的冲动。此次当然依然是不求甚解，仅仅把Docker当做虚拟机来使用……

背景：近期多次收到网友邮件或私信希望给出一个简单的说明，方便由简到难的来逐步浏览和阅读专栏中的博文。自己按照上述的主线来写，一直以为逻辑还算清晰，但自己回想起来，对于初学者甚至外行来说，专栏整体还不够清晰，一时很难找到切入点进行学习。因此近期一直在考虑写一篇关于“DICOM学习路线图”的博文，构思许久仍感充满纰漏，如何能够让初学者快速掌握DICOM相关知识？如何能够学习知识点的同时展开实际编程训练？……

背景：作为分布式版本控制系统的代表git和github已经成为大多数开发人员首选版本控制工具。由于其不同与SVN的集中式版本管理，因此在协同工作时的方式略有不同，下面让我们来对比分析一下（这里以本人的DICOM3.0标准中文版开源书籍为例）。

背景：博文专栏中介绍过DICOM标准中文版书籍的协作模式DICOM：开源书籍之『DICOM标准中文版』启动计划，之所以选择看云平台目的是希望更多的、各行各业的人员加入，例如英语专业、非医疗从业者都十分欢迎，对翻译中的语法、语言表述，甚至专业知识点进行评判修改。当然，如果您是一名IT从业者，已熟练使用SVN和GIT各种版本工具的人员，可以通过Github直接发起Pull requests请求，完成协同编辑。

背景：上一篇博文“DICOM万能编辑工具之Sante DICOM Editor”介绍了DICOM万能编辑工具，在感叹Sante DICOM Editor神器牛掰的同时，想了解一下其底层是如何实现的。通过对比日常使用dcmtk、fo-dicom、dcm4che等开源库的兼容性推断Sante DICOM Editor很可能是基于dcmtk是实现的，本博文通过一个特殊数据来给大家对比一下三大开源库的兼容性。

背景：在专栏博文中曾出现过多次Sante DICOM Editor，但大多时间是作为DICOM图像编辑工具使用，其实Sante DICOM Editor的DICOM服务功能也很强大，提供了常用的DICOM查询、上传、下载服务，完全可以充当mini PACS使用，或用于测试其他DICOM Server性能。本篇博文着重介绍Sante DICOM Editor中的DICOM Service。

背景：之前翻译的DICOM3.0标准是在本地创建的git仓库，并非在github上创建，此时别人是无法访问的，当初的目的是想待标准翻译初步完成后再提交到github上，然而由于本地的翻译工作采用MarkDownPad进行编辑，文档中的图片需要有一个公网URL才能在文档中显示，因此就在Github上创建了DICOM-Chinese的仓库，在Figure子文件夹用于存放文档中出现的所有图片，现在需要将两者进行合并……

背景：上个月DICOM：开源书籍之『DICOM标准中文版』启动计划项目已顺利启动，最终组内成员选用了看云作为开源书籍的提交、整合、发布的平台。主要的用意是操作简单，使用者不需要面对git、svn等工具繁琐的指令，像编辑传统文档一样对文档进行多人协作以及版本管理。这里再介绍几种文档版本管理的方案，供大家交流学习。

背景：专栏之前对Transfer Syntax（暂定中文翻译为传输语义，8月初博客中提到的DICOM3.0标准中文版开源书籍计划顺利启动，后续会面临诸多专有名词的翻译工作，欢迎广大博友提意见）进行过多次的介绍，近期又在TransferSyntax章遇到了“坑”，因此本博文要介绍一下GE Private Transfer Syntax，CT Image Storage。

背景前段时间博文 DICOM：dcm4che工具包如何压缩dcm文件探讨（前篇）提到了一个问题：“利用dcm4che工具包中的dcm2dcm来进行dcm文件的压缩和加压缩，即改变dcm文件中的Transfer Syntax，例如由1.2.840.10008.1.2变成1.2.840.10008.1.2.4.70。在热心博友nanarongrong的帮助下，本博文中给出解决方案

背景：DICOM专栏系列中曾介绍过大多数的DICOM标准开源实现库，例如dcmtk、fo-dicom、mDCM，以及dcm4che。之前的介绍大都局限在表层，并未深入对比分析彼此的不同，因此在具体使用过程中很容易踩坑——例如此次对于dcm文件的压缩。近期由于项目需要，外出给客户部署云平台，鉴于当地网络环境以及数据量的问题，急需对数据进行压缩处理，由于医学数据主要用于临床辅助诊断，因此不能采用有损压

背景：之前专栏中介绍最多的两款PACS分别是基于dcmtk的dcmqrscp以及Orthanc，和基于fo-dicom的DicomService（自己开发的），该类应用场景都是针对于局域网，因此在使用DIMSE-C各项服务时并未遇到的复杂问题，学习和使用成本相对较低。通过近一年的时间也已经对C-ECHO、C-FIND、C-STORE、C-MOVE、N-PRINT等各项服务都进行了详细介绍，并且从DI

背景：近期由于项目需要，开始频繁接触基于Java的DICOM标准实现库，即dcm4che。与以往使用的dcmtk和fo-dicom不同的是，dcm4che工具包是整个dcm4che项目的一部分，只作为解析DICOM格式的工具包被dcm4chee使用，而dcm4chee是一种托管在JBoss AS中的WEB应用。其内部添加了诸多的业务层的逻辑，在实际应用中遇到了几个问题，记录下来，以备后续仔细分析。