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

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

背景介绍cornerstone几乎是所有做B/S架构必要的学习框架，之前博文刚介绍过，cornerstone本身并不解析DICOM数据，而是依赖于dicomParser.js这个前端库。dicomParser库对DICOM格式的兼容性，目前是远远落后于dcmtk、dcm4che、fo-dicom这类后端库的，其本身并不是因为前/后端语言的差异，更多的是因为之前的解析都是放在后端，所以对前端库的维护和更新比较匮乏。DICOMer星球，每日更新知识点，欢迎加入，一起交流学习！此博文是DiBugs（即DI

题记：肿瘤放射治疗领域的研究是一个学习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与显示设备、打印机与相机领域的像素边界，后续没...

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

背景：原本该小节想直接套用上世纪一片著名论文《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世界观”系列博文中会打破标准原有章节次序，宏观整体抽象出一种方法，与此同时会补充相关理论知识（这里的理论指现阶段已经发现的并被大量观测实验证实过的自然定律），希望形成一套完整的理论。既是理论就有局限……

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

背景：git的使用其实没有想象中的那么复杂，平日里真正使用的指令都是极少数、最简单格式的。之所以使用过程中感觉操作复杂、冲突不断，究其根源是对git的设计理念缺乏了解，没有搞清楚git实现版本控制的巧妙之处。之前GIT科普系列试图从底层机制来入手讲解GIT的使用，抱着“授人以鱼不如授人以渔”的心态，但是对于希望快速学习和掌握GIT使用方法的读者来说可能收效甚微。

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

背景：公司内部主要以Git作为版本管理工具，在日常工作中发现大家使用Git很不熟练，而且学习的积极性不高，似乎GIT给人以一种望而却步的感觉。究其根源（个人臆测）有几点：一、以为GIT相较于SVN新颖很多，是很高端高大上的工具，上手很难； 二、习惯于传统的图形化GUI操作（这应该得利于Windows的全球普及），对于GIT的诸多bash指令没有好感，自动降低了学习和掌握的信心； ……

题记：近期连续写了几篇关于git的博文，大多从日常使用过程中遇到的难点入手（例如冲突、回滚、放弃本地修改），目的是希望能够让大家从博文中找到可以直接用于实战的经验，因此并没有像其他指导手册一样事无巨细、面面俱到。如果大家希望对GIT有一个全面的了解，可以直接阅读官方文档，内部也有官方翻译的各种语言版本，不建议初学者一上来直接阅读国内相关博客或其他网站的总结类文章，原因大概有两个……

背景：由于公司内部目前采用git来进行代码管理，因此近期会逐步更新部分关于git的介绍。一来是为了给大家提供一个集中学习和参考的地方；二来是希望通过具体的示例来给出git的操作指南。虽然之前介绍过很多关于git的使用但不够系统，不够集中。这次希望通过几篇连续的博文给出一个简单的git实用指南。 既然提到了开发代码的版本管理，那么首要的就是从目标仓库中获取开发代码，即SVN中常用的检出……

背景：为了方便整体产品的发布，希望通过docker实现增量发布。大致的思路如下： is-there-a-way-to-add-only-changed-files-to-a-docker-image-as-a-new-layer-with。本博文对这种方式进行了尝试，与此同时简单介绍如何通过Dockerfile来创建Docker镜像……

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

背景：日积月累系列主要用于自己日常的工作中的点点滴滴，这也是我希望并鼓励公司小伙伴们能够做到和坚持的。作为程序员每天的工作难免会遇到种种错误，各种问题。不能抱有奢望每天没有问题的心态，而应该怀揣一个勇于面对问题、剖析问题并尝试解决问题的心，掌握解决问题之道最重要。 本篇博文简单记录几个近期工作上遇到的问题，好记性不如烂笔头，今日的记录为了明天的事半功倍。

