COCO數據格式說明

?

標注工具推薦：https://github.com/wkentaro/labelme?

labelme自帶了轉換VOC和COCO的數據格式：labelme/examples

COCO的 全稱是Common Objects in COntext，是微軟團隊提供的一個可以用來進行圖像識別的數據集。MS COCO數據集中的圖像分為訓練、驗證和測試集。COCO通過在Flickr上搜索80個對象類別和各種場景類型來收集圖像，其使用了亞馬遜的Mechanical Turk（AMT）。

比如標注image captions（看圖說話）這種類型的步驟如下：

（AMT上COCO標注步驟）

COCO通過大量使用Amazon Mechanical Turk來收集數據。COCO數據集現在有3種標注類型：object instances（目標實例）, object keypoints（目標上的關鍵點）, 和image captions（看圖說話），使用JSON文件存儲。比如下面就是Gemfield下載的COCO 2017年訓練集中的標注文件：

可以看到其中有上面所述的三種類型，每種類型又包含了訓練和驗證，所以共6個JSON文件。

基本的JSON結構體類型

object instances（目標實例）、object keypoints（目標上的關鍵點）、image captions（看圖說話）這3種類型共享這些基本類型：info、image、license。

而annotation類型則呈現出了多態：

{"info": info,"licenses": [license],"images": [image],"annotations": [annotation], }info{"year": int,"version": str,"description": str,"contributor": str,"url": str,"date_created": datetime, } license{"id": int,"name": str,"url": str, } image{"id": int,"width": int,"height": int,"file_name": str,"license": int,"flickr_url": str,"coco_url": str,"date_captured": datetime, }

1，info類型，比如一個info類型的實例：

"info":{"description":"This is stable 1.0 version of the 2014 MS COCO dataset.","url":"http:\/\/mscoco.org","version":"1.0","year":2014,"contributor":"Microsoft COCO group","date_created":"2015-01-27 09:11:52.357475" },

2，Images是包含多個image實例的數組，對于一個image類型的實例：

{"license":3,"file_name":"COCO_val2014_000000391895.jpg","coco_url":"http:\/\/mscoco.org\/images\/391895","height":360,"width":640,"date_captured":"2013-11-14 11:18:45","flickr_url":"http:\/\/farm9.staticflickr.com\/8186\/8119368305_4e622c8349_z.jpg","id":391895 },

3，licenses是包含多個license實例的數組，對于一個license類型的實例：

{"url":"http:\/\/creativecommons.org\/licenses\/by-nc-sa\/2.0\/","id":1,"name":"Attribution-NonCommercial-ShareAlike License" },

Object Instance 類型的標注格式

1，整體JSON文件格式

比如上圖中的instances_train2017.json、instances_val2017.json這兩個文件就是這種格式。

Object Instance這種格式的文件從頭至尾按照順序分為以下段落：

{"info": info,"licenses": [license],"images": [image],"annotations": [annotation],"categories": [category] }

是的，你打開這兩個文件，雖然內容很多，但從文件開始到結尾按照順序就是這5段。其中，info、licenses、images這三個結構體/類型 在上一節中已經說了，在不同的JSON文件中這三個類型是一樣的，定義是共享的。不共享的是annotation和category這兩種結構體，他們在不同類型的JSON文件中是不一樣的。

images數組元素的數量等同于劃入訓練集（或者測試集）的圖片的數量；

annotations數組元素的數量等同于訓練集（或者測試集）中bounding box的數量；

categories數組元素的數量為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 >>>

2，annotations字段

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 ，矩形框左上角的坐標和矩形框的長寬會以數組的形式提供，數組第一個元素就是左上角的橫坐標值。

area是area of encoded masks，是標注區域的面積。如果是矩形框，那就是高乘寬；如果是polygon或者RLE，那就復雜點。

最后，annotation結構中的categories字段存儲的是當前對象所屬的category的id，以及所屬的supercategory的name。

