干医学影像这行的，几乎人手都逃不过一个“转格式”的活儿。科室里 DICOM 文件堆成山，一张 CT 一个序列就是几百帧，想发个微信给主任看一眼、想给模型做批训练数据、想把典型病例整理成 PPT 课件，结果对方一看到 .dcm 就傻眼，压根打不开。我自己带过好几个实习生，几乎每个第一次处理影像数据的人都会在“DICOM 转 JPG”这一步卡住，不是转出来全黑，就是方向翻转，再不然就是文件名乱成一团。这篇就把我这几年的实操经验整理出来，从工具选型到批量脚本，从踩坑记录到排查思路，一次性讲清楚。
先说清楚这工具和方案能解决什么问题：把 CT、MRI、DR、超声等设备输出的 DICOM 文件，批量转成 JPG、PNG，以及常见的 BMP、TIFF 等普通图片格式，同时保留可读的文件命名、目录结构和关键图像信息，整个过程支持批量操作，不让一张一张手动点。适合影像科技术员、临床科研医生、做 AI 辅助诊断的算法工程师，以及所有被 DICOM 文件搞得头大的医学数据处理人员。
1. 为什么要做 DICOM 批量格式转换
1.1 DICOM 的“专业”反而成了阻碍
DICOM 医学数字成像和通信标准，是医疗影像设备的通用语言，它把图像像素数据和一大堆病人信息、检查信息、设备参数打包在一起。好处是标准统一、信息完整，坏处是太重了。CT 一个序列动辄几百 MB，MRI 一个检查可能包含四五个序列，任何一个普通看图软件都打不开，更别提手机端、网页端、微信这些日常场景。
我最早遇到这个需求，是在做一次多中心科研项目的时候。要收集三家医院的影像数据，其中两家发来的还是 DICOM 光盘，另一家直接给了一个 DICOMDIR 索引文件。要把这些数据统一整理成算法组能直接读的格式，第一步就是得把它们从 DICOM 转成 PNG。当时我用的是最笨的办法，拿着 MicroDicom 一张张导出，导了整整两天，眼睛都快瞎了。后来才意识到，这种工作必须交给批处理脚本和命令行工具，否则纯属浪费生命。
1.2 哪些场景真正需要“批量转格式”
- 临床轻量共享：科室之间、医联体之间、和患者沟通病情时，JPG 是最通用的格式，任何设备都能打开。尤其远程会诊时，很多医生习惯在手机上看图，DICOM 无法直接预览，提前转好 JPG 才能保证会诊顺利。
- AI 数据集构建：深度学习语义分割、病灶检测模型的训练数据，绝大多数都需要 PNG 或 JPG 格式。PNG 无损压缩适合分割标注，JPG 有损压缩适合自然图像预训练，总之 DICOM 原始格式没有几家框架能直接处理。
- 科研论文与课件：论文投稿需要 TIFF 或 JPEG 格式的插图，组会汇报需要把典型病例截成图片贴到 PPT 里。批量转换加统一命名，能让整理病例库的效率翻好几倍。
- 患者影像档案留存：很多患者会要求拷贝自己的影像资料。带 DICOM 查看器虽然专业，但普通人不会用。转成 JPG/PNG 加上一个简单的 HTML 目录页，患者拿回去用浏览器就能翻看，体验好很多。
1.3 批量转换的核心诉求不止是“格式变了”
说得直白一点，单纯“变个格式”是个人都能写出来，真正麻烦的是这三件事：
图像显示要正确。DICOM 像素值不是普通的 8 位 RGB，CT 的像素值是 12 位灰度，MRI 的像素值是 16 位带符号整数，而且灰度范围可能从 -1024 到 3071 甚至更高。直接拿原始像素值当成普通灰度图保存，大概率得到一张全黑或全白的废图。必须做窗宽窗位映射、位深转换、缩放，才算真正“转成功”。
文件命名要有意义。设备导出的 DICOM 文件名往往是乱码一样的一串 ID，批量转换后如果直接命名为 image001.jpg，后面根本找不到哪个文件对应哪一帧。我实际项目里会用
SeriesNumber_InstanceNumber_Modality.jpg这种命名规则，避免文件覆盖和难以回溯的问题。元数据需要有选择地保留。虽然输出的是 JPG/PNG，但原始 DICOM 里的关键信息（检查号、序列号、层厚、像素间距、窗宽窗位）常常需要写到同名 CSV 或 JSON 里，方便后续程序读取。这也是批量转换比单张转换更有技术含量的地方。
2. 工具选型：四种主流方案怎么选
2.1 纯命令行工具 dcmtk：最稳定的批量转换基石
DCMTK这套命令行工具，医学影像圈的名气不用多提。它提供的dcm2jpg和dcm2pnm是专门负责图像导出的程序。dcm2pnm 严格来说是把 DICOM 转成 PGM/PPM 格式的中间工具，但通过参数可以直接输出 JPEG 或 PNG。
它的优势在于完全离线、不依赖 GUI、对 DICOM 标准的支持极其全面，什么压缩传输语法、老设备私有标签，它都能很好地处理。我在 Linux 服务器上跑大规模批量转换，几乎都是优先考虑它。
典型用法：
# 单张转换，自动应用窗宽窗位，输出JPG dcm2jpg input.dcm output.jpg # 强制输出PNG，关闭自动窗宽窗位（保留原始像素映射） dcm2pnm --write-png input.dcm output.png批量处理时，在 Windows 下配合批处理脚本，在 Linux 下配合 find + xargs 或简单的 bash 循环即可。不过它也有缺点：参数比较多，新手初次上手容易摸不着头脑，而且对“自定义映射彩色图像”这类需求不太方便。
2.2 Python 生态 pydicom + PILLOW：量身定制的灵活方案
如果你需要的不只是“格式转换”，还要同时完成裁剪、归一化、多序列分类、生成缩略图、统计像素特征，那就应该用 Python 自己写。pydicom负责读取 DICOM，numpy负责像素运算，Pillow负责保存 JPG/PNG。
为什么我推荐用 pydicom 而不是直接用 OpenCV 读取？因为 OpenCV 虽然也支持 DICOM，但支持不完整，对多帧、Overlay、传输语法等处理配置有限。pydicom则更“懂”DICOM 数据结构，读取像素后的pixel_array就是一个 numpy 数组，你想怎么处理都行。
import pydicom from PIL import Image import numpy as np ds = pydicom.dcmread('input.dcm') arr = ds.pixel_array # 此时arr是numpy数组，灰度值范围可能是0-4095或更多这个方案的强大之处在于：你可以为每个序列定制处理逻辑，比如根据WindowCenter和WindowWidth做对比度增强，根据RescaleSlope和RescaleIntercept还原真实 CT 值，甚至可以基于PixelSpacing在图像上叠加比例尺。
2.3 图形化工具 MicroDicom / RadiAnt：小白友好、单批效率低
说实话，我遇到很多临床科室的同事，他们要的不是什么编程，而是“打开软件、点几下、拖文件夹进去、导出”。这种情况 MicroDicom 就够了。它支持打开 DICOM 目录、调整窗宽窗位后导出为 JPG/BMP/TIFF/PNG，也支持基本的批量导出。
RadiAnt 是更轻量的 DICOM 浏览器，查看速度极快，但批量导出能力稍弱。这类 GUI 工具的缺点是批量导出时不可控因素多，文件名规则不稳定，而且如果一批数据里有不同模态、不同序列的混合，它往往不会自动分类导出。小规模使用尚可，真到了几千个文件的级别就不顶用了。
2.4 方案对比速查表
| 方案 | 上手难度 | 批量能力 | 可定制性 | DICOM支持 | 适用场景 |
|---|---|---|---|---|---|
| DCMTK | 中等 | 强 | 中等 | 极强 | 服务器批量、标准转换 |
| pydicom+Pillow | 中等偏高 | 强 | 极强 | 强 | AI数据预处理、科研定制 |
| MicroDicom | 低 | 中等 | 弱 | 强 | 科室日常、少量导出 |
| RadiAnt | 低 | 弱 | 弱 | 强 | 快速阅片、暂存看图 |
我个人的原则是：走廊里求助的临床同事用 MicroDicom，而我自己处理数据时永远选择 pydicom 或 dcmtk。道理很简单，批量转换这种环节，一旦出错就是成百上千张图一起出错，可控性和可复现性比“点几下”更重要。
3. 实操：Python 批量转换 DICOM 到 JPG/PNG 完整流程
3.1 环境准备和依赖安装
我建议直接用 MiniConda 建独立环境，避免污染日常 Python。版本上，Python 3.9 以上都没问题，pydicom 2.x 支持良好。需要安装的库只有三个：
pip install pydicom numpy opencv-python pillow这里有一个细节：很多人以为只需要 pydicom 和 pillow，其实还需要 numpy 做数组变换，以及 opencv-python 来处理某些需要旋转、翻转、插值的复杂情况。Pillow 虽然也能做 resize 和 rotate，但性能上和交互性上不如 OpenCV 顺手。
3.2 读取 DICOM 并处理像素数据的核心函数
到了关键部分。先给出一段我自己一直在用的核心函数，处理了位深、缩放、窗宽窗位：
import os import pydicom import numpy as np from PIL import Image def transform_dicom_to_pixels(ds): """ 把 pydicom 读取到的 Dataset 转换成适合保存为 JPG/PNG 的 8 位数组。 返回 (PIL.Image, 调用的窗宽窗位信息) """ # 取出像素数组。如果 pydicom 版本较新，可能要求安装 pylibjpeg 才能解压某些压缩格式 arr = ds.pixel_array.astype(np.float64) # 若是彩色 DICOM（如超声、内镜），arr 可能是三维数组，形状为 (rows, cols, 3) if arr.ndim == 3 and arr.shape[2] in (3, 4): # 直接给 PIL，但要先转换成 uint8 范围 arr = arr - arr.min() arr = arr / (arr.max() - arr.min() + 1e-8) arr = (arr * 255.0).astype(np.uint8) return Image.fromarray(arr), None # 对灰度图，优先使用标签中的 WindowCenter / WindowWidth 做映射 try: center = float(ds.WindowCenter) width = float(ds.WindowWidth) except Exception: center, width = None, None # 有的DICOM里 WindowCenter 可能是一个多值列表，取第一个常规值 if isinstance(center, (list, tuple)): center = center[0] if isinstance(width, (list, tuple)): width = width[0] if center is not None and width is not None: low = center - width / 2.0 high = center + width / 2.0 arr = np.clip(arr, low, high) arr = (arr - low) / (high - low + 1e-8) arr = (arr * 255.0).astype(np.uint8) return Image.fromarray(arr), (center, width) # 如果没有窗宽窗位，就退化为 min-max 归一化 arr = arr - arr.min() arr = arr / (arr.max() - arr.min() + 1e-8) arr = (arr * 255.0).astype(np.uint8) return Image.fromarray(arr), None这个函数解决了一个关键问题：为什么有些 DICOM 直接转成 JPG 是全黑的。因为 CT 的像素值范围通常是 0 到 4095 甚至更高，如果直接用 8 位存储，大于 255 的部分全被截断，当然黑。做了窗宽窗位映射后，图像看起来就和影像科工作站里看到的一样了。
之后是遍历目录的核心逻辑。要递归寻找所有.dcm文件，并跳过已经转换过的文件：
def batch_convert_dicom(input_root, output_root, target_format='jpg', quality=95): count = 0 for dirpath, _, filenames in os.walk(input_root): for name in filenames: if not name.lower().endswith(('.dcm', '.dicom')): continue dcm_path = os.path.join(dirpath, name) try: ds = pydicom.dcmread(dcm_path, stop_before_pixels=False) except Exception as e: print(f"[FAILED] read {dcm_path}: {e}") continue img, win_info = transform_dicom_to_pixels(ds) # 构造输出文件名为 序列号_实例号，保证唯一 series_num = getattr(ds, 'SeriesNumber', 0) instance_num = getattr(ds, 'InstanceNumber', 0) modality = getattr(ds, 'Modality', 'OT') out_name = f"{modality}_{series_num:03d}_{instance_num:04d}.{target_format}" # 保持相对于输入目录的层级结构 rel_dir = os.path.relpath(dirpath, input_root) out_dir = os.path.join(output_root, rel_dir) os.makedirs(out_dir, exist_ok=True) out_path = os.path.join(out_dir, out_name) if os.path.exists(out_path): continue if target_format.lower() == 'png': img.save(out_path, format='PNG') else: img.save(out_path, format='JPEG', quality=quality) # 顺带记录关键元数据到txt with open(os.path.join(out_dir, "meta.txt"), "a") as mf: mf.write(f"{out_name}\t{modality}\t{getattr(ds,'PatientID','NA')}\t{getattr(ds,'StudyDate','NA')}\n") count += 1 if count % 50 == 0: print(f"已转换 {count} 个文件...") print(f"批量转换完成，共 {count} 个文件。")3.3 保存格式选择：JPG 还是 PNG？质量参数有讲究
- JPG：适合 CT、MRI、DR 这类灰度图像，体积小。但注意保存质量参数，医学图像讲究细节，质量设置为 90-95 比较合适，不要用默认的 75，否则图像边缘会出现恼人的振铃伪影。灰度图像 JPG 不会有颜色空间问题，处理起来很放心。
- PNG：适合需要进一步做标注、分割、测量的场景，是无损压缩，保证每个像素点的原始信息不丢失。AI 分割任务里，真值 mask 必须用 PNG，这一点没有商量余地。
- TIFF：适合论文投稿，支持 16 位灰度，可保存更多原始位深信息。但文件体积大、Web 支持差，日常不推荐。
一个个人习惯：我给算法组提供训练数据时，原图存高质量 JPG，mask 存 PNG，元数据全放 CSV 里独立保存。这样兼顾了体积和可追溯性，也免得一张图像对应多个信息文件。
3.4 特殊场景处理：16 位灰度转 8 位，多帧影像抽取
很多人会在 16 位灰度上栽跟头。DICOM 里常见的是 12 位或 16 位像素数据，保存时你要么用 PNG 的 16 位模式（Pillow 支持mode='I;16'），要么就缩放到 8 位。科研论文如果要求原始灰度范围，就必须保留 16 位：
# 保留16位灰度PNG arr = ds.pixel_array # 不做归一化 img16 = Image.fromarray(arr.astype(np.uint16), mode='I;16') img16.save('output.png')但如果是 CT，每个像素的真实“意义”是亨氏单位（HU），单纯保留 16 位整数并不代表保留了真实 CT 值。需要在保存时额外使用RescaleSlope和RescaleIntercept把像素值映射到真实的 HU 范围。这一步常常被忽视，导致下游算法读出来的数值和标准 CT 值对不上。
多帧 DICOM（比如超声动态图、血管造影 DSA 序列）的像素数组形状是(frames, rows, cols)。这种情况批量转换时，可以只抽取关键帧，也可以全部帧都导出，但命名必须加上帧号：
arr = ds.pixel_array # shape: (n_frames, rows, cols) for frame_idx in range(arr.shape[0]): frame = arr[frame_idx].astype(np.float64) # 归一化处理... frame_img = Image.fromarray(frame_8bit) frame_img.save(f"{out_name}_frame{frame_idx:03d}.jpg")如果想把整段动态影像转成 GIF 或 H.264 MP4，我一般先用上面的代码导出 PNG 帧序列，再用 ffmpeg 合成为视频。流程稳、每一步都能检查，比试图一步到位的插件方案可靠得多。
4. DCMTK 命令行批量转换：服务器场景下的高效姿势
4.1 Windows 批处理脚本
如果你手上是 Windows 环境，又不想装 Python，可以下载安装 DCMTK 工具包，然后把dcm2jpg.exe所在目录加入 PATH。下面这个批处理脚本递归处理指定文件夹里所有.dcm文件：
@echo off setlocal enabledelayedexpansion set INPUT_DIR=C:\DICOM_Src set OUTPUT_DIR=C:\DICOM_Jpg for /r "%INPUT_DIR%" %%f in (*.dcm) do ( set "relPath=%%~pf" set "absInputPath=%INPUT_DIR%" call set "relPath=!relPath:%%absInputPath%%=!" if not exist "%OUTPUT_DIR%\!relPath!" mkdir "%OUTPUT_DIR%\!relPath!" dcm2jpg "%%f" "%OUTPUT_DIR%\!relPath!%%~nf.jpg" ) echo Done pause这个脚本的巧妙之处在于保留了 DICOM 文件原来的目录结构。比如原目录DICOM_Src\Patient1\CT里有image.dcm，转换后会输出到DICOM_Jpg\Patient1\CT\image.jpg，后续整理病例时能很轻松地对应回原始文件。
4.2 Linux 服务器上配合 find 批量处理
在服务器上，我最常用的是配合 find 命令：
#!/bin/bash SRC_DIR=/data/raw_dicom OUT_DIR=/data/output_jpg find "$SRC_DIR" -type f -name "*.dcm" | while read -r f; do rel_path="${f#$SRC_DIR/}" out_subdir="$OUT_DIR/$(dirname "$rel_path")" mkdir -p "$out_subdir" filename="$(basename "$f" .dcm).jpg" dcm2jpg "$f" "$out_subdir/$filename" done这段脚本的好处是天然处理了文件名带空格的情况，因为while read -r会完整读取一行路径。加不加-w参数要看需求，dcm2jpg 默认会应用窗宽窗位，想要原始灰度就加+w配合--use-gdcm之类。
4.3 批量生成图谱册（Contact Sheet）
有时想把一个序列的所有层面拼成一个总览图，方便快速浏览。我常用 dcm2pnm 导出 PGM 后，再用 ImageMagick 拼接：
# 导出当前序列为PGM灰度图 dcm2pnm --write-pgm input.dcm temp.pgm # 转换成JPG convert temp.pgm -auto-level current_slice.jpg # 多张图片横向拼接 montage slice_*.jpg -tile 5x4 -geometry +2+2 contact_sheet.jpg这种方式特别适合做病例随访对比：把治疗前和治疗后的同一层面图像，拼成左右对照图，一眼就能看出变化。
5. 常见问题与排查技巧实录
5.1 转出来的图片全黑或全白
这是新手遇到最多的现象，原因几乎都是像素数据没有经过范围映射。DICOM 图像位深可能达到 16 位，而 JPG 最多 8 位。如果你直接把pixel_array赋值给 Pillow，而没有做 min-max 缩放或窗宽窗位映射，值域可能全部低于 255 或全部超过 255。
排查步骤：
- 先打印
arr.min()和arr.max()。 - 如果最小值接近 0，最大值只有几十，图像当然偏黑。
- 如果最小值是负数，比如 -1024（空气的 CT 值），需要先做减去 intercept 的偏移。
- 在 Python 中建议观察直方图，确定像素值分布，再决定映射区间。
我写了一个简易探针函数，在批量转换前先跑一遍，检查一批数据的值域：
def probe_dicom(path): ds = pydicom.dcmread(path) arr = ds.pixel_array print(f"shape={arr.shape}, dtype={arr.dtype}, min={arr.min()}, max={arr.max()}") if hasattr(ds, 'WindowCenter'): print(f"WindowCenter={ds.WindowCenter}, WindowWidth={ds.WindowWidth}") if hasattr(ds, 'RescaleSlope'): print(f"RescaleSlope={ds.RescaleSlope}, RescaleIntercept={ds.RescaleIntercept}")5.2 图像方向翻转或旋转
MRI 图像尤其容易出现方向问题。DICOM 里有ImageOrientationPatient和ImagePositionPatient标签，定义了图像在病人坐标系里的方向。很多转换工具图省事，直接按像素数组原样输出，导致和影像科工作站上的方向不一致。
解决方案：读取方向标签后，做一个极简的 2D 判断。比如 CT 轴位图像，如果方向余弦向量的第一个分量是负值，通常说明需要左右翻转：
orientation = ds.ImageOrientationPatient # 取前三个元素是行方向余弦，后三个是列方向余弦 row_dir = orientation[:3] col_dir = orientation[3:] # 方向需要左翻/右翻的情况 if row_dir[0] < 0: img = img.transpose(Image.FLIP_LEFT_RIGHT) if col_dir[1] < 0: img = img.transpose(Image.FLIP_TOP_BOTTOM)这个方法并不覆盖所有方位情况，但对轴位、冠状位、矢状位的常见检查已经足够。如果要做严谨的医学图像处理，建议用 nibabel 或 dcm2niix 先把 DICOM 转成 NIfTI，利用完整的体数据方向信息，再切片导出。
5.3 文件名重复导致覆盖
如果直接用原始文件名输出，不同患者、不同检查、不同序列之间很可能出现同名文件，批量转换中一旦输出到同一个目录，就会互相覆盖。这个问题在 GUI 工具里尤其明显，导出完根本不知道少了哪些层。
我的方案是在文件名中拼接足够多的唯一信息，最简单的做法：
out_name = f"{ds.PatientID}_{ds.StudyInstanceUID[:8]}_{ds.SeriesNumber:03d}_{ds.InstanceNumber:04d}.jpg"如果是科研数据脱敏后使用，不想要 PatientID，就用StudyInstanceUID的前 8 位加上 SeriesNumber 和 InstanceNumber，基本可以保证全局唯一。
5.4 压缩传输语法读取失败
现在很多设备导出的 DICOM 是 JPEG 压缩传输语法（如 JPEG Baseline、JPEG 2000），使用 pydicom 读取时如果缺少解压库会直接报错。此时需要安装以下库：
pip install pylibjpeg pylibjpeg-openjpeg pylibjpeg-libjpeg gdcm安装后 pydicom 会自动调用这些处理器。如果你不想装这些，也可以改用 dcmtk 的dcmdjpeg先解压成标准 DICOM，再做后续转换。但直接在环境里装好gdcm更省事，一次配置，处处使用。
还有一种少见的传输语法是 RLE 无损压缩，GDCM 对它的支持比较好，而 pylibjpeg 对某些 RLE 变体的支持有限。真遇到读不出来的情况，先查一下ds.file_meta.TransferSyntaxUID，再决定安装哪个库，比瞎猜快得多。
5.5 乱码标签和私有标签污染
有些老设备或第三方刻录软件，会在 DICOM 里写入私有标签，甚至有些标签编码是 GBK 而不是标准 UTF-8。读取时如果不是纯 ASCII，pydicom 可能会抛 UnicodeDecodeError。这种情况建议用SpecificCharacterSet标签来判断字符集，必要时手动将 strings 解码：
# 读取患者姓名字段时 try: patient_name = str(ds.PatientName) except Exception: patient_name = "Unknown"更稳妥的办法是，在批量转换时不要依赖太多 DICOM 标签做文件命名，因为只要某个标签值异常，整个转换就报错。给所有标签读取加 try-except 兜底，批处理的鲁棒性会好很多。
5.6 转换后图片尺寸和原图像素不一致
有时候 UI 上显示图片有放大比例，但转换出来的图像尺寸和设备标称的像素尺寸不一致。注意看PixelSpacing（像素间距）标签，比如 DR 全身拼接图的像素间距可能不是整数，转换时不需要修改像素尺寸，但需要在保存时记录这个参数。如果一定需要统一输出尺寸，建议用最高分辨率作为基准，避免降采样丢失信息。
6. 基于转换流程的改进与扩展
6.1 自动生成关键影像预览
批量转换送出来的图太多，临床医生没时间一张张翻。我后来在转换脚本里加了一个简单逻辑：根据SliceLocation或InstanceNumber自动抽取序列中间层作为该序列的封面图。这样每个序列只预览两三张，先粗筛再看全部，效率明显提升。
增强 CT 有动脉期、静脉期、延迟期，不同时期代表意义完全不同。可以根据AcquisitionTime或ContrastBolusAgent标签自动分组，每组生成一张拼接预览图。这个做法在制作病例汇报时特别省事。
6.2 把转换结果封装为带索引 HTML 的影像浏览包
之前说患者拿 DICOM 不会看，我后来做了一种“浏览器直看”方案：转换 JPG 的同时，生成一个 HTML 文件，把每个序列的图片用<img>标签按目录结构罗列出来，再用简单的 CSS 做网格布局。患者拿回家用任何浏览器打开 HTML 就能浏览影像。隐私方面注意不要把患者真实姓名直接写进 HTML，用检查号代替即可。
6.3 与 DICOM 结构化报告关联
如果你在整理科研数据，经常还要把放射科报告里的结论影像和 DICOM 图像对应起来。可以在转换时读取StudyInstanceUID和SeriesInstanceUID，然后和 SR 结构化报告里的引用进行匹配，最终输出一个“影像-报告”对应关系的 JSON 文件。这套思路用在几个课题数据整理里，帮我们省了至少两周的人工比对时间，而且数据一致性比手动核对高得多。
6.4 OCR 识别老病历中的影像
现在很多医院还有大量打印在胶片上的老影像，没有电子 DICOM。如果手头有胶片扫描图，可以先用转换工具把扫描图统一转成 PNG，再用开源的医学影像 OCR 工具识别叠加在胶片上的标签文字（患者号、检查日期、序列说明），输出成可搜索文本。虽然这一步已经超出格式转换范围，但和批量转换配合起来，可以把整个老病历数字化流程打通。
7. 转换工作流的安全与规范化建议
7.1 原始 DICOM 永远不要覆盖
这是最最重要的一条铁律。批量转换必须遵守“只读源文件、单独写到输出目录”的原则。我自己见过不止一次，有人为了省空间直接在原始文件夹里输出 JPG，结果后续再跑一遍转换脚本时，把已经生成的 JPG 又当成 DICOM 去读，程序直接崩溃。更可怕的是如果脚本有写回操作，原始 DICOM 数据一旦被破坏，医院设备数据无法轻易恢复，这是严重事故。
如果硬盘空间紧张，输出目录可以放在另一个物理硬盘上。比起省几百 GB 的存储，保住原始数据的完整性更有价值。
7.2 脱敏处理
处理科研数据时，患者隐私问题怎么重视都不过分。批量转换时如果需要把数据带出医院，建议在脚本中直接跳过或打码以下标签：PatientName、PatientID、PatientBirthDate、AccessionNumber、InstitutionName。更严格的做法是重新赋一个伪 ID，并保存在本地映射表里，不能直接出现在输出文件里。
我的习惯是：输出 JPG/PNG 的文件名只用StudyUID前缀加序列号和实例号，完全不出现任何患者标识；元数据 CSV 中只保留脱敏后的 ID。这样交出去的图片包从源头就不含个人隐私字段。
7.3 转换日志与可追溯性
批量转换要留日志，这不是可选项而是必选项。日志至少记录：输入文件路径、输出文件路径、检查号、转换时间、使用的窗口参数、异常信息。一旦下游发现某批数据有问题，可以立刻追溯到是哪个环节出的错。
import logging logging.basicConfig( filename='conversion.log', level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s' ) logging.info(f"Converted {dcm_path} -> {out_path}, center={center}, width={width}")如果转换任务运行了数小时，日志还能帮你定位到中途失败的位置，不用从头再来。
8. 踩坑后的沉淀
这套批量转换流程从第一版到现在，已经迭代了很多次。最大的体会是：转换工具本身不难，难的是对“输入数据多样性”的敬畏。同一家医院的 DICOM 基本稳定，但换一家医院、换一个厂家的设备，就可能出现新的传输语法、新的私有标签、新的图像编码方式。所以我现在处理任何新来源的 DICOM 数据，第一件事永远是做抽样探针，把每一类模态、每一个序列的像素特征和标签情况摸清，再跑全量转换。
还有一个小技巧想分享给大家：批量转换完成之后，不要急着删原始文件。先随机抽 20 张输出图片，用 DICOM 查看器逐一比对原图，确认方向、对比度、命名都没问题，再决定是否进入下一步。这个人工抽检步骤看起来慢，实际上能避免大量返工。我因为当初偷懒跳过这一步，有一次把一组 MRI 序列的方向全部搞反了，直到算法组反馈训练指标异常才发现，被迫把所有数据重新转换一遍，那种教训一次就够了。
医学影像格式转换是数据处理流程里最基础的一环，但也恰恰是最容易被轻视的一环。把基础环节做稳、做规范，后续的科研分析、临床协作、AI 模型训练才会减少很多莫名其妙的问题。希望这篇经验整理能帮你少走一些弯路。
