简介这是一套面向计算机视觉与深度学习研究者的游泳溺水识别数据集包含9984张原始图片的COCO JSON格式标注平均识别率可达91.7%以上适用于目标检测、行为识别以及泳池安全监控等场景的模型训练与效果验证。数据集共2000个文件包括1998张JPEG图像和2个标注JSON文件压缩包大小约375MB。JPEG图像覆盖人物泳姿与溺水姿态的多视角样本JSON文件则提供标准化的边界框与类别标注便于直接接入主流检测框架使用。目前已有554人学习下载数据质量经过验证可帮助开发者节省数据清洗与标注时间快速构建高精度溺水预警模型。1. 泳池溺水识别数据集为什么值得把标注与训练链路吃透泳池边上坐着盯监控的救生员盯到第6个小时视线早就不聚焦了。视觉识别系统这时候能兜底——但前提是模型在真实场景里真能抓得住溺水瞬间而不是只在实验室视频里好看。这份「游泳溺水识别数据集9984张原始图片COCO JSON格式标注平均识别率91.7%以上」的标题核心价值就在数据端9984张图不算巨量但按COCO JSON统一标注后能直接喂给主流检测框架完成训练和迭代。标题里埋了三个关键信息标注格式是COCO JSON、识别率有明确数字91.7%以上、图片可视化已做博文里可直接查看。适合正在做智慧泳池、景区水域安全、或者想从通用目标检测转向细分场景的团队——新手可以照着这份数据集建立「标注工具→格式转换→模型训练→可视化验证」的完整闭环熟手则能直接复用COCO格式做增量优化和bad case挖掘。接下来的内容不聊概念只讲怎么做。2. 读懂COCO JSON标注格式9984张图要面对的五层结构和三个坑2.1 为什么选自选COCO JSON而不是YOLO txt或VOC XML做目标检测的数据集标注格式不外乎三种主流COCO JSON、YOLO txt、Pascal VOC XML。溺水识别这份数据集选择COCO JSON不是因为它最流行而是因为它在这个场景下最合适。COCO JSON是种结构化标注格式所有标注信息集中在一个JSON文件里通过不同的顶层字段组织图片信息、类别信息和标注信息。它的优势有三点。第一支持单张图片的多实例标注——泳池场景里经常一条画面同时出现多个游泳者其中一人可能正在溺水COCO的annotations数组天然支撑这种多目标场景而YOLO txt虽然有类似能力但每个目标的信息分散在独立txt文件里管理成本高。第二COCO格式对分割和关键点扩展性极好——如果后续要从检测升级到姿态估计或实例分割比如通过手臂摆动频率判断溺水风险COCO JSON可以平滑地加上segmentation或keypoints字段而YOLO格式要大规模改动。第三COCO生态的评估工具链是最成熟的pycocotools可以直接计算mAP、AR等指标。VOC XML的劣势则在于字段冗余度高且无法表达复杂结构。VOC用XML文件描述目标的bbox、类别和difficult属性即便一个目标没有segmentation也要写一堆标签。而COCO JSON里一个目标可能只对应一个字典字段精简清晰批量处理时内存占用也更可控。.**。但要注意训练时几乎所有的深度学习框架YOLO系列、Detectron2、MMDetection都能直接或间接支持COCO格式。YOLOv8官方支持COCO直接训练不强制要求转成YOLO txt后面会具体讲。2.2 annotations顶层字段逐个拆解顺便说清楚坐标坑在哪一份标准的COCO JSON标注文件顶层有五个必要字段info、licenses、images、annotations、categories。标题里9984张图对应的JSON文件结构长这样{ info: { description: swimming drowning detection dataset, version: 1.0, year: 2024 }, licenses: [ { id: 1, name: Attribution-NonCommercial } ], images: [ { id: 1, file_name: img_0001.jpg, width: 1920, height: 1080, license: 1, date_captured: 2024-06-01 10:00:00 } ], annotations: [ { id: 1, image_id: 1, category_id: 1, bbox: [520.5, 310.2, 180.3, 240.1], area: 180.3 * 240.1, iscrowd: 0, segmentation: [] } ], categories: [ { id: 1, name: drowning, supercategory: person } ] }.images里每个元素对应一张原始图file_name是图片相对路径width和height务必和图片实际尺寸一致——不一致时pycocotools会报错这是最常翻车的点。annotations里每个元素对应一个标注目标bbox格式是[x, y, width, height]其中x、y是左上角坐标单位是像素不是归一化值。从labelme、CVAT这些工具导出的标注往往自带归一化或相对坐标转换时如果忘记乘回图片宽高训练时坐标会乱飞。category_id从1开始不是0和YOLO类别下标从0开始不是一个习惯跨框架时极易错位。iscrowd这个字段在溺水识别场景里多数时候用不上但多人密集画面里比如泳池比赛如果一群人挤在一起成了无法分离的团块将它标记为1可以告诉评估器这块不需要精细匹配。segmentation字段未标注时留空数组不要填null否则部分框架读标注时直接抛异常。.categories字段决定了类别体系这份数据集至少包含两个类别正常游泳者swimmer和溺水者drowning如果细分还可以有无人empty。类别id在整个数据集里必须保持从1开始的递增整数中间不能跳号。注意检查标注JSON是否合法不要用眼睛硬看用pycocotools几行代码验证即可。from pycocotools.coco import COCO coco COCO(annotations/instances_train.json) print(fimages: {len(coco.imgs)}, annotations: {len(coco.anns)}, categories: {coco.cats})这段代码输出三个数值如果annotations数量和标注总量对不上一定是有图片漏标注或者JSON中途截断。pycocotools的loadRes方法还能在推理完成后直接跑评估是后续验证精度的核心工具。2.3 COCO JSON的类别统计与样本平衡先看清楚拿到了JSON第一件事不是急着训练而是先看类别分布。9984张图听起来不少但如果drowning类别只占5%那就是个标准的长尾问题。import json from collections import Counter with open(annotations/instances_train.json) as f: coco json.load(f) cat_names {c[id]: c[name] for c in coco[categories]} cat_counter Counter() img_counter Counter() for ann in coco[annotations]: cat_counter[cat_names[ann[category_id]]] 1 img_counter[cat_names[ann[category_id]]] img_counter.get(cat_names[ann[category_id]], 0) 1 # 一张图同时有正常和溺水目标img_counter不重复计数 print(目标总数:, dict(cat_counter)) print(涉及图片数:, dict(img_counter))打印出来的目标总数能直接告诉你类别平衡度。如果drowning的目标数不足swimmer的十分之一训练时就需要做类别重采样或加loss权重——这个细节在第四章展开。同时这个统计结果也是后续给甲方或团队汇报时的基础数据别跳过去。3. 从原始图片到COCO JSONCVAT标注与批量转换的完整流程3.1 标注工具选型CVAT、Label Studio还是labelme9984张原始图片做人工标注工具选错了效率差几倍。单人本地做小批量labelme最轻量安装即用画框后每张图产出独立JSON团队协作则优先CVAT或Label Studio两者都支持多人在线标注、任务分配和审核流程。CVAT的优势是自动标注插件丰富——先用检测模型做预标注人工修正能把标注效率拉高两到三倍Label Studio则胜在数据管理界面直观且支持从已有标注里检索bad case方便后期清洗。我的建议是如果这份数据集是你一个人维护labelme足够如果团队有两三个标注员同时干活直接上CVAT。原因在于溺水识别场景存在大量模糊边界帧——一个游泳者已经呛水但还在挣扎这算不算drowning多人协作的项目里这种歧义需要review机制兜底单机的labelme没有任务分配概念做不了这件事。CVAT导出的标注格式原生支持COCO JSON 1.0省去二次转换的麻烦。3.2 类别定义与标注规范drowning的边界到底是什么标注规范直接决定数据集质量进而决定91.7%这个数字是否可信。以下是习惯用的一套规范读者可直接抄走改造。类别判定标准框选范围swimmer正常游泳姿态舒展或踩水头部在水面上全身含手臂划水展开范围drowning挣扎、呛水、下沉趋势、垂直漂浮不动、头部频繁没入水面全身即使部分身体被水遮挡也要框出完整预测范围empty画面中无人员不标注表格里最关键的是drowning的两个特征判定头部反复没入水面或者身体垂直悬浮不动。这两个特征是溺水识别和普通人检测的最大区别——普通检测模型会把「垂直踩水的人」识别成正常游泳者而这份数据集的标注规范里踩水超过30秒就该框成drowning。框选的实际经验是溺水者的手臂动作幅度大且不协调bbox要留出边缘余量把挥舞手臂的位置带进去否则模型学到的目标轮廓是不完整的。注意标注「空镜帧」和「无人画面」不要标也不要删除。保留原图并空置annotations让模型学到「没人」这一类负样本对减少误报有奇效。标注时的双人复核规则每人标注完一批后由另一个人按5%~10%比例抽样复核框坐标偏差超过10像素或类别判定不一致则这一批全部返工。因为数据集的指标口径依赖标注一致性单人标注的主观漂移往往会在后期训练时暴露为成片的漏检。3.3 labelme转COCO JSON5960张的转换脚本与四个参数陷阱如果用的是labelme每张图会有一个同名的JSON文件。转换到COCO JSON需要一个脚本网上流传的版本很多但多数没处理坐标和类别映射的边界情况。这段是实测可用的核心逻辑import json import glob import os labelme_files glob.glob(labelme_jsons/*.json) coco_images [] coco_annotations [] coco_categories [{id: 1, name: swimmer, supercategory: person}, {id: 2, name: drowning, supercategory: person}] ann_id 1 for img_id, lm_file in enumerate(labelme_files, start1): with open(lm_file) as f: lm json.load(f) img_w, img_h lm[imageWidth], lm[imageHeight] file_name os.path.basename(lm[imagePath]) coco_images.append({ id: img_id, file_name: file_name, width: img_w, height: img_h }) for shape in lm[shapes]: label shape[label] if label not in [swimmer, drowning]: continue points shape[points] xs [p[0] for p in points] ys [p[1] for p in points] x_min, y_min, w, h min(xs), min(ys), max(xs) - min(xs), max(ys) - min(ys) # 坐标落在画布外裁剪回合法范围 if x_min 0 or y_min 0 or x_min w img_w or y_min h img_h: x_min max(0, x_min) y_min max(0, y_min) w min(w, img_w - x_min) h min(h, img_h - y_min) category_id 1 if label swimmer else 2 coco_annotations.append({ id: ann_id, image_id: img_id, category_id: category_id, bbox: [round(x_min, 2), round(y_min, 2), round(w, 2), round(h, 2)], area: round(w * h, 2), iscrowd: 0, segmentation: [] }) ann_id 1 coco_json { images: coco_images, annotations: coco_annotations, categories: coco_categories } with open(instances_train.json, w) as f: json.dump(coco_json, f)逻辑说明labelme的points存的是多边形顶点坐标即使用矩形框标注points里也是两个对角坐标因此代码里先拆出所有x和y再取最小值和差值算出bbox避免直接取points[0]导致框倾斜或反向。坐标裁剪那步是血泪经验——标注时鼠标拖出画布边缘是常事如果不在转出阶段钳制坐标训练resize时会出现负坐标或超界框pycocotools评估时把这些框直接忽略指标崩塌但肉眼看不到报错。round(..., 2)保留两位小数COCO官方允许浮点坐标但训练时大多数框架会转成整数提前round掉减少后续不确定性。这里的标注数据是segmentation: []意味着这份数据集只做检测不做分割。如果后续要升级实例分割需要回到labelme保留多边形坐标而不是只用bbox。那意味着标注工作量要翻倍所以一开始就确定好几类任务边界避免返工。3.4 CVAT导出COCO时要注意的导出选项用CVAT标注的团队导出COCO JSON时界面里有几个选项容易踩坑。导出格式选择“COCO JSON 1.0”不要选“COCO JSON 1.0 with points”——后者会多出keypoints字段初始化检测模型时部分框架按类别解析字段会错乱。导出范围选择“全部任务”还是“当前任务”取决于你的项目结构。但最隐蔽的坑是「分组模式」CVAT默认按track分组视频标注时同一个目标跨帧会被合并成同一个annotation id但检测任务标注的是一张张静态图应该选“不使用分组”否则转换结果里annotation id会大量缺失评估时pycocotools统计的检测目标数会少于实际标注数。导出后同样跑一遍上一节的验证代码确认image数量和annotation数量对得上再进入训练环节。别省这一步。4. 用这份数据集训练检测模型YOLOv8训练自己的数据识别率91.7%是怎么来的4.1 数据划分是先决条件按场景分组而不是随机打散标注完成后的第一件事不是训练而是划分train/val/test。很多团队随手shuffle一下按比例切分结果训练集和验证集里出现了同一视频源的连续帧——模型在train里见过几乎相同的画面val的mAP虚高真正的评估指标全面失真。溺水识别数据集如果来自几个固定泳池的监控视频这种情况几乎无法避免。正确做法是按「视频片段」或「拍摄场景」分组再划分数据。拿9984张图来说假设来自30段不同场景的视频先把30个场景随机分成train 22个、val 4个、test 4个场景再从每个场景内抽帧构成数据集。这样训练集和验证集之间是「不同时间、不同角度」的画面而不是「同一秒的相邻帧」。划分代码不复杂但直接影响91.7%这个数字有多少水分。import random from collections import defaultdict # 每张图片记录所属场景形如 {img_0001.jpg: scene_01} img_scene {} # 从你的数据表里加载 scene_groups defaultdict(list) for img, scene in img_scene.items(): scene_groups[scene].append(img) scenes list(scene_groups.keys()) random.seed(42) random.shuffle(scenes) train_scenes scenes[:22] val_scenes scenes[22:26] test_scenes scenes[26:] train_imgs [img for s in train_scenes for img in scene_groups[s]] val_imgs [img for s in val_scenes for img in scene_groups[s]] test_imgs [img for s in test_scenes for img in scene_groups[s]]逻辑说明random.seed(42)保证每次运行划分结果一致便于复现场景维度划分保证同一场景的帧不会被拆散到train和val。实际划分比例按场景数调整不按图片数——因为同一个场景内的帧高度相似按图数比例切分等于变相放大了相似帧的权重。划分完成后把train/val/test的image_id集合分别提取出来从COCO JSON里筛出各自的images和annotations生成三个JSON文件instances_train.json、instances_val.json、instances_test.json。直接用原始大JSON训练会让val场景泄漏到train环境。4.2 YOLOv8在自己的COCO数据上训练命令只有十几行数据就绪后训练直接用ultralytics库。YOLOv8原生支持COCO JSON格式的数据集只要准备一个YAML配置文件指向JSON路径即可。# drowning.yaml path: /data/drowning_dataset train: instances_train.json val: instances_val.json test: instances_test.json names: 1: swimmer 2: drowning注意names的索引从1开始和COCO的category_id保持一致。这里用YAML顶层字段train/val/test直接指向COCO JSON文件。names这个字段YOLOv8要求从0开始还是1开始实测中YOLOv8的YAML里names是一个有序列表索引对应模型的类别输出层idx它期望的索引是0、1、2而不是1、2。所以更保险的做法是names: 0: swimmer 1: drowning这带来的直接后果是模型输出的类别0对应泳池里的swimmerCOCO category_id1类别1对应drowningCOCO category_id2。ultralytics内部在加载COCO格式时会把category_id减一映射到模型类别索引所以这样写才是对的。地图上反过来写会报标签索引越界。yolo train modelyolov8m.pt datadrowning.yaml epochs200 imgsz1280 batch16 lr00.01训练启动后观察loss曲线是否稳定下降。imgsz1280不是随手定的——泳池监控画面里人物占比普遍偏小一个溺水者可能在1080P画面里只有100像素高缩到640会让目标小到无法分辨。1280和640相比训练时间增加约两倍但检测率提升十分明显。推理端如果实时性要求高可以在训练后用imgsz1280的权重做export时再调低分辨率训练和部署分开设值。怀疑这个方向也可以考虑一步方案如果项目周期紧优先用yolov8x而不是yolov8m识别率能多出2%左右代价是训练和推理速度变慢。当前算力允许的前提下模型选型不要先压缩。4.3 类别极端不平衡时必调的三个参数从2.3的统计能看到drowning目标数大概率远少于swimmer如果不做任何处理模型会把所有目标都预测成swimmer整体准确率依然很高但drowning类几乎全漏。三个参数可以压制这个倾向。第一个是loss权重。YOLOv8命令行不直接暴露分类loss权重但可以在训练脚本里修改loss_cls系数或换用带cls权重的配置。常见做法是正样本加权drowning类的分类loss乘2~5倍。第二个是数据增强的mosaic。增加mosaic1.0默认开启让模型在同一张训练图里看到多个场景的随机拼接天然放大小样本类的出现频率。第三个是close_mosaic设置——最后10个epoch关闭mosaic增强让模型在正常分布上微调收敛这个小技巧能在不明显掉点的情况下稳定最终mAP。from ultralytics import YOLO model YOLO(yolov8m.pt) results model.train( datadrowning.yaml, epochs200, imgsz1280, batch16, lr00.01, mosaic1.0, close_mosaic10, seed42 )这里mosaic1.0是增强强度开关的下限实测溺水识别场景不需要上采样复制drowning样本——mosaic已经足够。如果drowning目标占比低于2%则应考虑补充采集数据单纯调参救不回来。还有一个细节seed42别省训练的可复现性靠它。别人复现你的91.7%用的也是同一个seed下的权重不写seed的话每次结果漂移指标没法对齐。4.4 91.7%到底是哪个口径mAP0.5和mAP0.5:0.95的巨大差异看到标题里「平均识别率91.7%以上」从业者第一反应是先确认这个数字的口径。检测任务里「识别率」可能是分类准确率、带IOU阈值的精确率、或综合mAP。泳池场景有大量小目标和遮挡mAP0.5:0.95严格口径走到80%已经不错而mAP0.5宽松口径超过90%很常见。两者差距能到15个百分点左右。验证报告里如果只写「平均识别率91.7%」大概率用的是mAP0.5。这个数字没有假只是不全面。自己训练时评估两方面指标都要看但对外说话时先声明口径。from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) metrics model.val(datadrowning.yaml, imgsz1280) print(fmAP0.5: {metrics.box.map50:.4f}) print(fmAP0.5:0.95: {metrics.box.map:.4f})metrics.box.map50就是mAP0.5metrics.box.map是严格版的mAP0.5:0.95。两个都要记录。如果map低于0.5而map50超过0.9说明模型框的位置不够准但类别判断基本正确——对溺水救援场景来说这不是能用「准确率很高」带过的。框的位置偏了半个身位救援定位就错了。5. 标注、转换、训练避坑指南5个让人翻车的现场记录5.1 转换脚本跑通后训练时bbox坐标乱飞现象确认标注和转换后的COCO JSON都正常但训练前数据检查发现边框跑出画面、尺寸忽大忽小。原因labelme的坐标在部分版本里做了归一化存储或者转换脚本把相对坐标当成了绝对坐标。还有一种情况是CVAT导出时选了「相对坐标」选项。解决转换后在pycocotools里随机抽10张画出边界框叠加在原图上肉眼确认左上角和右下角位置是否与目标贴合。这个步骤放在训练前才值得花这十分钟。检查代码如下import json import cv2 from pycocotools import mask as mask_utils with open(instances_train.json) as f: coco json.load(f) for i in range(10): img_info coco[images][i] img cv2.imread(fimages/{img_info[file_name]}) anns [a for a in coco[annotations] if a[image_id] img_info[id]] for ann in anns: x, y, w, h [int(v) for v in ann[bbox]] cv2.rectangle(img, (x, y), (x w, y h), (0, 255, 0), 2) cv2.imwrite(fcheck_{i}.jpg, img)这个脚本跑完检查产出的check_0.jpg到check_9.jpg。如果框的位置整体偏移但尺寸正常是坐标原点不同COCO用左上角有的工具用中心点如果框比目标大一圈或小一圈是标注习惯问题需要回炉改规范。5.2 mAP0.5虚高mAP0.5:0.95腰斩博文里的91.7%不能直接对标现象自己的模型mAP0.5达到92%但mAP0.5:0.95只有55%看起来像bug。原因这是小目标数据集的典型表现。泳池画面宽旷人物占整图比例小IOU计算对框的偏移极其敏感。检测框稍微偏离真实位置几个像素mAP0.5:0.95就断崖式下跌。解决先确认不是坐标换算错误确认后针对小目标提升有两条路第一条是提高imgsz到1536或更大第二条是开启YOLOv8的safer增强或手动放大小目标样本的裁剪。实测中imgsz1536比imgsz1280在strict指标上高出3~5个百分点但显存占用接近翻倍。另外如果评估指标用的是metrics.box.map50报告中明确写出这是宽松口径避免团队内外对数字的理解产生分歧——这属于项目管理层面的避坑。5.3 训练集和验证集数据「泄漏」指标好得不敢信现象训练时val loss很低mAP超高交付demo演示几乎完美但换一个泳池的视频检测效果立刻拉垮。原因数据划分用了随机切分同一段监控视频前后几帧被分到了train和val。模型等于「见过」验证画面。场景覆盖不足泛化能力是虚假的。解决按4.1的场景分组重新划分。划分后看val的mAP是否明显下降下降5~10个点是正常的如果下降超过15个点说明原指标水分很大训练轮数要适当增加且数据采集要补充新场景——只调参数没有出路。5.4 标注框习惯性收窄模型学不到完整目标轮廓现象推理结果里溺水者的框只框住了上半身下半身被切出画面外且漏检集中在姿态不舒展的目标上。原因标注员看到水面反光导致下半身轮廓模糊习惯性地只标注清晰可见的上半身。这导致模型头重脚轻地学习了目标的「可见部分」而不是「完整对象」。解决标注规范强制要求即使肢体被水遮挡或在水面以下不可见也要根据上下文推断并框选完整范围。这块需要在标注任务发布时用3~5个示例图明确演示并由复核人在返工单里持续抽查。数据集质量决定模型上限标注规范这里省下的功夫后面会在bad case里成倍找回来。5.5 JSON文件体积过大训练dataloader卡死或内存溢出现象训练时每个epoch开始前都要等几分钟有时直接OOM单个JSON文件超过1GB。原因9984张图的标注加若干空镜帧如果segmentation没有留空polygon坐标会占用大量空间。部分转换脚本把segmentation字段做成了逐像素掩码体积爆炸。解决检测任务直接在转换脚本里把segmentation设为[]文件体积能缩小70%。同时JSON文件用半精度浮点round两位存储pycocotools读取后转成float不影响训练。如果数据集后续要扩展到数万张建议把COCO JSON拆成train/val/test三个文件训练时只读当前需要的部分避免重复加载和解析。6. 最后一道质检可视化验证与bad case驱动标注迭代6.1 把预测结果和真值叠在同一张图上训练结束第一件事不是看指标是看可视化。随机抽取100张验证集图片每张图预测把预测框和标注框同时画在同一张图上预测框用红色真值框用绿色视觉差异一目了然。import cv2 from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) results model.predict(sourceval_images, imgsz1280, show_labelsFalse, saveTrue)saveTrue后预测图里只有红色框还需要叠加绿色真值框做对比。上面的命令只是第一步真正的对比是把每张图读取出来用OpenCV的rectangle手动画上两组框再拼图输出。红色多出来的是误检绿色多出来的是漏检。这一步能看到90%的问题也是标题里「图片可查看博文」这种呈现方式的核心价值——数据集的真实面貌光看JSON或指标数字看不出门道。6.2 bad case归类方法漏检看起来只是一张张散图但归好类会发现规律。把bad case按三个维度切片维度分组典型failure光照室内顺光 / 逆光 / 夜间红外逆光时全部漏检目标尺寸人物高200px / 100~200px / 100px小目标几乎全漏遮挡无遮挡 / 局部水花遮挡 / 多人遮挡水花遮挡误检为drowning按上面表格打标签后统计各分组的漏检率。如果某个分组的漏检率显著高于均值对应的不是一个参数问题而是数据缺口。比如100px的小目标全漏说明采集时这类样本占比过低需要补采或从已有视频里多抽帧比如夜间红外全部漏检说明训练数据里夜间图像占比太小或标注规范里没有区分白天/夜间的判定标准。6.3 循环补标与权重更新bad case归类完成后选择漏检最集中的50~100张图人工补标后加入训练集重训。重训后的指标对比不建议只看mAP而是看bad case分组的漏检率变化——有时候mAP没涨但逆光组的漏检率从80%降到30%这是实质进步。做三轮这样的闭环迭代比盲目调到1500个epoch有效得多。最后说一个习惯每次训练结束后我只在训练日志里记录两个数字——mAP0.5:0.95和最难分组按6.2的表格的漏检率。前一个验证整体精度后一个验证这个模型在真实部署时「能用」的程度。识别率91.7%是一个值得参考的基准线但真正决定你是否该把系统交给救生员用的是最后一个数字。希望这份把从COCO JSON标注到可视化闭环的完整路径能帮你少走几段弯路。本文还有配套的精品资源点击获取
