DICOM医学图像处理:DCMTK的wiki资料学习之PACS调试

背景:

前段时间着重从dcmtk和fo-dicom(mDCM)源码角度进行剖析,期望加深对DICOM协议的理解。知其然,知其所以然。如果“所以然”很不好懂,那我们还是先多多“知其然”吧。搞清楚原理的目的不也是为了更好的运用于实践么?所以理论和实践应该彼此交错进行,理论搞不动了就搞搞应用,应用久了就钻研钻研理论。

以前上DCMTK官网仅仅是浏览关于开源库中各个类的设计模式、依赖关系。最近在打开DCMTK官网的wiki时,才发现OFFIS对DCMTK的介绍是如此的详细。正值国庆假日,就不深挖DCMTK源码了,那就按照DCMTK
wiki中给出的介绍来实际体验分析一下DCMTK,从实践角度来学习一下。

PACSDebugging with DCMTK

前几篇博文分别介绍了worklist查询服务(DICOM医学图像处理:基于DCMTK工具包学习和分析worklist、DICOM医学图像处理:利用fo-dicom发送C-Find查询Worklist)、C-STORE服务(DICOM医学图像处理:storescp.exe与storescu.exe源码剖析,学习C-STORE请求、DICOM医学图形处理:storescp.exe与storescu.exe源码剖析,学习C-STORE请求(续))和C-MOVE服务(DICOM医学图像处理:AETitle在C-FIND和C-MOVE请求中的设置问题)。此次参考wiki中的说明利用DCMTK中的工具来讲解一下如何调试PACS系统。

下文中会用到的工具有以下两类


服务端


dcmqrscp


客户端


echoscu、storescu、findscu、movescu

PACS是什么?在DICOM标准中并没有明确的定义,DICOM协议大多是通过定义SOP来描述相关网络服务。但是几乎每一个PACS系统会包含以下几种SOP类,


Verification SOP Class


又称为DICOM ECHO服务,用于查明网络对端系统(即PACS)是否符合DICOM标准(即talks DICOM),以便双方按照DICOM标准进行对话。


Storage SOP Classes


将一个或多个DICOM对象存储到PACS服务器。一个PACS系统往往需要支持多种Storage SOP Classes,用以存储不同设备的图像数据(如CT、US、MR等)。


Query SOP Classes


根据指定的关键字查询PACS数据库。但是并不下载图像,仅仅是查询图像有关的信息。


Retrieve SOP Classes


根据Query SOP Classes的结果找到目标图像后,利用Retrieve SOP Classes服务从PACS服务器下载图像到本地。


Storage Commitment SOP Classes


客户通过该服务确认PACS服务端已经成功完成了图像的归档。

因此可以简单的理解为PACS就是提供了上述多种服务的服务端。在DCMTK工具包中给我们提供了一个PACS模拟工具——dcmqrscp,该工具提供了上表中的所有服务(Storage
Commitment SOP Classes除外,该部分并未包含在DCMTK开源包中,而需要购买商用版本)。

下面就利用dcmqrscp与其他的dcmtk工具来模拟调试一下客户端与PACS服务端的交互过程,从实际应用的角度熟悉DICOM3.0标准。

1)安装PACS服务器:

利用DCMTK给出的dcmqrscp工具包结合自己定制的配置文件来搭建我们的PACS服务器(为了更好的学习DCMTK工具包,不建议直接使用wiki中给出的公用版PACS,即www.dicomserver.co.uk/

dcmqrscp跟其他dcmtk工具包一样,可以通过添加-h或--help命令行参数来查看工具包的使用说明。唯一不同的是要想启动PACS服务器还需要指定一个配置文件。DCMTK提供的默认的配置文件为dmqrscp.cfg。打开dcmtk工具包中的dcmqrscp.cfg文件,其中的注释已经很清楚。简单概括为三部分:

第一部分,网络配置,即传统网络编程中用到参数。如NetworkTCPPort——监听端口,用于监听来自客户端的各种连接请求(需要注意的是要配置自己的防火墙,开放指定的端口);MaxAssociations——允许的最大连接数;MaxPDUSize——定义PDU传输时刻的最大长度等等。

第二部分,关于连接到dcmqrscp服务器的客户机定义。该部分包含在dcmqrscp.cfg配置文件HostTable
BEGIN和Host Table END内。默认的定义如下:

简而言之,该部分就是定义可能连接到PACS服务器的客户机信息,通常包含AETitle、HostName、PortNamer三部分。需要指出的是目前HostName(主机名称)还不支持直接IP地址的方式,因此在本地配置的时候要格外注意。

本地机的配置如下:

acme1 = (ACME1,localhost,11110)

acme2 = (ACME2,localhost,11110)

acmeCTcompany =acme1 , acme2

第三部分,客户机的详细信息。该部分目的多是为了方便用户的阅读,方便配置时使用。在下文中的调试过程中并未用到,因此就不做介绍了。

第四部分,PACS服务端存储位置信息定义。通过该部分设置,可以实现将不同客户端传统过来的数据归档到不同的PACS服务器目录。同时针对不同的AE指定不同的读写权限、存储的研究(study)数量等。默认的配置文件如下,

该部分配置的时候要注意路径必须在本地已经存在,否则会引发错误。例如我在本地的配置如下,

ACME_STORED:\DcmScuScp\DcmScp RW (9, 1024mb) acmeCTcompany

下面给出我在本地机的dcmqrscp.cfg配置文件,

在命令行启动dcmqrscp工具,输出状态如下:

2)PACS的功能调试

PACS可以简单的理解为提供了多种DICOM标准中SOP服务的软件。我们已经利用dcmqrscp工具启动了一个PACS系统,接下来就按照上一节中PACS提供的SOP服务类表格来依次进行测试

Verification SOPClass服务测试

VerificationSOPClass服务是每一个PACS系统必须提供的一项服务,用于指出该PACS服务符合DICOM协议。DCMTK工具包中的echoscu工具可发起该请求,具体指令如下:echoscu.exe
–dlocalhost 11110

11110对应于dcmqrscp.cfg配置文件第一部分给出的NetworkTCPPort,-d是调试选项,方便我们观察工具包的运行状态。运行后的输出结果如下:

喔?竟然出现了几个致命错误。幸好我们开启了-d调试开关,从调试结果中看出错误的原因是无法识别Called
AE Title,因为我们在echoscu命令行中并未指定dcmqrscp的名称。修改后指令如下,echoscu.exe
–d localhost 11110 –aec ACME_STORE

竟然又出现了同样的错误?想必很多第一次接触dcmtk的同学看到这个结果就已经心凉了一半,无心继续下去了。DMCTK的wiki中指出这个错误提示并未指出真正的错误原因,这个是dcmqrscp.exe工具包的问题。这里应该是要求我们同时指定我们自己的AE名称,再次修改后的代码如下:echoscu.exe
–dlocalhost 11110 –aec ACME_STORE –aet ACME1

好吧,又出现了同样的错误,我是服了。看来想好好学习应用也不是很容易的啊。为了能够继续后续的其他测试,查看一下dcmqrscp工具包的源码文件dcmqrscp.cc,找出产生上述问题的原因。

问题排查:

在dcmqrscp.cc文件main函数中的waitForAssociation一行插入断点,进行单步调试。如上在命令行开启echoscu,发送C-ECHO请求。逐行运行代码,具体流程如下,

最后代码停留在_stricmp(HostName,CNF_Config.AEEntries[i].Peers[j].HostName)一行,如下:

该行中的HostName函数指的是我们主机的名称,例如我本机的名称是:PC-201408122158,而CNF_Config.AEEntries[i].Peers[j].HostName指的是我们配置文件dcmqrscp.cfg中的HostTable部分,其中HostName对应的就是上面配置文件中的localhost。

至此,经过简单的源码分析,已经顺利找到了问题的原因。之所以一直提示“Called
AE Title Not Recognized”就是因为我们将HostTable中的Hostname误认为是本机IP地址的字符名称,所以错误的将主机名称设置成了localhost。其实在dcmqrscp工具包的配置文件dcmqrscp.cfg中曾有过提示“Note:in
the current implementation you cannot substitutean IP address for a hostname”。

重新修改配置文件中的hostname为PC-201408122158,再次进行尝试。此次连接测试顺利通过,测试结果如下:

Storage SOP Classes服务测试

连接测试顺利通过后,利用storescu.exe工具包对Storage
SOPClass服务进行测试。具体指令如下:storescu.exe –dlocalhost 11110 00.dcm –aec ACME_STORE –aet ACME1,测试结果显示为Success(如下图)

