肿瘤影像的一座整库 — TCIA 的两百余个 collection

240 个 collection / 逐集许可 / 逐集 DOI

来源 https://www.cancerimagingarchive.net/collections/发布时间: 2026-10-26最后更新: 2026-10-26 阅读 4
肿瘤影像的一座整库 — TCIA 的两百余个 collection

信息速览

数据集名称肿瘤影像的一座整库 — TCIA 的两百余个 collection
数据类型原始影像,元数据,人工标注,文献引用
规模不适用(整库层无统一病例数;各 collection 独立计数,最大单集合两万余例)
接入方式https://www.cancerimagingarchive.net/collections/
AI 就绪度

TCIA 不是「一个数据集」,而是一层归档。它把几百个按疾病、部位或模态组织起来的研究队列收进同一个检索目录,每个队列各自带着许可、DOI、版本号和访问级别。你在页面上看到的一行,是一整支队列;你下载到的,是这支队列的全部病例影像;你引用时写下的,是它自己的那一串 DOI。

这层结构给出的好处很直接:同样找肺部 CT,你不需要分别去七八个机构网站注册、逐份同意不同的条款、逐个理解不同的目录约定,一次检索就能看到候选,再逐个判断哪一个可用。麻烦也在这里——整库并没有统一规格。许可、病例数、有没有标注、能不能商用,全部由单个集合决定,目录层只负责把它们并列摆出来。

于是判断 TCIA 能不能用,实质上是判断「你的任务能否落在某一个或几个具体集合的能力边界之内」。本文按「先定位、再取数、最后看边界」的顺序展开,把整库的收录规则、许可分层、DOI 机制与多版本问题逐一拆开,并在 §4.2 用一个集合从申报到再版的全过程当作贯穿案例。一屏速览见下表。

维度 内容
官方名称 The Cancer Imaging Archive(TCIA)
中文常用名 癌症影像归档 / 开放癌症影像库
资助与管理 NCI 癌症影像计划(CIP)资助,FNLCR 合同管理,历史策展由 UAMS 承担
入口 cancerimagingarchive.net/collections/
整库性质 归档层,聚合两百余个独立发布的 collection
目录规模 官方 Browse Collections 表约两百四十行,其中 Complete 约两百一十一、Ongoing 约二十六(含两个表外状态)
单集合规模 十余例至两万余例不等,最大为 NLST 队列
数据格式 放射影像以 DICOM 为主;病理含 SVS 等全切片格式;支持数据含 SAS、XLSX、XML、DOCX、ZIP
许可 逐集合:多数 CC BY 3.0 或 CC BY 4.0,少数历史集合 CC BY-NC,头颈类为受限许可
访问级别 Public(注册与否皆可下载)与 Limited(需 dbGaP 申请)
标识符 每个 collection 一个 DOI,Analysis Results 另有 DOI
版本机制 每个集合独立版本号,页面保留 Previous Versions 与更新说明
取数方式 网页下载 + NBIA Data Retriever + NBIA REST API + tcia_utils + IDC 云平台
外部关联 ClinicalTrials.gov 编号、GDC 基因组、CDAS 临床试验数据集
适合 肿瘤影像预训练、跨机构泛化评测、影像组学与放射基因组研究

§1 它要解决的具体麻烦

1.1 癌症影像的稀缺不是缺图,而是缺「能被合法复用并且能追溯到来源的图」

医院里堆着的肿瘤影像远比公开库多,问题在于这些影像被三件事挡在门内。第一件是去标识化:一份带日期、带机构、带设备序列号的 DICOM 头,直接公开就是一次隐私事故。第二件是授权链路:影像归采集机构,患者同意的范围未必覆盖二次研究,机构内部还要过伦理审查。第三件是来源可追溯:即使影像被拷出去,下游无法知道它出自哪个队列、哪个版本、对应哪篇论文。

TCIA 的定位就是把这三件事一次性做掉。提交方在数据离院之前,由 TCIA 团队协助完成去标识化与策展,再由 TCIA 发布、分配 DOI、写引用格式。对使用者来说,拿到的是一个可以写进论文参考文献的发布单元,而不是一个来源不明的压缩包。也正因为这一层承担了合规与策展,它的产物必然是「很多个发布单元」而不是「一个大文件」——这是理解后面所有细节的前提。

1.2 三条常见的错误期待

第一条期待是把 TCIA 当成一个规格统一的大数据集。它的目录确实是一张表,所有行共用同一组列名,看起来像是一个关系数据库。但这些列只是展示用的摘要,进入单个集合后,数据访问表的列数、字段名、文件格式、许可声明各不相同。指望用一套代码吃下整库,会在第二个集合上就撞墙。

第二条期待是把「有影像」等同于「有标注」。影像本体(DICOM 序列)与标注(分割、结节勾画、影像组学特征)是两条分别发布的线,后者放在 Analysis Results 里,有自己的 DOI 和自己的提交者。有的集合两者齐全,有的只有影像,有的影像在 TCIA 而标注在第三方平台。

第三条期待是把「公开可下载」等同于「可以随便用」。TCIA 的公开是访问层面的公开,不是许可层面的无条件。署名、引用 DOI、不得尝试重新识别受试者,是每个集合都有的底线;此外还有非商业限制、TCGA 类数据的发表窗口等附加条款,逐集合不同。

1.3 它能给到的与给不到的

你的需求 它给的 够不够
找一批肺癌 CT 做病灶检测预训练 多个肺癌相关集合,单集合可至两万余例,均有 DICOM 够,但需自行按模态与层厚筛
找带体素级肿瘤分割的训练集 部分集合自带 RTSTRUCT 或 SEG,更多分割在 Analysis Results 够,但要跨两层检索
找病理全切片图像 多个集合含 Whole Slide Image 与 Tissue Microarray 够,注意非 DICOM 格式与专用下载通道
找同一患者影像加基因组 TCGA 系集合与 GDC 可对应,部分集合含 Molecular Test 部分够,需自行做跨库对齐
找统一协议采集的对照人群 有少量健康受试者集合,规模几十到百余例 不够,正常对照总体偏少
找一个可以直接喂进模型的张量文件 提供 DICOM,不提供 NIfTI 或 NumPy 张量 不够,转换要自己做
找带完整临床随访表的队列 部分集合附临床表与数据字典,NLST 等附 SAS 与 ZIP 部分够,字段跨集合不统一
找带官方划分的训练/验证/测试切分 绝大多数集合不提供切分 不够,需自建并按患者分组

1.4 你的处境与它能帮到的事

你的处境 它能帮你什么 下一步该做什么
课题要在半年内做出一个可发表的肿瘤分割基线,没有自有数据 提供多个带标注或可挂接标注的集合,可直接作为训练与外部验证来源 先按 §6.2 的路径筛出「有标注 + Public + 癌种匹配」的集合
模型在本地数据上表现很好,投出去被质疑泛化性 提供多机构、多设备来源的同类影像,天然构成外部测试集 选两个以上机构来源不同的集合作外部测试,并写明来源差异
想研究影像特征与基因型的关系,手上只有影像 TCGA 系集合可与基因组数据按病例对齐,部分集合自带分子检测结论 从 TCGA 系集合入手,先核对病例编号体系是否能与 GDC 对齐
数据要进商业产品,法务要求许可链路清楚 每个集合有明确许可与 DOI,目录层可先筛 逐个核对许可版本,排除 CC BY-NC 与受限许可集合
学生团队做课程项目,预算与算力都有限 有大量中小规模集合,几十到几百例,下载量在十几 GB 量级 选单集合而非整库,避免一次拉取数 TB
已经下载过某个集合,发现数字和论文里不一致 页面保留版本历史与更新说明,可定位差异来源 核对版本号与更新日期,必要时回退到论文所述版本
需要在论文里合规地声明数据来源 提供集合级数据引用格式与致谢模板 按页面 Citations 区原样引用,不要用网页 URL 代替 DOI

1.5 一句话判断

如果你要的是「一批来源可追溯、许可可核对、能写进参考文献的肿瘤影像」,TCIA 是当下最省事的起点;如果你要的是「一个开箱即用的张量数据集」,它给不了,你还要自己做一层工程转换。

1.6 不适合谁:四条边界

不适合需要单一许可、希望一次授权覆盖全部数据的产品团队。整库没有统一许可,逐个集合核对是绕不过去的工作量;一旦产品同时用到 CC BY 与 CC BY-NC 的集合,授权范围就必须按最严的那一个收紧。

