【转】DICOM：DICOM三大开源库对比分析之“数据加载”

系统管理员 2023-01-17 03:14 282阅读 0赞

# **背景：** #

上一篇博文[DICOM：DICOM万能编辑工具之Sante DICOM Editor][DICOM_DICOM_Sante DICOM Editor]介绍了DICOM万能编辑工具，在日常使用过程中发现，**“只要Sante DICOM Editor打不开的数据，基本可以判定此DICOM文件格式错误（准确率达99.9999%^\_^）”**。在感叹Sante DICOM Editor神器牛掰的同时，想了解一下其底层是如何实现的。通过日常使用以及阅读软件帮助手册推断其底层依赖库很可能是dcmtk，就如同本人使用dcmtk、fo-dicom、dcm4che3等诸多DICOM开源库遇到的兼容性问题类似，**——dcmtk兼容性最强，fo-dicom次之，dcm4che3最差**。

# **问题：** #

本篇通过对比dcmtk3.6与dcm4che3.x解析同一**特殊dicom文件**（**包含非标准VR的元素**）分析**dcmtk、dcm4che以及fo-dicom数据加载的兼容性**问题。  
特殊的dicom文件内容如下：  
28 00 20 01 20 20 02 00 30 F8，具体描述如下：  
![20150905235427453][]  
使用dcmtk与fo-dicom加载数据时都未出现错误，例如dcmtk加载数据时的提示如下：  
![20150905235457747][]  
由此可以看出dcmtk已经顺利识别出了**非标准VR的元素(0028,0120)**，并成功加载。  
虽然使用fo-dicom加载数据没有出现错误，但是对于上述**非标准VR的元素(0028,0120)**后的元素未顺利加载，如下图所示：  
![20150905235512949][]  
而dcm4che3加载过程中直接弹出了错误，如下所示：  
![20150905235526032][]

# **问题分析：** #

出现该问题的原因是dcm4che3和fo-dicom在解析**0028,0120**元素时，对于20 20的**非标准VR**无法识别。下文中将通过分析dcm4che3与dcmtk的源码来定位问题的具体位置并给出解决方案（此处暂时只对比分析了dcm4che3.3.8最新版与dmctk3.6的源码，对于fo-dicom的源码分析待后续整理完成后再补充）。

## **1. dcmtk3.6源码：** ##

使用dcmtk编写本次数据加载测试工程，简单的示例代码如下：

<code class="language-C">int main()
 {
 OFLog::configure(OFLogger::TRACE_LOG_LEVEL);
 char* ifname = "c:\\1.dcm";
 E_FileReadMode readMode = /*ERM_fileOnly*/ERM_autoDetect;
 E_TransferSyntax xfer = EXS_Unknown;
 Uint32 maxReadLength = DCM_MaxReadLength;
 bool loadIntoMemory = true;
 DcmFileFormat dfile;
 DcmObject *dset = &dfile;
 if (readMode == ERM_dataset) dset = dfile.getDataset();
 OFCondition cond = dfile.loadFile(ifname, xfer, EGL_noChange, maxReadLength, readMode);
 if (cond.bad())
 {
 return 1;
 }
 return 0;
 }</code>

单步调试，可以知道dcmtk加载dicom文件的流程如下：

> 1.  创建**DcmMetaInfo、DcmDataset**元素
> 2.  分别加载**DcmMetaInfo、DcmDataset**元素
> 3.  使用**DcmItem**中的**readGroupLength、readTagAndLength、readSubElement**逐步加载**DcmMetaInfo、DcmDataset**的各个子元素。

在DcmItem类中对于**非标准VR元素**有相应的警告提示信息，

