三十三万张日常场景图 — COCO 通用物体上下文库

33 万张图像 / 80 个物体类别 / 150 万个实例

来源 https://cocodataset.org/#home发布时间: 2026-10-29最后更新: 2026-10-29 阅读 3
三十三万张日常场景图 — COCO 通用物体上下文库

信息速览

数据集名称三十三万张日常场景图 — COCO 通用物体上下文库
数据类型图像数据,多边形分割,关键点标注,图像描述,JSON标注
规模日常场景图像,众包标注者,无患者数据
接入方式https://cocodataset.org/#home
AI 就绪度

一个检测模型能在二十个类别、每张图两三个物体、物体居中且占据画面大半的数据集上拿到漂亮的数字,然后在一张普通的家庭聚会照片上掉一半。掉分的原因通常不是网络结构,而是训练数据的取景方式:物体被单独框出来拍,背景干净,姿态典型。真实照片里,物体挤在一起、被遮挡、尺度跨度极大,一半的像素属于"草地"“墙”"天空"这种没有确定形状的区域。要把模型推向可用,训练与评测的素材必须同时具备三样东西——日常场景、逐实例的精确轮廓、以及一套能同时评价定位与分类的指标。

COCO 通用物体上下文库(Common Objects in Context)就是按这三样东西建的。它的官方自我描述是"大规模的目标检测、分割与图像描述数据集",首页给出的规模是 33 万张图像(其中逾 20 万张带标注)、150 万个物体实例、80 个物体类别、91 个 stuff 类别、每图 5 条描述、25 万个带关键点的人。这六个数字里,真正稀缺的不是"33 万"——比它大的图像集并不少见——而是"同一批图像上同时挂着检测框、实例轮廓、人体关键点、区域语义和自然语言描述"这件事。一个模型只要跑一次推理,就能在五个任务上被同一套数据检验。

它的代价同样写在明处:图像的版权不在数据发布方手里。官方条款页把权利切成三层——标注与网站归 COCO Consortium 并按 CC BY 4.0 许可;图像不属于 Consortium,使用须遵守 Flickr 条款,使用者自担全部责任;软件是 2015 年的 BSD 风格许可。这三层决定了它能怎么被用,也决定了它不能被怎么用。一屏速览见下表。

维度 内容
全名 COCO 通用物体上下文库(Common Objects in Context);论文题名 Microsoft COCO: Common Objects in Context
官方站点 cocodataset.org,站内设 Home / People / Overview / Explore / Download / External / Terms of Use 七个页签
权利主体 COCO Consortium(标注与网站);图像版权归原拍摄者;软件署名 COCO Consortium 2015
首次发布 论文 2014 年 5 月提交 arXiv(编号 1405.0312),同年 9 月发表于 ECCV 2014(苏黎世)
最近一次挑战赛 2020 年(Detection / Keypoints / Panoptic / DensePose),2021 年起无 COCO 挑战赛,官方引导参加 LVIS
图像规模 330K 张,其中逾 200K 张带标注
标注实例 150 万个物体实例;检测任务页写 train/val 公开标注含逾 50 万个已分割实例
类别 80 个 thing(可数物体)类别;91 个 stuff(无定形区域)类别
关键点 250,000 个人体实例带关键点;train/val 公开逾 150,000 人与 170 万个已标注关键点
图像描述 每图至少 5 条(部分图像更多)
标注格式 JSON,五类标注共享 info / images / annotations / licenses 顶层结构
图像与掩码格式 图像为 JPEG 打包成 zip;掩码以多边形存储,按需转 RLE;全景分割另配 PNG
许可(标注与网站) Creative Commons Attribution 4.0
许可(图像) 不属于 Consortium,须遵守 Flickr 条款,使用者自担责任
下载与托管 托管于 Google Cloud Platform,提供 zip 直链与 gsutil rsync 两种方式
典型用途 检测与实例分割评测、姿态估计、全景分割、图像描述与视觉语言模型评测、通用视觉预训练

§1 它要解决的具体麻烦

1.1 三个条件,此前没人同时满足

目标识别这条线上,数据的供给长期是分段的。一类数据给类别标签:一张图一个或几个标签,回答"这是什么",适合分类,回答不了"在哪"。另一类数据给框:每张图若干个矩形,回答"在哪",但矩形把背景一起圈进去,_mask 与背景的边界是模糊的。第三类数据给轮廓,但往往只覆盖少数几个类别、或者只在受限场景里采集,物体居中、尺度单一、遮挡很少。

COCO 的立项理由写在论文摘要第一句:把物体识别放进场景理解这个更大的问题里去看。落到数据上就是三条同时成立——图像是复杂的日常场景,物体处在自然上下文里而不是单独摆拍;标注用逐实例分割而不是只给框,以便精确定位;类别要覆盖四岁小孩就能认出的日常物体。官方首页把同样的意思拆成九条特征清单,前三条是"物体分割"“上下文中的识别”“超像素 stuff 分割”,后六条是规模数字。

这件事的难点不在采集图像,而在标注成本。逐实例多边形分割比画框贵得多,官方给的解决办法是三阶段众包界面:先做类别检测,再做实例点选,最后做实例分割。论文致谢部分写明,全部众包任务的经费由微软提供;Pietro Perona 与 Deva Ramanan 受 ONR MURI 资助(编号 N00014-10-1-0933)。因此"微软出资"是对的,但要精确:出资的是众包标注环节,图像本身来自 Flickr,权利不在出资方手里。

1.2 四条常见的错误期待

第一条,期待它是"微软拥有的图库"。官方首页的赞助方一栏列了四家:CVDF(Common Visual Data Foundation)、Microsoft、Facebook、MightyAI;协作者一栏十三人,署名机构横跨 Google Brain、Caltech、Cornell Tech、TTI-Chicago、FAIR、Georgia Tech、CMU、WaveOne。条款页写明标注与网站属于 COCO Consortium。它不是一个公司的资产。

第二条,期待"33 万张都能下载、都能训练"。330K 是首页给出的整体规模口径,其中逾 200K 带标注;剩余部分包括测试集图像与 2017 年发布的无标注图像。下载页按年度划分给出各组,而 2017 的 train/val 与 2014 的 train/val 是同一批图像的不同划分,张数不能相加。

第三条,期待"80 个类别就是全部标注"。80 是 thing 类别,另有 91 个 stuff 类别走的是另一套标注(stuff 分割任务),全景分割任务再把两者合并成一个统一框架,并对重叠部分做了人工消解。

第四条,期待"图像是 CC BY 4.0,可以随意商用"。条款页的措辞很硬:Consortium 不持有图像版权,图像使用必须遵守 Flickr 条款,使用者接受包括制作副本在内的全部责任。CC BY 4.0 覆盖的是标注与网站本身。

1.3 它能给到的与给不到的

你的需求 它给的 够不够
目标检测的横向对比 80 个类别、12 项指标、公开排行榜、test-dev 全年开放 够,这是它的主战场
实例分割 每个实例带多边形掩码,iscrowd 区分单体与群体 够,掩码是它的核心资产
人体关键点与姿态 25 万个人体实例带关键点,OKS 作为相似度度量 够,但关键点集中在中等与大尺度、非人群实例
场景的"无定形区域"理解 91 个 stuff 类别,官方称 stuff 覆盖 COCO 约 66% 的像素 够做 stuff 分割,注意标注采集于超像素之上
全景分割 80 thing 加 91 stuff 的子集,配 PNG 段图与 segments_info 够,且是官方推荐取代 stuff 任务的赛道
图像描述与视觉语言评测 每图至少 5 条人工描述 够做描述生成,评价指标另有工具包
医学影像的直接训练 无此项 不够,它是日常场景库,类别体系里没有医学类别
有确定分辨率的输入 无此项 不够,官方下载页未给统一分辨率,宽高逐图给出
图像版权的兜底 不提供 不给,官方明确不持有图像版权
视频或时序任务 无此项 不够,它是静态图像集

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