不适合以病灶级精细标注为核心需求的团队。TCIA 的强项是影像本体与队列结构,标注覆盖不齐;需要逐层、逐病灶、多读者一致性标注时,往往要转向专门的分割挑战数据集,再把 TCIA 的影像作为补充。

不适合需要前瞻性、统一协议、严格入排标准的临床研究。绝大多数集合是回顾性数据,来自常规诊疗或历史试验,扫描参数与随访节奏都不统一;把它当作临床试验级证据使用,会在混杂因素上失守。

不适合申请人层级不够的团队去碰受限数据。受控访问要求申请人达到相当于终身教职或资深科学家的层级,研究生与博士后不能作为申请人;含面部影像的集合尤其如此,绕不开这条规定。

§2 数据构成与规格

2.1 两层发布单元:Collection 与 Analysis Results

TCIA 的发布单元有且只有两种。第一种是 Collection,官方定义是「由共同疾病、影像模态或研究焦点关联起来的患者队列」,它是影像数据的载体。第二种是 Analysis Results,是对已有集合做的分析产物——分割、标注、影像组学特征、批量处理后的衍生影像。两者在网站上分属两个浏览入口,各有独立的 DOI,也各有自己的许可与引用格式。

这个二分法决定了检索方式。你要找「有没有这个癌种的影像」,去 Collections;你要找「有没有人对这批影像做过勾画」,去 Analysis Results。一个常见的工作流是先在 Collections 里锁定影像,再去 Analysis Results 里找挂在该集合下的衍生数据。集合页面的 Related Datasets 区会把这两类并列展示,并用图例标出哪一条是 Analysis Result、哪一条是 Collection。

需要强调的是,Analysis Results 并不必然由原始集合的作者提交。第三方团队可以基于公开集合做标注并另行发布,这在肺部结节方向尤其常见,于是同一个影像集合下可能挂着多个来源不同的标注版本,彼此的分读者、标注规范、病例覆盖范围都不一致。

2.2 目录层字段的完整字典

Browse Collections 表是整库的目录视图。每一行代表一个集合,列名固定,但只承担摘要职能。

字段 含义 取值形态 使用注意
Collection 集合名,指向集合主页 英文短名,多为疾病缩写或机构缩写组合 是整库内的唯一键,引用时用它定位页面
Cancer Type 癌种 可多值,逗号分隔,含 Non-Cancer 一个集合可同时标多个癌种
Locations 解剖部位 可多值,用的是解剖学本体术语 与癌种不是一对一,同一部位可对应多个癌种
Species 物种 Human、Mouse、Canine 等 非人物种集合不适合直接当临床数据用
Subjects 病例数 整数 是人数不是影像数,与 Image Count 不是一个量级
Data Types 数据类别 可多值,影像模态与支持数据混排 出现 Segmentation 表示集合内自带分割数据
External Resources 外链类别 Clinical、Genomics、Proteomics、Image Analyses 等 表示该集合可在其他平台找到配套数据
Access 访问级别 Public 或 Limited Limited 需按 §5.4 走审批
Status 状态 Complete 或 Ongoing Ongoing 表示集合仍在扩充
Updated 更新日期 年/月/日 是集合内数据最后一次变动的时间

这张表之外还有三个不在列名里的隐式字段:每个集合的许可、DOI 与版本号。它们只出现在集合主页的数据访问表与引用区,目录层的表格不带。这一点是很多自动化脚本踩空的地方——从目录接口拿到的元数据里没有许可信息,必须再取一次单集合页面。

2.3 一条目录记录与一条集合记录的完整解剖

目录层的一条记录,展开成 JSON 大致是下面这个形状。字段名随接口版本变化,值取自官方目录当日所见,形态与真实返回一致。

{
  "Collection": "NLST",
  "CancerType": "Malignant Lung Neoplasm, Non-Cancer",
  "Location": "Chest",
  "Species": "Human",
  "Subjects": 26254,
  "DataTypes": "CT, Other, Tissue Microarray, Demographic, Diagnosis, Exposure, Measurement, Follow-Up",
  "ExternalResources": "Clinical",
  "Access": "Public",
  "Status": "Complete",
  "Updated": "2021/09/24"
}

进入单集合页面后,同一条记录会展开成一张数据访问表,每一行是一类可下载的文件,各自带格式、体量、许可与计数。以 NLST 为例,放射影像、组织切片、临床表被拆成不同的下载行,体量从兆字节级到太字节级相差三个数量级。

下载行 数据类型 格式 体量 Subjects Studies Series Images 许可
Radiology CT Images CT DICOM 11.14 TB 26254 73116 203099 21082265 CC BY 4.0
Tissue Slide Images Tissue Microarray SVS 775 GB 451 不适用 1225 不适用 CC BY 4.0
Clinical data Demographic / Diagnosis / Exposure / Measurement / Follow-Up SAS、ZIP、DOC 2.18 MB 不适用 不适用 不适用 不适用 CC BY 4.0
Additional histopathology slides Tissue Microarray SVS 1.62 GB 2 不适用 4 不适用 CC BY 4.0
Second primary tumor slides Tissue Microarray SVS 18.7 GB 10 不适用 23 不适用 CC BY 4.0

从这张表能读出三件事。第一,Subjects 不等于 Series,更不等于 Images,三者相差近四个数量级,用哪个数描述规模必须写清楚。第二,同一个集合内不同下载行的许可可以相同也可以不同,NLST 恰好处处相同,但这不是通则。第三,体量差异极大,规划存储时要按行看,而不是按集合看。

2.4 集合规模的分布形态

整库的病例数分布是典型的头部集中。绝大多数集合的病例数在几十到几百之间,少数几个大集合撑起总量。这种形态直接影响使用策略:如果目标是「大规模训练」,可选集合其实不多;如果目标是「多机构泛化评测」,大量中小集合反而是优势,因为它们覆盖了更多采集来源。

病例数量级 典型集合形态 适合的任务 下载体量感受
十余例至五十例 单中心小队列、罕见瘤种、体模研究 案例研究、小样本微调、方法演示 数百 MB 至数 GB
五十例至三百例 单中心或双中心专题队列 分割训练、单瘤种分类 数 GB 至数十 GB
三百例至一千例 多中心汇总队列、挑战赛来源 分割与分类基线、外部验证 数十 GB 至数百 GB
一千例至五千例 大型试验子集、跨机构汇总 大规模预训练、队列研究 数百 GB 至数 TB
五千例以上 国家级筛查试验影像 罕见,仅个别集合 太字节级

这张表回答的是「选哪个量级」。它不回答「具体多少例」——具体数字必须逐个集合核对,因为同为「几百例」的两个集合,实际规模可能差一倍,随访完整度也可能完全不同。

2.5 与同类资源的字段差异

维度 TCIA 单一挑战赛数据集 单中心开放库 云原生影像库(如 IDC)
收录单位 集合,数百个 一篇论文或一届赛事一个包 一个机构的若干个队列 集合的云镜像,附派生标注
许可 逐集合不同 通常单一,随赛事声明 通常单一 继承上游,逐集合不同
标识符 每集合一个 DOI 常有 DOI,也可能只有网页 视项目而定 继承上游 DOI
版本机制 每集合独立版本与历史 通常一版定稿 少有正式版本号 跟随上游版本
影像格式 以 DICOM 为主 常被预处理成 NIfTI 或 NPZ 混合 DICOM,另提供派生格式
标注覆盖 不齐,标注另层发布 赛事任务所需部分较齐 视项目而定 含大量社区派生标注
获取方式 网页、API、客户端 直接下载压缩包 直接下载 云查询、SQL 元数据、Python 客户端
适合的判断 覆盖面与来源可追溯性 可比性与基线复现 深度与随访完整度 免下载、免转换的实验效率

差异的核心在收录单位。挑战赛数据集以「一次评测」为单位,规模与标注都为该评测服务;TCIA 以「一支队列」为单位,规模与标注服务于这支队列本身的科研用途。前者可比性强,后者覆盖面广。两者并不是替代关系,很多挑战赛的影像源头本身就是 TCIA 的集合。

§3 整库的身份:它把自己放在哪一层

3.1 归档层,而不是采集方

