fMRI原始数据分割实操指南：从DICOM到BIDS的整理与校验

接手第一批fMRI数据那会儿，我压根没把“分割”俩字放心上。当年从扫描仪拷回来的文件夹一堆DICOM文件，我满脑子想的都是“赶紧跑预处理”，结果第一步就卡了壳——软件不认这些格式，文件东一个西一个，连哪个序列是功能像、哪个是结构像都分不清。后来才意识到，fMRI原始数据分割听起来像是个不起眼的杂活，实际上是整个数据分析流程能不能顺利跑通的命门。这篇笔记，就是把我这几年处理原始数据时摸索出来的一套分割、整理和校验的方法记录下来，给刚入坑fMRI数据处理的研究生，以及被多被试、多session数据折磨到崩溃的科研助理做个参考。

这里说的“分割”，不是指把大脑影像分割成灰质、白质那种组织分割，而是数据层面的拆分与组织：把一堆混乱的原始文件，整理成一个个干净、可追溯、能被下游工具直接读取的标准文件。搞清楚这件事，后面所有预处理步骤才有意义。

1. 为什么“分割”不只是一个搬运文件的机械动作

1.1 扫描仪导出的原始数据到底长什么样

MRI扫描仪输出到光盘或服务器上的数据，绝大多数是DICOM格式。这个格式本身没有问题，它是医学影像的通用标准，医院PACS系统全靠它运行。但问题在于，DICOM文件到了科研分析环境中非常”笨重“：一个功能像序列可能包含几百上千个独立文件（一个slice一个文件），还夹杂着定位像、校准像、各种名字看不懂的序列。分析工具像FSL、SPM、AFNI，虽然也能读DICOM，但效率低，而且容易把不同序列搞混。

还有一种情况：有些研究组已经用配套软件把DICOM转成了4D的NIfTI文件（一个文件包含整个时间序列），比如说bold_4D.nii.gz。那是不是就不需要分割了？不一定。后面要做slices到volume的一致性检查、剔除前几个不稳定volume、按条件切分回归量，都需要把4D文件拆开处理。“分割”在这条流程里的意思是双重的：一是把DICOM按序列拆成NIfTI，二是把4D NIfTI按时间点或空间位置拆开。

1.2 分割要解决的是三个层面的混乱

第一层是序列层面：一次扫描会出来几十个序列，要能从中挑出T1结构像、BOLD功能像、场图（field map）、扩散像等，并且正确配对，不张冠李戴。第二层是时间层面：功能像通常是4D数据，分割成单个3D volume后，才能逐帧检查头动、信号异常；多run实验也需要把连续采集的数据切回每个run对应的独立文件。第三层是空间层面：个别场景下要单独提取某个slice或某个区域来检查，比如确认slice order设置是否对应实际采集顺序。

如果这三层混乱没有理清就急着去做头动校正、配准，往往会在结果里埋雷，而且一旦进到后面步骤，再回头排查原始数据问题，代价极大。所以我现在的习惯是：拿到数据的第一天，先不做任何高难度处理，专心把数据组织结构搞清楚。这一步踏实了，后面全流程都能受益。

2. 分割前先花十分钟摸清DICOM的数据结构

2.1 看懂Patient/Study/Series/Image四个层级

DICOM的数据组织方式类似于医院病历的归档逻辑。最顶层是Patient，对应一个受试者；往下是Study，对应一次检查（比如某天在扫描仪上做的一次完整扫描）；再往下是Series，对应一个扫描序列（比如T1_MPRAGE、BOLD_rest、fieldmap_phase）；最底层是Image，对应单个slice或单个信号采集对应的文件。要注意的是，不同厂家的扫描仪导出的文件夹命名习惯完全不同：西门子经常是带一堆序号的全大写目录，GE是.IMA后缀居多，飞利浦则喜欢用随机字符串命名。靠文件夹名字猜内容很不靠谱，一定要靠DICOM头部信息来识别。

2.2 用工具快速列出一份“扫描清单”

我习惯在分割前先用dcm2niix的查看模式打印一份序列摘要，不需要任何图形界面，终端敲一行命令就行：

dcm2niix -v -o /tmp/dump /path/to/raw_data

-v会输出每个序列的详细信息，包括SeriesNumber、SequenceName、ImageType、TR/TE、矩阵大小、层数等。把这份输出存成一个文本文件，作为原始数据的索引档案。如果数据是.IMA或是嵌套目录，dcm2niix会自动递归找到所有DICOM文件，所以不用自己写find命令去逐个统计。

如果只想快速知道有哪些序列、每个序列多少张图，还可以用dcmdump（DCMTK工具包）配合grep来提取关键标签，比如：

dcmdump $(find /path/to/raw_data -type f | head -n 1) | grep -E "SeriesDescription|SeriesNumber|EchoTime|RepetitionTime"