你的处境 它能帮你什么 下一步该做什么
你要给一个新检测器找一个能说服同行的横向对比基准 提供统一数据、统一指标与公开排行榜,AP 跨 10 个 IoU 阈值与全部 80 类平均 按 §5 下 2017 划分,在 val 上自评、在 test-dev 上报数,注意每日上传限额
你在做医学影像分割,想找一个预训练源 通用视觉特征与实例掩码形态可迁移 用它做骨干预训练,再在你的数据上微调;引用时写明预训练源
你要比较"框"与"轮廓"两种监督的差距 同一批图像、同一批实例同时有 bbox 与掩码 固定训练配置,只换监督形式,其余不动
你在做姿态估计,需要知道指标怎么算 OKS 的定义、κ=2σ 的来源、九类关键点的 σ 值都由官方给出 直接读 keypoints 评测页,别自己定义相似度
你要做一个能同时输出检测与分割的系统 全景分割任务给了统一框架与 PQ 指标 下 panoptic 标注包,注意 PNG 的 id 要按 R+G256+B256^2 还原
你在搭数据工程流水线,需要一个格式样板 JSON 的顶层结构与五类扩展结构全部公开 照 §2 的字段字典设计你的中间层,不要依赖类别 id 连续

1.5 一句话判断

它不是一个"图更多"的数据集,而是一台"同一批图上挂五套标注、用同一套指标打分"的评测机器——价值在标注的共存与指标的统一,不在图像的体量。

1.6 不适合谁:四条边界

不适合拿来做医学影像的直接训练。 类别体系是四岁小孩能认的日常物体,与医学语义不相交。它在这类项目里的位置是预训练源与工程样板,不是训练目标。

不适合在版权敏感的场景里直接分发图像。 官方不持有图像版权,也不为分发背书。需要再分发的项目,要么逐图确认 Flickr 授权,要么只分发标注与图像 URL。

不适合拿 test 集做自监督或半监督训练。 官方测试指南写明:以任何形式使用 COCO 测试集做有监督或无监督训练是被严格禁止的;外部页面还要求不要在任何情况下发布 test 集图像的标注,以免破坏挑战赛的完整性。

不适合期待一次下载解决所有年份的任务。 2015/2016 的任务挂在 2014 与 2015 划分上,2017 及之后的任务挂在 2017 划分上。参加哪一届,就下哪一套,混着下只会浪费带宽。

§2 数据构成与规格

2.1 一次下载拿到的三类东西

官方下载页把可下载物分成三类。第一类是图像,按年度划分打包成 zip,文件名即划分名,例如 train2017.zip、val2017.zip、test2017.zip、unlabeled2017.zip。第二类是标注,也是 zip,命名按内容区分:annotations_trainval2017.zip 是检测与关键点的主力包,stuff_annotations_trainval2017.zip 与 panoptic_annotations_trainval2017.zip 是两个更大的专项包,image_info_test2017.zip 只给测试集图像的元信息。第三类是 COCO API,托管在 GitHub,提供 Matlab、Python、Lua 三套实现。

三类东西的落地位置由 API 的 README 规定:图像解压放进 coco/images/,标注解压放进 coco/annotations/。这个约定不是形式主义——API 的示例代码按这两个相对路径找文件,全景分割的 PNG 还要求与同名 JSON 处在同一层目录下。

类别 官方给出的包 形态 说明
图像 2014 Train / Val / Test zip,83K/13GB、41K/6GB、41K/6GB 服务于 2015、2016 的检测、描述、关键点任务
图像 2015 Test zip,81K/12GB 服务于 2015、2016 的检测与关键点任务
图像 2017 Train / Val / Test zip,118K/18GB、5K/1GB、41K/6GB 2017 及之后所有任务的唯一图像来源
图像 2017 Unlabeled zip,123K/19GB 官方标注为"任意比赛的optional data",与带标注图像同类分布
标注 2014 Train/Val annotations zip,241MB 检测与关键点,2014 划分
标注 2017 Train/Val annotations zip,241MB 检测与关键点,2017 划分
标注 2017 Stuff Train/Val annotations zip,1.1GB 91 个 stuff 类别,JSON 与 PNG 两种格式
标注 2017 Panoptic Train/Val annotations zip,821MB 全景分割,JSON 加同名目录下的 PNG
标注 Testing / Unlabeled Image info zip,1MB / 4MB / 2MB 只含图像元信息,不含标注
工具 COCO API GitHub 仓库 CocoApi / MaskApi,三种语言

2.2 JSON 的顶层结构

官方数据格式页写明:COCO 有多种标注类型,但都用 JSON 存储,且共享同一个基础结构。这个结构是理解全部五类标注的入口——后面所有的差异都是在这个基础上加字段。

字段 类型 含义 使用注意
info 对象 数据集元信息 见下表
images 数组 图像记录列表 每张图一条,id 是主键
annotations 数组 标注记录列表 检测/关键点/stuff/描述是逐物体或逐描述一条;全景是逐图像一条
licenses 数组 图像对应的许可记录 image.license 指向 license.id
categories 数组 类别记录列表 位于 annotations 结构内,见 §2.6

info 对象的完整字段:

字段 类型 含义
year int 数据集年份
version str 版本字符串
description str 描述
contributor str 贡献者
url str 链接
date_created datetime 创建时间

2.3 image 与 license 的字段

图像记录的字段设计里藏着两个容易被忽略的信息:一是宽高逐图给出,官方下载页没有承诺统一分辨率;二是每条图像都带着一个许可 id,指向 Flickr 侧的授权记录,而 flickr_url 与 coco_url 同时给出,方便回溯到原图页面。

字段 类型 含义 使用注意
id int 图像主键 annotation.image_id 指向它
width int 图像宽度(像素) 逐图不同,没有统一值
height int 图像高度(像素) 逐图不同
file_name str 文件名 在 coco/images/<划分名>/ 下定位
license int 许可 id 指向 licenses[].id
flickr_url str Flickr 原图页 版权回溯用
coco_url str 官方托管的图像地址 下载用
date_captured datetime 拍摄时间 可能是日期粒度

许可记录只有三个字段:id(int,被 image.license 引用)、name(str,许可名称)、url(str,许可全文链接)。这一层的存在本身就是条款页三层权利结构的证据——数据集把"每张图用什么许可"当作逐图可变的事实记录下来,而不是给整库打一个统一标签。

2.4 检测标注的字段与一条完整解剖

检测标注是五类标注里最基础的一种,其余四类都由它扩展而来。

字段 类型 含义 使用注意
id int 标注主键 全局唯一
image_id int 所属图像 与 image.id 对应
category_id int 类别 id 必须经 categories 映射,不要当作序号
segmentation RLE 或 [polygon] 分割掩码 iscrowd=0 用多边形,iscrowd=1 用 RLE
area float 面积 官方检测评测页说明面积按分割掩码的像素数计
bbox [x, y, width, height] 外接框 从左上角起算,0 基,注意是宽高不是右下角坐标
iscrowd 0 或 1 是否群体 1 表示一大群物体,用 RLE

一条完整记录的形态:

{
  "id": 1768,
  "image_id": 289343,
  "category_id": 18,
  "segmentation": [[510.66, 423.01, 511.72, 420.03, 510.45, 416.00]],
  "area": 702.10,
  "bbox": [473.07, 395.93, 38.65, 28.67],
  "iscrowd": 0
}

从这条记录能读出四件事。第一,bbox 的四个值是左上角坐标加宽高,不是左上右下——把它当 [x1,y1,x2,y2] 用是最常见的解析错误,画出来的框会偏到右下并且尺寸减半。第二,area 与 bbox 的宽高乘积不相等,因为面积按掩码像素数计而不是按框计;用框面积做阈值筛选会与官方口径不一致。第三,iscrowd=0 时掩码是多边形,且一个物体可能需要多段多边形(例如被遮挡);iscrowd=1 时掩码是 RLE。第四,category_id 只是一个指针,类别名与 supercategory 要去 categories 里查。

掩码的存储策略本身就是一段工程史。官方给每个实例都存掩码,这带来两个问题:存得紧凑、算得快。解决办法是自定义 RLE:RLE 的长度与掩码的边界像素数成正比,面积、并、交等运算可以直接在 RLE 上做。官方给出的复杂度结论是:形状不太复杂时,RLE 的表示规模是 O(√n),常见运算同样是 O(√n),而直接在解码后的数组上算是 O(n)。同时官方说明,大部分真值掩码实际是以多边形形式存的(相当紧凑),需要时才转成 RLE。