TCIA 自己不采集影像。它的角色是接收、去标识化、策展、发布、分配标识符、维护版本。这个身份的后果是:整库的数据质量上限由提交方决定,TCIA 只能做下限保证——保证数据能被合法公开,保证来源可追溯,保证格式能被通用工具读取。

理解这一点,就能理解为什么目录层的字段如此克制。它只描述「这个集合是什么、有多大、能不能直接下」,不描述「这个集合的影像质量如何」。后者需要有临床背景的人进去看,或者等第三方做质量评估后再以 Analysis Results 的形式发布。

3.2 与 NCI 数据生态的接口位置

TCIA 挂在 NCI 癌症影像计划之下,是 NCI 癌症研究数据 commons 体系里负责影像的那一环。它和基因组数据 commons、临床试验数据系统、云分析平台之间有明确的接口关系,而不是各自为政。

对端系统 关系 对使用者的实际含义
GDC(基因组数据 commons) TCGA 系集合的影像与基因组分别存放,按病例编号对齐 需要自己做跨库对齐,不能期待开箱即用
CDAS(临床试验数据访问系统) 试验完整临床数据在此,TCIA 只放可公开分发的子集 完整随访表要去 CDAS 申请
IDC(影像数据 commons) 公开 DICOM 的云镜像与查询入口,2026 年起承接 TCIA 的公开 DICOM 后端 免下载浏览与 SQL 查询的入口在这里
dbGaP 受控访问数据的申请受理方 受限集合的审批在这里,不在 TCIA
ClinicalTrials.gov 试验类集合的注册号来源 集合页面会给出 NCT 编号,可用于追溯试验方案

这张表解释了一个常见困惑:为什么有些集合的临床数据「看起来不全」。不是 TCIA 藏了数据,而是完整临床数据按设计留在 CDAS,TCIA 只放可公开分发的那一部分,剩下的要靠试验编号去 CDAS 申请。

3.3 身份的三个可核验标记

判断一个页面是不是官方集合页,有三个标记可以核对。第一是 DOI,前缀统一为 10.7937,后面接一段专属标识,每个集合一个。第二是数据引用区,写着完整的引用格式与声明的许可。第三是版本历史,已维护过的集合会在页面下部列出 Previous Versions 与每次更新的说明。

三个标记里最有辨识度的是 DOI 前缀。10.7937 是 TCIA 的注册前缀,看到这个前缀基本可以确认是 TCIA 分配的集合级标识符。这也意味着引用时可以直接写 DOI 而不是网页地址——官方明确要求这样做,理由是 DOI 稳定而 URL 会随站点改版变化。

3.4 整库层的三个数字口径

描述 TCIA 的规模时,不同来源给出的数字差别很大,原因是口径不同。理解口径比记住数字重要。

口径 含义 典型来源 使用时注意
集合数 已发布的 Collection 条数 目录表行数 不含 Analysis Results
数据集数 集合数加 Analysis Results 数 项目方对外宣传 比集合数大,两数不可互换
病例数 去重后的人数 项目方统计或论文 跨集合可能有同一受试者重复出现
影像数 DICOM 实例数 单集合页面 与层厚强相关,不宜跨集合直接比
体量 存储占用的太字节数 单集合页面 常含重复序列,与实际有效信息量不等

这五个口径经常被混用。看到「多少数据集」时,要追问是集合数还是含 Analysis Results 的总数;看到「多少例」时,要追问是否去重。本文在必须给数字的地方一律注明口径与日期。

§4 整库的质量与特色

4.1 去标识化与策展是它可以被公开的前提

公开肿瘤影像最难的一步不是收集,而是证明它足够安全。TCIA 的做法是把去标识化放在数据离院之前,由 TCIA 团队与提交方一起做,并在提交页面上明确要求提交方不要在联系 TCIA 之前自行去标识化——理由是自行去标识化常常会删掉下游研究需要的信息。

这套流程带来两个可观察的后果。一是影像能保持 DICOM 原生结构,因为去标识化是在 DICOM 层面做的,没有把数据压成张量。二是策展深度受人力限制,一个集合从申报到发布通常需要几个月,因为 TCIA 长期在处理来自全球的提交队列。

4.2 案例:NLST 从受限试验影像到公开集合的三次再版

NLST 是整库中规模最大的集合,也是理解 TCIA 版本机制、许可变更与访问分级最好的样本。它来自美国国家肺癌筛查试验,试验本身在高危人群中比较低剂量 CT 与胸片筛查,注册号 NCT00047385,入组五万余人,其中低剂量 CT 组两万六千余人。TCIA 收录的是这批受试者中两万余例的低剂量 CT 影像,外加部分组织切片与临床表。

这个集合的访问状态经历过一次关键转折。早期它在 TCIA 上属于受限访问,2021 年 9 月限制解除,同时新增可下载的病理切片数据与临床数据表、数据字典。页面上的 Version 3 更新说明把这个转折写得很清楚:限制解除、病理与临床数据加入。许可也随之明确为 CC BY 4.0。

版本历史把这个集合的三次发布串了起来。Version 1 在 2013 年 3 月,是最初的影像发布;Version 2 在 2015 年 12 月,更新说明是修复存储迁移过程中损坏或缺失的影像;Version 3 在 2021 年 9 月,是前面提到的限制解除与数据扩充。三次发布之间相隔数年,每次都由外部事件触发,而不是例行刷新。

从 §4.2 的案例可以抽出三条可迁移的判断。第一,访问级别会变,早期受限不等于永久受限,早期公开也不保证永久公开(含面部影像的集合在 2022 年后反向收紧)。第二,版本号指向的是发布批次,不等于数据修正的次数,版本之间的差异要看更新说明而不是猜。第三,规模最大的集合往往也是结构最复杂的集合,因为它同时含放射影像、病理切片与多张临床表,下载行之间体量相差三个数量级。

4.3 特色:把「支持数据」当成一等公民

多数开放影像库只放影像,临床与分子数据由用户另找。TCIA 的做法相反:它把患者结局、治疗细节、基因组、影像分析结果都列为可随集合提供的支持数据,并在目录层的 Data Types 列里明确标出。这使得一个集合可以在影像之外,额外提供可用于生存分析或放射基因组研究的表。

支持数据类型 目录层的写法 是否常见 使用门槛
人口学与诊断 Demographic、Diagnosis 常见 低,随集合表下载
治疗与随访 Treatment、Follow-Up 较常见 中,字段名跨集合不统一
暴露与家族史 Exposure、Family History 少见,多见于筛查试验 中,需读数据字典
分子检测 Molecular Test 较少 中高,需与病理或基因组对齐
影像组学特征 Radiomic Feature 较少 中,注意特征提取软件版本
分割与标注 Segmentation、Measurement 中等 中,格式可能是 XML、SEG 或 ZIP
全切片影像 Whole Slide Image、Tissue Microarray 中等 高,非 DICOM,需专用通道

4.4 特色:每个集合都带一个可以写进参考文献的引用

这是 TCIA 相对多数开放库最实用的一处设计。集合页面的 Citations 区给出两段现成的引用:一段是数据引用,格式是「作者. (年份). Data From 集合名 [Data set]. The Cancer Imaging Archive. DOI」;另一段是数据集作者推荐的方法学论文引用,用于说明数据来源与设计。

引用要素 位置 写法要求
数据引用 集合页 Citations 区 必须含 DOI,不能只给网页地址
作者推荐论文 同区 Related Publications 通常必须一并引用
致谢模板 部分集合给出固定句式 按原样使用,不要改写机构名
通用方法学引用 Data Usage 页面 未使用具体集合、仅泛指 TCIA 时用

这套引用的价值在于可核查。审稿人拿到 DOI 就能定位到具体集合,也就能判断你用的规模与版本是否与你声称的一致。

4.5 质量的两个软肋

第一个软肋是采集协议不统一。回顾性集合的扫描参数分散在很宽的范围里,层厚、管电压、重建核、对比剂时相都可能不同。这对需要严格预处理一致性的任务构成实质障碍,也意味着跨集合训练时必须显式处理域差异,而不能假设数据同分布。

第二个软肋是标注口径不统一。同一个解剖结构,不同集合的勾画规范可能不同:有的勾画大体肿瘤体积,有的勾画临床靶区,有的只勾画增强部分。把这些标注混在一起训练,模型学到的是勾画习惯的平均值,而不是解剖边界。

§5 怎么把它取到手