<code class="language-C">/* if the VR which was read is not a standard VR, print a warning */
 if (!vr.isStandard())
 {
 OFOStringStream oss;
 oss << "DcmItem: Non-standard VR '"
 << ((OFstatic_cast(unsigned char, vrstr[0]) < 32) ? ' ' : vrstr[0])
 << ((OFstatic_cast(unsigned char, vrstr[1]) < 32) ? ' ' : vrstr[1]) << "' ("
 << STD_NAMESPACE hex << STD_NAMESPACE setfill('0')
 << STD_NAMESPACE setw(2) << OFstatic_cast(unsigned int, vrstr[0] & 0xff) << "\\"
 << STD_NAMESPACE setw(2) << OFstatic_cast(unsigned int, vrstr[1] & 0xff)
 << ") encountered while parsing element " << newTag << OFStringStream_ends;
 OFSTRINGSTREAM_GETSTR(oss, tmpString)
 /* encoding of this data element might be wrong, try to correct it */
 if (dcmAcceptUnexpectedImplicitEncoding.get())
 {
 DCMDATA_WARN(tmpString << ", trying again with Implicit VR Little Endian");
 /* put back read bytes to input stream ... */
 inStream.putback();
 bytesRead = 0;
 /* ... and retry with Implicit VR Little Endian transfer syntax */
 return readTagAndLength(inStream, EXS_LittleEndianImplicit, tag, length, bytesRead);
 } else {
 DCMDATA_WARN(tmpString << ", assuming " << (vr.usesExtendedLengthEncoding() ? "4" : "2")
 << " byte length field");
 }
 OFSTRINGSTREAM_FREESTR(tmpString)
 }
 
 /* set the VR which was read in the above created tag object. */
 newTag.setVR(vr);
 
 /* increase counter by 2 */
 bytesRead += 2;</code>

在警告后，对于**非标准VR元素**的处理过程如下：

<code class="language-C"> /* read the value in the length field. In some cases, it is 4 bytes wide, in other */
 /* cases only 2 bytes (see DICOM standard part 5, section 7.1.1) */
 if (xferSyn.isImplicitVR() || nxtobj == EVR_na) //note that delimitation items don't have a VR
 {
 inStream.read(&valueLength, 4); //length field is 4 bytes wide
 swapIfNecessary(gLocalByteOrder, byteOrder, &valueLength, 4, 4);
 bytesRead += 4;
 } else { //the transfer syntax is explicit VR
 DcmVR vr(newTag.getEVR());
 if (vr.usesExtendedLengthEncoding())
 {
 Uint16 reserved;
 inStream.read(&reserved, 2); // 2 reserved bytes
 inStream.read(&valueLength, 4); // length field is 4 bytes wide
 swapIfNecessary(gLocalByteOrder, byteOrder, &valueLength, 4, 4);
 bytesRead += 6;
 } else {
 Uint16 tmpValueLength;
 inStream.read(&tmpValueLength, 2); // length field is 2 bytes wide
 swapIfNecessary(gLocalByteOrder, byteOrder, &tmpValueLength, 2, 2);
 bytesRead += 2;
 valueLength = tmpValueLength;
 }
 }</code>

由上述代码可知，**0028,0120**的**VR=20,20**，被dcmtk解析为 EVR\_UNKNOWN2B类型，如同代码注释中所描述：

> /// used internally for elements with unknown VR with 2-byte length field in explicit VR  
> EVR\_UNKNOWN2B

DICOM标准**PS5的7.1.2**有对于非标准VR的相关描述，如下：  
![20150905235659217][]

## **2. dcm4che3.3.8源码：** ##

再对比dcm4che3.3.8的源码，单步调试发现，对于**0028,0120**的**VR=20,20**，被dcmtk直接标记为UN类型，

<code class="language-Java">public static VR valueOf(int code) {
 try {
 VR vr = VALUE_OF[indexOf(code)];
 if (vr != null)
 return vr;
 } catch (IndexOutOfBoundsException e) {}
 LOG.warn("Unrecogniced VR code: {0}H - treat as UN",
 Integer.toHexString(code));
 return UN;
 }</code>

并且在dcm4che3中对于UN类型定义为  
![20150905235724462][]  
此处UN类型是参照上述截图中DICOM3.0标准对于VR=UN（unknown）类型的标签约束来定义的，**即，其VR字段应该是四个字节**。然而此处**0028,0120**的**VR=20,20**后的**Value Length**只有两个字节**02 00**。因此导致dcm4che3在加载**0028,0120**元素时，将其长度错误地解析为**4163895298**，即十六进制的**F8 30 00 02**，如下图所示：  
![20150905235741374][]