经过此次storescu测试,成功的将D盘根目录下的00.dcm文件上传到了dcmqrscp.cfg中指定的存储目录下,即D:\DcmScuScp\DcmScp,在存储的过程中dcmqrscp将00.dcm文件进行了重命名(关于重命名的规则可参见DCMTK对dcmqrscp的wiki介绍,也可以通过命令行参数来设定重命名的方式),同时在归档目录下生成了一个名称为index.dat的记录文件,如下图:

Query SOP Classes服务测试

继续我们的调试,通过使用storescu.exe已经能够顺利的将我们的图像上传到指定的PACS服务目录下。接下来对我们上传的数据进行查询测试,使用的工具是findscu.exe,测试的具体指令为:findscu.exe
-v -S -aec ACME_STORE -aet ACME1 localhost11110 -k QueryRetrieveLevel=STUDY -k StudyDate -k StudyDescription -kStudyInstanceUID,查询的结果如下:

查询反馈的结果与我们在利用dcmdump工具显示的信息完全一致,这说明Query
SOPClasses测试顺利通过。

Retrieve SOP Classes服务测试

进行我们最后一项测试,就是将上传到PACS服务器的图像数据重新下载到本地。测试的工具是movescu.exe,具体指令如下:movescu.exe
-v -S-aec ACME_STORE -aet ACME1 -aem ACME1 --port 11110 -od D:\DcmScuScp\DcmSculocalhost 11110 -k QueryRetrieveLevel=STUDY -k StudyInstanceUID = 2.16.840.114421.81295.9407241257

原本以为会顺利将图像保存到本地D:\DcmScuScp\DcmScu目录下,结果PACS服务端和客户端同时停在了如下状态,

由上图可以看出网络连接部分的交互已经完成了,而且对于dcmqrscp.exe模拟的PACS服务端的各项服务(VerificationSOPClass、StorageSOPClass、QuerySOPClass、RetrieveSOPClass)我们都已经测试过了,为何信息交互停留在了ConstructionAssociation
RQ PDU部分呢?仔细检查一下命令行参数以及dcmqrscp.cfg配置文件,发现在本地测试的时候我们将dcmqrscp.exe模拟的PACS服务器监听端口和可能连入的客户端端口都设置成了11110,因此在进行图像传输的过程中会发生冲突,为了验证我们的猜测,将ACME1客户端的端口修改为12345,再一次进行movescu的测试,指令如下:movescu.exe
-v -S-aec ACME_STORE -aet ACME1 -aem ACME1 --port 12345 -od D:\DcmScuScp\DcmScu localhost11110 -k
QueryRetrieveLevel=STUDY -kStudyInstanceUID=2.16.840.114421.81295.9407241257,测试结果如下:

打开本地的D:\DcmScuScp\DcmScu目录,可以看到由storescu.exe上传到PACS服务器的文件。

至此利用DCMTK工具对PACS的调试工作全部结束了,上述的调试完全参照DCMTK中wiki的相关内容,原文链接为http://support.dcmtk.org/redmine/projects/dcmtk/wiki/Howto_PACSDebuggingWithDCMTK,这里我的操作仅供大家参考,如果有精力还希望仔细阅读一下英文原文,原文的讲解更详细更全面。

后续专栏博文介绍

Dicom中的MPPS服务介绍

C#的异步编程模式在fo-dicom中的应用

VMWare三种网络连接模式的实际测试

作者:[email protected]

时间:2014-10-03

时间: 2024-10-30 05:59:17

DICOM医学图像处理:DCMTK的wiki资料学习之PACS调试的相关文章

DICOM医学图像处理:Dcmtk与fo-dicom保存文件的不同设计模式之“同步VS异步”+“单线程VS多线程”

一.背景: 最近一直在做DCM相关的编程工作,以前项目使用C++居多,所以使用DCMTK开源库,而目前团队使用C#居多,所以需要转向使用fo-dicom库,由于前一篇专栏文章DICOM医学图像处理:利用fo-dicom发送C-Find查询Worklist在调试过程中需要对DIMSE信息进行手动保存,偶然间发现了dcmtk开源库与fo-dicom开源库在保存dcm文件时使用的方式差异很大,因此决定研究一下,期望通过对比分析来看一下孰优孰劣. 二.dcmtk与fo-dicom保存文件函数的源码剖析:

DICOM医学图像处理:storescp.exe与storescu.exe源码剖析,学习C-STORE请求

背景: 上一篇专栏博文中针对PACS终端(或设备终端,如CT设备)与RIS系统之间worklist查询进行了介绍,并着重对比分析了DICOM3.0中各部分对DICOM网络通讯服务的定义.此次通过结合早些时间的博文DICOM医学图像处理:基于DCMTK工具包学习和分析worklist,对DCMTK开源库中提供的storescp.exe和storescu.exe工具的源码进行剖析,从底层深入了解C-STORE服务的触发及响应. 分析思路: storescp.exe和storescu.exe分别充当着

DICOM医学图像处理:开源库mDCM与DCMTK的比较分析(一),JPEG无损压缩DCM图像(续)

背景: 上周通过单步调试,找出了开源库mDCM与DCMTK在对DICOM图像进行JPEG无损压缩时的细小区别,并顺利实现了在C++和C#环境下对DICOM图像的压缩.但是问题接踵而至啊,随着项目的深入,发现在单独的测试工程中可以实现的mDCM版本,在嵌入到项目整体中后,却意外地出现了错误,并未顺利实现DICOM图像的JPEG无损压缩.因此需要继续详细对比分析mDCM与DCMTK两者,期望寻找原因. 问题分析: 开启项目的日志功能后,得到的信息反馈为: No registered codec fo

DICOM医学图像处理:DCMTK在VS2012中的配置

背景: 最近由于项目需要,将原本的开发IDE环境由VS2008升级到了VS2012.本以为编译完成后的DCMTK开源库可以直接从VS2008移植到VS2012.但是通过项目属性添加完包含目录和依赖库后,编译会出现大量的链接错误(大多是跟dcmdata.lib.oflog.lib有关). 解决方法: 重新按照原本的博客前辈柳北风儿(大神目前已经博客转移到网易:http://blog.163.com/[email protected]/),利用CMake工具,选择VS2012本地编译器对DCMTK3

DICOM医学图像处理:DICOM存储操作之 “多幅JPG图像数据存入DCM文件”

背景: 续上篇,继续介绍如何将多幅JPG图像数据存入DCM文件.即将有损压缩数据直接写入DCM文件,存储为Multi-frame形式. 多幅JPG图像数据存入DCM文件: 为了避免引起歧义,这里着重说明一下.本博文的描述的场景是:假设我们手中有多张JPG文件,想把JPG文件写入DCM文件,即单个DCM文件包含多幅图像信息的Multi-Frame形式.该问题之前与CSDN博友y317215133y也讨论过,当时我在OFFIS论坛中找到了一个帖子直接给了y317215133y答复.今天重新梳理了一下

DICOM医学图像处理:DICOM存储操作之“多幅BMP图像数据存入DCM文件”

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

DICOM医学图像处理:DICOM网络传输

背景: 专栏取名为DICOM医学图像处理原因是:博主是从医学图像处理算法研究时开始接触DICOM协议的.当初认识有局限性,认为DICOM只是一个简单的文件格式约定,简而言之,我当时认为DICOM协议就是扩展名为DCM文件的格式说明.其实不然,随着对医疗行业的深入,对DICOM协议也有了更全面的认识.而今才发现DCM文件只是DICOM协议一部分中的一小节,仅仅是整个协议中的一个数据结构,而DICOM协议更多的是关于医疗行业各种服务及相关流程的约定,因此其实DICOM协议中最主要的是信息流,是对医院

DICOM医学图像处理:浅析SWF、WML、SPS、MPPS

背景: 最近重新花时间阅读了DICOM标准,顺带着看了一下HL7标准和IHE,对标题中提到的SWF.WML.SPS和MPPS有了更进一步的认识,现将自己的理解整理出来,算作读书笔记吧.通过对比学习DICOM.HL7和IHE,从而更全面.更清晰的了解医疗信息行业. IHE.HL7与DICOM DICOM IHE.HL7与DICOM,先介绍DICOM,即Digital Imaging and Communications in Medicine,是1983年美国放射学会(ACR)和美国电气制造商协会

DICOM医学图像处理:Deconstructed PACS之Orthanc

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