5.1 三条取数通道与各自适用场景

TCIA 提供三条取数通道,选择哪一条取决于你要的是「几个集合」还是「整库」。

通道 取什么 适合 不适合
网页下载 + Data Retriever 单集合的影像清单与文件 精确下载某一集合 大批量、需要脚本化
NBIA REST API 集合列表、患者、研究、序列、影像元数据 建目录、做筛选、拉元数据 直接拉影像体素
tcia_utils(Python 包) 对上面两个通道的封装 教学、快速原型 超大规模并发
IDC 云平台 TCIA 公开 DICOM 的云镜像与 SQL 元数据 免下载浏览、跨集合 SQL 查询 需要私有部署或离线场景

2026 年起这套通道发生了结构变化:公开 DICOM 的后端逐步接入 IDC,受控访问数据迁至 NCI 数据 commons,TCIA 前端保留统一入口。Data Retriever 的新版本能读同一种清单文件、自动判断数据实际存放在哪个后端。对使用者来说,下载路径不变,但「Search」按钮会按数据归属跳转到不同平台。

5.2 用 API 把目录拉到本地

下面这段脚本取集合清单,用途是把目录层的快照存下来,便于日后对比版本变化。它只依赖标准库,不需要额外安装。注意这个端点只返回集合名,不返回状态,状态列需要在集合页面上取。

#-- 拉取 TCIA 集合目录并统计状态分布,仅用标准库
import json
import urllib.request
from collections import Counter

URL = ("https://services.cancerimagingarchive.net/nbia-api/services/v1/"
       "getCollectionValues?format=json")

#-- 官方接口偶尔对无 User-Agent 的请求返回 403,带上标识更稳
req = urllib.request.Request(URL, headers={"User-Agent": "tcia-catalog-check/1.0"})
with urllib.request.urlopen(req, timeout=60) as resp:
    raw = resp.read().decode("utf-8")

data = json.loads(raw)
print("返回行数:", len(data))
print("首条字段:", sorted(data[0].keys()))

#-- 该端点只给集合名,不含病例数与状态;后者要到集合主页取
names = sorted({row.get("Collection") for row in data})
print("唯一集合名:", len(names))
print("前十个:", names[:10])

#-- 存快照,文件名带日期,便于下次比对新增与消失的集合
import datetime
stamp = datetime.date.today().isoformat()
with open(f"tcia_collections_{stamp}.json", "w") as fh:
    json.dump(names, fh, ensure_ascii=False, indent=2)
print("已写入", f"tcia_collections_{stamp}.json")

与下次快照比对时,只要取两个文件的差集,就能看出哪些集合是新增、哪些已从目录里撤下。这一步比人工翻页可靠,也比依赖第三方清单稳妥,因为集合名本身是最稳定的键。

这段代码的产出是一份集合名列表,而不是完整的目录表。原因是集合值端点只返回名字,病例数、状态、访问级别都在单集合页面上。要做完整的目录快照,得再逐个访问集合页,或者改用带元数据的端点。

5.3 用 tcia_utils 一次取到集合级元数据

tcia_utils 把网页、API、病理、DOI 四条接口封装成四个模块。它的 wordpress 模块能直接抓到集合表里的结构化字段,是建本地目录最省事的办法。

#-- 取集合表与集合详情
import pandas as pd
from tcia_utils import wordpress as wp

#-- 集合表:一行一个集合,含癌种、部位、病例数、状态、更新日期
collections = wp.getCollections()
print(collections.shape)
print(collections.columns.tolist())

#-- 只看仍在扩充的集合
ongoing = collections[collections["status"].str.lower() == "ongoing"]
print("Ongoing 集合数:", len(ongoing))

#-- 单个集合的详情页字段(含 DOI、许可、版本)
detail = wp.getCollectionDetails("NLST")
for key in ("doi", "license", "status"):
    print(key, "=", detail.get(key))

两个模块的分工要说清楚:wordpress 管元数据,nbia 管影像。前者回答「有哪些集合、各有多大」,后者回答「这个集合里有哪些序列」。把两者混用是初学者最常见的浪费——用 nbia 去查集合名,会多走好几层调用。

5.4 受限数据:申请链路与它的硬门槛

受限访问不是「点一下申请」那么简单。2025 年 4 月起,NIH 对受控访问数据仓库施加了新的访问限制,面向特定国家的机构与研究者停止访问;为符合这一政策,TCIA 自 2025 年 7 月 8 日起停止直连托管受控数据,改由 dbGaP 受理申请、NCI 数据 commons 托管。

#-- 受限数据的取数流程(申请批准后才可执行)
#-- 第 1 步:在 dbGaP 确认所属 PHS 号
#--   含面部影像的 TCIA 集合统一为 phs004225
#--   Cancer Moonshot Biobank 的面部影像为 phs002192
#--   NCTN 试验数据按试验分别申请,PHS 号可在 TCIA 临床试验页查
#-- 第 2 步:dbGaP 提交数据访问请求,等待数据访问委员会审批
#-- 第 3 步:批准后登录 NCI 数据 commons 框架服务,生成 API Key 并存为 JSON
export NCI_DCF_KEY=/path/to/approved_key.json
test -f "$NCI_DCF_KEY" && echo "密钥文件就位"

#-- 第 4 步:从集合页取得 manifest,用 TCIA Data Retriever 指定密钥文件后拉取
#-- 第 5 步:核对下载完成数与 manifest 中的序列数是否一致
wc -l manifest-nlst_allCT.tcia

这条链路的硬门槛在申请资格,而不在技术。按 NIH 的规定,申请人须达到相当于终身教职或资深科学家的层级,研究生与博士后不能作为申请人,但可以在获批项目下参与使用。这意味着学生团队即使技术能力足够,也需要一位符合资格的负责人。

5.5 字段级陷阱:目录层看不见的四件事

拿到目录表之后,有四个信息不在表里,但它们决定了集合能不能用。

陷阱 表现 后果 规避办法
许可只在单集合页 目录表无许可列 误用 CC BY-NC 集合做商用 进入集合页读数据访问表的 License 列
版本只在单集合页 目录表只给最近更新日期 复现时版本不一致 记录版本号,并读 Previous Versions 说明
标注在另一层 目录表的 Segmentation 只表示集合内有 以为有全套体素标注 同时检索 Analysis Results
体量按下载行计 一个集合多行,各行体量不同 按集合总量估存储会偏大或偏小 按实际要用的下载行累加

第一和第二条最容易被自动化脚本忽略,因为接口返回的元数据结构里没有这两个字段。第三条是概念性的:集合内有分割,不等于每个病例都有分割,也不等于分割覆盖全部病灶。第四条是工程性的,规划存储时应以实际需要的下载行为单位。

5.6 从 DICOM 到可训练张量的最小转换链

TCIA 给的是 DICOM,模型要的是张量。中间这一步没有官方标准答案,但有公认的最短路径:读序列、按层厚重采样、转 HU、窗宽窗位归一化、按患者分组切分。这四步里最容易出错的是重采样,因为不同集合的层厚差异很大。

#-- 单个 DICOM 序列转成 HU 体素并做简单归一化
import numpy as np
import pydicom

def load_series(paths, slope_default=1.0, intercept_default=0.0):
    slices = []
    for p in paths:
        ds = pydicom.dcmread(p, force=True)
        #-- RescaleSlope 缺失时按 1 处理,这是 CT 的常见约定
        img = ds.pixel_array.astype(np.float32)
        img = img * float(getattr(ds, "RescaleSlope", slope_default))
        img = img + float(getattr(ds, "RescaleIntercept", intercept_default))
        origin = float(getattr(ds.ImagePositionPatient, "__getitem__")(2)) if hasattr(ds, "ImagePositionPatient") else 0.0
        slices.append((origin, img))
    slices.sort(key=lambda t: t[0])
    volume = np.stack([s[1] for s in slices], axis=0)
    #-- 软组织窗裁剪,避免金属伪影把分布拉偏
    volume = np.clip(volume, -1000.0, 400.0)
    return (volume + 1000.0) / 1400.0

#-- 调用方需保证 paths 属于同一 SeriesInstanceUID

这段代码省掉了两件工程上必要、但与本例无关的事:一是重采样到统一层厚,二是把不同设备的像素间距对齐。这两件事没有统一的默认参数,必须按目标任务决定,因此留在调用方。

