天天看點
傳回

COCO資料格式說明

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（看圖說話）這種類型的步驟如下：

COCO資料格式說明

（AMT上COCO标注步驟）

COCO通過大量使用Amazon Mechanical Turk來收集資料。COCO資料集現在有3種标注類型：object instances（目标執行個體）, object keypoints（目标上的關鍵點）, 和image captions（看圖說話），使用JSON檔案存儲。比如下面就是Gemfield下載下傳的COCO 2017年訓練集中的标注檔案：

COCO資料格式說明

可以看到其中有上面所述的三種類型，每種類型又包含了訓練和驗證，是以共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 val
    for c in range(rle[pos]):
        M[n] = val
        n += 1

GEMFIELD = 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{
    "id": int,
    "image_id": int,
    "caption": str
}      
{
  "image_id": 179765,
  "id": 38,"caption": "A black Honda motorcycle parked in front of a garage."
}
COCO資料标注 COCO格式 COCO資料格式 labelme轉換COCO json
上一篇: 資料倉庫 資料湖 資料流 - 朋友，敵人，亦敵亦友？
下一篇: 微信公衆平台測試号

繼續閱讀