简介面向计算机视觉与智能交通开发者的车辆再识别参考实现基于二〇一八年人工智能城市挑战赛第三赛道构建涵盖车辆检测、单摄像头跟踪与跨摄像头特征匹配的完整流程。系统利用卷积神经网络提取全局特征并借助自适应特征学习技术提升跨场景迁移能力便于直接部署或二次开发。压缩包共二百五十四个文件以Python脚本为主另有八十个YAML配置、十个Jupyter交互式笔记、九个Markdown说明及若干底层扩展模块整体仅五点一二MB目录结构清晰。目前已有二百二十七人浏览学习适合具备深度学习基础、希望研究多目标跟踪与车辆重识别的研究者。资源内附完整代码、配置说明与目录结构文档可快速搭建环境复现赛题流程并据此改进或移植至其他视觉任务。1. 多摄像头车辆检测、跟踪和再识别从单镜头MOT到跨镜头ID合并停车场的三个相机分别盯着入口、出口和弯道视野完全不重叠。单镜头跟踪MOT做得再好车辆一离开画面轨迹就断了第二次出现在另一个镜头里时系统只当它是新车。车流统计错、轨迹还原乱实际是“跨镜头身份合并”出了问题。这个问题拆开就是标题的三件事车辆检测负责扣出车单镜头跟踪负责维持镜头内的ID连续再识别ReID负责把不同相机的轨迹特征拿去做比较判断是不是同一台车。整条链路在Python里能完全落地下面按算法选型、代码骨架、跨镜头融合、指标验证四层讲清适合正在做车流统计、停车场管理或路侧感知数据处理的工程师。2. 系统骨架检测、单镜头跟踪与ReID特征在哪一层汇聚先想清楚数据流再想代码。常见做法是把系统拆成三条互不干扰的线每帧图像先经过车辆检测得到矩形框矩形框送入单镜头跟踪器维护每个镜头本地的临时ID与此同时每条轨迹片段tracklet定期提取一次ReID特征存入轨迹档案。跨摄像头匹配只发生在轨迹片段这一层不做逐帧全局匹配——逐帧算全局关联的计算量随相机数平方上涨而且噪声极大。单镜头跟踪器输出的是“镜头内身份”ReID输出的是“外观身份”。两者合并才得到全局身份全局ID 当地轨迹ID ReID特征。这个层级关系决定了系统里所有模块的职责边界也决定了代码目录该怎么划分。2.1 检测器选型YOLOv8或RT-DETR两阶段模型在这条链路上不划算车辆检测在整个链路里是单位算力需求最大的模块选型直接影响系统能同时跑几路视频。两阶段检测器在小目标上有精度优势但车辆属于中大型目标且监控相机通常架设位置固定、尺度变化有限把算力花在区域候选网络上不划算。YOLOv8这类单阶段模型在mAP相当的情况下推理延迟低了一个量级更适合“多摄像头”这个前提。如果目标场景是夜间或雨天建议把模型从n级升到s级甚至m级而不是换检测范式。YOLO家族对车辆类别的召回本来就足够好真正影响夜间表现的是数据增强策略与图像预处理比如自动白平衡和去雾。另一个需要提前决定的点是类别过滤COCO数据集中和车辆相关的类别是bicycle、car、motorbike、bus、truck在监控场景通常只用car、bus、truck过滤掉自行车的理由是它会让跟踪器产生大量短轨迹干扰ID分发。2.2 单镜头跟踪选型ByteTrack的简洁与BoT-SORT的补偿单镜头跟踪的标准骨架是卡尔曼滤波加匈牙利匹配。卡尔曼负责预测目标在当前帧的位置匈牙利负责把预测框和检测框做最优配对。ByteTrack的核心贡献在于它不丢弃低置信度检测框而是把它们放入第二次关联这对被遮挡的车辆非常有效——车辆互相遮挡时检测分数会明显下降直接过滤掉会让轨迹提前断掉。BoT-SORT则是在ByteTrack基础上加了相机运动补偿ECC和外观特征融合。固定机位的监控相机如果存在轻微晃动ECC能显著减少预测框漂移车辆这种刚体目标在高速运动时外观特征能帮忙纠正重合度不高的关联。实际使用中如果每个相机都固定在三脚架或立杆上我一般先跑ByteTrack画面有风摆或车辆速度很快时再切BoT-SORT。这两者的接口在Python生态里基本一致my迁移成本很低。下表是我做选型时的判据跟踪器运动模型外观特征最适用的场景新增算力开销ByteTrack卡尔曼滤波无相机固定、遮挡频繁的密集车流极低BoT-SORT卡尔曼滤波 ECCReID特征相机轻微晃动、车速快或出画频繁中DeepSORT卡尔曼滤波分类网络特征目标少、且已有人脸或车脸模型中2.3 再识别特征与整条链路的组织方式tracklet是核心对象系统里最重要的数据结构不是“帧”也不是“框”而是轨迹片段。轨迹片段是一辆车在单个相机里持续出现的完整生命周期进入画面、被跟踪、离开画面。这个生命周期结束后留下车辆类别、时间范围、轨迹点序列和一组ReID特征。跨摄像头合并时拿出来的就是这些特征向量。工程上我会把代码组织成四个目录detector/、tracker/、reid/、fusion/。检测和跟踪可以作为同一个处理单元跑在每个相机进程里ReID特征提取可以滞后一步不必每帧都做——通常轨迹每10帧或15帧采样一次特征取均值。这样一来每路相机只需要一个推理模型常驻显存多个相机共享同一份检测模型权重。下面这个配置文件定义了每路相机的处理参数是这套系统最基础的拼图camera: id: cam_p1 rtsp_url: rtsp://192.168.1.64/stream1 fps: 25 frame_interval: 1 detector: model_name: yolov8s.pt conf_thres: 0.25 iou_thres: 0.7 classes: [2, 5, 7] # car, bus, truck tracker: type: bytetrack track_buffer: 90 match_thresh: 0.9 reid: enabled: true feature_dim: 512 sample_interval: 10 queue_size: 5这里track_buffer控制车辆消失后轨迹保留多少帧90帧在25fps下相当于3.6秒。如果同一辆车在画面里停了很久或者出画后马上从另一侧返回来buffer太小会让轨迹断开但buffer太大又可能导致车辆重新出现时被旧轨迹抢先锁住。这个参数是整个系统里最容易调坏的一个后面会专门讲。3. 用ultralytics加filterpy在本地跑通单镜头车辆跟踪选型定了下一步是把检测器和跟踪器串起来。最直接的做法是用YOLO做检测把检测框交给跟踪器做关联。这里的核心代码不复杂但要理解每个参数在做什么。下面这份代码直接可以跑输入是一段视频输出是带跟踪ID的框。import cv2 from ultralytics import YOLO model YOLO(yolov8s.pt) cap cv2.VideoCapture(cam_p1.mp4) while cap.isOpened(): ok, frame cap.read() if not ok: break results model.track( frame, persistTrue, trackerbytetrack.yaml, classes[2, 5, 7], conf0.25, iou0.7, verboseFalse, ) if results[0].boxes.id is not None: boxes results[0].boxes.xyxy.cpu().numpy() ids results[0].boxes.id.cpu().numpy().astype(int) for box, tid in zip(boxes, ids): x1, y1, x2, y2 box.astype(int) cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.putText( frame, fid{tid}, (x1, y1 - 8), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 255, 0), 2, ) cv2.imshow(single-camera track, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release()代码里最重要的参数是persistTrue它让模型在跨帧时保留tracker的状态如果忘了这个参数每一帧都会重新初始化跟踪器所有ID都会闪烁。trackerbytetrack.yaml指定用ByteTrack配置ultralytics把卡尔曼滤波和匈牙利匹配都封装在内部Visual Studio Code里调试时可以跟着源码走一遍看它内部如何维护Track对象。如果你所在的环境不方便直接使用内置的tracker我一般会改用filterpy自建一个最小实现状态向量取[x, y, a, h, vx, vy, va, vh]观测向量取[x, y, a, h]用卡尔曼预测和更新。这个实现的核心是预测框和检测框的IOU损失矩阵再用scipy.optimize.linear_sum_assignment求解最优匹配。链路不长但自己维护时要注意卡尔曼滤波的Q和R矩阵要按像素尺度调不要用默认单位阵。跟踪ID在离开画面后并不会立刻释放。track_buffer90意味着车辆出画后系统还会用卡尔曼预测状态持续等待90帧。如果车辆在这段时间内重新入画且位置与预测位置接近跟踪器会继续沿用旧ID。这个机制对临时遮挡很有用但也埋了一个坑如果车辆绕到另一条车道再回来预测位置早就偏了却还占着旧ID。我遇到的实际问题是track_buffer开得越大跨镜头合并时越容易出现两个镜头同时持有同一辆车的情况。由于多摄像头场景里车辆出画时间通常超过几秒track_buffer不宜依赖默认值建议按下表调整参数默认值常见调整范围调整原因conf0.250.15~0.45雨天或夜间降低减少漏检iou0.70.5~0.8车辆密集时降低避免同一个框被强占track_buffer90帧30~150帧与相机覆盖范围相关覆盖小就调低classes[2,5,7]按场景增删不需要的类别会产生大量无效轨迹提示model.track的输出里id在每帧都可能消失车辆的检测框和跟踪ID不是严格一一对应的。写业务逻辑时务必先判断id is not None否则拿到None时直接索引会崩。4. 跨摄像头再识别特征提取、相似度矩阵与身份合并单镜头跟踪只能保证“在这个相机里是同一辆车”跨摄像头之后唯一持久的信息是车辆外观。再识别做的事情就是把外观压缩成一个固定长度的向量然后用向量距离判断是不是同一辆车。4.1 用ResNet50提取车辆embedding训练与推理两套流程训练和推理是两套完全不同的流程。推理阶段的模型不输出分类概率而是输出分类头前一层的特征向量。常见做法是加载一个预训练的ResNet50去掉最后的全连接层得到2048维特征再通过一个降维层压到512维。车辆ReID和行人ReID有一个显著差异车辆的同类外观极多黑色SUV在监控视频里长得几乎一样因此单靠全局特征很容易串线。实际系统里车身颜色和车型信息会作为额外的硬标签参与过滤特征向量只负责细粒度区分。俯瞰下面这段特征提取代码的关键逻辑import torch import torchvision.models as models from torchvision import transforms from PIL import Image class VehicleEmbedding(torch.nn.Module): def __init__(self): super().__init__() backbone models.resnet50(weightsmodels.ResNet50_Weights.IMAGENET1K_V1) self.features torch.nn.Sequential(*list(backbone.children())[:-1]) self.project torch.nn.Linear(2048, 512) def forward(self, x): x self.features(x) x torch.flatten(x, 1) x self.project(x) return torch.nn.functional.normalize(x, dim1) preprocess transforms.Compose([ transforms.Resize((256, 256)), transforms.CenterCrop(224), transforms.ToTensor(), transforms.Normalize( mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225], ), ]) def get_embedding(model, image_path): img Image.open(image_path).convert(RGB) inp preprocess(img).unsqueeze(0) with torch.no_grad(): emb model(inp) return emb[0].cpu().numpy()这段代码的关键点是最后一行做了L2归一化。归一化让向量之间的比较可以使用余弦相似度而且向量模长不再影响匹配结果这对不同曝光条件下的同一辆车非常关键。project层把特征压到512维不仅压缩了存储也一定程度上过滤掉对光照和角度过于敏感的分量。用ImageNet预训练权重直接提特征只能算一个可跑的baseline在真实监控数据上效果往往不够。如果条件允许用车辆ReID的公开数据集做微调。微调思路不复杂用“分类代理”训练一个能区分数千辆车ID的分类头训练时把最后一层分类头扔掉取前面的特征向量作为ReID特征。4.2 跨镜头匹配余弦相似度矩阵、贪心匹配与时空门控拿到特征向量之后跨镜头匹配就变成一个矩阵问题。假设相机A刚结束的轨迹有3条相机B有4条活跃轨迹先算出3x4的相似度矩阵再在这个矩阵上做最优分配。直接用scipy.optimize.linear_sum_assignment做全局最优匹配是很常见的选择。关键一点是不能只看余弦相似度。跨镜头匹配前必须先做时空门控两个相机如果覆盖的是同一路段的上下游车辆从A到B需要满足最短通行时间和最长等待时间两个相机如果覆盖完全不同的区域匹配直接禁止。车型也是一道强门控——卡车和轿车之间的余弦相似度可能意外地高但现实中它们不可能是同一辆车。一个简洁的匹配流程如下import numpy as np from scipy.optimize import linear_sum_assignment def match_tracklets(tracklets_a, tracklets_b, sim_thresh0.5): sim_mat np.zeros((len(tracklets_a), len(tracklets_b))) for i, ta in enumerate(tracklets_a): for j, tb in enumerate(tracklets_b): if not gate(ta, tb): # 时空门控时间差、区域可达性 sim_mat[i, j] -1.0 else: sim_mat[i, j] cosine_sim(ta.embedding, tb.embedding) cost 1.0 - sim_mat rows, cols linear_sum_assignment(cost) matches [] for i, j in zip(rows, cols): if sim_mat[i, j] sim_thresh: matches.append((i, j, sim_mat[i, j])) return matches def gate(ta, tb): dt tb.start_time - ta.end_time if dt ta.min_transit or dt ta.max_transit: return False if ta.vehicle_type ! tb.vehicle_type: return False return Truelinear_sum_assignment求的是全局代价最小但代价矩阵里已经塞入了不可达项设为-1对应代价2.0不可达的配对会被强制排除。sim_thresh决定了“最长见到的可能性”这个阈值一般取0.45到0.6之间。阈值调低召回率上升但会导致不同车辆被合并调高系统会倾向于把同一辆车当成两个不同身份。对比测试时从0.5起步看IDF1的变化再回调。另外一个比较隐蔽的问题是相机A的多条轨迹如何与相机B的多条轨迹对应。一个相机里同一辆车只会有一条轨迹但由于track_buffer的存在车辆出画后轨迹会延迟结束时可能导致同一个ID的轨迹被切割成两段。融合模块收到这种轨迹时要先做同镜头内的短轨迹合并再做跨镜头匹配否则会出现一辆车被匹配两次。4.3 多摄像头数据流每相机一个进程主进程汇合轨迹多摄像头系统的工程架构和单镜头有明显差别。单镜头可以完全串行地处理每一帧但多镜头场景会受限于最慢的那个相机因此我一般会为每个相机单独起一个进程进程内独立跑检测器和跟踪器。同一份检测模型权重可以通过共享显存加载但各进程持有各自的跟踪器状态彼此不共享内存。进程间通讯用Queue传递轨迹端点信息。一个相机进程在一条轨迹结束时把“轨迹ID、车辆类型、时间戳、筛选过的剪裁图、ReID特征”打包成一条消息发给融合进程。融合进程维护一个全局身份表负责把镜头内ID映射到全局ID。这里要注意的是检测模型所在的进程不能直接把原始视频帧发出去带宽和反序列化开销会让整个队列饱和。正确做法是仅在轨迹结束时发送特征和必要元数据不要把中间帧都发到主进程。from multiprocessing import Process, Queue def camera_worker(cam_cfg, out_queue): tracker init_tracker(cam_cfg) for frame in read_frames(cam_cfg): dets detector(frame) tracks tracker.update(dets) for t in tracks: if t.is_closed(): out_queue.put({ cam: cam_cfg[id], local_id: t.id, type: t.vehicle_type, start: t.start_time, end: t.end_time, embedding: t.embedding, }) def fusion_process(in_queue): global_ids {} while True: msg in_queue.get() gid assign_global_id(msg, global_ids) global_ids[msg[cam], msg[local_id]] gid摄像头数量增加时瓶颈会从算力转为融合进程的单点吞吐。常见做法是根据相机覆盖关系把系统划分为多个区域每个区域一个融合进程区域之间只在边界处交换轨迹。跨区域匹配失败的轨迹落到最后的全局表中做慢速关联每天或每小时跑一次批处理。这样在线系统保持低延迟离线清算兜底。4.4 相似度阈值和特征队列的配合跨镜头轨迹匹配比“两条完整轨迹之间比一次”更复杂。车辆在镜头B里可能只露了一两秒或者轨迹还没结束就需要和镜头A匹配。所以融合进程内部要为每个全局ID维护一个滑动窗口特征队列保存最近若干次更新的特征向量。每次新轨迹到来时用它和全局ID的队列均值做比较而不是和某个时刻的单帧特征比。特征队列的容量一般取3~5。容量太小对车辆角度变化过于敏感容量太大车辆转弯或光照变化时旧特征会拖低匹配准确率。更新方式用指数滑动平均的写法新特征权重取0.3~0.4让特征缓慢漂移。参数推荐范围作用sim_thresh0.45~0.6控制跨镜头匹配门槛时空门控时间差5~120秒依赖相机位置与车速特征队列容量3~5平衡角度变化与噪声特征更新权重0.3~0.4决定新旧特征的信任度提示特征写入前做一次车辆清晰度判断模糊帧的特征不要入队。一个简单判据是裁切图的方差小于阈值就丢弃避免出画时运动模糊污染队列。5. 验证与横向对比从MOTA、IDF1到跨镜头误匹配率系统改完了用指标说话。单镜头跟踪效果看MOTA跨镜头身份一致性看IDF1和ID Switch。如果你用ultralytics跑出跟踪结果已经可以直接计算这些指标不需要在跑的时候实时统计。def compute_idf1(gt_ids, pred_ids): tp sum(1 for g, p in zip(gt_ids, pred_ids) if g p) fp sum(1 for g, p in zip(gt_ids, pred_ids) if g is None and p is not None) fn sum(1 for g, p in zip(gt_ids, pred_ids) if g is not None and p is None) id_precision tp / (tp fp 1e-9) id_recall tp / (tp fn 1e-9) idf1 2 * id_precision * id_recall / (id_precision id_recall 1e-9) return idf1测试时最好故意挑一段“同色车流连续穿过两个视野”的视频集这种路段是最容易把不同车辆合并成同一辆的场景。跑完后统计误匹配发生在哪些时间段然后反查相似度矩阵看当时的余弦相似度到底有多高。如果两辆不同车的相似度超过0.6说明全局特征区分度不够此时别只调阈值先检查预处理是否统一了车辆裁切尺寸和光照。一个更快的验证技巧是只跑两个相机把其中一个相机的轨迹按时间倒序喂给匹配模块正确率应该大幅下降。如果倒序后匹配成功率仍然很高说明模型在靠车身颜色和类型做判断而不是在靠细粒度外观特征ReID模型的训练方向需要调整。货车和小客车占比不均的数据先后按车型硬过滤再算余弦相似度往往比无限调低阈值更快见效。本文还有配套的精品资源点击获取
多摄像头车辆检测、跟踪与跨镜头ReID身份合并实战
简介面向计算机视觉与智能交通开发者的车辆再识别参考实现基于二〇一八年人工智能城市挑战赛第三赛道构建涵盖车辆检测、单摄像头跟踪与跨摄像头特征匹配的完整流程。系统利用卷积神经网络提取全局特征并借助自适应特征学习技术提升跨场景迁移能力便于直接部署或二次开发。压缩包共二百五十四个文件以Python脚本为主另有八十个YAML配置、十个Jupyter交互式笔记、九个Markdown说明及若干底层扩展模块整体仅五点一二MB目录结构清晰。目前已有二百二十七人浏览学习适合具备深度学习基础、希望研究多目标跟踪与车辆重识别的研究者。资源内附完整代码、配置说明与目录结构文档可快速搭建环境复现赛题流程并据此改进或移植至其他视觉任务。1. 多摄像头车辆检测、跟踪和再识别从单镜头MOT到跨镜头ID合并停车场的三个相机分别盯着入口、出口和弯道视野完全不重叠。单镜头跟踪MOT做得再好车辆一离开画面轨迹就断了第二次出现在另一个镜头里时系统只当它是新车。车流统计错、轨迹还原乱实际是“跨镜头身份合并”出了问题。这个问题拆开就是标题的三件事车辆检测负责扣出车单镜头跟踪负责维持镜头内的ID连续再识别ReID负责把不同相机的轨迹特征拿去做比较判断是不是同一台车。整条链路在Python里能完全落地下面按算法选型、代码骨架、跨镜头融合、指标验证四层讲清适合正在做车流统计、停车场管理或路侧感知数据处理的工程师。2. 系统骨架检测、单镜头跟踪与ReID特征在哪一层汇聚先想清楚数据流再想代码。常见做法是把系统拆成三条互不干扰的线每帧图像先经过车辆检测得到矩形框矩形框送入单镜头跟踪器维护每个镜头本地的临时ID与此同时每条轨迹片段tracklet定期提取一次ReID特征存入轨迹档案。跨摄像头匹配只发生在轨迹片段这一层不做逐帧全局匹配——逐帧算全局关联的计算量随相机数平方上涨而且噪声极大。单镜头跟踪器输出的是“镜头内身份”ReID输出的是“外观身份”。两者合并才得到全局身份全局ID 当地轨迹ID ReID特征。这个层级关系决定了系统里所有模块的职责边界也决定了代码目录该怎么划分。2.1 检测器选型YOLOv8或RT-DETR两阶段模型在这条链路上不划算车辆检测在整个链路里是单位算力需求最大的模块选型直接影响系统能同时跑几路视频。两阶段检测器在小目标上有精度优势但车辆属于中大型目标且监控相机通常架设位置固定、尺度变化有限把算力花在区域候选网络上不划算。YOLOv8这类单阶段模型在mAP相当的情况下推理延迟低了一个量级更适合“多摄像头”这个前提。如果目标场景是夜间或雨天建议把模型从n级升到s级甚至m级而不是换检测范式。YOLO家族对车辆类别的召回本来就足够好真正影响夜间表现的是数据增强策略与图像预处理比如自动白平衡和去雾。另一个需要提前决定的点是类别过滤COCO数据集中和车辆相关的类别是bicycle、car、motorbike、bus、truck在监控场景通常只用car、bus、truck过滤掉自行车的理由是它会让跟踪器产生大量短轨迹干扰ID分发。2.2 单镜头跟踪选型ByteTrack的简洁与BoT-SORT的补偿单镜头跟踪的标准骨架是卡尔曼滤波加匈牙利匹配。卡尔曼负责预测目标在当前帧的位置匈牙利负责把预测框和检测框做最优配对。ByteTrack的核心贡献在于它不丢弃低置信度检测框而是把它们放入第二次关联这对被遮挡的车辆非常有效——车辆互相遮挡时检测分数会明显下降直接过滤掉会让轨迹提前断掉。BoT-SORT则是在ByteTrack基础上加了相机运动补偿ECC和外观特征融合。固定机位的监控相机如果存在轻微晃动ECC能显著减少预测框漂移车辆这种刚体目标在高速运动时外观特征能帮忙纠正重合度不高的关联。实际使用中如果每个相机都固定在三脚架或立杆上我一般先跑ByteTrack画面有风摆或车辆速度很快时再切BoT-SORT。这两者的接口在Python生态里基本一致my迁移成本很低。下表是我做选型时的判据跟踪器运动模型外观特征最适用的场景新增算力开销ByteTrack卡尔曼滤波无相机固定、遮挡频繁的密集车流极低BoT-SORT卡尔曼滤波 ECCReID特征相机轻微晃动、车速快或出画频繁中DeepSORT卡尔曼滤波分类网络特征目标少、且已有人脸或车脸模型中2.3 再识别特征与整条链路的组织方式tracklet是核心对象系统里最重要的数据结构不是“帧”也不是“框”而是轨迹片段。轨迹片段是一辆车在单个相机里持续出现的完整生命周期进入画面、被跟踪、离开画面。这个生命周期结束后留下车辆类别、时间范围、轨迹点序列和一组ReID特征。跨摄像头合并时拿出来的就是这些特征向量。工程上我会把代码组织成四个目录detector/、tracker/、reid/、fusion/。检测和跟踪可以作为同一个处理单元跑在每个相机进程里ReID特征提取可以滞后一步不必每帧都做——通常轨迹每10帧或15帧采样一次特征取均值。这样一来每路相机只需要一个推理模型常驻显存多个相机共享同一份检测模型权重。下面这个配置文件定义了每路相机的处理参数是这套系统最基础的拼图camera: id: cam_p1 rtsp_url: rtsp://192.168.1.64/stream1 fps: 25 frame_interval: 1 detector: model_name: yolov8s.pt conf_thres: 0.25 iou_thres: 0.7 classes: [2, 5, 7] # car, bus, truck tracker: type: bytetrack track_buffer: 90 match_thresh: 0.9 reid: enabled: true feature_dim: 512 sample_interval: 10 queue_size: 5这里track_buffer控制车辆消失后轨迹保留多少帧90帧在25fps下相当于3.6秒。如果同一辆车在画面里停了很久或者出画后马上从另一侧返回来buffer太小会让轨迹断开但buffer太大又可能导致车辆重新出现时被旧轨迹抢先锁住。这个参数是整个系统里最容易调坏的一个后面会专门讲。3. 用ultralytics加filterpy在本地跑通单镜头车辆跟踪选型定了下一步是把检测器和跟踪器串起来。最直接的做法是用YOLO做检测把检测框交给跟踪器做关联。这里的核心代码不复杂但要理解每个参数在做什么。下面这份代码直接可以跑输入是一段视频输出是带跟踪ID的框。import cv2 from ultralytics import YOLO model YOLO(yolov8s.pt) cap cv2.VideoCapture(cam_p1.mp4) while cap.isOpened(): ok, frame cap.read() if not ok: break results model.track( frame, persistTrue, trackerbytetrack.yaml, classes[2, 5, 7], conf0.25, iou0.7, verboseFalse, ) if results[0].boxes.id is not None: boxes results[0].boxes.xyxy.cpu().numpy() ids results[0].boxes.id.cpu().numpy().astype(int) for box, tid in zip(boxes, ids): x1, y1, x2, y2 box.astype(int) cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.putText( frame, fid{tid}, (x1, y1 - 8), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 255, 0), 2, ) cv2.imshow(single-camera track, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release()代码里最重要的参数是persistTrue它让模型在跨帧时保留tracker的状态如果忘了这个参数每一帧都会重新初始化跟踪器所有ID都会闪烁。trackerbytetrack.yaml指定用ByteTrack配置ultralytics把卡尔曼滤波和匈牙利匹配都封装在内部Visual Studio Code里调试时可以跟着源码走一遍看它内部如何维护Track对象。如果你所在的环境不方便直接使用内置的tracker我一般会改用filterpy自建一个最小实现状态向量取[x, y, a, h, vx, vy, va, vh]观测向量取[x, y, a, h]用卡尔曼预测和更新。这个实现的核心是预测框和检测框的IOU损失矩阵再用scipy.optimize.linear_sum_assignment求解最优匹配。链路不长但自己维护时要注意卡尔曼滤波的Q和R矩阵要按像素尺度调不要用默认单位阵。跟踪ID在离开画面后并不会立刻释放。track_buffer90意味着车辆出画后系统还会用卡尔曼预测状态持续等待90帧。如果车辆在这段时间内重新入画且位置与预测位置接近跟踪器会继续沿用旧ID。这个机制对临时遮挡很有用但也埋了一个坑如果车辆绕到另一条车道再回来预测位置早就偏了却还占着旧ID。我遇到的实际问题是track_buffer开得越大跨镜头合并时越容易出现两个镜头同时持有同一辆车的情况。由于多摄像头场景里车辆出画时间通常超过几秒track_buffer不宜依赖默认值建议按下表调整参数默认值常见调整范围调整原因conf0.250.15~0.45雨天或夜间降低减少漏检iou0.70.5~0.8车辆密集时降低避免同一个框被强占track_buffer90帧30~150帧与相机覆盖范围相关覆盖小就调低classes[2,5,7]按场景增删不需要的类别会产生大量无效轨迹提示model.track的输出里id在每帧都可能消失车辆的检测框和跟踪ID不是严格一一对应的。写业务逻辑时务必先判断id is not None否则拿到None时直接索引会崩。4. 跨摄像头再识别特征提取、相似度矩阵与身份合并单镜头跟踪只能保证“在这个相机里是同一辆车”跨摄像头之后唯一持久的信息是车辆外观。再识别做的事情就是把外观压缩成一个固定长度的向量然后用向量距离判断是不是同一辆车。4.1 用ResNet50提取车辆embedding训练与推理两套流程训练和推理是两套完全不同的流程。推理阶段的模型不输出分类概率而是输出分类头前一层的特征向量。常见做法是加载一个预训练的ResNet50去掉最后的全连接层得到2048维特征再通过一个降维层压到512维。车辆ReID和行人ReID有一个显著差异车辆的同类外观极多黑色SUV在监控视频里长得几乎一样因此单靠全局特征很容易串线。实际系统里车身颜色和车型信息会作为额外的硬标签参与过滤特征向量只负责细粒度区分。俯瞰下面这段特征提取代码的关键逻辑import torch import torchvision.models as models from torchvision import transforms from PIL import Image class VehicleEmbedding(torch.nn.Module): def __init__(self): super().__init__() backbone models.resnet50(weightsmodels.ResNet50_Weights.IMAGENET1K_V1) self.features torch.nn.Sequential(*list(backbone.children())[:-1]) self.project torch.nn.Linear(2048, 512) def forward(self, x): x self.features(x) x torch.flatten(x, 1) x self.project(x) return torch.nn.functional.normalize(x, dim1) preprocess transforms.Compose([ transforms.Resize((256, 256)), transforms.CenterCrop(224), transforms.ToTensor(), transforms.Normalize( mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225], ), ]) def get_embedding(model, image_path): img Image.open(image_path).convert(RGB) inp preprocess(img).unsqueeze(0) with torch.no_grad(): emb model(inp) return emb[0].cpu().numpy()这段代码的关键点是最后一行做了L2归一化。归一化让向量之间的比较可以使用余弦相似度而且向量模长不再影响匹配结果这对不同曝光条件下的同一辆车非常关键。project层把特征压到512维不仅压缩了存储也一定程度上过滤掉对光照和角度过于敏感的分量。用ImageNet预训练权重直接提特征只能算一个可跑的baseline在真实监控数据上效果往往不够。如果条件允许用车辆ReID的公开数据集做微调。微调思路不复杂用“分类代理”训练一个能区分数千辆车ID的分类头训练时把最后一层分类头扔掉取前面的特征向量作为ReID特征。4.2 跨镜头匹配余弦相似度矩阵、贪心匹配与时空门控拿到特征向量之后跨镜头匹配就变成一个矩阵问题。假设相机A刚结束的轨迹有3条相机B有4条活跃轨迹先算出3x4的相似度矩阵再在这个矩阵上做最优分配。直接用scipy.optimize.linear_sum_assignment做全局最优匹配是很常见的选择。关键一点是不能只看余弦相似度。跨镜头匹配前必须先做时空门控两个相机如果覆盖的是同一路段的上下游车辆从A到B需要满足最短通行时间和最长等待时间两个相机如果覆盖完全不同的区域匹配直接禁止。车型也是一道强门控——卡车和轿车之间的余弦相似度可能意外地高但现实中它们不可能是同一辆车。一个简洁的匹配流程如下import numpy as np from scipy.optimize import linear_sum_assignment def match_tracklets(tracklets_a, tracklets_b, sim_thresh0.5): sim_mat np.zeros((len(tracklets_a), len(tracklets_b))) for i, ta in enumerate(tracklets_a): for j, tb in enumerate(tracklets_b): if not gate(ta, tb): # 时空门控时间差、区域可达性 sim_mat[i, j] -1.0 else: sim_mat[i, j] cosine_sim(ta.embedding, tb.embedding) cost 1.0 - sim_mat rows, cols linear_sum_assignment(cost) matches [] for i, j in zip(rows, cols): if sim_mat[i, j] sim_thresh: matches.append((i, j, sim_mat[i, j])) return matches def gate(ta, tb): dt tb.start_time - ta.end_time if dt ta.min_transit or dt ta.max_transit: return False if ta.vehicle_type ! tb.vehicle_type: return False return Truelinear_sum_assignment求的是全局代价最小但代价矩阵里已经塞入了不可达项设为-1对应代价2.0不可达的配对会被强制排除。sim_thresh决定了“最长见到的可能性”这个阈值一般取0.45到0.6之间。阈值调低召回率上升但会导致不同车辆被合并调高系统会倾向于把同一辆车当成两个不同身份。对比测试时从0.5起步看IDF1的变化再回调。另外一个比较隐蔽的问题是相机A的多条轨迹如何与相机B的多条轨迹对应。一个相机里同一辆车只会有一条轨迹但由于track_buffer的存在车辆出画后轨迹会延迟结束时可能导致同一个ID的轨迹被切割成两段。融合模块收到这种轨迹时要先做同镜头内的短轨迹合并再做跨镜头匹配否则会出现一辆车被匹配两次。4.3 多摄像头数据流每相机一个进程主进程汇合轨迹多摄像头系统的工程架构和单镜头有明显差别。单镜头可以完全串行地处理每一帧但多镜头场景会受限于最慢的那个相机因此我一般会为每个相机单独起一个进程进程内独立跑检测器和跟踪器。同一份检测模型权重可以通过共享显存加载但各进程持有各自的跟踪器状态彼此不共享内存。进程间通讯用Queue传递轨迹端点信息。一个相机进程在一条轨迹结束时把“轨迹ID、车辆类型、时间戳、筛选过的剪裁图、ReID特征”打包成一条消息发给融合进程。融合进程维护一个全局身份表负责把镜头内ID映射到全局ID。这里要注意的是检测模型所在的进程不能直接把原始视频帧发出去带宽和反序列化开销会让整个队列饱和。正确做法是仅在轨迹结束时发送特征和必要元数据不要把中间帧都发到主进程。from multiprocessing import Process, Queue def camera_worker(cam_cfg, out_queue): tracker init_tracker(cam_cfg) for frame in read_frames(cam_cfg): dets detector(frame) tracks tracker.update(dets) for t in tracks: if t.is_closed(): out_queue.put({ cam: cam_cfg[id], local_id: t.id, type: t.vehicle_type, start: t.start_time, end: t.end_time, embedding: t.embedding, }) def fusion_process(in_queue): global_ids {} while True: msg in_queue.get() gid assign_global_id(msg, global_ids) global_ids[msg[cam], msg[local_id]] gid摄像头数量增加时瓶颈会从算力转为融合进程的单点吞吐。常见做法是根据相机覆盖关系把系统划分为多个区域每个区域一个融合进程区域之间只在边界处交换轨迹。跨区域匹配失败的轨迹落到最后的全局表中做慢速关联每天或每小时跑一次批处理。这样在线系统保持低延迟离线清算兜底。4.4 相似度阈值和特征队列的配合跨镜头轨迹匹配比“两条完整轨迹之间比一次”更复杂。车辆在镜头B里可能只露了一两秒或者轨迹还没结束就需要和镜头A匹配。所以融合进程内部要为每个全局ID维护一个滑动窗口特征队列保存最近若干次更新的特征向量。每次新轨迹到来时用它和全局ID的队列均值做比较而不是和某个时刻的单帧特征比。特征队列的容量一般取3~5。容量太小对车辆角度变化过于敏感容量太大车辆转弯或光照变化时旧特征会拖低匹配准确率。更新方式用指数滑动平均的写法新特征权重取0.3~0.4让特征缓慢漂移。参数推荐范围作用sim_thresh0.45~0.6控制跨镜头匹配门槛时空门控时间差5~120秒依赖相机位置与车速特征队列容量3~5平衡角度变化与噪声特征更新权重0.3~0.4决定新旧特征的信任度提示特征写入前做一次车辆清晰度判断模糊帧的特征不要入队。一个简单判据是裁切图的方差小于阈值就丢弃避免出画时运动模糊污染队列。5. 验证与横向对比从MOTA、IDF1到跨镜头误匹配率系统改完了用指标说话。单镜头跟踪效果看MOTA跨镜头身份一致性看IDF1和ID Switch。如果你用ultralytics跑出跟踪结果已经可以直接计算这些指标不需要在跑的时候实时统计。def compute_idf1(gt_ids, pred_ids): tp sum(1 for g, p in zip(gt_ids, pred_ids) if g p) fp sum(1 for g, p in zip(gt_ids, pred_ids) if g is None and p is not None) fn sum(1 for g, p in zip(gt_ids, pred_ids) if g is not None and p is None) id_precision tp / (tp fp 1e-9) id_recall tp / (tp fn 1e-9) idf1 2 * id_precision * id_recall / (id_precision id_recall 1e-9) return idf1测试时最好故意挑一段“同色车流连续穿过两个视野”的视频集这种路段是最容易把不同车辆合并成同一辆的场景。跑完后统计误匹配发生在哪些时间段然后反查相似度矩阵看当时的余弦相似度到底有多高。如果两辆不同车的相似度超过0.6说明全局特征区分度不够此时别只调阈值先检查预处理是否统一了车辆裁切尺寸和光照。一个更快的验证技巧是只跑两个相机把其中一个相机的轨迹按时间倒序喂给匹配模块正确率应该大幅下降。如果倒序后匹配成功率仍然很高说明模型在靠车身颜色和类型做判断而不是在靠细粒度外观特征ReID模型的训练方向需要调整。货车和小客车占比不均的数据先后按车型硬过滤再算余弦相似度往往比无限调低阈值更快见效。本文还有配套的精品资源点击获取
