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

题记：肿瘤放射治疗领域的研究是一个学习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年的尾巴写出来。可惜闭关这么久，猛的出山，怎奈...

背景：前一篇博文通过扩展JMeter的java请求，结合dcm4che2现有的工具包dcmsnd.bat实现了简单的测试DICOM服务器C-STORE SCP性能的尝试。由于借用了现有的dcmsnd.bat命令行工具，会有诸多的局限性，比如：1）必须构造命令行中的参数，才能调用dcmsnd.bat，操作多此一举2）无法准确跟踪一张图像上传完成后的准确时间3）需要准备海量测试图像。本文对DcmSnd修改……

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

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

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

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

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

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

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

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

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

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

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

背景：开源书籍之【DICOM标准中文版】启动计划。如我博客格言“只要踏出一步，路就在前方”所言，路总是需要一步一步走的，事情总是需要一件一件做的。因此近期开始着手启动“DICOM中文标准”开源书籍项目，由于DICOM标准浩如瀚海，仅凭一己之力很难推动。需要集合大家所长，这也是开源书籍的最大魅力所在。

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

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

背景： 本专栏“DICOM医学图像处理”受众较窄，起初只想作为自己学习积累和工作经验的简单整理。前几天无聊浏览了一下，发现阅读量两极化严重，主要集中在“关于BMP（JPG）与DCM格式转换”和“DICOM 通讯协议”，尤其是许久前的第一篇博文DCMTK开源库的学习笔记1：将DCM文件保存成BMP文件或数据流（即数组）。因此在2014年底前打算写几篇关于DCM格式转换的文章，此次主要聚焦“如何将BMP、JPG等常规图像保存成DCM文件”，以DCMTK库为基础，给出简单的实例。

背景：最近去医院部署设备，调试PACS系统，遇到了一个奇葩的问题。基本场景是：医院内部网络情况复杂，多个楼层的诊室都安装了看图端，都需要访问顶楼机房的PACS服务器。起初为了调试关闭了防火墙，并确保各楼层的看图端与PACS服务器之间可以ping通，端口也顺利开放。但是具体部署调试过程中发现“有些楼层可正常进行worklist查询和Query/Retrieve查询，而有些楼层只能正常进行worklist查询，Query/Retrieve查询后本地并未获得图像数据”；...

背景介绍： 最近项目需求，需要使用C#进行最新的UI和相关DICOM3.0医学图像模块的开发。在C++语言下，我使用的是应用最广泛的DCMTK开源库，在本专栏的起初阶段的大多数博文都是对DCMTK开源库的介绍和学习。目前由于项目需要，现开始对mDCM开源库继续学习分析，因此本专栏接下来的文章会大多以mDCM开源库为例进行医学图像的讲解，DCMTK作为我学习和剖析mDC的依据。

背景：专栏之前对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的帮助下，本博文中给出解决方案

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

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

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

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

背景： 最近重新花时间阅读了DICOM标准，顺带着看了一下HL7标准和IHE，对标题中提到的SWF、WML、SPS和MPPS有了更进一步的认识，现将自己的理解整理出来，算作读书笔记吧。通过对比DICOM、HL7和IHE，更全面、更清晰的了解医疗信息行业。

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

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

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

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

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

题记：2017.12.31,…… 转眼之间，又走到了尽头。 这一年最明显的特征就是“忙碌” 忙着忙着似乎变成了碌碌无为，却鲜有时间停下脚步来整理思绪。 ……

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

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

背景：时间过得好快，今天已然是2016年的最后一天。从最初对图像的一无所知，到与医学图像的偶然结缘，逐渐接触了各类医学影像设备、熟悉了医学成像原理；再到如今对DICOM医学国际标准的掌握和精通，对医疗信息化的渴望与热爱，走过的年头，踩过的坑已经记不清倒底有多少了。2016又是匆匆的一年，或许离心中的梦想又近了一步，但还是未能完成。还是未能打磨出一款真正令自己满意的产品，医疗大健康事业依然任重道远，吾

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

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

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