§6 与库内其他页面的关系

6.1 关系图谱

库内已经收了若干来自 TCIA 的单个集合,本文补的是它们上方的那一层。两者是「目录」与「细分」的关系:既有页面回答「这个集合具体长什么样」,本文回答「这个集合在整库里处于什么位置、同类的还有哪些、选它的依据是什么」。

关系类型 库内对应方向 与本文的分工
上游父子 肺癌筛查影像专题 那边给出单集合细节,本文给出它在整库中的规模位次
上游父子 肺结节标注衍生数据专题 那是 Analysis Results 的一例,本文解释这一层的发布规则
同源不同集合 乳腺、脑、头颈等专题集合 各自展开,本文提供跨集合的许可与版本对照
平行生态 云原生影像库 本文说明两者的镜像关系与取数差异
平行生态 影像组学挑战赛 本文说明挑战赛影像多源自本库,可用于回溯来源
数据供给 多模态肿瘤分割 本文可回答其影像的上游集合与许可链路

6.2 检索路径

从整库定位到可用集合,最短的路径是四步筛选,每步都会砍掉大量候选。

步骤 筛什么 在哪筛 典型剩余
第一步 癌种与部位 目录表的 Cancer Type 与 Locations 列 原列表的一小部分
第二步 访问级别为 Public 目录表的 Access 列 去掉受限集合
第三步 数据类别含需要的模态与标注 目录表的 Data Types 列 去掉模态不匹配的
第四步 许可可接受、版本已稳定 进入集合页读 License 与 Version 最终候选,通常个位数

四步之后剩下的集合通常不多,这时才值得逐个打开页面看数据访问表的细节。反过来做——先下载再判断——会浪费大量带宽,尤其是遇到体量在太字节级的集合时。

关于 §4.2 的案例,这里可以给出一条具体的检索示范:以肺部筛查为起点,第一步在癌种列筛肺部相关,第二步限定 Public,第三步限定含 CT 与 Segmentation,第四步核对许可为 CC BY 4.0 且版本已更新到较新批次。四步走完,NLST 与其下挂的多个 Analysis Results 就会同时浮现,剩下的判断是「我要原始影像还是要别人做好的标注」。

再把这四步套到 §4.2 的案例上,还能看出一个容易被忽略的细节:第四步读版本的产出不只是「版本够不够新」,还包括「这次再版改了什么」。§4.2 的案例里,第二次再版的说明是修复存储迁移造成的影像损坏,第三次再版是访问限制解除并新增病理与临床数据。前者意味着旧版存在已知缺陷,应直接跳过;后者意味着新版的能力边界扩大了,早先「没有病理」的判断已经失效。同样是「有新版本」,两者对决策的意义完全相反。

§7 质量评估与已知局限

7.0 阅读本节前的一个前置校正

在给 TCIA 打分之前,需要先校正一个几乎人人都会犯的错位:把整库当成一个产品来评价。整库不是产品,它是一个发布平台;真正被评价的对象是集合,而集合的质量由提交方决定。用同一把尺子量整库,得到的分数既不能指导选数据,也不能指导用数据,只能制造误判。

更具体的误判有三种。第一种是把个别集合的缺陷当成整库缺陷,比如看到某个集合没有体素标注,就断定 TCIA 不适合分割任务。第二种是把整库的平均水平当成任一集合的保证,比如因为多数集合是 CC BY 3.0 就默认自己要用的那个也是。第三种是把平台的策展能力当成数据的科学性,比如因为去标识化做得规范,就认为扫描协议也规范。

校正之后的评价方式是按层次打分:平台层评价「收录、标识、许可、版本、取数」这五件事做得如何;集合层评价「规模、标注、采集一致性、随访完整度」这四件事做得如何。本节的两个评分表分别对应这两层,不要混读。

7.1 五维评分(平台层)

DAIMS 是数据资产与信息管理的评估框架,这里借它的五个维度给平台层打分。分数只针对「作为归档层」的职能,不针对任何具体集合。

维度 得分 判断依据 主要扣分点
可发现性 4.5 / 5 目录表字段规整,支持文本检索与筛选取值,DOI 齐全 目录层不含许可与版本,需二次进入
可访问性 3.5 / 5 公开集合直接下载,API 与客户端齐备 受限集合的门槛高,2025 年后链路变更
互操作性 4 / 5 放射影像统一 DICOM,支持数据用通用表格格式 病理为非 DICOM,临床表字段跨集合不统一
可复用性 4 / 5 引用格式现成,版本历史公开,去标识化规范 采集协议与标注口径不一致,限制跨集合直接复用
治理透明度 4.5 / 5 提交规则、许可政策、受限政策、版本说明全部公开 部分历史集合的许可沿革需回溯 wiki 旧页

平台层的总分接近 4,说明它在「让数据可被找到、可被引用、可被合规使用」这件事上是合格的。扣分集中在访问链路的复杂度与跨集合的语义一致性,这两点属于平台难以为继的固有难题,而不是执行失误。

7.2 集合层的四项检查

选到具体集合后,用四项检查替代打分,因为集合之间差异太大,分数没有可比性。

检查项 通过的样子 不通过的样子 怎么查
规模是否够 病例数满足任务下限,且有冗余 刚好够,留不出验证集 目录表的 Subjects 列
标注是否齐 目标结构在多数病例上有标注 只在少数病例上有 数据访问表的 Data Type 行
采集是否一致 层厚、设备分布集中 跨代设备混排、层厚跨度大 集合页的 Acquisition 或补充说明
随访是否全 临床表字段齐、缺失有说明 只有基线,无结局 支持数据表与数据字典

四项检查里最容易被跳过的是第三项,因为它没有直接的字段可查。层厚与设备的分布要读集合页的采集说明,或者抽样打开几例 DICOM 头自己数。§4.2 的案例之所以值得反复参照,就是因为它把这一项的答案摊开写了:同一批筛查影像来自几十家机构、跨多个年份,采集条件并不统一,这既是它的价值(真实世界多样性),也是它的代价(需要显式的域处理)。

7.3 已知的、可枚举的偏差

偏差 具体表现 对结论的影响
癌种覆盖偏斜 肺、脑、乳腺、头颈占多数 罕见瘤种上训练出的模型泛化证据薄弱
地域偏斜 以北美机构为主,少数欧洲、亚洲来源 人群构成与本地不一致时,流行病学结论不可直接搬
采集时间跨度长 早期集合的扫描参数已不代表当代设备 用旧集合训练、新设备部署时性能会掉
回顾性设计 多数集合无统一入排标准 混杂因素无法在数据层面控制
标注者差异 不同集合由不同团队勾画 跨集合训练学到的是勾画习惯的平均
正常对照偏少 健康受试者集合规模普遍偏小 分类任务的负类样本不易凑齐
临床表字段异构 同名概念在不同集合用不同列名 跨集合合并需人工映射

第七条的规避方式是借助官方的语义整合工作,但那层整合并非覆盖全部集合,且更新节奏慢于集合本身的扩充。实际工作中更可靠的做法是自己维护一张跨集合字段映射表,每接入一个新集合就补一行。

7.4 外部验证矩阵

判断一个平台或集合是否可靠,最省事的办法是看它被谁用过、怎么用。下面这张表列出四类可核查的外部证据,每类的核查入口与它能证明什么。

可核查的外部证据有四类,各自能证明的东西不同。数据集描述论文能证明设计与规模,但证明不了真实任务上的表现;引用该集合的第三方评测研究能证明它在特定任务上可用,但换一个任务就未必;赛事官网的数据来源说明能证明它有可比基线,但比不出标注质量的高低;政策文件与资助说明能证明合规地位,但证明不了科学价值。四类证据叠在一起,才构成对「这个集合能不能信」的合理判断。

以本文引用的第三方研究为例,有工作把 TCIA 中六个集合并成一千余例喉癌 CT 构建评测基准,也有工作把 TCIA 的直肠肝转移集合作外部验证队列。这类研究的共同特征是:先说明用了哪个集合、哪个版本,再报告在该集合上的表现。它们构成 §4.2 的案例之外的第二种用法示范——不是为了复现某个集合,而是把它当作独立来源的检验。

7.5 它为何能持续:靠一套不依赖单次资助的提交与引用循环