背景：随着新技术的层出不穷和业务逻辑日趋复杂，昔日的前端和后端也早已相互融合，使得软件开发任务逐渐繁重。与此同时，Git等分布式版本控制系统的出现，使得项目开发从数量上来看参与者愈来愈多，从范围上来看分布广度越来越大。因此做好项目管理显得尤为重要，使用恰当合理的项目管理工具，可以提升开发效率、确保开发质量，使得协作配合顺畅高效。

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

背景：版本管理对开发人员来说至关重要，之前一直使用svn（主要是TortoiseSVN）作为团队配合的协作工具。但是自己相关的开源项目使用的是git发布在github上。由于项目自身的局限性，很少有大家修改共同文件，以及放弃working directory本地未提交修改的情况。因此对于git的使用存在着些许模糊。本篇博文通过实例来讲解一下git如何放弃working direcotry中未提交的本

题记： 北冥有鱼，其名为鲲。鲲之大，不知其几千里也。化而为鸟，其名为鹏。鹏之背，不知其几千里也，怒而飞，其翼若垂天之云。是鸟也，海运则将徙于南冥。南冥者，天池也…… 鹏之徙于南冥也，水击三千里，抟扶摇而上者九万里，去以六月息者也…… ——《逍遥游》节选

背景：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线程池。

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

题记：近期看了一篇关于架构方面的良心长文你的架构是如何一步步腐化的？，文中字字句句道出了诸多从业者、初创企业，以及BAT都会遇到的问题，细细品读后觉得工作生活中的诸多情况皆如此，都会有一个体量由小到大的增长过程，这就面临着如何管理的问题，逐步优化 or 推倒重来？

背景：马上跨年了，记得小时候元旦都不是事儿，怎么长大了长大了感觉越来越热闹了反而。各种饭局、各种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网络传输的实现。

背景：WCF可以看作是微软对SOA架构的一种实现，或者说WCF的存在让开发者更容易创建面向服务的程序。面向服务本身不是一种技术，而是设计和实现软件的一种架构方式。从最早的面向过程（PO）、面向对象编程（OO），到后来的面向服务（SO）、面向资源（RO）编程，本身没有本质区别，反映出的是人们认识世界的方法论的迭代进化。 PO、OO、SO、RO，还有一个不沾边的O2O，各种概念层出不穷，在学习使用时要

背景：专栏之前剖析过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标准中文版开源书籍为例）。

题记：从大数据到云计算、从O2O到可穿戴，身处移动互联网快速发展的时代，各种信息漫天飞，用信息大爆炸形容此情此景也早显苍白无力。 从宏观角度来看，全球化合作日渐频繁，一带一路、TPP；从微观分析，个体信息的获取、任务的实现也已从1-1单一直线关联转向了1-n多点网状关联。宏观与微观关联紧密，正如《三体》中通过人类世界各种不同文明的演化史来同宇宙大文明系统进行类比。背景：传统的程序员“大牛”是从基层

背景：日积月累与踩坑填坑，是两个对应的系列。介绍主题、更新频率不如DICOM医学图像处理专栏般固定，主要用于记录日常工作中遇到的问题，可能很深奥、也可能很肤浅，其主要目的是备忘与交流。在互联网，尤其是移动互联网飞速发展的今天，信息爆炸已经不足以表达海量信息的量级，毕竟个人的记忆量有限，因此记录日常点滴就显得尤为重要。本篇记录两个简单的问题：SVN全新分支创建与VS窗体工程拷贝。

背景：博文专栏中介绍过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等工具繁琐的指令，像编辑传统文档一样对文档进行多人协作以及版本管理。这里再介绍几种文档版本管理的方案，供大家交流学习。

背景：之前对于数据库操作部分大多停留在会使用阶段，并未真正考虑过数据库SQL语句的执行效率问题。近期响应项目组其他成员需要，协助手动修改数据库。为了提高工作效率编写了C#测试工程进行相关操作。由于数据库记录量较大（超过10K条），在编写程序过程中发现不同的操作执行效率相差甚远，特做记录如下，待后续有时间再深入分析各种数据库的SQL语句的执行效率。此次数据库修改要求涉及到删除、修改、添加等各种操作，

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