这一步的核心目的是：在动手分割之前，先把“这一批数据里到底有什么”这个问题回答清楚。我见过有人拿到数据就盲目批量转换，转完才发现漏了场图序列，或者把定位像当成功能像转了出来，浪费了半天时间。

3. 两条主流分割路线的实操对比

3.1 路线一：dcm2niix 一把梭，DICOM转NIfTI

这是绝大多数情况下的首选。dcm2niix（Chris Rorden出品）是目前转换DICOM到NIfTI的事实标准，跨平台，支持几乎所有主流扫描仪的私有格式，还能直接按BIDS风格输出JSON文件。

我最常用的转换命令长这样：

dcm2niix -z y -o /data/BIDS/sub-01/func -f sub-01_task-rest_run-1 %d /path/to/SERIES_FOLDER

逐个解释参数：

• -z y：输出压缩的NIfTI文件（.nii.gz），能省下大概一半的磁盘空间。
• -o：指定输出目录。我习惯提前按BIDS目录结构建好，转换完直接落到正确位置。
• -f：指定输出文件名模板。%d会被替换为SeriesNumber加序列描述，避免重名；更精细的做法是自己拼名字，比如sub-01_task-rest_run-1。
• 最后的参数指向某个序列的文件夹，如果直接指向受试者总目录，dcm2niix默认会把所有序列都转出来。对新手来说，一次全转然后手动挑文件也是个可行策略，但前提是你已经对着2.2的清单核对过一遍。

dcm2niix在转换时还会自动生成.json文件，里面记录了TR、TE、翻转角、slice timing等关键参数。这个文件别删，后续做时间层校正、设计矩阵时全靠它。还有一个隐藏好处：部分扫描仪（比如西门子的VB系列）在DICOM头里的slice order信息不完整甚至错误，dcm2niix会尝试从SequenceName和私有标签推断，虽然不能保证100%正确，但至少比一个外行空手查DICOM头靠谱得多。

3.2 路线二：fslsplit 按时间点把4D序列切成3D文件

很多时候你手里的数据已经是4D NIfTI（比如别人已经帮你转好了，或者你从OpenNeuro这类公开数据库下载的数据）。这时候要做的是把4D数据按时间点切开，比如：检查每个volume的头动、去掉前5个预扫描volume、把静息态数据按连续帧切块做滑动窗口分析。

FSL里的fslsplit一行命令搞定：

fslsplit sub-01_task-rest_bold.nii.gz sub-01_task-rest_vol -t

参数-t表示按时间轴（第4维）切分，输出文件会得到sub-01_task-rest_vol0001.nii.gz、sub-01_task-rest_vol0002.nii.gz这样按顺序编号的3D文件。默认编号是四位数，如果你的数据超过9999个volume（实际上几乎不可能），需要加-z参数调整填充位数。比如：

fslsplit sub-01_task-rest_bold.nii.gz vol_ -t -z

如果不希望压缩输出，可以加--nocompress，但一般没必要。

切完之后要验证一下数量对不对：总共应该等于原始4D文件的时间点数。用一条命令确认：

fslhd sub-01_task-rest_bold.nii.gz | grep dim4 # 或者 python -c "import nibabel as nib; print(nib.load('sub-01_task-rest_bold.nii.gz').shape)"

我在实际工作中还经常用到一个反向操作fslmerge，把切开的文件再合并回去。这个在特殊场景下很有用，比如你手动去掉了一些坏volume之后，可以fslmerge -t把剩下的文件重新拼成一个完整的4D序列继续跑后续流程。

3.3 如果只想抽特定几个时间点或某个slice

有一个需求频率也很高：只提取某个时间点，或者只看某个位置的slice。比如你想确认第10个volume和第100个volume之间有没有明显的全局信号跳变，或者你想把第20层的图像单独导出来画个图。fslroi最顺手：

# 提取第10个volume（索引从0开始） fslroi input_4D.nii.gz vol_10.nii.gz 10 1 # 提取第20层slice，保留所有时间点 fslroi input_4D.nii.gz slice_20.nii.gz 0 -1 0 -1 20 1 # 提取第5到第10个time point（共6个volume） fslroi input_4D.nii.gz sub_bold_05_10.nii.gz 5 6

它的参数逻辑是<输入> <输出> <xmin> <xsize> <ymin> <ysize> <zmin> <zsize>，没有写的维度默认全取。写完参数建议自己拿fslhd核对一下输出的维度，这个ROI提取虽然不难，但三维坐标写反的情况我见过不少次。

如果你更习惯用Python，nibabel的方式同样直观：

import nibabel as nib import numpy as np img = nib.load("input_4D.nii.gz") data = img.get_fdata() # 取第10个volume（索引为9） vol = data[:, :, :, 9] # 取第20层slice，所有时间点 sl = data[:, :, 19, :] # 保存 nib.save(nib.Nifti1Image(vol, img.affine), "vol_10.nii.gz")