TCIA 能长期存在,不是因为它存得多,而是因为它把「提交」和「引用」连成了一个闭环。研究者提交数据,得到 DOI 与可引用的身份;后来的研究者引用这些数据,为提交者积累学术credit;提交者因此有动力继续提交,资助方也因此有理由继续支持。这个循环每一环都有明确的责任方:提交方负责数据,平台负责合规与发布,引用方负责致谢。

这套循环还有一个防退化的设计:版本历史公开。任何一次再发布都会留下记录与更新说明,这让「数据变过」这件事本身成为可核查的事实,而不是需要靠信任的承诺。

§8 生态位与历史

8.1 从前身系统到独立归档

TCIA 的前身是 NCI 癌症影像计划用来托管临床试验影像的一套系统,2011 年以新名字重新定位为覆盖更广来源的开放归档。这个转向的意义在于收录范围:原来只收试验影像,现在扩展到临床诊疗影像、体模研究、动物模型,甚至犬类肿瘤数据。

发展阶段可以分成四段,每段都有可指认的转折事件:前身期只托管临床试验影像,数据来源单一、公开程度有限;2011 年前后更名并扩展收录范围,开始按集合发布,使用者第一次可以用统一入口找多来源影像;2010 年代中期集合数量快速增加,支持数据与标注同步纳入,可用数据从影像扩展到影像加表;2020 年前后版本机制、许可分层、受限政策逐步固化,引用与合规有了稳定规则;2025 年至 2026 年进入重构期,受控数据迁出、公开 DICOM 后端接入云平台,下载入口不变而检索入口分流。

第五阶段的动因是政策而非技术。2025 年 4 月 NIH 调整受控访问数据仓库政策,TCIA 在三个月后停止直连托管受控数据;2026 年 4 月公布混合架构,把公开 DICOM 逐步交给云平台承接,同时保留前端统一体验。

8.2 与同期开放影像资源的生态分工

资源 生态位 与 TCIA 的关系 选择判据
云原生肿瘤影像库 镜像与增值层 承接 TCIA 公开 DICOM,叠加派生标注 要免下载与跨集合 SQL 时选它
单病种挑战赛数据集 可比性层 影像常源自 TCIA 集合,标注按赛事规范重做 要与公开榜单对齐时选它
医院自建影像库 深度层 随访与影像质量更高,但不对公开 需要前瞻性数据时选它
基因组数据 commons 分子层 与 TCGA 系集合按病例对齐 要做放射基因组时两库并用

这张表说明 TCIA 的位置不是「最大的库」,而是「来源最杂、许可最正规的一层」。它不追求单一病种的深度,追求的是覆盖面与可追溯性。

8.3 哪些集合已经冻结,哪些还在长

Status 列的 Complete 与 Ongoing 是最容易被忽略的一列。Complete 表示这个集合按设计已经发布完毕,不会再增加病例;Ongoing 表示还在扩充,今天下载的和半年后下载的可能不是同一批。

状态 含义 使用策略 风险
Complete 按设计发布完毕 可以作为稳定基准长期使用 低,但仍有维护性再版可能
Ongoing 仍在扩充 适合做持续评测,需记录下载日期 中,前后两次下载的样本集不同
Limited + Complete 冻结但需审批 适合做合规要求高的研究 中高,审批周期与资格限制
Limited + Ongoing 双重要求 谨慎,先确认能否获批再规划 高,两个不确定叠加

用 Ongoing 集合做评测时,至少要在方法部分写明下载日期与集合版本。否则半年后的重复实验会复现不出来,而这不是模型的错。

8.4 它今天面对的三个结构性压力

第一个压力是体量。大集合的下载量在太字节级,个人研究者很难反复拉取,云平台的免下载查询因此成为刚需。这也是公开 DICOM 后端迁移的直接动因之一。

第二个压力是病理。全切片影像不走 DICOM 标准通道,下载依赖专用工具,格式又以厂商格式为主。TCIA 在策略讨论中把病理的元数据体系列为优先事项,说明这一块的规范化尚未完成。

第三个压力是正常对照的稀缺。影像 AI 的多数任务需要负类样本,而公开库里健康受试者的集合规模普遍偏小。项目方已公开征集「正常」影像,这类征集本身说明缺口确实存在。

§9 使用指引

9.1 三种角色的最短路径

算法工程师的最短路径是三步:先用目录表按癌种与模态筛出 Public 候选,再逐个核对许可与标注覆盖,最后只下载筛剩的一两个集合。不要一开始就下载整库,也不要试图写一个能吃下所有集合的通用加载器——集合之间的目录约定与支持数据字段差异,会让通用加载器的复杂度迅速超过收益。

你的角色 第一件事 第二件事 第三件事 常见弯路
算法工程师 目录表筛癌种与模态 核对许可与标注覆盖 单集合下载并做转换 写通用加载器
放射或病理科研究者 找与本专业匹配的集合 读采集协议与勾画规范 评估队列的代表性 直接用他人标注当金标准
影像组学与多组学分析者 定位 TCGA 系或其他带分子数据的集合 确认病例编号能否与基因组库对齐 核对特征提取软件版本 假设同名特征可跨软件比较

放射或病理科研究者的关注点与工程师相反。工程上「能不能跑通」是第一位的,临床上「这批影像代表不代表我的患者」是第一位的。看一个集合是否合用,最该读的不是规模数字,而是它的入排说明、采集协议与勾画规范。

影像组学方向多一步跨库对齐。TCGA 系集合的影像在 TCIA、基因组在另一个库,两侧按病例编号对应,但编号体系并不总是同名同义。对齐失败是这一方向最常见的返工点,值得在动手前单独花时间核对。

9.2 一条最短的可用流程

从零到拿到一个可训练的体素,最短的流程是五步。下面这条命令序列把五步串起来,每一步都有可检查的产出。

#-- 第 1 步:确认 Python 环境与依赖
python3 -m venv .venv && . .venv/bin/activate
pip install --quiet tcia-utils pydicom numpy pandas

#-- 第 2 步:取集合表,确认目标集合存在且为 Public
python3 -c "from tcia_utils import wordpress as wp; \
c=wp.getCollections(); \
row=c[c['collection'].str.upper()=='LIDC-IDRI']; \
print(row[['collection','subjects','status']].to_string())"

#-- 第 3 步:下载该集合的 DICOM 清单(manifest)
#-- 在集合主页的数据访问表点 Download 即可得到,或由 API 生成
ls -lh manifest*.tcia

#-- 第 4 步:用 Data Retriever 按清单拉取(GUI 或命令行)
#-- 命令行模式需先安装并配置 Java 运行时
java -jar tcia-retriever.jar --manifest manifest-lidc-idri.tcia --directory ./dicom

#-- 第 5 步:统计下载结果,与清单中的序列数对照
find ./dicom -name "*.dcm" | wc -l

检查点在第 5 步:如果文件数与清单里的序列数差距过大,通常是下载中断,而不是清单错误。重新执行第 4 步前先清空不完整的目录,否则续传会跳过缺失文件。

9.3 引用方式

引用分三种情形,写法不同。用了具体集合,写集合的数据引用,必须含 DOI;同时按该集合推荐的论文一并引用。只泛指 TCIA,用平台的方法学论文。用了某个 Analysis Results,引用它自己的 DOI,不要引用它挂靠的那个集合。

三种情形的写法不同。用了具体集合,就让引用落在这个集合的 Data Citation 上,DOI 必须出现,不能拿网页地址顶替;同时把数据集作者推荐的方法学论文一并列出,这一步常被漏掉。用了多个集合,就逐个列,不要合并成一句「来自 TCIA 的若干个数据集」,因为每个集合的许可与致谢要求可能不同。只泛指平台而没有落到具体集合时,才用平台自己的方法学论文,DOI 为 10.1007/s10278-013-9622-7。用了某个 Analysis Results,引用它自己的 DOI,不要引用它挂靠的那个集合;如果标注是别人做的,只引集合等于把功劳记错了人。

还有一条容易漏的:部分集合要求固定的致谢句式,并按原样把资助机构写进去。这类要求写在集合页 Citations 区末尾,格式是「作者致谢国家癌症研究所与其合作基金会」的固定表述,改写成自己的话会被视为未履行致谢义务。

§10 AI 使用声明