Mask API 提供的八个操作正好对应这条链路:

函数 作用
encode 用 RLE 编码二值掩码
decode 解码 RLE
merge 计算编码掩码的并或交
iou 计算掩码间的交并比
area 计算编码掩码的面积
toBbox 取包围掩码的外接框
frBbox 由外接框转成编码掩码
frPoly 由多边形转成编码掩码

2.5 五类标注的结构差异

五类标注不是五个独立文件,而是在同一基础结构上做三种不同的扩展方式:加字段(关键点)、换主体(全景从逐物体变逐图像)、换内容(描述只留一句文本)。

标注类型 主体 新增/替换字段 与检测标注的关系
目标检测 逐物体 无新增字段 基础形态
关键点检测 逐人体实例 keypoints(长度 3k)、num_keypoints;categories 增 keypoints、skeleton 包含检测标注的全部字段
Stuff 分割 逐类别、逐图像 单条 RLE 代表图像中的一个 stuff 类别,iscrowd 置 0 格式与检测完全相同,官方称"identical and fully compatible"
全景分割 逐图像 image_id、file_name(PNG)、segments_info;categories 增 isthing、color 主体从物体变成整图,另配一张 PNG
图像描述 逐描述句 id、image_id、caption 只剩文本
DensePose 逐人体实例 dp_masks、dp_x、dp_y、dp_I、dp_U、dp_V 独立字段,掩码统一 256×256

关键点标注的三个细节值得单独拆开。其一,keypoints 是长度 3k 的数组,k 是该类别定义的关键点总数,每个关键点由 x、y 与可见性标志 v 三元组构成。其二,v 的取值是三档:v=0 表示未标注(此时 x=y=0)、v=1 表示已标注但不可见、v=2 表示已标注且可见;官方补充说"可见"指关键点落在物体分割区域内。其三,num_keypoints 记录 v>0 的关键点个数,官方明确提到人群与小尺度目标常常是 0。

全景标注的两个细节同样关键。其一是 PNG 的解码方式:官方要求按 ids = R + G*256 + B*256^2 还原段 id,未标注像素(void)为 0。其二是 segments_info 里的每一段都带 id、category_id、area、bbox、iscrowd,其中 iscrowd 只对 thing 类别有意义。

DensePose 的字段里,官方把人体拆成 14 个语义部件(Torso、Right Hand、Left Hand、Left Foot、Right Foot、Upper Leg Right、Upper Leg Left、Lower Leg Right、Lower Leg Left、Upper Arm Left、Upper Arm Right、Lower Arm Left、Lower Arm Right、Head),又把表面分成 24 个块,其中部分部件被拆成两块(例如 1、2 都是 Torso,7、9 都是 Upper Leg Right)。所有部件掩码统一 256×256,采集点的坐标也按外接框缩放至 256×256。

2.6 类别字段与 80/91 的关系

类别结构 categories 是理解 80 与 91 这两个数字的关键。检测与关键点任务里,它有三个字段:id、name、supercategory;全景任务里再加两个:isthing(区分 stuff 与 thing)、color(用于一致的着色)。

字段 出现在 含义
id 全部 类别主键,annotation.category_id 指向它
name 全部 类别名
supercategory 检测 / 关键点 / stuff / 全景 上层类别名
keypoints 关键点 长度 k 的关键点名数组
skeleton 关键点 关键点连边,用于可视化
isthing 全景 0 = stuff,1 = thing
color 全景 RGB 三元组,用于一致的着色

两个数字的分工很清楚:80 是 thing 类别数,即可数物体的类别数,检测与关键点任务都用它;91 是 stuff 类别数,即无定形区域的类别数,stuff 分割任务用它。全景分割任务同时使用两者,但官方说明它取的是 stuff 任务 91 类的一个子集,并对 thing 与 stuff 之间的重叠做了人工消解。所以"全景 = 80 + 91"这种加法是不成立的。

§3 它是谁的数据

3.1 贡献者与机构

官方首页的协作者一栏列出十三人及其署名机构,赞助方一栏列出四家机构。这两栏的信息量比看上去大:它说明这个数据集从一开始就是一个跨机构协作体,而不是单一实验室的产物;也说明"微软的数据集"这个说法只在出资层面成立。

角色 名单
协作者(首页列出) Tsung-Yi Lin(Google Brain)、Genevieve Patterson(MSR)、Matteo R. Ronchi(Caltech)、Yin Cui(Google)、Michael Maire(TTI-Chicago)、Serge Belongie(Cornell Tech)、Lubomir Bourdev(WaveOne, Inc.)、Ross Girshick(FAIR)、James Hays(Georgia Tech)、Pietro Perona(Caltech)、Deva Ramanan(CMU)、Larry Zitnick(FAIR)、Piotr Dollár(FAIR)
赞助方 CVDF(Common Visual Data Foundation)、Microsoft、Facebook、MightyAI
权利主体 COCO Consortium(标注与网站)
论文作者(ECCV 2014) Tsung-Yi Lin、Michael Maire、Serge Belongie、James Hays、Pietro Perona、Deva Ramanan、Piotr Dollár、C. Lawrence Zitnick
2020 检测赛道组织者 Yin Cui、Tsung-Yi Lin、Matteo Ruggero Ronchi、Alexander Kirillov

需要注意名单的时间性:首页协作者一栏是历史快照,2020 年各赛道的组织者与评奖委员会名单里出现了更多 FAIR 与 Google 的人员,且部分名字在脚本里被注释掉。用这份名单判断"谁在维护"容易过时,判断"数据从哪来"则足够。

3.2 时间线

时间 事件 出处
2014-05-01 论文 v1 提交 arXiv(1405.0312) arXiv 提交历史
2014-09 发表于 ECCV 2014(苏黎世),LNCS 8693 CaltechAUTHORS 记录
2015-02-21 论文修订至 v3 arXiv 提交历史
2015 首届 Detection 与 Captioning 挑战赛(CVPR 2015 LSUN workshop) 官方任务页
2016 Detection 与 Keypoints 挑战赛 官方任务页
2017 图像划分改为 118K/5K,stuff 任务加入,test 四分改两分,发布无标注图像 官方下载页更新说明
2018 Panoptic 与 DensePose 任务加入 官方任务页
2019 Detection / Keypoints / Stuff / Panoptic 四赛道 官方任务页
2020 最后一届,四赛道;官方声明数据全部未变 官方下载页 2020 更新
2021 不设 COCO 挑战赛,官方引导参加 LVIS 2021 首页 News

3.3 采集场景:日常照片与众包界面

图像的来源是 Flickr 上的日常场景照片,这一点由条款页与图像记录的 flickr_url 字段共同确认。选图口径在论文摘要里给了一句很实用的描述:这些照片里的 91 类物体是"四岁小孩就能轻易认出的"。这句话实际划定了类别体系的边界——它覆盖的是日常可见的物体,而不是专业领域或长尾类别。

标注环节由众包完成,官方给出的三个界面是类别检测、实例点选、实例分割。这个三段式设计决定了标注的粒度结构:先确定图里有哪些类别,再点出每个实例的位置,最后画轮廓。代价与收益都在这里——逐实例多边形的成本远高于画框,但它换来了掩码级别的定位精度,也换来了后面 stuff、全景、DensePose 一系列扩展可以复用同一批图像。

stuff 标注另有一条额外的采集约束,官方写得很直白:为了把标注规模做上去,stuff 的分割是在图像的超像素分割之上采集的。这意味着 stuff 掩码的边界精度受超像素粒度约束,而不是像素级手绘。

3.4 来源的三个层次

层次 内容 权利归属 使用约束
第一层:图像 Flickr 日常场景照片 原拍摄者,不属于 COCO Consortium 须遵守 Flickr 条款,使用者自担全部责任
第二层:标注与网站 五类标注 JSON、PNG、站点内容 COCO Consortium CC BY 4.0,需署名
第三层:软件 COCO API(Matlab / Python / Lua) Copyright © 2015, COCO Consortium 保留版权声明与免责声明的三条款式许可;不得用 Consortium 或贡献者名义背书