这个路子适合要顺带做点数据检查的情况，比如算一下某个slice的时间序列均值、看有没有全0序列等。

4. 分割后的一致性检查：参数不能拍脑袋

4.1 用fslhd逐项核对关键元数据

分割操作完成后，最大的风险在于：文件路径是对的，命名也对，但里面的参数和实验设计对不上。比如你计划里写TR=2000ms，实际扫描TR=1500ms；或者你打算用隔层采集（interleaved），实际是顺序采集（sequential）。这些如果不在源头纠正，后面所有套用固定参数的脚本都会乖乖地把错误放大。

我的检查清单固定包含这几项，全部来自fslhd或nibabel的输出：

有时dcm2niix转出来的文件，pixdim4会显示一个很小的小数（比如0.000833），那是因为某些扫描仪把TR记录为毫秒但文件内部按秒又有误差。遇到这种情况不要急着改数字，先回看.json文件里的RepetitionTime字段，以那个为准，后续预处理时手动传入正确的TR即可。

4.2 用BIDS风格命名文件和目录，而不是随手取名

分割整理出来的数据，最终要服务的是下游所有人（包括未来的你自己）。我在吃过几次亏之后彻底倒向了BIDS（Brain Imaging Data Structure）命名规范。它不只是一套命名规则，更是一套能机器可读的数据组织标准。简单来说，功能像放在func/目录，文件名按sub-<label>_task-<task>_run-<run>_bold.nii.gz的格式来，结构像放anat/，场图放fmap/。这个规范的好处是：FSL、SPM、fMRIPrep等工具可以直接识别，你换一个人来分析数据也不会一头雾水。

一个典型的BIDS目录结构长这样：

sub-01/ ├── anat/ │ └── sub-01_T1w.nii.gz ├── func/ │ ├── sub-01_task-rest_bold.nii.gz │ └── sub-01_task-rest_bold.json ├── fmap/ │ ├── sub-01_phasediff.nii.gz │ └── sub-01_magnitude1.nii.gz └── sub-01_scans.tsv

当然，如果你只是自己跑通一条分析流程，不打算公开发布数据，BIDS看起来有点重。但至少文件名里要带上subjID_task_scanDate这类信息，别用001.nii.gz这种根本追溯不到出处的名字。

4.3 建立一份扫描记录表，比任何记忆都可靠

分割、命名都做完了，还差最后一件事：把每一步整理的依据记录下来。我习惯在每个被试的目录下放一个scans_notes.tsv，里面包含：

这份表不只是给别人看的，更是给两周后的自己看的。人的记忆在大量数据面前非常不可靠，尤其是同时处理二三十个被试的时候，记录表就是你的导航系统。

5. 分割过程中几个让人血压升高的翻车现场

5.1 多回波数据被当成单回波一股脑合并

现在很多研究组用multiband多回波序列（比如Siemens的CMRR序列），每个时间点会采集两个或更多个回波（TE不同）。这种数据在DICOM层面是同一个序列里的多个Series，或者在同一个Series里交替存储。如果直接用dcm2niix默认参数去转，它可能会把多个回波合并到一个4D文件里，或者生成带_e1、_e2后缀的多个文件，具体行为取决于扫描仪和版本。

我遇到过的最坑的情况是：三个回波被合并成了一个3倍时间点数的文件，第一眼看过去还以为是正常数据，结果后面做glm时激活图一团糟。排查了好久才发现时间点数不对。处理多回波数据时，务必用2.2的清单确认好每个回波的图像数量，然后分割成独立的回波文件。dcm2niix有一个-m参数可以设置合并策略，但我更推荐先把各回波拆开，等预处理阶段再按需要合并或做加权平均，这样始终保留原始信息。

5.2 slice order方向搞反，时间层校正直接废掉

时间层校正（slice timing correction）非常依赖slice order信息。slice order指的是扫描仪采集slice的先后顺序，常见的有sequential descending（从顶部到底部）、sequential ascending（从底部到顶部）、interleaved（隔层采集）等。如果分割时没有正确记录slice order，或者转换工具推断错了，后面的时间层校正就是在错误的方向上插值，相当于给每个voxel的时间序列引入系统性的相位错误。

怎么核对slice order？最靠谱的方式是看扫描仪的DICOM头或扫描参数页。西门子数据可以在.json文件里看SliceTiming字段，GE和飞利浦则需要翻序列参数。dcm2niix生成的.json里通常有SliceTiming数组，里面有每个slice的采集时间点，把这个数组画出来或者输出到文本，和扫描协议里的采集方式对照一下，基本就能确认。我曾经在分不清SeqDesc和SeqAsc的情况下硬跑了整个流程，结果发现事件相关设计的统计结果一片乱麻，浪费了整整一周。现在我的习惯是：做时间层校正之前，先把slice order打印出来贴在工位上。