项目 声明内容
本文是否由 AI 辅助生成 是,结构与初稿由 AI 起草,事实以官方页面为准逐条核对
数据是否由 AI 处理或再分发 否,本文未下载、未转换、未再分发任何 TCIA 影像
数量与来源的核对方式 以官方目录表与集合页当日所见为准,日期标注在各处
无法核实的数字 已在附录 B 标为未核实,未做推测填充
是否做过任何模型训练 否,本文不含任何基于 TCIA 数据的实验结果
许可判断的依据 官方数据使用政策页与各集合数据访问表的 License 列
推荐建议的性质 工程与研究方法层面的建议,不构成法律意见
更新与纠错渠道 通过千方医数集反馈入口提交,后续按官方变动修订

常见误读(避坑清单)

常见说法 实际 证据
TCIA 是一个数据集 它是归档层,发布单元是两百余个 collection 目录表每行一个集合,各有独立 DOI
整库统一 CC BY,可以随便商用 逐集合声明,存在 CC BY-NC 与受限许可 官方政策页与单集合 License 列
没标注的集合没用 可用于预训练、域适应与推理验证 大量集合只有影像,仍被广泛用作外部测试
一个集合就是一个版本 每个集合有独立版本号与历史记录 集合页 Previous Versions 区
Subjects 数就是影像数 人数与序列数、实例数相差几个数量级 NLST 的 Subjects 与 Series 列
受限数据申请即可得 有申请人层级门槛与国别访问限制 NIH 受控数据政策页
有影像就有分割 分割多作为 Analysis Results 另层发布 集合页 Related Datasets 区分两类
挑战赛数据与 TCIA 无关 多届挑战赛影像取自本库集合 赛事说明与集合页关联标注
下载体量等于集合总量 同集合多行下载,体量按行计 数据访问表逐行列出体量与格式
引用写网页地址即可 官方要求用 DOI 引用 数据使用政策页的引用要求

FAQ

Q1:TCIA 是一个数据集还是一个目录?
两者都是。作为归档层,它用一个目录把两百余个独立发布的研究队列聚合起来;作为数据本体,每个 collection 自带 DOI、许可、版本与访问级别,可以单独下载、单独引用。把它当作一个统一数据集使用,会在许可和字段一致性上立刻遇到麻烦。

Q2:同一个 collection 为什么会有多个版本?
TCIA 对已发布集合做维护性再发布时会递增版本号,并在页面上保留历史记录。常见触发是存储迁移造成的影像损坏或缺失修复、第三方文件误入主数据清单、去标识问题更正。不同版本的病例子集不一定完全一致,复现实验时应记录版本号与更新日期。

Q3:CC BY-NC 的集合能不能用于商业模型训练?
不能。非商业许可禁止商业使用,训练进产品模型属于商业使用的一种。TCIA 提交页明确说明新提交不再接受禁止商业使用的许可,所以 CC BY-NC 只会出现在历史集合上,遇到时按非商业处理并回溯该集合的具体许可版本。

Q4:2025 年之后不再能直接下载的数据怎么办?
受控访问数据自 2025 年 7 月 8 日起由 TCIA 停止直连托管,改由 dbGaP 受理申请、NCI 数据 commons 托管。含面部影像的集合统一并入 phs004225 一个申请号,NCTN 试验数据按试验分别申请。申请资格要求申请人达到相当于终身教职或资深科学家的层级。

Q5:没有标注的集合还有价值吗?
有,但用途不同。无体素级标注的集合适合做预训练、域适应与自监督学习,也适合做分割模型的推理验证集。要做有监督的分割训练,更稳的做法是选已挂接 Analysis Results 的集合,或自己用可复核的流程生成标注并单独记录来源。

Q6:整库到底有多少个集合?
以官方 Browse Collections 目录当日所见为准,本文采用约两百四十行的口径,其中 Complete 约两百一十一、Ongoing 约二十六,其余两行属于表内其他状态。这个数字每天都在变,写论文时应记录抓取日期,而不是只写数字。

Q7:为什么有些集合的临床数据看起来不全?
不是被藏起来,而是按设计分流。完整临床数据留在临床试验数据访问系统,TCIA 只放可公开分发的子集。要看完整随访表,需要拿试验注册号去那个系统另行申请,这一步与 TCIA 的账号体系无关。

Q8:Analysis Results 算不算在集合数里?
不算。它是另一条发布线,有自己的浏览入口与 DOI。项目方对外的「数据集总数」通常把两条线加起来,所以会比目录表的行数大;引用时必须分清楚你用的是集合还是衍生分析。

Q9:DICOM 一定要转成 NIfTI 吗?
不一定,取决于你的训练框架。现代框架里已有直接读 DICOM 的加载器,能省掉转换环节;但如果你要复用别人的预处理流程或预训练权重,多数流程以 NIfTI 为输入,转换就不可避免。转换时务必保留层厚与像素间距。

Q10:能不能只用 IDC 而不碰 TCIA?
可以,而且对公开 DICOM 来说往往更方便。IDC 镜像了 TCIA 的公开影像并叠加了大量社区派生标注,还提供 SQL 元数据查询。局限在于非 DICOM 的病理与部分支持数据仍只在 TCIA 侧,且 IDC 的版本跟随上游,有滞后。

Q11:用 TCIA 数据发论文有什么额外义务?
三条:引用具体集合的 DOI、按集合要求引用作者推荐论文、按需使用固定致谢句式。此外任何情况下都不得尝试重新识别受试者,这条写在数据使用政策的开头,不因集合是否受限而改变。

Q12:如果发现某篇论文用的数字与官网不一致怎么办?
先核对口径与日期。常见原因是论文写了「数据集数」而官网目录是「集合数」,或论文引用的版本早于当前版本。确认是口径差异后,按官网当日所见为准并注明日期;若是版本差异,回退到论文所述版本再比。

术语表

术语 含义
Collection 集合,按疾病、模态或研究焦点聚合的患者队列,是 TCIA 的基本发布单元
Analysis Results 分析结果,基于已有集合产出的分割、标注或特征,独立发布并独立分配 DOI
Subject 受试者,集合中的人数计数单位
Study 检查,一次就诊产生的影像集合
Series 序列,一次扫描产生的一组同参数影像
Instance 实例,单张 DICOM 影像文件
NBIA 影像归档系统的旧称,也是 API 与下载客户端名称的来源
Data Retriever 官方下载客户端,按清单文件拉取影像
Manifest 清单文件,列出待下载的序列与来源后端
DOI 数字对象标识符,集合级持久标识,前缀多为 10.7937
Public 公开访问级别,注册与否皆可下载
Limited 受限访问级别,需经 dbGaP 审批
Complete 集合已按设计发布完毕
Ongoing 集合仍在扩充
CC BY 署名许可,允许商用
CC BY-NC 署名非商业许可,禁止商用
受控访问 需数据访问协议与审批的访问方式
dbGaP NIH 的基因组与表型数据档案系统,受理受控数据申请
IDC NCI 影像数据 commons,公开肿瘤影像的云平台
GDC NCI 基因组数据 commons,TCGA 基因组数据的存放地
CDAS 临床试验数据访问系统,存放试验完整临床数据
NIfTI 神经影像常用的体素文件格式,TCIA 主体不提供
RTSTRUCT 放疗结构集,用于存放勾画轮廓
SEG DICOM 分割对象,用于存放射影像分割
SVS 全切片影像的常用厂商格式
TotalSegmentator 常用的器官自动分割工具,其产物常作为派生标注发布

附录 A:核心数字核对表

项 值 来源 来源层级
目录行数 约 240 Browse Collections 当日所见 官方页面
Complete 集合数 约 211 Browse Collections 当日所见 官方页面
Ongoing 集合数 约 26 Browse Collections 当日所见 官方页面
最大集合病例数 两万六千余例,精确值见集合页 NLST 集合页 官方页面
最大集合影像数 两千万余张,精确值见集合页 NLST 集合页 官方页面
最大集合序列数 二十万余个,精确值见集合页 NLST 集合页 官方页面
LIDC-IDRI 病例数 1010 集合页 官方页面
集合级 DOI 前缀 10.7937 多个集合页一致 官方页面
受控数据停止托管日期 2025-07-08 受控数据政策页 官方页面
含面部影像统一申请号 phs004225 受控数据政策页 官方页面
平台方法学论文 DOI 10.1007/s10278-013-9622-7 数据使用政策页 官方页面
已支撑论文数 三千四百余篇 NCI 部门通讯 官方页面
整库去重病例总数 未核实 官方未给统一口径 未核实
整库总存储体量 未核实 各集合体量分别给出 未核实

