COCO通过大量使用Amazon Mechanical Turk来收集数据。COCO数据集现在有3种标注类型：object instances(目标实例), object keypoints(目标上的关键点), 和image captions(看图说话)，使用JSON文件存储。比如下面就是Gemfield下载的COCO 2017年训练集中的标注文件：

可以看到其中有上面所述的三种类型，每种类型又包含了训练和验证，所以共6个JSON文件。

以instances_train2014.json为例，总体形式如下：

(1)images字段列表元素的长度等同于划入训练集(或者测试集)的图片的数量；

(2)annotations字段列表元素的数量等同于训练集(或者测试集)中bounding box的数量；

(3)categories字段列表元素的数量等同于类别的数量，coco为80(2017年)；

>>> ann_train_file='annotations/instances_train2017.json'

>>> coco_train = COCO(ann_train_file)

loading annotations into memory...

Done (t=19.30s)

creating index...

index created!

>>> len(coco_train.dataset['categories'])

80

>>> len(coco_train.dataset['images'])

118287

>>> len(coco_train.dataset['annotations'])

860001

>>>

这是用来train的json中保存的东西，首先json保存的是一个大的字典：

info这个key指向的字典是一些基本信息，包括时间，版本，贡献者，网址链接等不重要，可以忽略。

images这个key指向的列表(注意是列表，上面info指向的是字典)是图片信息，列表中的每一个字典下存储一张图片的信息，license、coco_url、data_captured和flickr_url这几个key指向的信息大概了解下就行，在你已经下载到原图jpg文件的情况下，这些信息基本没用。接下来就是比较重要的几个信息了，首先是file_name，指向的是一个字符串，是jpg的文件名；其次是height和width指向的是该图片的高和宽，id指向的数字可能让大家比较迷惑，这个信息非常至关键，这一串数字是每张图片特有的一个标志，数字不重复，可以看作是图片的身份信息，就像身份证那一串数字一样。

下一个License这个key指向的信息也可以忽略不计，就是途中被我选中标黑的那个部分。

再下一个annotations这个key是本json中最最最最最重要的一个部分了。

annotations字段是包含多个annotation实例的一个数组，annotation类型本身又包含了一系列的字段，如这个目标的category id和segmentation mask。segmentation格式取决于这个实例是一个单个的对象(即iscrowd=0，将使用polygons格式)还是一组对象(即iscrowd=1，将使用RLE格式)。如下所示：

annotation{

"id": int,

"image_id": int,

"category_id": int,

"segmentation": RLE or [polygon],

"area": float,

"bbox": [x,y,width,height],

"iscrowd": 0 or 1,

}

注意，单个的对象(iscrowd=0)可能需要多个polygon来表示，比如这个对象在图像中被挡住了。而iscrowd=1时(将标注一组对象，比如一群人)的segmentation使用的就是RLE格式。

注意啊，只要是iscrowd=0那么segmentation就是polygon格式；只要iscrowd=1那么segmentation就是RLE格式。另外，每个对象(不管是iscrowd=0还是iscrowd=1)都会有一个矩形框bbox ，矩形框左上角的坐标和矩形框的长宽会以数组的形式提供，数组第一个元素就是左上角的横坐标值。

该key指向的是一个list，然后包含多个字典，每个字典包含一个物体分割的信息。看该列表中第一个字典，segmentation指向是的一个套着两个list的东西，里面一堆数字的含义是像素级分割得到的物体边缘坐标(有心的同学会发现这里面的数字个数都是偶数，因为坐标是成对出现的)；area指向该segmentation的面积，iscrowd目前来看都指向0，表示没有重叠吧，有重叠指向1(我的理解是这样，可能有偏差，不过影响不大)；image_id就是前面images中存储的id ！读取json信息的时候会用到；bbox指向的就是物体的框；category_id指向的数字代表类别(这里说一下，有些博客说是有90类，但是从coco2014上来看，只是category_id标定到了90这个数字而已，但是实际类数只有80类，因为，1-90这数字中有一些是跳过的，即有些数字没有)；id不同于images中的id，images中的id是每幅图片的身份编号，而此处的id是每个框的身份编号，注意区分。

最后一部分

Object Keypoint 类型的标注格式

1，整体JSON文件格式

比如上图中的person_keypoints_train2017.json、person_keypoints_val2017.json这两个文件就是这种格式。

Object Keypoint这种格式的文件从头至尾按照顺序分为以下段落，看起来和Object Instance一样啊：