# **解决方案：** #

至此我们找到了dcm4che3错误解析**0028,0120**的**VR=20,20**非标准VR元素的原因。**对于这种非标准VR不能统一当做VR.UN类型进行处理，而应该根据其后续的Value Length的具体长度为2或者4来进行分类处理**（**关于该问题后续博文会继续深入剖析，请注意**），需要修改的地方有两处：

## **1. 正确解析Non-standard VR：** ##

<code class="language-Java">//VR.java,Line 110
 public static VR valueOf(int code) {
 try {
 VR vr = VALUE_OF[indexOf(code)];
 if (vr != null)
 return vr;
 } catch (IndexOutOfBoundsException e) {}
 LOG.warn("Unrecogniced VR code: {0}H - treat as UN",
 Integer.toHexString(code));
 //return UN;
 LOG.warn("zssure:to solve non-standard VR,Unrecogniced VR code: {0}H - treat as UN",
 Integer.toHexString(code));
 return null;//zssure:to solve non-standard VR
 }
 </code>

## **2. 正确读取Non-standard VR的VL：** ##

<code class="language-Java">//DicomInputStream.java Line 386
 public int readHeader() throws IOException {
 byte[] buf = buffer;
 tagPos = pos; 
 readFully(buf, 0, 8);
 switch(tag = ByteUtils.bytesToTag(buf, 0, bigEndian)) {
 case Tag.Item:
 case Tag.ItemDelimitationItem:
 case Tag.SequenceDelimitationItem:
 vr = null;
 break;
 default:
 if (explicitVR) {
 vr = VR.valueOf(ByteUtils.bytesToVR(buf, 4));
 //zssure:to solve non-standard VR
 //referred:dcmtk/dcitem.cc/readTagAndLength,Line 970
 if(vr == null)
 {
 length = ByteUtils.bytesToUShort(buf, 6, bigEndian);
 return tag; 
 }
 //zssure:end
 if (vr.headerLength() == 8) {
 length = ByteUtils.bytesToUShort(buf, 6, bigEndian);
 return tag;
 }
 readFully(buf, 4, 4);
 } else {
 vr = VR.UN;
 }
 }
 length = ByteUtils.bytesToInt(buf, 4, bigEndian);
 return tag;
 }</code>

# **测试文件下载：** #

本文中使用的测试数据已经上传到了我Github的CSDN仓库中，可自行下载，为了保护患者隐私已经进行了匿名化处理。  
[Download Non-standard VR test dcm file][]

# **后续博文介绍：** #

**1. 由dcm4che3.x库看Java流操作之”流的拷贝”**  
**2. Eclipse自动编译dcm4che3.x源码**  
**3. DICOM三大开源库对比分析之“数据加载”（续）**

**作者：zssure@163.com**  
**时间：2015-09-05**

[DICOM_DICOM_Sante DICOM Editor]: http://blog.csdn.net/zssureqh/article/details/48186109
[20150905235427453]: /images/20221022/4a24401fdfb44a65853d396aa30b1302.png
[20150905235457747]: /images/20221022/c167a4b63f9f4d21b28b7924da6ab1a6.png
[20150905235512949]: /images/20221022/81cfcf2bb3dc4a9793265a1f20a49bdc.png
[20150905235526032]: /images/20221022/bb923d4407354c5e8d7421f8408af590.png
[20150905235659217]: /images/20221022/5bc7bdf466844c9ca39c5c1a1c095525.png
[20150905235724462]: /images/20221022/68e5c55a8a644fe5a91da316d77bb628.png
[20150905235741374]: /images/20221022/8a47a8c43b3e4add96eee7c57604c337.png
[Download Non-standard VR test dcm file]: https://github.com/zssure-thu/CSDN/tree/master/Non-standard%20VR