附录 B:数字的来源分层

层级 含义 本文中的例子 使用建议
一级:官方页面 可直接在官网核对,含日期 目录行数、单集合计数、许可声明、DOI 可直接引用,注明日期
二级:论文与第三方研究 经同行评议或赛事材料 第三方对集合的使用方式与评测结论 可作为佐证,不作规模依据
三级:未核实 官方未给出或口径不一 整库去重病例数、整库总存储 只写「未核实」,不推测

分层的目的是防止把不同置信度的数字平铺着写。规模类的数字只要有一级来源,就用一级;只有二级来源的,明确写「论文口径」;两者都没有的,直接留白。

附录 C:完整参考文献

  1. Clark K, Vendt B, Smith K, Freymrey J, Kirby J, Koppel P, Moore S, Phillips S, Maffitt D, Pringle M, Tarbox L, Prior F. The Cancer Imaging Archive (TCIA): Maintaining and Operating a Public Information Repository. Journal of Digital Imaging, 2013, 26(6): 1045-1057. DOI: 10.1007/s10278-013-9622-7
  2. The Cancer Imaging Archive. Browse Collections. https://www.cancerimagingarchive.net/collections/ (访问日期 2026-10-26)
  3. The Cancer Imaging Archive. NLST 集合页. https://www.cancerimagingarchive.net/collection/nlst/ (访问日期 2026-10-26)
  4. The Cancer Imaging Archive. LIDC-IDRI 集合页. https://www.cancerimagingarchive.net/collection/lidc-idri/ (访问日期 2026-10-26)
  5. The Cancer Imaging Archive. Data Usage Policies and Restrictions. https://www.cancerimagingarchive.net/data-usage-policies-and-restrictions/ (访问日期 2026-10-26)
  6. The Cancer Imaging Archive. NIH Controlled Data Access Policy. https://www.cancerimagingarchive.net/nih-controlled-data-access-policy/ (访问日期 2026-10-26)
  7. The Cancer Imaging Archive. Evolving The Cancer Imaging Archive: A New Hybrid Infrastructure for Open Science. 2026-04-28 (访问日期 2026-10-26)
  8. The Cancer Imaging Archive. Submit Your Data. https://www.cancerimagingarchive.net/submit-your-data/ (访问日期 2026-10-26)
  9. National Cancer Institute, Division of Cancer Treatment and Diagnosis. Powering Cancer Research: How The Cancer Imaging Archive Is Evolving. 2026 (访问日期 2026-10-26)
  10. National Lung Screening Trial Research Team. Reduced Lung-Cancer Mortality with Low-Dose Computed Tomographic Screening. New England Journal of Medicine, 2011, 365(5): 395-409. DOI: 10.1056/nejmoa1102873
  11. Imaging Data Commons. IDC data release v24 / v25 公告. https://discourse.canceridc.dev/ (访问日期 2026-10-26)
  12. Europe PMC 检索接口,查询式 TCIA cancer imaging archive,结果数 2857(检索日期 2026-10-26)

附录 D:集合筛选决策代码

下面这段脚本把 §6.2 的四步筛选写成可执行的形式。它接收一份本地缓存好的目录表,输出按四步收敛后的候选清单。

#-- 四步筛选:癌种 -> 访问级别 -> 模态与标注 -> 许可与版本
import pandas as pd

#-- 目录表需含 collection / cancer_type / access / data_types 四列
cat = pd.read_csv("tcia_catalog_snapshot.csv")

def shortlist(cat, cancer_kw, need_types, allow_license):
    step1 = cat[cat["cancer_type"].str.contains(cancer_kw, case=False, na=False)]
    step2 = step1[step1["access"].str.lower() == "public"]
    mask = step2["data_types"].apply(
        lambda s: all(t.lower() in str(s).lower() for t in need_types))
    step3 = step2[mask]
    #-- 许可与版本不在目录层,需回填后过滤
    step4 = step3[step3["license"].isin(allow_license)]
    return step4[["collection", "cancer_type", "subjects", "status", "license"]]

if __name__ == "__main__":
    out = shortlist(cat, "lung", ["CT", "Segmentation"],
                    ["CC BY 3.0", "CC BY 4.0"])
    print(out.sort_values("subjects", ascending=False).to_string(index=False))

许可列需要回填,因为目录层不带许可。回填方式有两种:逐个打开集合页读,或用支持 DOI 查询的接口批量取。批量取更省事,但要处理接口限速。

如果不想依赖任何第三方封装,用标准库直接查 DOI 解析服务也能拿到集合级的元数据。这个办法的好处是不受站点改版影响——DOI 注册信息由注册机构维护,比网页结构稳定得多。

#-- 用 DOI 解析服务取集合级元数据(DataCite 内容协商)
import json
import urllib.request

def fetch_doi(doi):
    url = "https://api.datacite.org/dois/" + doi
    req = urllib.request.Request(url, headers={"Accept": "application/json",
                                              "User-Agent": "tcia-catalog-check/1.0"})
    with urllib.request.urlopen(req, timeout=60) as resp:
        return json.loads(resp.read().decode("utf-8"))

#-- NLST 的集合级 DOI,前缀 10.7937 为 TCIA 分配
meta = fetch_doi("10.7937/TCIA.HMQ8-J677")
attrs = meta["data"]["attributes"]
print("标题:", attrs["titles"][0]["title"])
print("发布年:", attrs.get("publicationYear"))
print("许可:", attrs.get("rightsList"))

#-- 同一集合的多个版本在 DataCite 上通常表现为同前缀不同后缀,需逐个核对

这段脚本的产出可以补上目录表缺失的许可与发布年。缺点是它只覆盖已注册 DOI 的集合,少数早期集合或在注册前撤下的集合查不到,遇到空结果时应回退到集合页人工核对,而不是判定该集合不存在。

附录 E:如果只记五件事

序号 记住这一条
一 TCIA 是归档层,发布单元是集合,每个集合有自己的许可、DOI 与版本
二 目录表只是摘要,许可与版本必须进集合页看
三 受控访问自 2025 年 7 月起迁出,申请要过 dbGaP,且有申请人层级门槛
四 影像与标注是两条发布线,找标注要去 Analysis Results
五 引用写集合的 DOI,不写网页地址;用多个集合就逐个列

编辑说明

本文的核对日期为 2026 年 10 月 26 日。核对方式为直接访问 TCIA 官方站点的目录页、集合页、数据使用政策页与受控数据政策页,以及 NCI 部门通讯页;论文层面的佐证取自 Europe PMC 检索接口与期刊公开摘要。受限于网络条件,NBIA API 端点与 wiki 站点在本次核对中未能直连,相关结论以官方页面文本与政策页表述为准。

未覆盖的内容包括:单个集合内部的字段级质量统计、跨集合的去重病例总数、整库总存储体量的精确值、历史集合许可沿革的逐条追溯。这些项目若需要,应另立专题逐集合核对,而不是在整库层用推算填充。

本文所引用的规模数字均以核对当日所见为准,目录行数随时间变化,引用时请一并标注日期。文中出现的第三方研究仅用于说明集合的使用方式,不构成对任何方法的优劣评价。


相关数据集导航

以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集,按相关度降序排列:

  • cptac-imaging — 共享标签:医学影像 / CT / 病理图像 / 肿瘤学
  • cptac-stad — 共享标签:医学影像 / CT / 病理图像 / 肿瘤学
  • cmb-crc — 共享标签:医学影像 / CT / 病理图像 / 肿瘤学
  • cmb-gec — 共享标签:医学影像 / CT / 病理图像 / 肿瘤学
  • cptac-pda — 共享标签:医学影像 / CT / 病理图像 / 肿瘤学
  • hnscc-ct-atlas — 共享标签:医学影像 / CT / 肿瘤学
  • ocelot — 共享标签:医学影像 / 病理图像 / 肿瘤学
  • sicapv2 — 共享标签:医学影像 / 病理图像 / 肿瘤学
  • msk-impact — 共享标签:医学影像 / 病理图像 / 肿瘤学
  • munich-bmc — 共享标签:医学影像 / 病理图像 / 肿瘤学

导航说明:本章节由全站统一标签体系自动计算生成(标签重合度算法),双向可达;点击链接可跳转至对应数据集词条。

返回 AI-Ready 数据集