第三层的条款里有一条常被忽略:不得以 COCO Consortium 或其贡献者的名义为衍生产品背书或推广。这一条与 CC BY 4.0 的署名要求是两回事——署名是义务,背书是禁止。

§4 它最独特的东西

4.1 稀缺的不是"大",是"同一批图上挂五套标注"

比 COCO 图像多的公开图像集并不少见,比它标注更精细的也有。它不可替代的地方在于:同一张图像上同时存在检测框、实例掩码、人体关键点、区域语义与自然语言描述,并且这五套标注共享同一个 image_id 主键。这意味着一个视觉系统只要跑一次推理,就能在五个任务上被交叉检验;也意味着研究者可以做"用 A 任务的监督训练、在 B 任务上评测"这类迁移实验,而不需要担心数据分布不一致的问题。

这个设计在数据工程上的价值常常被低估。做多任务学习的团队最贵的成本不是模型,而是把不同来源的标注对齐到同一批图像上;COCO 把这件事预先做完了,并且把对齐关系写进了主键里。

4.2 差异化证据

对比维度 只给类别标签的数据 只给框的数据 COCO
能否回答"在哪" 不能 能,矩形粒度 能,掩码粒度
背景区域是否有标注 无 无 有,91 个 stuff 类别
官方给出的像素占比 无此项 无此项 stuff 覆盖约 66% 的像素
人体是否有结构化标注 无 无 有,关键点与 DensePose
是否有自然语言 无 通常无 每图至少 5 条描述
是否提供统一评测代码 视情况 视情况 提供 Matlab / Python / Lua 三套评测代码

4.3 案例:同一张图上的四种标注形态

设想一张公园里的日常照片:长椅上坐着三个人,背后是草地与天空,远处有一辆车。这张图在 COCO 里会同时产生四类记录。

检测标注给每个可数物体一条记录:三个人各一条,长椅一条,车一条。每条带 bbox、segmentation、category_id、iscrowd。若远处还有一群人挤在一起,官方的做法是给这一群一条 iscrowd=1 的记录,掩码用 RLE 而不是多边形。

关键点标注只在人体实例上出现,且官方说明只标注中等与大尺度、非人群的人体实例。远景里那些小到几十像素的人,通常 num_keypoints=0。

stuff 标注给草地、天空这类区域各一条 RLE 记录,覆盖图像中没有确定形状的部分。官方给出的口径是这类区域占了 COCO 大约 66% 的像素——这也是为什么"只做检测"的模型在场景理解上永远差一口气。

全景标注把上面两类合并成一条逐图像记录:segments_info 里既有人(thing,带实例 id)也有草地(stuff,不带实例区分),另配一张 PNG 存逐像素的段 id。

这四种形态共用同一个 image_id,所以从检测切到全景不需要重新对齐数据,只需要换一个标注文件。

4.4 标注的粒度:多边形、RLE 与超像素

同一个数据集里存在三种掩码表示,各有各的适用位置。多边形是存储形态,官方说大部分真值掩码以多边形存储,因为它紧凑;RLE 是计算形态,需要算面积、交并、合并时临时转换;超像素是 stuff 标注的采集基底,决定了 stuff 掩码的边界精度上限。

理解这三者的关系能避开一类隐蔽的错误:把 iscrowd=1 的 RLE 掩码当多边形解析,或者反过来。官方的规则很干脆——iscrowd=0 用多边形(可能多段),iscrowd=1 用 RLE。解析代码必须先读 iscrowd 再决定走哪条分支。

4.5 边界条件:什么情况下它不再适用

当任务需要像素级精确的区域边界时。 stuff 掩码采集于超像素之上,边界是超像素级别的,不是手绘像素级。

当目标很小或处于人群之中时。 官方明确说关键点只标注在中等与大尺度、非人群的人体实例上,小目标与人群实例的 num_keypoints 常为 0。

当类别不在日常物体范围内时。 类别体系按"四岁小孩能认"选取,专业领域类别(医学器械、工业零件、遥感地物)不在其中。

当需要确定的输入尺寸时。 官方下载页没有给出统一分辨率,宽高是逐图字段。任何假设固定尺寸的数据加载器都要自己做缩放,并记得缩放会改变 area 与尺度分档的语义。

§5 怎么拿到

5.1 目录结构

官方给出的约定只有两条路径,但这两条路径决定了所有示例代码能不能跑起来。

coco/
├── images/
│   ├── train2017/        #-- 118K 张,18GB
│   ├── val2017/          #-- 5K 张,1GB
│   ├── test2017/         #-- 41K 张,6GB
│   └── unlabeled2017/    #-- 123K 张,19GB
└── annotations/
    ├── instances_train2017.json
    ├── instances_val2017.json
    ├── person_keypoints_train2017.json
    ├── person_keypoints_val2017.json
    ├── captions_train2017.json
    ├── captions_val2017.json
    ├── stuff_train2017.json
    ├── stuff_val2017.json
    ├── panoptic_train2017.json
    ├── panoptic_val2017.json
    ├── panoptic_train2017/    #-- 与 JSON 同名的 PNG 目录
    ├── panoptic_val2017/
    ├── image_info_test2017.json
    └── image_info_test-dev2017.json

全景分割的目录约定有一条硬规则:PNG 放在与 JSON 同名的文件夹下,即 annotations/name.json 对应 annotations/name/。官方的原话是 PNGs are in a folder with the same name as the JSON。

5.2 批量下载

官方推荐用 gsutil rsync 而不是拖 zip,理由是避免下载巨大的压缩包。托管方是 Google Cloud Platform,官方强调使用 gsutil 不需要 GCP 账号,也不需要运行 gcloud init。

#-- (1) 安装 gsutil
curl https://sdk.cloud.google.com | bash

#-- (2) 建本地目录,目录名即划分名
mkdir -p coco/images/val2017

#-- (3) 同步,把 val2017 换成要下的划分后重复 (2)(3)
gsutil -m rsync gs://images.cocodataset.org/val2017 coco/images/val2017

#-- 可同步的划分:train2014 val2014 test2014 test2015 train2017 val2017 test2017 unlabeled2017
gsutil -m rsync gs://images.cocodataset.org/train2017 coco/images/train2017

#-- (4) 取标注包
gsutil -m rsync gs://images.cocodataset.org/annotations coco/annotations

不需要 rsync 的场景下,下载页也给了直链。各包的体积是选包的主要依据:

包 体积 什么时候必下
train2017.zip 18GB 参加 2017 及之后任何任务
val2017.zip 1GB 自评与调参
test2017.zip 6GB 需要官方服务器评分时
unlabeled2017.zip 19GB 做半监督实验才需要
annotations_trainval2017.zip 241MB 检测与关键点,必下
stuff_annotations_trainval2017.zip 1.1GB 做 stuff 分割才需要
panoptic_annotations_trainval2017.zip 821MB 做全景分割才需要
image_info_test2017.zip 1MB 只需要测试集图像清单时

第一条省时间的判断:如果只做检测或关键点,图像下 train2017 + val2017(19GB),标注下 annotations_trainval2017(241MB)就够起步,剩下 26GB 可以之后再补。

5.3 用 COCO API 读取

官方 API 的命名约定写在下载页:ann 指 annotation,cat 指 category,img 指 image。八个入口函数覆盖了绝大多数取数需求。

函数 作用
getAnnIds 按过滤条件取标注 id
getCatIds 按过滤条件取类别 id
getImgIds 按过滤条件取图像 id
loadAnns 按 id 载入标注
loadCats 按 id 载入类别
loadImgs 按 id 载入图像
loadRes 载入算法结果并生成可访问的 API
showAnns 显示指定标注
from pycocotools.coco import COCO
import numpy as np

#-- 载入检测标注,路径按官方约定放在 coco/annotations/
coco = COCO('coco/annotations/instances_val2017.json')

#-- 取全部类别名,注意 id 与数组下标不是一回事
cats = coco.loadCats(coco.getCatIds())
print(len(cats))                       #-- thing 类别数
print([c['name'] for c in cats[:5]])

#-- 取某一类的全部图像 id,再取这些图的标注
cat_ids = coco.getCatIds(catNms=['person', 'car'])
img_ids = coco.getImgIds(catIds=cat_ids)
ann_ids = coco.getAnnIds(imgIds=img_ids[:20], catIds=cat_ids, iscrowd=None)
anns = coco.loadAnns(ann_ids)