背景：许久没有写“医疗时鲜咨询”博文，究其原因是越来越觉得各种新闻满天乱飞，有些滥竽充数、有些毫无真实性可言、有些编辑拙劣。对从众多新闻消息中提取有用信息早已感到吃力,本篇起初打算写关于各种医疗工具（诸如杏仁医生、杏树林的病历夹、珍立拍、丁香园用药助手等等）的对比分析，以及背后的技术实力，近期偶然看到的两篇文章《22岁！天使轮估值超6亿 将颠覆整个视频和广告行业》和《22岁金证济苍和6亿云视链是假的

背景：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

题记：前一篇随笔：做一个平庸程序员，are you scared？博文中提到的豆瓣深度好文原文，想想还是转载过来吧，以免作者将原文给删掉。怎奈CSDN转载不是很方便，这里就直接截屏了，有兴趣的大家可以去源链接阅读，直接跟作者交流。 原文出处：一个平庸程序员的自白

背景:一个平庸程序员的自白。近期看到的少有的好文，细细品味，感触良多，思来想去不知如何与作者交流。无论从工作经验，还是从境界，都与原作与译作有一段差距。但很多人都会有相似的经历，说出自己的故事，彼此交流或许是最好的途径。题记:编程在外人看来绝对属于脑力劳动，至少从大学教育来看软件工程、计算机专业都是需要很强的理科功底的。然而看看帝都上地、中关村深夜的壮观景象，你又会觉得编程是体力活，要不怎么会被戏称

背景：作为传统厂商，从入职到现在总算看到了公司试图转型的苗头，近期正在筹划一个在现有终端基础上的牙科影像分享和诊断平台，敬请期待。这半年来好久没有记录相关的医疗资讯了，2014互联网医疗元年刚过，无论是投资方还是创业者都冷静了许多，私底下开始加紧谋划新产品。在大众胃口被调起来后，真正能够笼络和留住用户的是产品的体验。所以上半年的资讯略显平淡。

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

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

背景：之前博文DICOM：开源DICOM服务框架DCM4CHEE安装中曾介绍过在Windows7环境下安装部署dcm4chee。近期公司项目需要与部署到Linux系统的远端基于dcm4chee框架的DICOM服务器进行交互。由于网络问题，为了提高调试效率，就在本地Ubuntu14虚拟机中尝试安装部署了一套dcm4chee服务以及oviyam2客户端，详情如下。

背景：之前专栏中介绍过fo-dicom来实现DICOM标准中的DIMSE-C各项服务，此次现实中遇到了特殊需求，即“要根据不同的dicom文件存储到不同的位置，且该位置信息通过dicom文件内部自有信息无法构造”。在具体实现过程中由于WCF实例模型、C#闭包等原因，走了不少弯路，这里将整个分析过程记录下来，供以后学习参考。

背景:5月份的前半段好懒惰，手里积攒了好多篇文章，也有之前答应过博友要写的，迟迟未动笔。究其根源，有些许懒惰，但更多的是迷惑和一知半解，虽想写但却不知如何入手，零星的感悟要积累成文还是需要时间去沉淀的，以期尽量做到每篇博文有理有据。今天正好借着手头新任务介绍DICOM标准中的又一新内容，参照dcm4che2工具扩展fo-dicom(mDCM)向A-ASSOCIATE-RQ PDU中添加UserIdentity。

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

背景：目前对于传统WEB网站性能（压力/负载）的测试工具有很多，诸如loadrunner、iperf、siege等，操作都比较简单，这里就不介绍了。然而对于医疗领域内的服务器，通常指的是DICOM服务器，此刻使用传统的性能检测工具无法实施DIMSE服务测试，本文通过扩展JMeter的Java请求，结合dcm4che2工具包给出测试DICOM服务器性能的一种解决方案。