下面是從instances_val2017.json文件中摘出的一個annotation的實例，這里的segmentation就是polygon格式：

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

polygon格式比較簡單，這些數按照相鄰的順序兩兩組成一個點的xy坐標，如果有n個數（必定是偶數），那么就是n/2個點坐標。下面就是一段解析polygon格式的segmentation并且顯示多邊形的示例代碼：

import numpy as np import matplotlib.pyplot as plt import matplotlib from matplotlib.patches import Polygon from matplotlib.collections import PatchCollection fig, ax = plt.subplots() polygons = [] num_sides = 100 gemfield_polygons = [[125.12, 539.69, 140.94, 522.43......]] gemfield_polygon = gemfield_polygons[0] max_value = max(gemfield_polygon) * 1.3 gemfield_polygon = [i * 1.0/max_value for i in gemfield_polygon] poly = np.array(gemfield_polygon).reshape((int(len(gemfield_polygon)/2), 2)) polygons.append(Polygon(poly,True)) p = PatchCollection(polygons, cmap=matplotlib.cm.jet, alpha=0.4) colors = 100*np.random.rand(1) p.set_array(np.array(colors))ax.add_collection(p) plt.show()

如果iscrowd=1，那么segmentation就是RLE格式(segmentation字段會含有counts和size數組)，在json文件中gemfield挑出一個這樣的例子，如下所示：

segmentation : {u'counts': [272, 2, 4, 4, 4, 4, 2, 9, 1, 2, 16, 43, 143, 24......], u'size': [240, 320] }

COCO數據集的RLE都是uncompressed RLE格式（與之相對的是compact RLE）。 RLE所占字節的大小和邊界上的像素數量是正相關的。RLE格式帶來的好處就是當基于RLE去計算目標區域的面積以及兩個目標之間的unoin和intersection時會非常有效率。 上面的segmentation中的counts數組和size數組共同組成了這幅圖片中的分割 mask。其中size是這幅圖片的寬高，然后在這幅圖像中，每一個像素點要么在被分割（標注）的目標區域中，要么在背景中。很明顯這是一個bool量：如果該像素在目標區域中為true那么在背景中就是False；如果該像素在目標區域中為1那么在背景中就是0。對于一個240x320的圖片來說，一共有76800個像素點，根據每一個像素點在不在目標區域中，我們就有了76800個bit，比如像這樣（隨便寫的例子，和上文的數組沒關系）：00000111100111110...；但是這樣寫很明顯浪費空間，我們直接寫上0或者1的個數不就行了嘛（Run-length encoding)，于是就成了54251...，這就是上文中的counts數組。下面這個python代碼片段直觀的顯示了這些bit：

rle = [272, 2, 4, 4, 4, 4, 2, 9, 1, 2, 16, 43, 143, 24, 5, 8......] assert sum(rle) == 240*320

也可以使用下面的代碼將這個rle數組表示的分割區域畫出來：

import numpy as np import matplotlib.pyplot as plt rle = [272, 2, 4, 4, 4, 4, 2, 9, 1, 2, 16, 43, 143, 24, 5, 8......] assert sum(rle) == 240*320 M = np.zeros(240*320) N = len(rle) n = 0 val = 1 for pos in range(N):val = not valfor c in range(rle[pos]):M[n] = valn += 1GEMFIELD = M.reshape(([240, 320]), order='F') plt.imshow(GEMFIELD) plt.show()

3，categories字段

categories是一個包含多個category實例的數組，而category結構體描述如下：

{"id": int,"name": str,"supercategory": str, }

從instances_val2017.json文件中摘出的2個category實例如下所示：

{"supercategory": "person","id": 1,"name": "person" }, {"supercategory": "vehicle","id": 2,"name": "bicycle" },

至2017年的時候，一共有80個category。

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." }

?

總結

以上是生活随笔為你收集整理的COCO数据格式说明的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。