#-- 一条标注的字段形态
a = anns[0]
print(sorted(a.keys()))
print(a['bbox'], a['area'], a['iscrowd'])

loadRes 这一步是评测的入口:把算法输出按官方结果格式组织后交给它,就能复用同一套 evaluate() 与 accumulate() 逻辑,不需要自己写匹配。

5.4 转成通用的表结构

很多流水线需要把 JSON 摊平成表。下面这段给出最小可用的转换,并保留了掩码形态的判断分支。

from pycocotools.coco import COCO
from pycocotools import mask as maskUtils
import pandas as pd

coco = COCO('coco/annotations/instances_train2017.json')
name_of = {c['id']: c['name'] for c in coco.loadCats(coco.getCatIds())}

rows = []
for img_id in coco.getImgIds():
    img = coco.loadImgs(img_id)[0]
    for a in coco.getAnnIds(imgIds=img_id):
        ann = coco.loadAnns(a)[0]
        x, y, w, h = ann['bbox']
        rows.append({
            'ann_id': ann['id'],
            'image_id': img_id,
            'file_name': img['file_name'],
            'width': img['width'],
            'height': img['height'],
            'cat_id': ann['category_id'],
            'cat_name': name_of.get(ann['category_id'], ''),
            'x': x, 'y': y, 'w': w, 'h': h,
            'area': ann['area'],
            'iscrowd': ann['iscrowd'],
            #-- iscrowd=1 时 segmentation 是 RLE,不能按多边形解析
            'mask_kind': 'rle' if ann['iscrowd'] == 1 else 'polygon',
        })

df = pd.DataFrame(rows)
print(df.shape, df['cat_name'].nunique())

掩码按需解码:

from pycocotools import mask as maskUtils

def to_binary(ann, height, width):
    #-- 多边形与 RLE 走不同分支,这是最容易写错的一处
    if ann['iscrowd'] == 1:
        rle = ann['segmentation']
    else:
        rles = maskUtils.frPyObjects(ann['segmentation'], height, width)
        rle = maskUtils.merge(rles)
    return maskUtils.decode(rle)

5.5 类别 id 的映射

类别 id 必须由 categories 数组映射,不能按出现顺序编号。categories 里的 id 与数组下标之间没有官方保证的对应关系,任何写死 idx + 1 的代码都是隐患。

from pycocotools.coco import COCO

coco = COCO('coco/annotations/instances_val2017.json')
cats = coco.loadCats(coco.getCatIds())

#-- 三个方向都要建:id->name、name->id、id->supercategory
id2name = {c['id']: c['name'] for c in cats}
name2id = {c['name']: c['id'] for c in cats}
id2super = {c['id']: c['supercategory'] for c in cats}

#-- 全景标注的类别多两个字段:isthing 与 color
pan = COCO('coco/annotations/panoptic_val2017.json')
pan_cats = pan.loadCats(pan.getCatIds())
print(sorted(pan_cats[0].keys()))

5.6 五个最容易出错的地方

坑 现象 正确做法
把 bbox 当 [x1,y1,x2,y2] 框整体偏右下、尺寸减半 官方写明是 [x,y,width,height],从左上角起算、0 基
按数组下标当类别 id 类别名整体错位 一律经 categories[].id 映射
把 iscrowd=1 的掩码当多边形解析 解析报类型错误 iscrowd=0 用多边形(可能多段),iscrowd=1 用 RLE
把各年度图像张数相加 得到的总数大于 330K 2017 的 train/val 与 2014 是同一批图像的不同划分
用框面积代替 area 做尺度分档 与官方指标口径不一致 官方说明面积按分割掩码的像素数计

§6 与站内相关资源的关系

6.1 关系图谱

COCO 在本站的位置是"通用视觉基准",与站内以医学影像为主的资源形成分工而不是竞争。

相邻资源 共享的标签 分工
landsat 图像数据、栅格/影像、地球观测 遥感影像,地物语义与尺度体系自成一套
multimodal-satellite-data 多模态、影像、公共卫生 卫星影像加公共卫生变量,偏公共卫生应用
cad-chest 医学影像、影像-文本对齐 胸部影像与报告对齐,任务在检出的医学语义上
egd-cxr 医学影像、可解释性 胸部放射影像,关注可解释性
covid-19-thermal 医学影像、红外成像 红外热成像,模态与日常照片差别大
medvh / mimic-ext-mimic-cxr-vqa 视觉问答、多模态评测 视觉语言评测,评测对象换成医学图文
vqa-evaluation-mimic-cxr 视觉问答、多模态评测 同上,评测方法与指标自成体系
medical-diff-vqa 视觉问答、纵向影像 同上,且带纵向时间维度
llava-rad-mimic-cxr-annotation 文本标注、多模态 放射报告的标注体系,标注对象不是图像区域
uci-ml-repository 数据仓储、评测基准 通用数据仓库,跨领域,不做图像标注
glue 评测基准、多任务 自然语言理解的多任务基准,结构与 COCO 的榜单逻辑相近
common-voice 众包数据集 众包采集的语音语料,可对照众包质量与许可问题

6.2 检索路径

你想找什么 该走的路径
通用视觉的横向对比基准 本页;按 2017 划分下数据与标注
姿态估计的指标定义 官方格式页的关键点一节与 keypoints 评测页
区域语义分割 官方 stuff 任务页与 stuff 标注包
统一的场景分割 官方 panoptic 任务页与 panoptic 标注包
图像描述与视觉语言 官方 captions 任务页与 COCO Caption Evaluation Toolkit
医学影像任务 转 cad-chest、egd-cxr 一类医学影像资源
多模态评测方法 转 medvh、vqa-evaluation-mimic-cxr 一类资源

6.3 与相邻资源的分工判据

判据 选 COCO 选医学影像资源
类别语义 日常物体与无定形区域 解剖结构与病灶
图像来源 Flickr 日常照片,版权分散 临床采集,通常有机构层级的使用审批
标注形态 实例掩码、关键点、区域语义、描述句 病变标注、报告文本、分诊标签
许可形态 标注 CC BY 4.0,图像另按 Flickr 条款 多数需数据使用协议或受限访问
评测方式 公开评测服务器与排行榜 多为论文内自评或专项评测

一句话概括这个分工:COCO 解决"通用视觉能力怎么量",医学影像资源解决"临床语义怎么学"。两者可以在预训练环节接力,但评测环节不能互相替代。

§7 质量评估与局限性

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

评价它的尺度不是"标注准不准"这一维。作为众包产出的通用基准,它的价值主要来自三件事:规模足够支撑深度模型、任务足够多支撑交叉检验、指标与评测代码统一因而结果可比。拿"单张掩码是否像素级精确"去衡量它,会得出偏低的结论,也会误判它的用途。

7.1 五维评分

维度 评价 依据
规模 高 330K 张图像、逾 200K 张带标注、150 万个实例
标注粒度 高 逐实例多边形掩码,另有人体关键点与 DensePose 部件掩码
任务覆盖 高 检测、关键点、stuff、全景、DensePose、描述共六类
工程完备度 高 三语言 API、Mask API、评测代码、结果上传与排行榜
权利清晰度 中 三层权利写得很清楚,但图像侧的授权要使用者自行确认

7.2 标注质量的两层

第一层是实例层。多边形掩码由众包工作者绘制,官方为控制成本采用了三段式界面(类别检测、实例点选、实例分割)。官方没有公布逐实例的复核比例或一致率,所以这一层的质量只能从"掩码以多边形存储、可用 RLE 精确计算面积与交并"这类结构性事实去判断,不能给出量化的准确率。

第二层是区域层。stuff 掩码采集于图像的超像素分割之上,边界精度受超像素粒度约束;官方把这一点直接写在任务页里,属于明示的取舍而不是隐藏的缺陷。

7.3 已知的、可枚举的偏差

