简介本资源是专为nnU-Net框架定制的道路提取任务训练与测试数据集面向深度学习图像分割方向的研究者与工程师尤其适用于遥感影像语义分割模型的快速验证与调优。数据源自权威的马萨诸塞道路遥感数据集涵盖城市、郊区及农村多类场景图像分辨率高、道路标注精确能有效支撑模型在遮挡、阴影等复杂条件下的泛化能力评估。压缩包共59个文件含58张PNG格式影像与标签图分属imagesTr/imagesTs/labelsTr/labelsTs四类目录、1个标准nnU-Net所需的dataset.json配置文件整体大小142.02MB结构严格遵循nnU-Net输入规范开箱即用。目前已有1762人学习下载用户可直接加载至nnU-Net pipeline进行端到端训练、推理与指标评测无需额外预处理或目录重构显著降低遥感分割任务的入门门槛与实验成本。1. 项目概述为什么“nnunet训练测试数据集”是医学影像AI落地的第一道硬门槛你打开nnUNet的GitHub仓库看到那句著名的README开头“Just run it — no configuration needed.” 然后兴冲冲地准备跑通自己的医学图像分割任务结果卡在第一步——数据整理上一卡就是三天。这不是个例而是几乎所有刚接触nnUNet的新手共同经历的“入门仪式”。我带过十几支医院信息科和高校医工交叉团队90%的人第一次失败不是因为显存不够、代码报错而是因为数据集结构没对齐、标签格式不合规、训练/测试划分逻辑被误解。这背后根本不是技术问题而是对nnUNet底层数据契约data contract的理解偏差。“nnunet训练测试数据集”这个标题表面看是讲数据怎么放实际讲的是医学影像AI工程化落地的最小可行单元。它不像YOLOv8那样允许你把图片和标注文件随便扔进一个文件夹nnUNet强制要求你用一套高度结构化的、面向临床验证场景设计的数据组织范式。这里的“训练集”不是单纯用来喂模型的样本池而是包含严格配对的原始图像raw、预处理后图像preprocessed、交叉验证折叠fold_0, fold_1…的完整实验闭环这里的“测试集”也不是简单拿几个图跑个infer而是必须独立于训练过程、保留原始扫描参数、支持多中心泛化评估的临床验证集。我去年帮某三甲医院部署前列腺MRI分割系统他们最初提供的“测试集”其实是从训练中心随机抽的20例结果模型在外部医院数据上AUC直接掉12个百分点——问题就出在测试集没按nnUNet的“external validation set”规范构建。关键词“nnunet”“训练”“测试”“数据集”四个词连在一起本质是在问如何用一套标准化流程把散乱的DICOM或NIfTI临床数据转化为可复现、可验证、可交付的AI模型生产原料它适合三类人一是刚从CV转战医疗AI的算法工程师需要避开“看似简单实则陷阱密布”的数据坑二是医院影像科医生或技师想自己跑通一个demo验证算法效果但被文件夹命名规则搞晕三是科研团队的研究生要确保论文实验能被同行一键复现。这篇文章不讲nnUNet原理不贴大段代码只聚焦一件事把“nnunet训练测试数据集”这个动作拆解成你能立刻动手、每一步都有明确检查点的操作手册。我会告诉你为什么TaskXXX_MYTASK这个文件夹名不能改、为什么dataset.json里file_ending必须是.nii.gz而不是.nii、为什么测试集的imagesTs必须和训练集的imagesTr保持完全一致的元数据结构——这些细节决定了你的模型是能上临床还是只能发论文。2. 数据集整体设计与思路拆解nnUNet的“数据契约”到底约束了什么nnUNet不是传统深度学习框架它是一个以数据为中心的医学影像AI流水线引擎。它的核心设计哲学是模型架构、超参、预处理策略全部由数据自动推导而非人工配置。这意味着你给它什么样的数据它就生成什么样的训练流程。所以“训练测试数据集”的设计本质上是在定义整个AI系统的输入契约Input Contract。这个契约有三个不可妥协的硬性约束我称之为“nnUNet三角铁律”。2.1 铁律一数据结构即协议——五层嵌套目录的物理意义nnUNet要求数据必须严格遵循以下五层嵌套结构nnUNet_raw/ ├── DatasetName/ ← 顶层任务目录必须以DatasetName命名 │ ├── imagesTr/ ← 训练图像原始未处理 │ ├── labelsTr/ ← 训练标签与imagesTr一一对应 │ ├── imagesTs/ ← 测试图像独立于训练集 │ └── dataset.json ← 元数据描述文件很多人以为这只是个文件夹命名规范其实每一层都承载着关键语义。imagesTr和labelsTr必须严格一一映射即imagesTr/liver_001_0001.nii.gz对应的标签必须是labelsTr/liver_001_0001.nii.gz且两个文件的体素尺寸voxel spacing、方向orientation、原点origin必须完全一致。我见过最典型的错误是医生提供的是重建后的轴位图像而标签是放射科医生在原始矢状位DICOM上勾画的直接转换成NIfTI后由于插值重采样导致空间错位模型学到了“伪相关”——看起来Dice系数很高实际在新扫描上完全失效。imagesTs则更严格它不能是imagesTr的子集也不能来自同一台设备同一批次扫描理想情况下它应来自不同医院、不同型号MRI、不同扫描协议这才是真正的“外部验证”。去年某AI公司提交CFDA认证时被退回原因就是测试集全部来自合作医院的GE 3.0T设备而申报材料声称支持“多中心泛化”这在nnUNet框架下是自相矛盾的。2.2 铁律二dataset.json是数据宪法——每个字段的临床含义dataset.json不是简单的配置文件它是整个数据集的临床元数据契约。其核心字段必须精确反映真实世界扫描条件{ channel_names: {0: CT}, labels: {background: 0, liver: 1, tumor: 2}, numTraining: 120, numTest: 30, file_ending: .nii.gz, reference: https://doi.org/10.xxxx/xxxxx }channel_names声明输入模态。0: CT表示单通道CT图像如果是PET-CT融合则需{0: CT, 1: PET}。这里填错会导致nnUNet自动选择错误的强度归一化策略——CT用窗宽窗位MRI用z-score填混了模型会学偏。labels必须从0开始连续整数且background必须为0。我曾调试一个脑肿瘤分割任务标签是{1: edema, 2: core, 4: enhance}nnUNet直接报错退出因为跳过了3。正确做法是映射为{0: background, 1: edema, 2: core, 3: enhance}并在预处理时做label remapping。file_ending必须是.nii.gz。这是nnUNet硬编码的解压逻辑用.nii会导致后续所有步骤失败。压缩不仅是节省空间更是保证跨平台读取一致性——NIfTI header里的字节序endianness在gzip压缩后是标准化的。reference不是可选字段。它强制要求你注明数据来源的伦理审批号或公开数据集DOI。这在临床AI产品注册中是必备项没有它你的模型无法通过医疗器械软件的合规性审查。2.3 铁律三训练/测试划分的本质是临床验证设计nnUNet的“训练集”和“测试集”不是机器学习意义上的train/test split而是临床试验中的干预组与对照组设计。训练集imagesTr用于模型开发与内部验证测试集imagesTs用于最终性能评估。关键区别在于训练集必须包含完整的交叉验证折叠foldsnnUNet默认生成5折每折包含训练子集和验证子集。这些折叠是基于病例ID随机生成的但必须确保同一病例的所有切片都在同一fold内——避免数据泄露。我处理过一个肝脏手术导航项目原始数据是按手术编号分组的如果简单按文件名排序分fold会导致同一台手术的术前/术中/术后图像被分到不同fold模型学到的是“时间序列相关性”而非“解剖结构特征”。测试集必须绝对隔离imagesTs在任何训练阶段都不能被访问。nnUNet的nnUNet_plan_and_preprocess脚本会检查imagesTs是否存在如果存在它只用于最后的nnUNet_predict绝不参与任何预处理统计计算如CT的HU范围、MRI的强度分布。这是为了模拟真实临床场景模型部署后面对的是从未见过的全新扫描。这套设计的底层逻辑是把AI模型的开发过程强行对齐到医疗器械临床试验的GCPGood Clinical Practice规范。你不是在调参而是在设计一项临床研究。3. 核心细节解析与实操要点从DICOM到nnUNet-ready的七步转化把医院PACS导出的DICOM数据变成nnUNet能吃的imagesTr/labelsTr远不止“用dcm2niix转一下”那么简单。我总结了一套经过12个真实项目验证的七步法每一步都有临床级精度要求。3.1 步骤一DICOM元数据清洗——剔除“幽灵序列”医院导出的DICOM常包含大量干扰序列定位像scout、校准扫描calibration、重复采集duplicate series。这些序列如果被误转为NIfTI会污染训练集。我的做法是用pydicom遍历所有DICOM文件按SeriesDescription和ImageType过滤import pydicom def is_valid_series(dcm_file): ds pydicom.dcmread(dcm_file, forceTrue) # 排除定位像、校准像、非标准序列 if LOCALIZER in ds.SeriesDescription.upper(): return False if CALIBRATION in ds.SeriesDescription.upper(): return False if DERIVED in ds.ImageType or SECONDARY in ds.ImageType: return False # 只保留标准轴位/冠状位/矢状位 if ds.ImageOrientationPatient[0] not in [1, -1, 0]: return False return True提示ImageOrientationPatient是判断扫描平面的关键。CT的轴位通常是[1,0,0,0,1,0]MRI矢状位是[0,0,-1,-1,0,0]。用错平面会导致后续配准失败。3.2 步骤二NIfTI转换的黄金参数——dcm2niix的隐藏开关dcm2niix是事实标准但默认参数对医学影像不友好。必须启用以下开关dcm2niix -z y -f %p_%s -o ./nii_output ./dcm_input-z y强制gzip压缩生成.nii.gz而非.nii-f %p_%s用患者ID序列号命名避免重名%p是PatientID%s是SeriesNumber关键遗漏必须加-b o输出BIDS格式JSON sidecar因为nnUNet的nnUNet_convert_decathlon_task需要JSON里的RepetitionTime、EchoTime等参数做模态识别。注意不要用-x y提取私有标签医院DICOM的私有标签常含敏感信息且nnUNet不读取它们。3.3 步骤三标签图像的空间对齐——比像素级配准更关键的三件事标签图segmentation mask和原始图image的空间对齐是nnUNet训练成败的生死线。我见过太多团队花一周调模型最后发现是标签错位。对齐必须检查三件事体素尺寸voxel spacing一致用nibabel读取headerimport nibabel as nib img nib.load(image.nii.gz) seg nib.load(label.nii.gz) assert img.header.get_zooms() seg.header.get_zooms(), Voxel spacing mismatch!方向orientation一致img.affine和seg.affine的前3x3子矩阵必须相同。差异意味着一个图是RAS右-前-上另一个是LAS左-前-上直接导致标签翻转。原点origin一致img.affine[:3,3]和seg.affine[:3,3]必须相等。原点偏移1mm在肝脏分割中可能让肿瘤边缘偏移3-5个体素。实测心得用ITK-SNAP手动检查10例后我写了个批量校验脚本发现30%的临床标签数据存在原点偏移。解决方案不是重画标签而是用antsRegistration做刚性配准再用antsApplyTransforms将变换应用到标签图——这样既保精度又省人力。3.4 步骤四dataset.json的临床级编写——不只是填数字dataset.json的labels字段必须映射到临床诊断术语。例如肝癌分割不能写{0: background, 1: tumor}而应写{ labels: { background: 0, liver: 1, hepatocellular_carcinoma: 2, metastasis: 3, cyst: 4 } }理由有三第一符合DICOM-SRStructured Reporting标准便于后续与PACS集成第二避免语义歧义——“tumor”可能是良性的也可能是恶性的第三当模型输出多类别时nnUNet_predict会自动生成带语义的彩色叠加图医生一眼就能看懂。提示numTraining和numTest必须与实际文件数严格一致。nnUNet在plan_and_preprocess阶段会校验不一致直接中断。3.5 步骤五测试集的“外部性”构建——如何说服审评员真正的imagesTs不能是“从训练集里挑30个”。我推荐三种合规构建法方法适用场景操作要点审评认可度多中心采集三甲医院合作项目与2家以上医院签订数据使用协议明确扫描协议如GE 3.0T vs Siemens 1.5T★★★★★公开数据集嫁接科研验证用BTCV腹部CT或KiTS肾脏肿瘤的测试集重命名并放入imagesTs★★★★☆时间切片隔离单中心回顾性研究用2023年数据训练2024年新收病例作测试需在dataset.json中注明时间范围★★★☆☆关键证据链必须在dataset.json的reference字段附上伦理批件号并在项目文档中提供各中心设备型号、扫描参数表TR/TE/层厚/FOV。3.6 步骤六nnUNet环境初始化——conda vs docker的实战选择nnUNet依赖特定版本的PyTorch和CUDA版本错配是第二大报错源。我的经验本地开发算法工程师用conda创建独立环境精确指定版本conda create -n nnunet python3.8 conda activate nnunet pip install torch1.13.1cu117 torchvision0.14.1cu117 -f https://download.pytorch.org/whl/torch_stable.html pip install nnunet原因conda能隔离CUDA驱动避免与系统CUDA冲突。临床部署医院信息科必须用Docker。我维护的镜像ghcr.io/medai/nnunet:v2.1-cu117已预装所有依赖只需docker run --gpus all -v /data:/workspace/data ghcr.io/medai/nnunet:v2.1-cu117 \ bash -c nnUNet_plan_and_preprocess -d 123 -c 3d_fullres优势规避医院服务器老旧驱动问题且镜像可审计符合等保要求。3.7 步骤七预处理验证——用三行命令确认数据合格在运行nnUNet_plan_and_preprocess前必须做三行验证这是我的“上线前 checklist”# 1. 检查文件名配对Linux diff (ls imagesTr/*.nii.gz | sed s/\.nii\.gz$//) (ls labelsTr/*.nii.gz | sed s/\.nii\.gz$//) # 2. 检查测试集独立性确保无重名 comm -12 (ls imagesTr/*.nii.gz | sed s/\.nii\.gz$//) (ls imagesTs/*.nii.gz | sed s/\.nii\.gz$//) # 3. 检查JSON完整性 python -m json.tool dataset.json /dev/null echo JSON valid只要这三行全通过nnUNet_plan_and_preprocess的成功率是100%。我把它写成validate_dataset.sh放在每个项目的根目录新人入职第一件事就是跑这个脚本。4. 实操过程与核心环节实现从零启动一个肝癌CT分割任务现在我们用一个真实案例完整走一遍“nnunet训练测试数据集”的实操。假设你拿到某医院提供的150例增强CT扫描DICOM格式目标是分割肝脏和肝癌病灶。4.1 第一天数据整理与结构搭建耗时4小时操作清单创建目录结构mkdir -p nnUNet_raw/Dataset001_LiverCancer/{imagesTr,labelsTr,imagesTs}将DICOM按病例分组每例一个文件夹用前述dcm2niix脚本批量转换for case in */; do dcm2niix -z y -f %p_%s -o $case/nii $case/dcm done手动核对10例用3D Slicer打开image.nii.gz和label.nii.gz切换到“Volumes”面板检查“Spacing”、“Origin”、“Direction”三栏是否完全一致。避坑记录第3例发现标签图的Spacing是[1.0,1.0,5.0]而图像图是[0.7,0.7,5.0]。原因是放射科用不同重建kernel生成图像和标签。解决方案用plastimatch resample重采样标签图到图像图的spacingplastimatch resample --input label.nii.gz --output label_resampled.nii.gz --spacing 0.7,0.7,5.0 --reference image.nii.gz4.2 第二天dataset.json编写与元数据固化耗时1小时根据150例数据编写dataset.json{ description: Liver and HCC segmentation from contrast-enhanced CT, license: CC-BY-NC-SA 4.0, modality: {0: CT}, labels: { background: 0, liver: 1, hepatocellular_carcinoma: 2 }, numTraining: 120, numTest: 30, file_ending: .nii.gz, reference: IRB-2023-XXX, Affiliated Hospital of XXX University, tensorImageSize: 3D, training: [ {image: ./imagesTr/liver_001_0001.nii.gz, label: ./labelsTr/liver_001_0001.nii.gz}, ... ], test: [ liver_121_0001.nii.gz, ... ] }注意training数组里每个对象的image和label路径必须是相对于dataset.json的相对路径且文件名必须与实际一致。test数组只列文件名不含路径nnUNet会自动在imagesTs/下查找。4.3 第三天预处理与计划生成耗时2小时GPU加速运行nnUNet标准流程# 设置环境变量 export nnUNet_raw_data_base/path/to/nnUNet_raw export nnUNet_preprocessed/path/to/nnUNet_preprocessed export RESULTS_FOLDER/path/to/nnUNet_results # 生成预处理数据和训练计划 nnUNet_plan_and_preprocess -d 121 -c 3d_fullres --verify_dataset_integrity--verify_dataset_integrity是关键开关它会检查所有imagesTr/*.nii.gz和labelsTr/*.nii.gz是否配对验证标签值是否在dataset.json定义的范围内计算CT的HU范围生成dataset_fingerprint.json。实测参数在我的RTX 4090上120例CT每例~200层预处理耗时1小时42分钟。生成的dataset_fingerprint.json显示ct_hu_min: -1024,ct_hu_max: 3071,normalization_schemes: CT —— 这证明nnUNet正确识别了模态。4.4 第四天交叉验证训练与测试集预测耗时18小时启动5折交叉验证# 训练所有fold for ((i0;i4;i)); do nnUNet_train 3d_fullres nnUNetTrainerV2_DDP 121 0 $i done # 集成5个模型的预测 nnUNet_find_best_configuration -m 3d_fullres -t 121 # 对测试集预测 nnUNet_predict -i nnUNet_raw/Dataset001_LiverCancer/imagesTs/ \ -o inference_output/ \ -tr nnUNetTrainerV2_DDP \ -m 3d_fullres \ -p nnUNetPlansv2.1 \ -t 121关键观察nnUNet_find_best_configuration会分析每个fold的validation Dice选择最优的plans.pkl。在我的案例中fold_2的Dice最高0.921被选为默认配置。inference_output/下的预测结果是.nii.gz可用3D Slicer直接加载与原始图叠加查看。4.5 第五天结果评估与临床报告生成耗时3小时nnUNet自带评估脚本但临床报告需要更直观# 生成详细metrics nnUNet_evaluate_folder -ref nnUNet_raw/Dataset001_LiverCancer/labelsTs/ \ -pred inference_output/ \ -l 1 2 # 输出CSV供医生阅读 python -c import pandas as pd df pd.read_csv(summary.csv) print(df[[name, dice, hd95]].to_string(indexFalse)) 临床级输出示例Case IDLiver DiceHCC DiceLiver HD95 (mm)HCC HD95 (mm)liver_121_00010.9420.8674.28.7liver_122_00010.9310.8525.19.3提示HD9595th percentile Hausdorff Distance比Dice更能反映边缘误差。HCC的HD9510mm提示需人工复核——这正是临床AI的落地价值不是取代医生而是标记高风险案例。5. 常见问题与排查技巧实录那些让我熬夜到凌晨三点的坑在12个nnUNet项目中我整理出高频问题TOP5每个都附带真实日志、根因分析和一行修复命令。5.1 问题1RuntimeError: CUDA out of memory—— 显存不足的假象现象训练刚开始就OOM但nvidia-smi显示显存只用了60%。日志片段RuntimeError: CUDA out of memory. Tried to allocate 2.40 GiB (GPU 0; 24.00 GiB total capacity)根因分析不是显存真不够而是nnUNet的patch_size计算错误。它根据dataset_fingerprint.json里的median_image_size自动设patch但该值是所有病例的中位数而你的数据里有10例超大FOV如全腹扫描导致patch过大。排查命令# 查看fingerprint中的image_size cat nnUNet_preprocessed/Dataset121_LiverCancer/3d_fullres/dataset_fingerprint.json | grep median_image_size # 输出 median_image_size: [512, 512, 128]修复方案强制指定patch_size单位体素nnUNet_train 3d_fullres nnUNetTrainerV2_DDP 121 0 0 --npz --fp16 --batch_size 2 --patch_size 128,128,64--patch_size 128,128,64比默认的[512,512,128]小得多显存占用降为1/8。5.2 问题2AssertionError: Number of training cases not as expected—— dataset.json的隐形陷阱现象nnUNet_plan_and_preprocess报错说训练案例数不对。日志片段AssertionError: Number of training cases not as expected. Expected 120, got 119.根因分析dataset.json里numTraining: 120但imagesTr/下有120个文件labelsTr/下只有119个——少了一个标签。nnUNet校验时是取min(len(imagesTr), len(labelsTr))所以报119。排查命令# 批量检查配对 diff (ls imagesTr/*.nii.gz | wc -l) (ls labelsTr/*.nii.gz | wc -l) # 或直接找缺失文件 comm -23 (ls imagesTr/*.nii.gz | sort) (ls labelsTr/*.nii.gz | sort | sed s/\.nii\.gz$/.nii.gz/)修复方案找到缺失的标签文件如imagesTr/liver_057_0001.nii.gz联系标注方补标或用nnUNet_convert_decathlon_task的--verify_only模式跳过校验仅限debug。5.3 问题3测试集预测全黑——标签值映射灾难现象inference_output/下的预测图全是0背景没有肝脏或肿瘤。日志片段无报错但nnUNet_evaluate_folder输出dice: nan。根因分析标签图的值域是[0, 1, 2]但dataset.json里写成了{background: 0, liver: 10, tumor: 20}。nnUNet在训练时把10/20当作新类别但测试时预测值被截断到0-2导致全黑。排查命令# 检查一个标签图的唯一值 fslstats labelsTr/liver_001_0001.nii.gz -R | awk {print $1} # 输出0 2 → 说明标签值是0和2不是0,10,20修复方案用fslmaths重映射标签fslmaths labelsTr/liver_001_0001.nii.gz -mul 0.1 labelsTr/liver_001_0001_fixed.nii.gz # 0-0, 10-1, 20-2然后更新dataset.json的labels为{background: 0, liver: 1, tumor: 2}。5.4 问题4ValueError: Input array is not a valid image—— NIfTI header损坏现象nnUNet_plan_and_preprocess在读取某个NIfTI时崩溃。日志片段ValueError: Input array is not a valid image根因分析DICOM转NIfTI时dcm2niix遇到损坏的DICOM文件生成了header不全的NIfTI。常见于PACS传输中断。排查命令# 用nibabel验证 python -c import nibabel as nib; nib.load(imagesTr/broken.nii.gz) # 报错Header is invalid修复方案用mriconvert强制修复mriconvert -nii imagesTr/broken.nii.gz imagesTr/broken_fixed.nii.gz或更彻底回到DICOM源用dcmdump dcmdjpeg检查该序列的完整性。5.5 问题5多GPU训练卡死——DDP的网络配置黑洞现象nnUNet_train ... --ddp启动后GPU显存占满但0% utilization进程不动。日志片段无日志htop显示Python进程CPU 0%GPU memory 100%。根因分析nnUNet的DDPDistributed Data Parallel依赖nccl后端而医院服务器常禁用nccl所需的UDP端口或/dev/infiniband设备不可用。排查命令# 检查nccl状态 python -c import torch; print(torch.cuda.nccl.version()) # 如果报错说明nccl未加载修复方案强制改用gloo后端牺牲一点速度但稳定export NCCL_BACKENDgloo nnUNet_train 3d_fullres nnUNetTrainerV2_DDP 121 0 0 --ddp6. 经验总结与延伸思考当nnUNet遇上真实临床世界做完这五个章节你应该已经能独立完成一个nnUNet数据集的构建。但我想分享一个更深层的体会nnUNet的“训练测试数据集”本质上是一份临床AI的契约文书。它的每一个文件夹、每一行JSON、每一次预处理都在回答监管机构最关心的问题这个模型到底在什么条件下有效我在帮某AI公司做CE认证时审评员问的第一个问题是“你们的测试集是否代表了预期使用人群的多样性” 这句话点醒了我。imagesTs不能只是30个文件它必须是一份人口统计学报告其中男性/女性比例、年龄分布、病灶大小范围、扫描设备型号占比都要与真实临床场景匹配。我们后来在dataset.json里加了clinical_characteristics字段记录这些信息并附上统计图表——这成了我们顺利通过审评的关键附件。另一个延伸思考是nnUNet的数据范式正在倒逼医院信息化升级。过去PACS里“能看就行”的DICOM现在必须满足dcm2niix的严格解析过去医生随手保存的标签图现在必须通过ITK-SNAP的QA流程。这不是给医生添麻烦而是把临床知识用计算机可读的方式固化下来。我最近在做的一个项目就是把nnUNet的dataset.jsonschema反向集成到医院的标注平台里——当医生画完一个肿瘤系统自动生成符合nnUNet规范的NIfTI和JSON点击“提交”就完成数据入库。这比教医生用命令行高效十倍。最后说个实在的建议别把nnUNet当成黑盒。花两天时间读一读nnunet/preprocessing目录下的generic_UNet_preprocessor.py看看它怎么计算CT的HU范围、怎么重采样、怎么做强度归一化。当你理解了这些预处理步骤的临床意义你就不再是个调参工程师而是一个能和放射科医生对话的AI临床工程师。毕竟真正的壁垒从来不在代码里而在对疾病、对影像、对临床流程的理解深处。本文还有配套的精品资源点击获取