背景：近期在跟圈内朋友谈一件事情： **搭建一个关于DICOM协议的中文社区，以开源书籍的模式，自发翻译DICOM官方最新标准。以DICOM协议为切入点，通过阅读、研究、到最后翻译，更加全面掌握标准，尤其是加深对医疗行业的了解。 随着国内新医改的逐步深入，各行各业的创业者开始涉足医疗行业，无论出于颠覆旧有体制和现行标准，还是出于对DICOM标准了解不足的角度，未来新的医疗大环境下必然需要标准

背景：踩坑填坑系列博文坚持之前的约定，主要用于记录工作中遇到的各种问题，或简单，或繁琐。在还未详细剖析之前，先找到解决方案解决工作上的燃眉之急，待有时间后会整理成文，PUSH到日积月累系列中。此次“踩坑填坑”系列博文中介绍的内容略显分散，从DevExpress WinForm控件，到Telerik OpenAccess ORM，再到StarUML建模，详情见下文。

背景：昨天专栏中发表了一篇关于DICOM Print中MetaSOPClass与SOPClass对比分析，文章从部署中遇到的实际情况出发，对DICOM Print中的连接协商（Association Negotiation）进行了剖析，本文可看做是上一篇博文的补充，重新浏览和整理了DICOM3.0标准中对DICOM Print 服务的介绍，加深对DICOM打印的理解。

背景：最近项目中遇到的实际问题较多，且大多是较隐蔽的、不易被发现的错误。究其根源来看，还是对DICOM3.0协议中的细节掌握不够仔细。继前篇剖析DicomClient函数调用逻辑错误导致的System.ObjectDisposedException异常后，接下来讲解关于DICOM胶片打印服务PresentationContext协商中MetaSOPClass与SOPClass的对比。

背景：此次通过剖析DicomClient类中的AddRequest和Send源代码，以及DicomServiceUser服务的具体逻辑，结合C-STORE服务的具体应用场景对fo-dicom库中的C-STORE服务的实现进行了再分析，更加清晰的梳理了C-STORE服务的实现流程，找到了实际部署过程中常常会遇到的误区，解决了System.ObjectDisposedException异常问题。

背景：近期由于项目需要，开始学习和使用WCF技术。初次涉猎一种陌生技术领域，最常见的就是踩“坑”了。虽然之前浏览和阅读了很多WCF资料，但是在项目实际开发过程中，还是遇到了这样和那样的问题。因此决定在博客中开辟“踩坑填坑”系列博文，该类博文主要用于记录在运用新技术开发过程中遇到的各种奇葩错误，同时直接给出解决方案。然文中却不会对问题的根源和解决方案进行详细介绍，待日后有时间再发文到“日积月累”系列进行详细剖析。

背景：WCF服务需要寄宿到相应的可运行进程中执行，常见的有四种寄宿，分别是控制台程序、WinForm程序、IIS和Windows服务。之前学习老A博客和《WCF全面解析》时最常用到的是控制台寄宿，近期由于项目需求，需要在WinForm程序中调用WCF服务，本博文通过一个简单的实例来演示WCF在WinForm中的寄宿。并着重介绍如何利用事件绑定控制宿主主UI界面控件。

背景：近期发现，床头和书柜的书已然许久没有翻过了，看来还是太懒惰了。也有很长一段时间没有在CSDN中转载过博文了，总结起来大致有两点原因吧，第一点，好博文有很多，但快速浏览并解决心中疑惑后似乎总缺少点什么——“味同爵蜡”。知识不是靠传授，靠的是领悟。因此不希望将博客写成简单的记录大牛神作的黄页，而是希望随着时间慢慢沉淀出自己的感悟后再写点什么出来；……

背景：前一篇博文“DICOM：开源DICOM服务框架DCM4CHE 安装”中介绍了一款开源DICOM服务框架DCM4CHE，对于开源项目学习的流程是先下载二进制可执行包安装，然后使用测试。在熟悉了大致的功能服务后，从官网下载源代码进行本地构建（Build），进而从根本上了解开源项目的底层框架设计，为后续修复、扩展做准备。本博文是继“DCM4CHE安装”后的续篇，讲解如何在本地构建DCM4CHE开源项目，文中尽量做到全面，但是由于刚开始接触J2EE领域，且多半都是自学，因此博文中还留有部分未解问题，如有熟悉的