偏差 机制 影响
图像来源偏差 图像取自 Flickr,拍摄者与题材分布受平台用户结构影响 场景与物体的先验与真实部署环境可能不同
关键点覆盖偏差 只标注中等与大尺度、非人群的人体实例 小目标与人群上的姿态性能缺乏真值支撑
区域边界偏差 stuff 标注采集于超像素之上 stuff 掩码边界不是像素级手绘精度
类别口径偏差 按"四岁小孩能认"选取类别 长尾与专业类别缺失
尺度构成偏差 官方评测页给出:约 41% 的物体是小目标(面积 < 32²),34% 中等(32²–96²),24% 大(面积 > 96²) 小目标占比最高,只看整体 AP 会掩盖小目标问题
分辨率不统一 宽高逐图给出,官方下载页未给统一值 固定尺寸的输入假设需要自己做缩放

上表第六行的三个比例来自官方评测页的明文表述,属于官方给出的构成口径,不是自行统计。

7.4 外部验证矩阵

声称的能力 能否用官方页直接验证 依据
330K 张图像、逾 200K 张带标注 能,首页特征清单 首页 What is COCO 一节
150 万个物体实例 能,首页特征清单 同上
80 个 thing 类别、91 个 stuff 类别 能,首页与检测任务页 首页特征清单;检测任务页写 80 object categories
每图至少 5 条描述 能,格式页描述一节 格式页写明"each image has at least 5 captions"
250,000 个带关键点的人 能,首页与关键点任务页 两处一致
图像版权归属 能,条款页 条款页 Images 一节
标注与网站为 CC BY 4.0 能,条款页 条款页 Annotations & Website 一节
论文发表于 ECCV 2014 能,arXiv 与 CaltechAUTHORS 后者给出卷期与会议信息
众包经费来自微软 能,论文致谢 CaltechAUTHORS 记录的 Funding 字段

7.5 它为何能持续:稀缺的是指标,不是图像

从 2017 年起,官方在下载页反复声明"所有挑战赛数据保持不变";2020 年之后不再办赛,官方把参与者引导到 LVIS。数据不变这件事本身就是它的竞争力来源:一个基准如果每年都在变,跨年份的数字就无法比较。它真正的资产是一套被广泛接受的度量——10 个 IoU 阈值上的平均 AP、三档尺度划分、OKS 这套关键点相似度——以及配套的三语言评测代码。图像可以被替换,这套度量一旦被替换,整个领域的纵向比较就断了。

§8 生态位与历史

8.1 历史沿革

COCO 的出现处在一个特定位置:分类任务已经因为大规模图像集而被推到很高,而检测与分割的数据还停留在类别少、物体居中、尺度单一的阶段。论文摘要把它的目标写得很清楚——把物体识别放进场景理解这个更大的问题里。2014 年 9 月发表于 ECCV(苏黎世),DOI 为 10.1007/978-3-319-10602-1_48,收录于 LNCS 8693。

数据集本身随之进入逐年迭代:2015 年办检测与描述,2016 年加关键点,2017 年重划图像划分并加入 stuff,2018 年加入全景与 DensePose,2020 年是最后一届,2021 年起官方不再办赛。这条线说明它的角色从"新数据"逐渐变成"固定基准"。

8.2 与挑战赛的关系

年份 赛道
2015 Detection、Captioning
2016 Detection、Keypoints
2017 Detection、Keypoints、Stuff
2018 Detection、Keypoints、Stuff、Panoptic
2019 Detection、Keypoints、Stuff、Panoptic
2020 Detection、Keypoints、Panoptic、DensePose
2021 无(官方引导参加 LVIS 2021)

赛道与划分的绑定关系由下载页规定:2015、2016 的任务挂在 2014 与 2015 划分上;2017 及之后全部挂在 2017 划分上。官方还写明划分年份指的是图像划分发布的年份,不是标注发布的年份——这一句解释了为什么"2017 标注"这个说法本身就不严谨。

测试集的组织方式在 2017 年也变了。此前有四份(dev / standard / reserve / challenge),2017 年起简化为 dev 与 challenge 两份。官方给的理由是:办了几年之后没有看到针对特定划分过拟合的证据,而且输出空间复杂度与测试集规模本身就足以抵御简单攻击。提交限额也随之一并规定:val 不限次且即时出分,test-dev 每天限 5 次并全年开放,test-challenge 整届限 5 次且结果在 workshop 公布。

8.3 生态位:一台评测机器

它在生态里的位置更接近"尺"而不是"粮"。作为预训练源它当然可用,训练出来的骨干可以迁移到任何视觉任务;但真正无法替代的是它的评测位——公开排行榜、全年开放的 test-dev、统一的结果格式与评测代码。这个位置要求它保持稳定,所以官方才会逐年声明数据不变。

代价是它对新任务的响应很慢。COCO 的类别与标注是固定的,出现新任务(例如开放词汇检测)时,官方的选择不是扩充 COCO,而是引导社区去 LVIS。这说明维护方很清楚自己的边界。

8.4 谁在用,用来做什么

使用者 用它做什么 依赖的那一层
检测与分割模型的研发者 横向对比与纵向追踪 统一指标与排行榜
姿态估计研究者 OKS 评测与关键点训练 关键点标注与 κ=2σ 的度量设计
全景分割研究者 PQ 评测与统一场景分割 全景标注 PNG 与 segments_info
视觉语言模型研究者 描述生成与跨模态评测 每图 5 条人工描述
医学影像 AI 团队 骨干网络的通用预训练 大规模日常场景图像与实例掩码
数据工程团队 JSON 标注格式的样板 顶层结构与五类扩展结构

§9 使用指引

9.1 三种角色的路径

角色 最短路径
算法工程师,要跑一个基线 下 train2017 + val2017 + annotations_trainval2017;用 COCO API 载入;在 val 上用 loadRes 评测
医学影像研究者,要一个预训练源 只需 train2017 与检测标注;训练后在你的数据上微调;引用时写明预训练源与许可分层
数据工程人员,要定标注格式 只读格式页的五类结构;把 info/images/annotations/licenses 作为顶层,categories 作为映射表

9.2 一条最短的可用流程

from pycocotools.coco import COCO
from pycocotools.cocoeval import COCOeval

#-- 1) 载入真值与算法结果
coco_gt = COCO('coco/annotations/instances_val2017.json')
coco_dt = coco_gt.loadRes('results/val2017_bbox.json')

#-- 2) 评测;默认参数即官方口径:10 个 IoU 阈值、101 个召回阈值、4 档面积、3 档最大检测数
evaluator = COCOeval(coco_gt, coco_dt, iouType='bbox')
evaluator.evaluate()
evaluator.accumulate()
evaluator.summarize()      #-- 输出 12 项指标

#-- 3) 换 iouType 即可切到分割与关键点
#-- evaluator = COCOeval(coco_gt, coco_dt, iouType='segm')
#-- evaluator = COCOeval(coco_gt, coco_dt, iouType='keypoints')

官方评测页给出的默认参数是:IoU 阈值 .5:.05:.95 共 10 个,召回阈值 0:.01:1 共 101 个,面积分档 all / small / medium / large 共 4 档,每图最大检测数 1 / 10 / 100 共 3 档,评测时每图最多取 100 个得分最高的检测结果。这五个默认值一般不需要改动。

9.3 引用方式

场景 该写什么
引用数据集 写明数据集名(COCO / Common Objects in Context)、访问的划分与年份、官方站点地址
引用论文 Lin 等,Microsoft COCO: Common Objects in Context,ECCV 2014,DOI 10.1007/978-3-319-10602-1_48
引用标注的许可 标注与网站为 CC BY 4.0,须署名 COCO Consortium
引用图像的许可 说明图像版权不属于 COCO Consortium,使用遵守 Flickr 条款
引用评测指标 写明 AP 在 IoU=.50:.05:.95 上平均,并说明尺度分档的像素阈值

§10 AI 使用声明

项目 声明
文本生成 本文由 AI 辅助撰写,编辑把关结构与事实
数字来源 规模、结构、边界三类数字来自 cocodataset.org 各页签与 arXiv / CaltechAUTHORS 的论文记录
文件核验 home、download、termsofuse、format-data、detection-2020、keypoints-2020、keypoints-eval、detection-eval、stuff-2019、panoptic-2020、captions-2015、guidelines 各页经直接抓取核对
不一致说明 实例数有三个官方口径(首页 150 万、检测任务页 train/val 逾 50 万、论文摘要 250 万);无标注图像数在下载页为 123K、在 2017 更新说明里为 120K;已在正文与常见误读中各说明一次
论文信息 论文元数据经 arXiv 与 CaltechAUTHORS 两条来源核对,未读全文
未核验内容 逐类别的实例条数、关键点总数 k 的具体值、stuff 类别在全景任务里的子集构成、各年度图像集合的具体重叠张数
图像 无配图;封面为生成式提示词,不含真实图像内容
免责 本文不构成法律意见;图像的商业使用须自行确认 Flickr 授权,标注使用须遵守 CC BY 4.0 的署名要求