{

"info": info,

"licenses": [license],

"images": [image],

"annotations": [annotation],

"categories": [category]

}

是的，你打开这两个文件，虽然内容很多，但从文件开始到结尾按照顺序就是这5段。其中，info、licenses、images这三个结构体/类型 在第一节中已经说了，在不同的JSON文件中这三个类型是一样的，定义是共享的。不共享的是annotation和category这两种结构体，他们在不同类型的JSON文件中是不一样的。

images数组元素数量是划入训练集(测试集)的图片的数量；

annotations是bounding box的数量，在这里只有人这个类别的bounding box；

categories数组元素的数量为1，只有一个：person(2017年)；

2，annotations字段

这个类型中的annotation结构体包含了Object Instance中annotation结构体的所有字段，再加上2个额外的字段。

新增的keypoints是一个长度为3*k的数组，其中k是category中keypoints的总数量。每一个keypoint是一个长度为3的数组，第一和第二个元素分别是x和y坐标值，第三个元素是个标志位v，v为0时表示这个关键点没有标注(这种情况下x=y=v=0)，v为1时表示这个关键点标注了但是不可见(被遮挡了)，v为2时表示这个关键点标注了同时也可见。

num_keypoints表示这个目标上被标注的关键点的数量(v>0)，比较小的目标上可能就无法标注关键点。

annotation{

"keypoints": [x1,y1,v1,...],

"num_keypoints": int,

"id": int,

"image_id": int,

"category_id": int,

"segmentation": RLE or [polygon],

"area": float,

"bbox": [x,y,width,height],

"iscrowd": 0 or 1,

}

从person_keypoints_val2017.json文件中摘出一个annotation的实例如下：

{

"segmentation": [[125.12,539.69,140.94,522.43...]],

"num_keypoints": 10,

"area": 47803.27955,

"iscrowd": 0,

"keypoints": [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,142,309,1,177,320,2,191,398...],

"image_id": 425226,"bbox": [73.35,206.02,300.58,372.5],"category_id": 1,

"id": 183126

},

3，categories字段

最后，对于每一个category结构体，相比Object Instance中的category新增了2个额外的字段，keypoints是一个长度为k的数组，包含了每个关键点的名字；skeleton定义了各个关键点之间的连接性(比如人的左手腕和左肘就是连接的，但是左手腕和右手腕就不是)。目前，COCO的keypoints只标注了person category (分类为人)。

定义如下：

{

"id": int,

"name": str,

"supercategory": str,

"keypoints": [str],

"skeleton": [edge]

}

从person_keypoints_val2017.json文件中摘出一个category的实例如下：

{

"supercategory": "person",

"id": 1,

"name": "person",

"keypoints": ["nose","left_eye","right_eye","left_ear","right_ear","left_shoulder","right_shoulder","left_elbow","right_elbow","left_wrist","right_wrist","left_hip","right_hip","left_knee","right_knee","left_ankle","right_ankle"],

"skeleton": [[16,14],[14,12],[17,15],[15,13],[12,13],[6,12],[7,13],[6,7],[6,8],[7,9],[8,10],[9,11],[2,3],[1,2],[1,3],[2,4],[3,5],[4,6],[5,7]]

}

Image Caption的标注格式

1，整体JSON文件格式

比如上图中的captions_train2017.json、captions_val2017.json这两个文件就是这种格式。

Image Caption这种格式的文件从头至尾按照顺序分为以下段落，看起来和Object Instance一样，不过没有最后的categories字段：

{

"info": info,

"licenses": [license],

"images": [image],

"annotations": [annotation]

}

是的，你打开这两个文件，虽然内容很多，但从文件开始到结尾按照顺序就是这4段。其中，info、licenses、images这三个结构体/类型 在第一节中已经说了，在不同的JSON文件中这三个类型是一样的，定义是共享的。不共享的是annotations这种结构体，它在不同类型的JSON文件中是不一样的。

images数组的元素数量等于划入训练集(或者测试集)的图片的数量；

annotations的数量要多于图片的数量，这是因为一个图片可以有多个场景描述；

2，annotations字段

这个类型中的annotation用来存储描述图片的语句。每个语句描述了对应图片的内容，而每个图片至少有5个描述语句(有的图片更多)。annotation定义如下：

annotation{

"id": int,

"image_id": int,

"caption": str

}

从captions_val2017.json中摘取的一个annotation实例如下：

{

"image_id": 179765,

"id": 38,"caption": "A black Honda motorcycle parked in front of a garage."

}