[疑难杂症2023-006]解压dicom压缩格式文件时的不定时阻塞问题解决方案

本文由Mrakdown语法编辑器编辑完成。

1. 背景

DICOM图像是医学中最常见的图像格式。关于DICOM图像的压缩格式，可以通过每一个文件的头信息(file_meta)来判断。
关于DICOM的压缩格式，或传输语法，可以参考tag: TransferSyntaxUID的说明来了解。
https://www.dicomlibrary.com/dicom/transfer-syntax/

常见的几种压缩格式如下：

TransferSyntaxUID	Transfer Syntax Name
1.2.840.10008.1.2.4.70	JPEG Lossless, Nonhierarchical, First- Order Prediction
1.2.840.10008.1.2.4.80	JPEG-LS Lossless Image Compression
1.2.840.10008.1.2.4.57	JPEG Lossless, Nonhierarchical (Processes 14)

采用压缩图像，一般是为了减小图像占据的空间。特别是采用以上这些常见的无损压缩格式时，用dicom viewer软件，基本上是看不出图像有什么区别的。但是它们占据的空间，却可以从500KB降低到300KB左右。这里一般是指RowsColumns=512512的CT图像。

但是有时候，又需要将图像进行解压。
在python中，一般是基于gdcm库，来进行压缩文件的解压。

解压方法1:

import gdcm  # noqa
import pydicom

ds = pydicom.read_file('path/to/compressed_dcm')
# decompress的运行，依赖于提前安装了gdcm的包，才可以。
ds.decompress()
ds.save_as('path/to/save/decompressed_dcm')

解压方法2：

import os
# gdcmconv,也是依赖于提前安装gdcm.
os.system('gdcmconv -i path/to/compress_dcm -o path/to/decompressed_dcm -W --raw')

无论是运用pydicom的读取和保存，还是直接在python中调用gdcmconv的指令实现解压。本质上，都是一个"读 + cpu解压 + 写"的过程。

在实际的运行过程中，在处理医院回传的一些压缩数据时，发生了运行时卡住的问题。
因为一个序列一般包含几百张图像，因此一般是用一个for循环，来循环调用以上的解压语句。

import os
import gdcm  # noqa
import pydicom
for file in series_dir:
	file_path = os.path.join(series_dir, file)
	ds = pydicom.read_file(file_path)
	ds.decompress()
	ds.save_as(file_path)

就是运行以上这段简单的代码时，每次处理几百张序列图像的解压时，就会不定期的卡在某一张的解压上，然后程序就没有任何反应了。既没有任何报错，也没有其他提示。

2. 解决方案

2.1 最朴素的解决方法

根据上述问题的症状，每次处理，都会随机的卡在某一张图像的解压上。而把卡住的这张图像单拿出来，读取，解压和保存，都是正常的。
那只能是怀疑是for循环的过程，造成了一些IO的瓶颈。比如上一个文件还没有完成写入的操作，紧接着又来了一个保存文件的操作。
这样，随着堆积的IO任务越来越多，系统就卡住了。
所以，先用了一个最笨的办法，就是在每一次解压和保存的时候，增加一个sleep的等待时间，以确保上一次的IO操作彻底完成后，再进行下一次操作。

第一次测试的时候，是time.sleep(0.5), 即等待500ms. 测试结果是，卡住的情况解决了。但是这样会导致处理时间变长。
第二次测试的时候，是time.sleep(0.05), 即等待50ms. 测试结果，仍然是可以正常解压和保存。
所以最后的代码为：

import os
import gdcm  # noqa
import pydicom
import time
for file in series_dir:
	file_path = os.path.join(series_dir, file)
	ds = pydicom.read_file(file_path)
	ds.decompress()
	ds.save_as(file_path)
	# 每一次循环操作，人为等待50ms.
	time.sleep(0.05)

2.2 理论依据

虽然通过增加sleep的方式，解决了上面这个棘手的问题。但心里面总归还是存在一些侥幸心理和不安。这次加了50ms, 不卡了。那假如下一次又卡住了，是要再增加等待时间吗？到底增加到多少算合适呢？