常见误读(避坑清单)

说法 实际 证据
「COCO 是微软的数据集」 众包任务经费由微软提供;标注与网站归 COCO Consortium;赞助方另有 CVDF、Facebook、MightyAI 论文 Funding 字段;首页 Sponsors 一栏;条款页
「图像是 CC BY 4.0」 CC BY 4.0 只覆盖标注与网站;图像版权不属于 Consortium,须遵守 Flickr 条款 条款页 Annotations & Website 与 Images 两节
「33 万张都能下载都能训练」 330K 中逾 200K 带标注,其余为测试集与无标注图像 首页特征清单;下载页各组体积
「2014 与 2017 的张数可以相加」 2017 的 train/val 与 2014 是同一批图像的不同划分 下载页 2017 更新说明
「80 个类别就是全部标注」 另有 91 个 stuff 类别;全景任务取 80 thing 加 91 stuff 的子集 首页特征清单;panoptic 任务页
「150 万个实例是唯一口径」 首页 150 万;检测任务页写 train/val 公开逾 50 万个已分割实例;论文摘要写 328k 图上 250 万个标注实例 三处官方文本
「bbox 是左上角加右下角」 是 [x,y,width,height],从左上角起算、0 基 格式页 Object Detection 一节
「test 集标注迟早会公开」 官方禁止以任何形式用测试集做训练,并要求不要发布 test 集图像的标注 guidelines 页;external 页
「类别 id 等于类别在数组里的序号」 id 由 categories[].id 给出,与下标无官方保证的对应关系 格式页 categories 结构
「官方写明了关键点有 17 个」 官方只给出 keypoints 长度为 3k 的约定,以及九类关键点的 σ 值列表 格式页关键点一节;keypoints 评测页 OKS 调优一节

FAQ

Q1:COCO 到底有多少张图像?为什么不同地方数字不一样?
官方首页写 330K 张,其中逾 200K 张带标注,这是整体规模口径。下载页按年度划分给出各组:2014 train 83K、val 41K、test 41K,2015 test 81K,2017 train 118K、val 5K、test 41K、unlabeled 123K。这些组的张数不能相加,因为官方在 2017 更新说明里写明 2017 的 train/val 与 2014 的 train/val 是同一批图像、只是划分不同。你实际能训练的图像数,取决于你选哪一年的划分,而不是 330K 这个总数。

Q2:它的图像可以商用吗?
不能按"CC BY 4.0"直接推定。条款页明确区分三层:标注与网站属于 COCO Consortium 并按 CC BY 4.0 许可;图像的版权不属于 Consortium,使用必须遵守 Flickr 条款,使用者接受包括制作副本在内的全部责任;软件另有 2015 年的三条款式许可。因此商用前需要逐图确认 Flickr 上的授权状态,数据集本身不提供兜底。

Q3:我该下 2014 版还是 2017 版?
看你要复现哪一届的任务。2015 与 2016 的检测、描述、关键点任务挂在 2014 与 2015 划分上;2017 及之后的所有任务都挂在 2017 划分上。官方在下载页直接写明:参加 2017、2018、2019、2020 的任务只需要 2017 图像,可以忽略更早的划分;并且因为 2017 的 train/val 与 2014 用的是同一批图像,用 2014 训练数据参加 2017 比赛没有增益。

Q4:关键点标注里的 v 标志该怎么用?
v 有三档:v=0 表示未标注,此时 x 与 y 都是 0;v=1 表示已标注但不可见;v=2 表示已标注且可见。官方补充说"可见"的判定标准是关键点是否落在物体分割区域内。num_keypoints 记录 v>0 的个数,人群与小尺度目标常常是 0。训练时如果直接把 v=0 的点当坐标 0 去回归,会把大量假坐标喂进模型——正确做法是只在 v>0 的点上计算损失。

Q5:为什么 AP 要在十个 IoU 阈值上平均,而不是只取 0.5?
官方评测页把这一点称为对传统的突破:传统做法只在单一 IoU=.50 上算 AP,而在 .50:.05:.95 这 10 个阈值上平均会奖励定位更准的检测器。此外 AP 还跨全部 80 个类别平均,官方明确说他们不区分 AP 与 mAP。因此报告 COCO 的 AP 时,必须说明是 10 阈值平均口径,否则与别人的数字不可比。

术语表

术语 解释
thing 可数物体类别,有确定的大小与形状,常由部件组成,COCO 有 80 类
stuff 无定形区域类别,由同质或重复的细粒度纹理定义,没有确定的空间范围或形状,COCO 有 91 类
实例分割 对每个物体实例给出像素级掩码,区别于只给外接框的检测
全景分割 同时对 thing 与 stuff 做逐像素标注,给每个像素一个语义标签与实例 id
supercategory 类别之上的粗分类,随类别记录一起给出
iscrowd 群体标志;0 表示单个物体(掩码用多边形),1 表示一大群物体(掩码用 RLE)
RLE 行程长度编码,官方用来紧凑存储掩码并高效计算面积、并、交
多边形掩码 以顶点序列存储的掩码,官方称大部分真值掩码采用这种紧凑形式
OKS 目标关键点相似度,关键点任务里扮演 IoU 的角色
κ(kappa) OKS 中控制衰减的每关键点常数,官方取 κ=2σ
visibility flag 关键点可见性标志 v,取值 0/1/2
bbox 外接框,格式为 [x, y, width, height],从左上角起算、0 基
area 面积,官方按分割掩码的像素数计
AP / AR 平均精度与平均召回;官方不区分 AP 与 mAP
IoU 交并比,检测任务里作为真值与预测之间的相似度度量
PQ 全景质量,全景分割任务的评价指标
DensePose 把人体表面参数化的标注任务,14 个部件、24 个表面块
COCO API 官方提供的标注读写与可视化接口,有 Matlab、Python、Lua 三套
Mask API 掩码操作接口,含 encode / decode / merge / iou / area 等八个函数
COCO Consortium 标注与网站的权利主体,也是软件版权署名方
CVDF Common Visual Data Foundation,首页列出的赞助方之一
gsutil Google Cloud 的命令行工具,官方推荐的下载方式
test-dev / test-challenge 2017 年起测试集的两份划分,前者全年开放、后者用于比赛

附录 A:核心数字核对表

项 值 出处
图像总数 330K 张,其中逾 200K 张带标注 首页特征清单
物体实例数 150 万个 首页特征清单
train/val 公开分割实例 逾 50 万个 detection-2020 任务页
论文口径的实例数 328k 张图上 250 万个标注实例 arXiv 1405.0312 摘要
thing 类别数 80 首页特征清单;detection-2020 任务页
stuff 类别数 91 首页特征清单;stuff-2019 任务页
stuff 像素占比 约 66% stuff-2019 任务页
每图描述条数 至少 5 条,部分更多 格式页 Image Captioning 一节
带关键点的人体实例 250,000 首页特征清单;keypoints-2020 任务页
train/val 关键点规模 逾 150,000 人、170 万个已标注关键点 keypoints-2020 任务页
DensePose 部件与表面块 14 个部件、24 个表面块、掩码 256×256 格式页 DensePose 一节
2017 划分 train 118K / val 5K / test 41K / unlabeled 123K 下载页
2014 划分 train 83K / val 41K / test 41K 下载页
2015 测试集 81K 下载页
检测指标数 12 项 detection-eval 页
关键点指标数 10 项 keypoints-eval 页
IoU 阈值 .50:.05:.95,共 10 个 detection-eval 页
尺度分档 small < 32²、medium 32²–96²、large > 96² detection-eval 页
每图最大检测数 检测 100,关键点 20 两处评测页
2017 测试集划分 约 40K 张,dev 与 challenge 各约 20K guidelines 页
论文发表 2014 年 9 月,ECCV 2014,DOI 10.1007/978-3-319-10602-1_48 CaltechAUTHORS
标注与网站许可 CC BY 4.0 条款页

