尧图网站开发 
简介一套面向2018 AI City Challenge Track 3的端到端多摄像头车辆检测、跟踪与重识别系统采用Python实现适合计算机视觉研究者、自动驾驶从业者及车辆ReID方向学习者。系统将输入视频依次经过车辆提议、单摄像头跟踪、多摄像头特征匹配三个阶段利用自适应特征学习技术提升跨摄像头下的身份匹配精度该思路亦可迁移至其他视觉重识别场景。资源共254个文件涵盖Python核心脚本、YAML参数配置、Jupyter演示及Markdown说明等压缩包约5.12MB目录结构清晰便于按模块查阅。目前已有227人学习包内含完整实现代码与README文档可帮助读者理解多摄像头车辆ReID的工程化落地方法。1. 多摄像头车辆检测、跟踪和再识别系统卡点不在检测而在“认人”一个老问题的真实版本车从 1 号相机画面消失4 秒后出现在 2 号相机画面里单镜头跟踪给它的局部 ID 是 7跨镜之后变成 38。这不是检测漏了而是两个摄像头之间的身份没有衔接上。这个标题里的系统就是把三件事串成一条流水线检测负责找车跟踪负责在同一镜头里维持 ID再识别ReID负责在不同镜头里认出同一个目标。它解决的是智慧交通、园区安防、高速收费站里最实际的“这辆车到底是谁”。这套系统的难点不在单独某个模型跑得准不准而在工程侧怎么把多路视频、多个局部 ID、一个全局身份库正确地拼起来。调度顺序、特征存储、匹配时机任何一环乱了都会导致同一辆车在系统里被当成三辆车。适合手里已经会跑 YOLO、想往多相机方向深入的人看下文会给你一套能落地的 Python 实现路径和调参方法。2. 系统架构和数据流把局部跟踪和全局身份解耦多摄像头系统最容易犯的错误是“一步到位”想用一个模型同时输出所有相机的目标 ID。实际写代码时你会发现检测框在两路视频里根本没有可比性同一个目标在 A 相机的框只是车头在 B 相机里可能只有车位直接把框拉出来做匹配特征全被背景污染。所以主流做法是分层解耦每个摄像头独立跑检测和单目标跟踪这一步解决“同一时刻是哪辆车”的局部问题然后单独抽一辆车的深度特征再做跨镜头的全局匹配这一步解决“不同镜头里是不是同一辆车”的全局问题。这样做的好处是模块可替换检测器换版本、跟踪器换算法、ReID 模型升级互不影响。2.1 为什么必须先做局部跟踪再做跨镜融合想象一条 600 米长的路口8 路相机、每路画面里同时有 20 辆车。如果直接做全局匹配就是把 8 路的 160 个检测框两两算相似度再在 160×160 的矩阵里求解分配问题每帧都要做一次 $O(n^2)$ 的特征比对。这还没算重算特征带来的 GPU 开销。先做局部跟踪之后每路相机对同一辆车只保留一条轨迹全局匹配的单位从“检测框”变成“轨迹片段”。20 辆车压缩成一条轨迹8 路就是 8 条轨迹匹配矩阵从 160×160 变成 8×8。工程上的说法是检测器每帧跑跟踪器降频跑ReID 特征只在轨迹结束或被遮挡时算一次整体开销能降一个数量级。另外局部跟踪还有一个作用纠正单帧检测的抖动。车辆检测偶尔会漏一帧、跳一帧叠加卡尔曼滤波目标跟踪的预测逻辑后轨迹框的位置更平滑抽出来的 ReID 特征也更稳。2.2 数据流向检测框、轨迹、特征三路并行整个系统我一般分成四个模块解码器、检测器、局部跟踪器、全局 ReID 融合。它们之间的数据流有明确的方向不能回环。模块输入输出触发频率视频解码相机 RTSP/USB 流RGB 帧 时间戳25 fps目标检测单帧图像目标框 类别 置信度每帧局部跟踪检测框序列局部轨迹 ID 平滑框每帧或隔帧ReID 特征目标裁剪图特征向量256/512 维轨迹结束时或每 N 帧全局融合特征向量 相机拓扑全局车辆 ID轨迹结束时注意“时间戳”这一列。多路相机采集到的帧不是同一时刻的A 相机第 100 帧和 B 相机第 98 帧可能才是同一物理时间。所以代码里所有数据结构都要带camera_id和frame_time两个字段后续做时空关联时这是消除误匹配的关键。2.3 组件选型检测、跟踪、ReID 怎么搭配不踩坑检测部分不用多说YOLOv8 或 YOLOX 是当前主流车辆类 COCO 里就是 car、bus、truck 三个类。关键是跟踪器的选择。我踩过一遍后的结论是车辆遮挡严重的路口优先 ByteTrack 或 BoT-SORT而不是 DeepSORT。DeepSORT 的外观特征在遮挡恢复后会主导 ID 分配但车辆侧面和车尾差异极大外观分支经常把同一辆车判成两辆。ByteTrack 靠运动信息和 IOU 匹配ID 切换率更低。BoT-SORT 在工业侧常见 C 部署版本Python 端编译成 so 后回调特征如果不想维护 C 代码ByteTrack 的 Python 版本同样能出效果代价是 ID 切换率略高一点点。ReID 模型的选择看你的算力。GPU 机子上用 OSNet 或 ResNet50 微调边缘盒子用 MobileNet 蒸馏版本。特征维度不用贪大512 维足够关键在训练数据的域差异——拿公开数据集训的模型到现场会打折扣落地时要用现场相机抽 1-2 万张图做微调这个投入比换更大的 Backbone 值。3. 用 Python 实现车辆检测和单摄像头跟踪下载下来的这类 Python 代码包结构基本是固定的先看目录再跑别上来就python main.py。我见过的多摄像头车辆检测跟踪项目里典型目录是这样project/ ├── configs/ # yaml 配置相机地址、模型路径、阈值 ├── detectors/ # 检测器封装基于 ultralytics 或 mmdet ├── trackers/ # ByteTrack/BoT-SORT 的 python 封装 ├── reid/ # 特征提取(全局特征库) ├── utils/ # 可视化、日志、坐标转换 ├── main.py # 多线程串联入口 └── requirements.txt注意main.py通常只负责编排模型路径和相机参数都在configs里。拿到代码先打开配置文件把model_path改成你机器上实际的权重路径把camera_list改成你自己的 RTSP 地址然后再跑。3.1 车辆检测模块只留车辆类我一般用 ultralytics 的 YOLOv8n 模型做轻量验证代码里不砍掉其他类别只做过滤方便调试时输出原始检测结果。import cv2 from ultralytics import YOLO # 加载检测模型权重文件会在首次运行时下载到本地 model YOLO(yolov8n.pt) # COCO 数据集中车辆相关的类别 id VEHICLE_CLASSES {2: car, 5: bus, 7: truck} def detect_vehicles(frame, conf_thres0.35): results model(frame, verboseFalse)[0] dets [] for box in results.boxes: cls_id int(box.cls[0]) if cls_id not in VEHICLE_CLASSES: continue conf float(box.conf[0]) if conf conf_thres: continue # 输出坐标统一为 [x1, y1, x2, y2] x1, y1, x2, y2 [float(v) for v in box.xyxy[0]] dets.append([x1, y1, x2, y2, conf, cls_id]) return dets该段代码做了两件事从模型输出里过滤掉非车辆类别再对置信度做一次硬过滤低于 0.35 的检测框直接丢弃减少后续跟踪器的噪音输入。参数方面conf_thres是第一个可调旋钮——场景简单、相机固定时调到 0.25 能多召回一些远处小车城市复杂路口建议 0.4 起步防止路灯、树影被当成车辆。3.2 单摄像头跟踪IOU 匹配加轨迹管理完整引入 ByteTrack 会让代码变长而且版本差异大。我一般先写一个 30 行的 IOU Tracker 做数据流自测确认检测、采集链路没问题后再替换成 ByteTrack。这个最小实现能帮你搞懂跟踪器的核心逻辑后面调 ByteTrack 参数也有感觉。import numpy as np from scipy.optimize import linear_sum_assignment class IOUTracker: def __init__(self, iou_threshold0.3, max_lost5): self.tracks [] # 活跃轨迹列表 self.next_id 1 self.iou_threshold iou_threshold self.max_lost max_lost # 轨迹丢失多少帧后删除 staticmethod def compute_iou(a, b): xx1 max(a[0], b[0]); yy1 max(a[1], b[1]) xx2 min(a[2], b[2]); yy2 min(a[3], b[3]) inter max(0, xx2 - xx1) * max(0, yy2 - yy1) area_a (a[2] - a[0]) * (a[3] - a[1]) area_b (b[2] - b[0]) * (b[3] - b[1]) return inter / (area_a area_b - inter 1e-6) def update(self, detections): # 预测这里真实项目应加卡尔曼滤波做位置外推IOU 匹配仅在相邻帧位移小时有效 matched {} if self.tracks and detections: cost np.array([[1 - self.compute_iou(t[box], d) for d in detections] for t in self.tracks]) rows, cols linear_sum_assignment(cost) for r, c in zip(rows, cols): if cost[r, c] 1 - self.iou_threshold: matched[r] c updated_tracks [] for r, trk in enumerate(self.tracks): if r in matched: trk[box] detections[matched[r]] trk[lost] 0 trk[hits] 1 updated_tracks.append(trk) else: trk[lost] 1 if trk[lost] self.max_lost: updated_tracks.append(trk) # 未被匹配的检测框作为新轨迹 used_cols set(matched.values()) for c, det in enumerate(detections): if c not in used_cols: updated_tracks.append({ id: self.next_id, box: det, lost: 0, hits: 1 }) self.next_id 1 self.tracks updated_tracks return [(t[id], t[box]) for t in self.tracks if t[hits] 1]逻辑说明先用匈牙利匹配在“上一帧轨迹”和“当前帧检测框”之间做全局最优配对配对代价是1 - IOU只有当代价小于阈值时才承认匹配没匹配上的轨迹进入lost状态连续丢失 5 帧直接删除检测框没匹配到任何轨迹就生成新 ID。linear_sum_assignment一次性给全局最优解比贪心匹配稳定很多。实际项目里IOU 匹配扛不住车辆快速变道因为两帧间框的重叠率会骤降这时轨迹会到处乱跳。所以我上面的注释里特意标注了“应加卡尔曼滤波做位置外推”——这就是热词里常说的“卡尔曼滤波目标跟踪”的用途预测上一帧轨迹在本帧的位置让匹配更稳。特征点跟踪的方案我一般不用车辆外形相似、摄像头视角变化大特征点跨镜即失效。3.3 多路视频并发线程加队列解耦多摄像头的数据流不能用for cap in caps: cap.read()串行读一路卡住全链路阻塞。常见做法是每路一个采集线程把帧放进队列检测主线程消费。队列设小一点比如 60存太多会导致处理完的帧已经过期。import threading import queue def capture_worker(camera_id, rtsp_url, frame_queue): cap cv2.VideoCapture(rtsp_url) while True: ret, frame cap.read() if not ret: # 重连机制rtsp 流断线后自动重试 cap.open(rtsp_url) continue if frame_queue.qsize() 60: try: frame_queue.get_nowait() except queue.Empty: pass frame_queue.put((camera_id, frame)) queues {} for cam_id, url in camera_config.items(): q queue.Queue(maxsize60) queues[cam_id] q t threading.Thread(targetcapture_worker, args(cam_id, url, q), daemonTrue) t.start()这段代码的核心是丢帧策略队列满时直接丢最旧的帧保证处理的永远是最新画面避免延迟累积。线程是常见的简化写法实际 CPU 密集的检测不适合多线程应该用多进程每个进程负责一路相机线程方案适合先验证连通性。3.4 调参顺序和推荐范围跟踪系统的参数是联动的不要单独调一个。我按下面的顺序调参数作用推荐初始值调整信号conf_thres检测置信度阈值0.35漏检多就降误检多就升iou_thresholdIOU 匹配阈值0.3ID 切换多就降到 0.2max_lost轨迹最大丢失帧数5车辆经常被遮挡就升到 10特征提取间隔ReID 抽帧间隔轨迹结束时抽 1 次长期遮挡要每 15 帧抽一次队列大小帧缓冲60内存占用高就降我的经验是先用默认参数把整条链路跑通再盯住一辆车看它的局部 ID 在哪一帧切换那个节点对应的就是某一项参数的选择问题。只看整体准确率没法定位问题一定要可视化。4. 跨摄像头车辆再识别 ReID 与全局 ID 分配局部跟踪给每个相机里的车一个内部 ID但这些 ID 互不相认。跨镜头的核心任务变成了给我一个裁剪好的车辆图我判断它和库里的哪辆全局车是同一个目标。这也是 ReID 这个术语的完整含义Re-Identification再识别。ReID 难在域差异。同一辆车A 相机是俯视车顶B 相机是平视车头颜色、形状、光照完全不同。所以 ReID 模型不能当作分类任务来训要当作度量学习任务来训——让同一辆车不同镜头的特征距离近不同车的特征距离远这一点决定了后面特征匹配时的距离阈值设计。4.1 特征提取从简单基线到深度学习特征没有 GPU 的时候先上一个颜色直方图基线能帮你验证整个全局匹配链路是不是通的import cv2 import numpy as np def feature_by_hist(crop_img, bins32): # 统一尺寸后再提取颜色特征降低分辨率对结果的影响 crop cv2.resize(crop_img, (128, 256)) hsv cv2.cvtColor(crop, cv2.COLOR_BGR2HSV) feats [] for i in range(3): hist cv2.calcHist([hsv], [i], None, [bins], [0, 256]) # 归一化以抵抗光照强度差异 hist cv2.normalize(hist, hist).flatten() feats.append(hist) return np.concatenate(feats)这段代码提取 HSV 三个通道的颜色直方图拼接后作为特征向量。HSV 颜色空间把色调和亮度分开比直接 RGB 直方图对光照更鲁棒但注意它完全没有形状信息。这个基线在单一场景下的效果是能用的跨场景换了个停车场就废了。实际系统的特征提取我建议用 torchvision 的 MobileNet 做 Backbone只保留 Global Average Pooling 之前的卷积层输出 1280 维特征再接一个全连接压缩到 512 维import torch import torchvision.transforms as T from torchvision import models class ReidExtractor: def __init__(self, weights_path, devicecuda): backbone models.mobilenet_v2(pretrainedFalse) backbone.classifier torch.nn.Identity() self.backbone backbone.to(device).eval() self.backbone.load_state_dict(torch.load(weights_path, map_locationdevice)) self.transform T.Compose([ T.ToPILImage(), T.Resize((128, 256)), T.ToTensor(), T.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]) ]) self.device device def extract(self, crop_bgr): crop_rgb cv2.cvtColor(crop_bgr, cv2.COLOR_BGR2RGB) tensor self.transform(crop_rgb).unsqueeze(0).to(self.device) with torch.no_grad(): feat self.backbone(tensor) # L2 归一化让特征只保留方向信息便于计算余弦相似度 return torch.nn.functional.normalize(feat).cpu().numpy().flatten()模型输出前做 L2 归一化这个操作很关键。归一化后两个特征的相似度可以用向量点积直接算也就是余弦相似度取值范围变成 [-1, 1]阈值语义变得统一。weights_path就是你在训练集上用度量学习训出来的 checkpoint不要试图用 ImageNet 预训练权重直接上线分类模型和度量模型的特征分布不一致匹配阈值没法调。4.2 特征匹配用相机拓扑消掉不可能的组合有了特征直接全局匹配还不够。两个相机如果物理位置隔了 5 公里车辆绝不可能在 5 秒内同时出现这种匹配应该直接排除。相机拓扑就是一张“相机之间可达时间”的表例如transit_time[cam_a][cam_b] 8表示从 A 到 B 最少需要 8 秒。匹配时两条轨迹的时间差小于 8 秒的直接不参与计算。给一个完整的最小匹配流程import numpy as np from scipy.optimize import linear_sum_assignment def match_global(candidate_feats, gallery_feats, transit_mask, sim_threshold0.6): # candidate: 待匹配的轨迹特征; gallery: 全局特征库 sims candidate_feats gallery_feats.T # 余弦相似度矩阵 # 用相机拓扑掩码过滤transit_mask 为 False 表示相机间不可达 sims[~transit_mask] -1.0 cost 1 - sims rows, cols linear_sum_assignment(cost) matched_global_id {} for r, c in zip(rows, cols): if sims[r, c] sim_threshold: matched_global_id[r] c # c 就是全局车辆 ID return matched_global_id代码里sims[~transit_mask] -1.0这行是核心把不可达相机组合的相似度压到最低匈牙利算法就不会选它们。sim_threshold是第二个核心参数它决定了“宁可漏配也不误配”还是反过来。智慧交通业务里误配的代价远高于漏配因为一次误配会污染全局 ID 的后续所有轨迹所以我一般把阈值放在 0.6 到 0.7 之间。4.3 全局特征库的更新不存旧账全局特征库不能无限增长。每小时有 1000 辆车经过每个全局 ID 存最近 5 条轨迹的特征库容也就是 5000 个向量512 维 float32 是 10MB没问题。但如果你把一个月前的特征都留在库里指识别结果会乱跳目标车辆颜色磨损、光照季节变化旧特征会和新特征打架。我通常给每个全局 ID 维护一个候选池保留最近 N 次出现的特征匹配时取池子和当前特征的最大相似度。新轨迹匹配成功后把新特征加入池子池子超过 5 条就淘汰最旧的。这会带来一个问题如果某辆车被误配过一次误配特征成了池子里的“种子”之后每次出现都容易继续误配给同一个全局 ID。解决办法是异常检测池子里相似度最高和次高的值相差不大时这条匹配标记为可疑送人工确认队列。5. 落到工程用可视化脚本验证 ID 切换率全局系统配完后不要只看最终准确率报告你要先做日志可视化。每产生一条跨镜头匹配就把帧号、相机 ID、全局 ID、相似度落一行到日志里。日志格式建议用 CSV至少 6 列字段含义frame_no全局帧计数camera_id相机编号local_id局部跟踪 IDglobal_id全局分配 IDsimilarity匹配相似度match_typenew/update/reid有了这份日志写一个脚本统计 IDSW全局 ID 切换次数这是比 MOTA 更重要的多摄像头指标。MOTA 衡量的是单帧检测和关联的总体误差但在跨镜场景下一次 ID 切换影响后续所有帧IDSW 能直接反映 ReID 和全局分配的好坏。import pandas as pd df pd.read_csv(global_log.csv) # 按全局 ID 分组检查同一个人是否反复在不同相机间出现且 ID 变化 df_sorted df.sort_values([global_id, frame_no]) id_switch_count [] for gid, group in df_sorted.groupby(global_id): cam_change group[camera_id].diff().ne(0).sum() id_switch_count.append((gid, cam_change)) print(全局 ID 切换次数:, sum(cnt for _, cnt in id_switch_count))这段代码统计每个全局 ID 切换相机的次数相机切换并不等于 ID 切换因为同一辆车可以合法地从一个相机去另一个相机但如果切换相机的同时local_id顺序对不上就要去查匹配日志里的similarity是不是低于阈值了。更直接的验证是可视化把同一全局 ID 在不同相机下的截图拼成九宫格人眼快速判断是不是同一辆车。最后说三个我踩过的坑都在配置层代码层反而不容易出问题。第一个是时间戳不同步多相机一定要用 PTP 或 NTP 统一时钟否则两条轨迹的时间差算错跨镜头的拓扑约束全失效。第二个是 ReID 特征更新的频率轨迹在相机 A 停留了 3 分钟特征抽每一帧和只抽最后一帧效果差很多车辆转弯过程中外观变化大建议每隔 15 帧抽一次入池时取平均。第三个是阈值联动检测置信度从 0.35 降到 0.25 时低质量检测框变多跟踪器喂进来的裁剪图模糊ReID 特征质量跟着下降——这时候不要把 ReID 相似度阈值也调低而是把检测阈值拉回去或者给特征提取加一个最小尺寸过滤小于 32×32 的裁剪图直接跳过匹配。把匹配阈值从 0.6 往上提宁可漏配也不误配全局准确性比召回率重要。本文还有配套的精品资源点击获取 
简介一套面向2018 AI City Challenge Track 3的端到端多摄像头车辆检测、跟踪与重识别系统采用Python实现适合计算机视觉研究者、自动驾驶从业者及车辆ReID方向学习者。系统将输入视频依次经过车辆提议、单摄像头跟踪、多摄像头特征匹配三个阶段利用自适应特征学习技术提升跨摄像头下的身份匹配精度该思路亦可迁移至其他视觉重识别场景。资源共254个文件涵盖Python核心脚本、YAML参数配置、Jupyter演示及Markdown说明等压缩包约5.12MB目录结构清晰便于按模块查阅。目前已有227人学习包内含完整实现代码与README文档可帮助读者理解多摄像头车辆ReID的工程化落地方法。1. 多摄像头车辆检测、跟踪和再识别系统卡点不在检测而在“认人”一个老问题的真实版本车从 1 号相机画面消失4 秒后出现在 2 号相机画面里单镜头跟踪给它的局部 ID 是 7跨镜之后变成 38。这不是检测漏了而是两个摄像头之间的身份没有衔接上。这个标题里的系统就是把三件事串成一条流水线检测负责找车跟踪负责在同一镜头里维持 ID再识别ReID负责在不同镜头里认出同一个目标。它解决的是智慧交通、园区安防、高速收费站里最实际的“这辆车到底是谁”。这套系统的难点不在单独某个模型跑得准不准而在工程侧怎么把多路视频、多个局部 ID、一个全局身份库正确地拼起来。调度顺序、特征存储、匹配时机任何一环乱了都会导致同一辆车在系统里被当成三辆车。适合手里已经会跑 YOLO、想往多相机方向深入的人看下文会给你一套能落地的 Python 实现路径和调参方法。2. 系统架构和数据流把局部跟踪和全局身份解耦多摄像头系统最容易犯的错误是“一步到位”想用一个模型同时输出所有相机的目标 ID。实际写代码时你会发现检测框在两路视频里根本没有可比性同一个目标在 A 相机的框只是车头在 B 相机里可能只有车位直接把框拉出来做匹配特征全被背景污染。所以主流做法是分层解耦每个摄像头独立跑检测和单目标跟踪这一步解决“同一时刻是哪辆车”的局部问题然后单独抽一辆车的深度特征再做跨镜头的全局匹配这一步解决“不同镜头里是不是同一辆车”的全局问题。这样做的好处是模块可替换检测器换版本、跟踪器换算法、ReID 模型升级互不影响。2.1 为什么必须先做局部跟踪再做跨镜融合想象一条 600 米长的路口8 路相机、每路画面里同时有 20 辆车。如果直接做全局匹配就是把 8 路的 160 个检测框两两算相似度再在 160×160 的矩阵里求解分配问题每帧都要做一次 $O(n^2)$ 的特征比对。这还没算重算特征带来的 GPU 开销。先做局部跟踪之后每路相机对同一辆车只保留一条轨迹全局匹配的单位从“检测框”变成“轨迹片段”。20 辆车压缩成一条轨迹8 路就是 8 条轨迹匹配矩阵从 160×160 变成 8×8。工程上的说法是检测器每帧跑跟踪器降频跑ReID 特征只在轨迹结束或被遮挡时算一次整体开销能降一个数量级。另外局部跟踪还有一个作用纠正单帧检测的抖动。车辆检测偶尔会漏一帧、跳一帧叠加卡尔曼滤波目标跟踪的预测逻辑后轨迹框的位置更平滑抽出来的 ReID 特征也更稳。2.2 数据流向检测框、轨迹、特征三路并行整个系统我一般分成四个模块解码器、检测器、局部跟踪器、全局 ReID 融合。它们之间的数据流有明确的方向不能回环。模块输入输出触发频率视频解码相机 RTSP/USB 流RGB 帧 时间戳25 fps目标检测单帧图像目标框 类别 置信度每帧局部跟踪检测框序列局部轨迹 ID 平滑框每帧或隔帧ReID 特征目标裁剪图特征向量256/512 维轨迹结束时或每 N 帧全局融合特征向量 相机拓扑全局车辆 ID轨迹结束时注意“时间戳”这一列。多路相机采集到的帧不是同一时刻的A 相机第 100 帧和 B 相机第 98 帧可能才是同一物理时间。所以代码里所有数据结构都要带camera_id和frame_time两个字段后续做时空关联时这是消除误匹配的关键。2.3 组件选型检测、跟踪、ReID 怎么搭配不踩坑检测部分不用多说YOLOv8 或 YOLOX 是当前主流车辆类 COCO 里就是 car、bus、truck 三个类。关键是跟踪器的选择。我踩过一遍后的结论是车辆遮挡严重的路口优先 ByteTrack 或 BoT-SORT而不是 DeepSORT。DeepSORT 的外观特征在遮挡恢复后会主导 ID 分配但车辆侧面和车尾差异极大外观分支经常把同一辆车判成两辆。ByteTrack 靠运动信息和 IOU 匹配ID 切换率更低。BoT-SORT 在工业侧常见 C 部署版本Python 端编译成 so 后回调特征如果不想维护 C 代码ByteTrack 的 Python 版本同样能出效果代价是 ID 切换率略高一点点。ReID 模型的选择看你的算力。GPU 机子上用 OSNet 或 ResNet50 微调边缘盒子用 MobileNet 蒸馏版本。特征维度不用贪大512 维足够关键在训练数据的域差异——拿公开数据集训的模型到现场会打折扣落地时要用现场相机抽 1-2 万张图做微调这个投入比换更大的 Backbone 值。3. 用 Python 实现车辆检测和单摄像头跟踪下载下来的这类 Python 代码包结构基本是固定的先看目录再跑别上来就python main.py。我见过的多摄像头车辆检测跟踪项目里典型目录是这样project/ ├── configs/ # yaml 配置相机地址、模型路径、阈值 ├── detectors/ # 检测器封装基于 ultralytics 或 mmdet ├── trackers/ # ByteTrack/BoT-SORT 的 python 封装 ├── reid/ # 特征提取(全局特征库) ├── utils/ # 可视化、日志、坐标转换 ├── main.py # 多线程串联入口 └── requirements.txt注意main.py通常只负责编排模型路径和相机参数都在configs里。拿到代码先打开配置文件把model_path改成你机器上实际的权重路径把camera_list改成你自己的 RTSP 地址然后再跑。3.1 车辆检测模块只留车辆类我一般用 ultralytics 的 YOLOv8n 模型做轻量验证代码里不砍掉其他类别只做过滤方便调试时输出原始检测结果。import cv2 from ultralytics import YOLO # 加载检测模型权重文件会在首次运行时下载到本地 model YOLO(yolov8n.pt) # COCO 数据集中车辆相关的类别 id VEHICLE_CLASSES {2: car, 5: bus, 7: truck} def detect_vehicles(frame, conf_thres0.35): results model(frame, verboseFalse)[0] dets [] for box in results.boxes: cls_id int(box.cls[0]) if cls_id not in VEHICLE_CLASSES: continue conf float(box.conf[0]) if conf conf_thres: continue # 输出坐标统一为 [x1, y1, x2, y2] x1, y1, x2, y2 [float(v) for v in box.xyxy[0]] dets.append([x1, y1, x2, y2, conf, cls_id]) return dets该段代码做了两件事从模型输出里过滤掉非车辆类别再对置信度做一次硬过滤低于 0.35 的检测框直接丢弃减少后续跟踪器的噪音输入。参数方面conf_thres是第一个可调旋钮——场景简单、相机固定时调到 0.25 能多召回一些远处小车城市复杂路口建议 0.4 起步防止路灯、树影被当成车辆。3.2 单摄像头跟踪IOU 匹配加轨迹管理完整引入 ByteTrack 会让代码变长而且版本差异大。我一般先写一个 30 行的 IOU Tracker 做数据流自测确认检测、采集链路没问题后再替换成 ByteTrack。这个最小实现能帮你搞懂跟踪器的核心逻辑后面调 ByteTrack 参数也有感觉。import numpy as np from scipy.optimize import linear_sum_assignment class IOUTracker: def __init__(self, iou_threshold0.3, max_lost5): self.tracks [] # 活跃轨迹列表 self.next_id 1 self.iou_threshold iou_threshold self.max_lost max_lost # 轨迹丢失多少帧后删除 staticmethod def compute_iou(a, b): xx1 max(a[0], b[0]); yy1 max(a[1], b[1]) xx2 min(a[2], b[2]); yy2 min(a[3], b[3]) inter max(0, xx2 - xx1) * max(0, yy2 - yy1) area_a (a[2] - a[0]) * (a[3] - a[1]) area_b (b[2] - b[0]) * (b[3] - b[1]) return inter / (area_a area_b - inter 1e-6) def update(self, detections): # 预测这里真实项目应加卡尔曼滤波做位置外推IOU 匹配仅在相邻帧位移小时有效 matched {} if self.tracks and detections: cost np.array([[1 - self.compute_iou(t[box], d) for d in detections] for t in self.tracks]) rows, cols linear_sum_assignment(cost) for r, c in zip(rows, cols): if cost[r, c] 1 - self.iou_threshold: matched[r] c updated_tracks [] for r, trk in enumerate(self.tracks): if r in matched: trk[box] detections[matched[r]] trk[lost] 0 trk[hits] 1 updated_tracks.append(trk) else: trk[lost] 1 if trk[lost] self.max_lost: updated_tracks.append(trk) # 未被匹配的检测框作为新轨迹 used_cols set(matched.values()) for c, det in enumerate(detections): if c not in used_cols: updated_tracks.append({ id: self.next_id, box: det, lost: 0, hits: 1 }) self.next_id 1 self.tracks updated_tracks return [(t[id], t[box]) for t in self.tracks if t[hits] 1]逻辑说明先用匈牙利匹配在“上一帧轨迹”和“当前帧检测框”之间做全局最优配对配对代价是1 - IOU只有当代价小于阈值时才承认匹配没匹配上的轨迹进入lost状态连续丢失 5 帧直接删除检测框没匹配到任何轨迹就生成新 ID。linear_sum_assignment一次性给全局最优解比贪心匹配稳定很多。实际项目里IOU 匹配扛不住车辆快速变道因为两帧间框的重叠率会骤降这时轨迹会到处乱跳。所以我上面的注释里特意标注了“应加卡尔曼滤波做位置外推”——这就是热词里常说的“卡尔曼滤波目标跟踪”的用途预测上一帧轨迹在本帧的位置让匹配更稳。特征点跟踪的方案我一般不用车辆外形相似、摄像头视角变化大特征点跨镜即失效。3.3 多路视频并发线程加队列解耦多摄像头的数据流不能用for cap in caps: cap.read()串行读一路卡住全链路阻塞。常见做法是每路一个采集线程把帧放进队列检测主线程消费。队列设小一点比如 60存太多会导致处理完的帧已经过期。import threading import queue def capture_worker(camera_id, rtsp_url, frame_queue): cap cv2.VideoCapture(rtsp_url) while True: ret, frame cap.read() if not ret: # 重连机制rtsp 流断线后自动重试 cap.open(rtsp_url) continue if frame_queue.qsize() 60: try: frame_queue.get_nowait() except queue.Empty: pass frame_queue.put((camera_id, frame)) queues {} for cam_id, url in camera_config.items(): q queue.Queue(maxsize60) queues[cam_id] q t threading.Thread(targetcapture_worker, args(cam_id, url, q), daemonTrue) t.start()这段代码的核心是丢帧策略队列满时直接丢最旧的帧保证处理的永远是最新画面避免延迟累积。线程是常见的简化写法实际 CPU 密集的检测不适合多线程应该用多进程每个进程负责一路相机线程方案适合先验证连通性。3.4 调参顺序和推荐范围跟踪系统的参数是联动的不要单独调一个。我按下面的顺序调参数作用推荐初始值调整信号conf_thres检测置信度阈值0.35漏检多就降误检多就升iou_thresholdIOU 匹配阈值0.3ID 切换多就降到 0.2max_lost轨迹最大丢失帧数5车辆经常被遮挡就升到 10特征提取间隔ReID 抽帧间隔轨迹结束时抽 1 次长期遮挡要每 15 帧抽一次队列大小帧缓冲60内存占用高就降我的经验是先用默认参数把整条链路跑通再盯住一辆车看它的局部 ID 在哪一帧切换那个节点对应的就是某一项参数的选择问题。只看整体准确率没法定位问题一定要可视化。4. 跨摄像头车辆再识别 ReID 与全局 ID 分配局部跟踪给每个相机里的车一个内部 ID但这些 ID 互不相认。跨镜头的核心任务变成了给我一个裁剪好的车辆图我判断它和库里的哪辆全局车是同一个目标。这也是 ReID 这个术语的完整含义Re-Identification再识别。ReID 难在域差异。同一辆车A 相机是俯视车顶B 相机是平视车头颜色、形状、光照完全不同。所以 ReID 模型不能当作分类任务来训要当作度量学习任务来训——让同一辆车不同镜头的特征距离近不同车的特征距离远这一点决定了后面特征匹配时的距离阈值设计。4.1 特征提取从简单基线到深度学习特征没有 GPU 的时候先上一个颜色直方图基线能帮你验证整个全局匹配链路是不是通的import cv2 import numpy as np def feature_by_hist(crop_img, bins32): # 统一尺寸后再提取颜色特征降低分辨率对结果的影响 crop cv2.resize(crop_img, (128, 256)) hsv cv2.cvtColor(crop, cv2.COLOR_BGR2HSV) feats [] for i in range(3): hist cv2.calcHist([hsv], [i], None, [bins], [0, 256]) # 归一化以抵抗光照强度差异 hist cv2.normalize(hist, hist).flatten() feats.append(hist) return np.concatenate(feats)这段代码提取 HSV 三个通道的颜色直方图拼接后作为特征向量。HSV 颜色空间把色调和亮度分开比直接 RGB 直方图对光照更鲁棒但注意它完全没有形状信息。这个基线在单一场景下的效果是能用的跨场景换了个停车场就废了。实际系统的特征提取我建议用 torchvision 的 MobileNet 做 Backbone只保留 Global Average Pooling 之前的卷积层输出 1280 维特征再接一个全连接压缩到 512 维import torch import torchvision.transforms as T from torchvision import models class ReidExtractor: def __init__(self, weights_path, devicecuda): backbone models.mobilenet_v2(pretrainedFalse) backbone.classifier torch.nn.Identity() self.backbone backbone.to(device).eval() self.backbone.load_state_dict(torch.load(weights_path, map_locationdevice)) self.transform T.Compose([ T.ToPILImage(), T.Resize((128, 256)), T.ToTensor(), T.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]) ]) self.device device def extract(self, crop_bgr): crop_rgb cv2.cvtColor(crop_bgr, cv2.COLOR_BGR2RGB) tensor self.transform(crop_rgb).unsqueeze(0).to(self.device) with torch.no_grad(): feat self.backbone(tensor) # L2 归一化让特征只保留方向信息便于计算余弦相似度 return torch.nn.functional.normalize(feat).cpu().numpy().flatten()模型输出前做 L2 归一化这个操作很关键。归一化后两个特征的相似度可以用向量点积直接算也就是余弦相似度取值范围变成 [-1, 1]阈值语义变得统一。weights_path就是你在训练集上用度量学习训出来的 checkpoint不要试图用 ImageNet 预训练权重直接上线分类模型和度量模型的特征分布不一致匹配阈值没法调。4.2 特征匹配用相机拓扑消掉不可能的组合有了特征直接全局匹配还不够。两个相机如果物理位置隔了 5 公里车辆绝不可能在 5 秒内同时出现这种匹配应该直接排除。相机拓扑就是一张“相机之间可达时间”的表例如transit_time[cam_a][cam_b] 8表示从 A 到 B 最少需要 8 秒。匹配时两条轨迹的时间差小于 8 秒的直接不参与计算。给一个完整的最小匹配流程import numpy as np from scipy.optimize import linear_sum_assignment def match_global(candidate_feats, gallery_feats, transit_mask, sim_threshold0.6): # candidate: 待匹配的轨迹特征; gallery: 全局特征库 sims candidate_feats gallery_feats.T # 余弦相似度矩阵 # 用相机拓扑掩码过滤transit_mask 为 False 表示相机间不可达 sims[~transit_mask] -1.0 cost 1 - sims rows, cols linear_sum_assignment(cost) matched_global_id {} for r, c in zip(rows, cols): if sims[r, c] sim_threshold: matched_global_id[r] c # c 就是全局车辆 ID return matched_global_id代码里sims[~transit_mask] -1.0这行是核心把不可达相机组合的相似度压到最低匈牙利算法就不会选它们。sim_threshold是第二个核心参数它决定了“宁可漏配也不误配”还是反过来。智慧交通业务里误配的代价远高于漏配因为一次误配会污染全局 ID 的后续所有轨迹所以我一般把阈值放在 0.6 到 0.7 之间。4.3 全局特征库的更新不存旧账全局特征库不能无限增长。每小时有 1000 辆车经过每个全局 ID 存最近 5 条轨迹的特征库容也就是 5000 个向量512 维 float32 是 10MB没问题。但如果你把一个月前的特征都留在库里指识别结果会乱跳目标车辆颜色磨损、光照季节变化旧特征会和新特征打架。我通常给每个全局 ID 维护一个候选池保留最近 N 次出现的特征匹配时取池子和当前特征的最大相似度。新轨迹匹配成功后把新特征加入池子池子超过 5 条就淘汰最旧的。这会带来一个问题如果某辆车被误配过一次误配特征成了池子里的“种子”之后每次出现都容易继续误配给同一个全局 ID。解决办法是异常检测池子里相似度最高和次高的值相差不大时这条匹配标记为可疑送人工确认队列。5. 落到工程用可视化脚本验证 ID 切换率全局系统配完后不要只看最终准确率报告你要先做日志可视化。每产生一条跨镜头匹配就把帧号、相机 ID、全局 ID、相似度落一行到日志里。日志格式建议用 CSV至少 6 列字段含义frame_no全局帧计数camera_id相机编号local_id局部跟踪 IDglobal_id全局分配 IDsimilarity匹配相似度match_typenew/update/reid有了这份日志写一个脚本统计 IDSW全局 ID 切换次数这是比 MOTA 更重要的多摄像头指标。MOTA 衡量的是单帧检测和关联的总体误差但在跨镜场景下一次 ID 切换影响后续所有帧IDSW 能直接反映 ReID 和全局分配的好坏。import pandas as pd df pd.read_csv(global_log.csv) # 按全局 ID 分组检查同一个人是否反复在不同相机间出现且 ID 变化 df_sorted df.sort_values([global_id, frame_no]) id_switch_count [] for gid, group in df_sorted.groupby(global_id): cam_change group[camera_id].diff().ne(0).sum() id_switch_count.append((gid, cam_change)) print(全局 ID 切换次数:, sum(cnt for _, cnt in id_switch_count))这段代码统计每个全局 ID 切换相机的次数相机切换并不等于 ID 切换因为同一辆车可以合法地从一个相机去另一个相机但如果切换相机的同时local_id顺序对不上就要去查匹配日志里的similarity是不是低于阈值了。更直接的验证是可视化把同一全局 ID 在不同相机下的截图拼成九宫格人眼快速判断是不是同一辆车。最后说三个我踩过的坑都在配置层代码层反而不容易出问题。第一个是时间戳不同步多相机一定要用 PTP 或 NTP 统一时钟否则两条轨迹的时间差算错跨镜头的拓扑约束全失效。第二个是 ReID 特征更新的频率轨迹在相机 A 停留了 3 分钟特征抽每一帧和只抽最后一帧效果差很多车辆转弯过程中外观变化大建议每隔 15 帧抽一次入池时取平均。第三个是阈值联动检测置信度从 0.35 降到 0.25 时低质量检测框变多跟踪器喂进来的裁剪图模糊ReID 特征质量跟着下降——这时候不要把 ReID 相似度阈值也调低而是把检测阈值拉回去或者给特征提取加一个最小尺寸过滤小于 32×32 的裁剪图直接跳过匹配。把匹配阈值从 0.6 往上提宁可漏配也不误配全局准确性比召回率重要。本文还有配套的精品资源点击获取