5.3 压缩格式带来的兼容性陷阱

dcm2niix默认输出.nii.gz，我很喜欢，因为省空间。但有一个坑：老版本的SPM（比如SPM8、SPM12某些配置）对.nii.gz的支持不稳定，某些插件和脚本会直接报“Unknown file type”错误。遇到这种情况，不一定是文件损坏，多半是工具不认压缩格式。解法很简单，解压即可：

gunzip sub-01_task-rest_bold.nii.gz

或者用fslchfiletype统一转格式：

fslchfiletype NIFTI input.nii.gz output.nii

类似的兼容性坑还有：nii和.img/.hdr两种NIfTI封装。fslchfiletype NIFTI转成.img/.hdr对老工具最友好。我的建议是：数据存档用.nii.gz，给具体工具跑之前先确认输入要求，省得在报错上反复折腾。

5.4 在原始DICOM目录里直接改文件

新手最容易犯的一个错误是在扫描仪导出的原始文件夹里直接做修改：重命名DICOM文件、移动子文件夹、甚至为了腾空间删除某些序列。这么做非常危险：一来原始DICOM文件是研究对象，出了问题很难重新获取；二来很多DICOM文件之间的关联依赖文件名和内部标签，手动乱改可能破坏序列完整性；最后，实验记录和伦理审查往往要求保留原始数据，不留痕迹地改动会让你后面写方法部分时无据可依。

我自己的硬性铁律是：任何处理都在副本上进行。拿到原始数据先做整体备份，然后在另一个工作目录里操作。分割产生的中间文件可以被随意删除重建，但原始文件夹始终保持复制过来后的初始状态。

6. 分割结果如何与下游预处理无缝衔接

6.1 分割后先做一轮简便QC，别急着跑全流程

分割整理好的数据，在进入fMRIPrep或者FSL全套流程之前，值得花几分钟做一次视觉和数值上的QC。我的做法分三步：

第一，看整体信号。用fslview或fsleyes加载一个中间volume，检查有没有明显的全脑信号丢失、头部外伪影、明显的死区。第二，看时间序列稳定性。用fslmeants提取全脑均值时间序列：

fslmeants -i sub-01_task-rest_bold.nii.gz -o global_signal.txt

然后快速画个图，观察有没有突然的大幅跳变或缓慢漂移。如果发现某些volume的信号特别异常，记下来后面处理。第三，估算头动。我一般先跑一次mcflirt，不看最终结果，只看它输出的.par文件里平移和旋转参数的峰值，头动超过3mm或3度的数据直接标记为高危。这三步做完，数据能跑什么级别的分析，心里就有底了。

6.2 把分割脚本化，集成到批处理或BIDS流程里

手动处理一个被试还可以接受，但二三十个被试还手动搞，纯属折磨自己。我强烈建议把分割和整理过程写成脚本。最简单的形式是一段Bash，循环处理多个被试的DICOM数据，自动创建BIDS目录结构，然后调用dcm2niix转换。

#!/bin/bash for subj in sub-01 sub-02 sub-03; do mkdir -p /data/$subj/{anat,func,fmap} dcm2niix -z y \ -o /data/$subj/func \ -f "${subj}_task-rest_bold" \ /raw/$subj/SERIES_8 done

脚本化之后最大的好处是可复现：无论谁在什么时间重跑，只要原始数据不变，得到的分割结果完全一致。这比命令行记在聊天记录里可靠多了。更进一步，可以研究一下dcm2bids这个工具，它专门用来把DICOM转成BIDS格式，通过一个JSON配置文件映射序列和输出文件名，整个分割过程只需要两条命令：

dcm2bids_scaffold -o /data/BIDS dcm2bids -d /raw/sub-01 -p 01 -c dcm2bids_config.json

配置文件的写法不复杂，核心就是把序列描述和BIDS标签对应起来：

{ "descriptions": [ { "dataType": "func", "modalityLabel": "bold", "customLabels": "task-rest_run-1", "criteria": { "SeriesDescription": "BOLD_rest" } } ] }

我第一次跑通这套批量转换的时候，最大的感慨是：之前花在人工整理数据上的时间，简直可以攒出一个完整的周末。早点把这些重复劳动交给脚本，专业的人做专业的事，数据整理同样值得认真对待。

从最原始的DICOM一堆散件，到规规矩矩的BIDS目录，中间经过的就是分割和整理这一步。它不复杂，但特别考验耐心和细心。以我自己的经验，分割时偷的懒，都会在后面的预处理和统计分析阶段加倍还回来。宁可多花一晚上把数据检查得清清楚楚，也别在结果一团糟的时候才回头追悔。