附录 B:数字的来源分层

第一层:官方站点各页签。 图像规模、实例数、类别数、关键点规模、描述条数、各年度划分的张数与体积、指标数量、阈值与分档、测试集划分与提交限额、三层许可。这些来自首页、下载页、条款页、格式页、各任务页、评测页与测试指南页,经直接抓取核对。

第二层:论文元数据。 论文的题名、作者、发表时间与会议、资助来源,来自 arXiv 提交历史与 CaltechAUTHORS 记录两条来源,互相印证。论文摘要里给出的 250 万个标注实例属于这一层,与首页的 150 万不是同一口径。

第三层:未核实。 逐类别的实例条数、关键点总数 k 的具体值、stuff 类别在全景任务中被取用的子集构成、各年度图像集合的具体重叠张数。这些需要下载标注文件后统计,本文按要求只写规模、结构、边界三类数字,正文中凡是涉及的地方都只做定性表述。

附录 C:完整参考文献

编号 文献 链接 用途
1 COCO 官方站点首页 https://cocodataset.org/#home 规模特征、协作者、赞助方
2 下载页 https://cocodataset.org/#download 各年度划分、体积、API、gsutil 用法
3 条款页 https://cocodataset.org/#termsofuse 三层许可与软件条款
4 数据格式页 https://cocodataset.org/#format-data 五类标注的 JSON 结构
5 检测评测页 https://cocodataset.org/#detection-eval 12 项指标、IoU 阈值、尺度分档
6 关键点评测页 https://cocodataset.org/#keypoints-eval OKS 定义、κ=2σ、σ 值、10 项指标
7 测试指南页 https://cocodataset.org/#guidelines 测试集划分与提交限额
8 检测任务页(2020) https://cocodataset.org/#detection-2020 80 类别与 train/val 公开标注规模
9 关键点任务页(2020) https://cocodataset.org/#keypoints-2020 关键点覆盖范围与规模
10 Stuff 任务页(2019) https://cocodataset.org/#stuff-2019 stuff 定义与 66% 像素占比
11 全景任务页(2020) https://cocodataset.org/#panoptic-2020 80 thing 与 91 stuff 子集的合并关系
12 描述任务页(2015) https://cocodataset.org/#captions-2015 描述任务的评价方式
13 Lin 等,Microsoft COCO: Common Objects in Context,ECCV 2014 https://doi.org/10.1007/978-3-319-10602-1_48 论文题名、会议、资助来源
14 同上,预印本 https://arxiv.org/abs/1405.0312 提交与修订时间、摘要

附录 D:任务代码

任务一:统计一个划分上的类别与标注规模

from pycocotools.coco import COCO
from collections import Counter

coco = COCO('coco/annotations/instances_train2017.json')

#-- 类别数:读 categories,不要靠数标注里出现的 id
cats = coco.loadCats(coco.getCatIds())
print('类别数', len(cats))
print('supercategory 数', len({c['supercategory'] for c in cats}))

#-- 标注总数与群体标注数
ann_ids = coco.getAnnIds()
anns = coco.loadAnns(ann_ids)
print('标注条数', len(anns))
print('iscrowd=1 条数', sum(a['iscrowd'] for a in anns))

#-- 尺度分档按官方口径:面积以掩码像素数计
small = sum(1 for a in anns if a['area'] < 32 ** 2)
medium = sum(1 for a in anns if 32 ** 2 <= a['area'] < 96 ** 2)
large = sum(1 for a in anns if a['area'] >= 96 ** 2)
print('small/medium/large', small, medium, large)

第二段代码里用的是官方给出的阈值(32² 与 96²),不是自行设定的分档。它的用途不是下结论,而是确认你手上的划分与官方口径一致——如果三档的构成与官方评测页给出的比例相差很远,通常是解析出了错(例如把 bbox 当成左上右下、或把 area 换成了框面积)。

任务二:把掩码解码成二值图并与外接框对齐

from pycocotools.coco import COCO
from pycocotools import mask as maskUtils
import numpy as np

coco = COCO('coco/annotations/instances_val2017.json')
img_id = coco.getImgIds()[0]
img = coco.loadImgs(img_id)[0]
anns = coco.loadAnns(coco.getAnnIds(imgIds=img_id))

for a in anns[:5]:
    #-- iscrowd 决定走哪条分支:1 是 RLE,0 是多边形
    if a['iscrowd'] == 1:
        rle = a['segmentation']
    else:
        rle = maskUtils.merge(maskUtils.frPyObjects(
            a['segmentation'], img['height'], img['width']))
    m = maskUtils.decode(rle)
    x, y, w, h = [int(round(v)) for v in a['bbox']]
    print(a['category_id'], m.shape, m.sum(), a['area'],
          '框内掩码占比', m[y:y + h, x:x + w].sum() / max(m.sum(), 1))

最后一行打印的是"掩码有多少落在自己的外接框内"。正常情况下这个数应当接近 1;如果明显小于 1,说明 bbox 被按左上右下解析了,框的位置已经偏出掩码。这是一条很便宜的自检。

附录 E:如果只记五件事

序号 记住什么 为什么
1 330K 张图像、逾 200K 带标注、150 万个实例、80 thing 加 91 stuff 这五个数字定义了一切用法与限制
2 三层权利:标注 CC BY 4.0、图像按 Flickr 条款、软件三条款式 商用前必须逐图确认授权,数据集不兜底
3 2017 划分是现行主力,2014 只服务 2015/2016 的任务 下错划分等于白下几十 GB
4 bbox 是 [x,y,width,height],area 按掩码像素数计 这两处解析错,指标就与官方口径不可比
5 它不可替代的是那套统一指标与评测代码,不是图像体量 数据自 2017 年起逐年声明不变,这正是它的价值所在

编辑说明

本文的核验时间为 2026 年 10 月 29 日。核对方式为直接抓取 cocodataset.org 的 home、download、termsofuse、format-data、detection-2020、keypoints-2020、keypoints-eval、detection-eval、stuff-2019、panoptic-2020、captions-2015、guidelines 等页签(站内页签内容由 dataset/<页签>.htm 异步加载,据此逐页读取),并用 arXiv 与 CaltechAUTHORS 两条来源交叉核对论文元数据。实例数存在三个官方口径(首页 150 万、检测任务页 train/val 逾 50 万个已分割实例、论文摘要 328k 图上 250 万个标注实例),本文三处并列呈现而不做合并;无标注图像数在下载页为 123K、在 2017 更新说明里为 120K,同样并列呈现。未覆盖的内容包括:逐类别的实例条数、关键点总数 k 的具体数值、stuff 类别在全景任务中被取用的子集构成、各年度图像集合的具体重叠张数。这些需要下载标注文件后统计,本文按要求只写规模、结构、边界三类数字。


相关数据集导航

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

  • landsat,共享标签:影像数据 / 地物语义 / 大规模标注入门
  • multimodal-satellite-data,共享标签:影像数据 / 多模态 / 公共卫生
  • cad-chest,共享标签:医学影像 / 影像-文本对齐 / 多模态
  • egd-cxr,共享标签:医学影像 / 可解释性 / 多模态
  • covid-19-thermal,共享标签:医学影像 / 红外成像 / 图像分类
  • medvh,共享标签:视觉问答 / 多模态模型 / 幻觉评估
  • mimic-ext-mimic-cxr-vqa,共享标签:视觉问答 / 多模态 / 基准评测
  • vqa-evaluation-mimic-cxr,共享标签:视觉问答 / 多模态评测 / 医学影像
  • medical-diff-vqa,共享标签:视觉问答 / 纵向影像 / 医学影像
  • llava-rad-mimic-cxr-annotation,共享标签:文本标注 / 多模态 / 自然语言处理
  • uci-ml-repository,共享标签:数据仓储 / 评测基准 / 元数据检索
  • glue,共享标签:评测基准 / 多任务 / 公开排行榜
  • common-voice,共享标签:众包数据集 / 多语种 / 开放许可

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

返回 AI-Ready 数据集