背景：专栏之前写过许多关于DICOM协议的相关文章，有关于概念解析的理论性文章，也有实例演示的应用性文章。目的只有一个，希望能引导大家快速掌握DICOM协议，并着手进行自定义化开发。DICOM协议实现有多种开源库，例如基于C++的DCMTK、基于C#的fo-dicom、基于Java的dcm4che。下面以DCMTK开源库为例，给出一个C-FIND SCU的实例工程，供大家交流学习。

背景：近两周没有发表医疗时鲜资讯相关博文，究其原因有两个，第一个是个人工作上有些忙，并未积极参加线下的讨论会、沙龙等等；第二个，经过了2014热炒的医疗元年后，2015似乎平淡了许多。这也是我本人愿意看到了，只有踏实做事才是王道，或许在经历了去年资本追捧后，各家创业公司目前都在加紧项目开发，希望能够有所成效，以期在未来更大的资本市场中受到追捧。

背景：dcm4chee是dcm4che开源项目中的一部分，是一款符合IHE规定的影像管理/归档应用。dcm4chee遵循DICOM、HL7标准，实现了图像存储、图像提取、及健康领域的工作流程管理。dcm4chee作为一款应用程序需要预打包，然后部署到JBoss应用服务器中。……

背景：之前博文中专门梳理过DICOM标准中与网络传输相关的内容，近期在重新整理fo-dicom开发的PACS相关测试用例时，对fo-dicom和mDCM两个库进行了再一次比较，与此同时重新翻阅了DICOM3.0标准中的部分章节，发觉之前曾经忽略了其中的很多细节，特编写此文。一来对之前该系列博文的疏忽和BUG进行补充修复，二来加深一下DICOM网络传输的了解。

背景：春节过后，医疗时鲜资讯系列继续。备受瞩目的移动医疗元年2014已过，诸多概念也被炒的热火朝天，有时候真担心2015怎么办？又会闹出什么动静？或许互联网就是这样让你永远不知道下一个受追捧的是什么。无论参加线下沙龙，还是浏览网络资讯，个人认为被资本看好的元年却并未有任何实质性的、能真正打动患者或医生的产品出来。但我坚信，只要踏出一步，路就在前方，新的一年里继续关注医疗行业最新资讯……

背景：最近抽空想了解一下DCM4CHEE开源DICOM框架，怎奈配置了许久也没有成功(汗)。多半原因是因为首次接触Java开发环境，毕竟跟C系列（C/C++/C#）不同，但这次失败经历，让我愈发感受到对大型项目的快速熟悉和把握能力的欠缺，其实这也正是我学习各种开源项目的出发点。所以决定趁着周末详细整理一下配置、学习、使用，甚至扩展开源项目的流程，算是对此次配置DCM4CHEE经验的一次总结和延伸。

背景：正如段子所言，“春节”副本已通关，您的属性有如下变化：力量 0，智力 0，敏捷 0，体重 15，金钱-999。您已被传送回出发点，系统时间从“初八”切换到“周四”，请继续进行主线任务……怎奈假期配置测试的DCM4CHEE系列文章还未整理完成，既然到了月底了，就凑一篇水文吧，把春节帮网友写的一个基于fo-dicom的DICOM Viewer贴出来，抛砖引玉了。

背景：Orthanc是本专栏中介绍过的一款新型DICOM服务器，具有轻量级、支持REST的特性，可将任意运行Windows和Linux系统的计算机变成DICOM服务器，即miniPACS。Orthanc内嵌多种模块，数据库管理简单，且不依赖于第三方软件。因此通过剖析Orthanc源码可以学习到搭建DICOM系统中的各个环节，例如SQLite嵌入型数据库、GoogleLog日志库、DCMTK医学DIC