后端能力: - 新增 Celery app、worker task、ProcessingTask 模型、/api/tasks 查询接口和 media_task_runner,将 /api/media/parse 改为创建后台任务并由 worker 执行 FFmpeg/OpenCV/pydicom 拆帧。 - 新增 Redis 进度事件模块和 FastAPI Redis pub/sub 订阅,将 worker 任务进度广播到 /ws/progress;Dashboard 后端概览接口改为聚合 projects/frames/annotations/templates/processing_tasks。 - 统一项目状态为 pending/parsing/ready/error,新增共享 status 常量,并让前端兼容归一化旧状态值。 - 扩展 AI 后端:新增 SAM registry、SAM2 真实运行状态、SAM3 状态检测与文本语义推理适配入口,以及 /api/ai/models/status GPU/模型状态接口。 - 补齐标注保存/更新/删除、COCO/PNG mask 导出相关后端契约和模板 mapping_rules 打包/解包行为。 前端能力: - 新增运行时 API/WS 地址推导配置,前端 API 封装对齐 FastAPI 路由、字段映射、任务轮询、标注归档、导出下载和 AI 预测响应转换。 - Dashboard 改为读取 /api/dashboard/overview,并订阅 WebSocket progress/complete/error/status 更新解析队列和实时流转记录。 - 项目库导入视频/DICOM 后创建项目、上传媒体、触发异步解析并刷新真实项目列表。 - 工作区加载真实帧、无帧时触发解析任务、回显已保存标注、保存未归档 mask、更新 dirty mask、清空当前帧后端标注、导出 COCO JSON。 - Canvas 支持当前帧点/框提示调用后端 AI、渲染推理/已保存 mask、应用模板分类并维护保存状态计数;时间轴按项目 fps 播放。 - AI 页面新增 SAM2/SAM3 模型选择,预测请求携带 model;侧边栏和工作区新增真实 GPU/SAM 状态徽标。 - 模板库和本体面板接入真实模板 CRUD、分类编辑、拖拽排序、JSON 导入、默认腹腔镜分类和本地自定义分类选择。 测试与文档: - 新增 Vitest 配置、前端测试 setup、API/config/websocket/store/组件测试,覆盖登录、项目库、Dashboard、Canvas、工作区、模型状态、时间轴、本体和模板库。 - 新增 pytest 后端测试夹具和 auth/projects/templates/media/AI/export/dashboard/tasks/progress 测试,使用 SQLite、fake MinIO、fake SAM registry 和 Redis monkeypatch 隔离外部服务。 - 新增 doc/ 文档结构,冻结当前需求、设计、接口契约、测试计划、前端逐元素审计、实现地图和后续实施计划,并同步更新 README 与 AGENTS。 验证: - conda run -n seg_server pytest backend/tests:27 passed。 - npm run test:run:54 passed。 - npm run lint、npm run build、compileall、git diff --check 均通过;Vite 仅提示大 chunk 警告。
4.3 KiB
4.3 KiB
目的与 Word 方案摘要
为什么要做这个系统
Word 文档《语义分割系统构建方案.docx》的核心目标是建设一个面向视频和连续帧的智能语义分割标注系统,解决传统标注工具在以下场景中的痛点:
- 视频或连续帧数量大,逐帧人工画 mask 成本高。
- 高分辨率图像上同时存在底图、点、框、多边形和遮罩,DOM 渲染难以支撑重交互。
- AI 分割需要低延迟点选/框选反馈,普通 REST 往返在密集交互场景下体验较差。
- 语义分割要求一个像素只能归属一个类别,因此需要模板、颜色、z-index 和类别优先级来解决遮罩重叠。
- 历史 GT mask 如果只是作为静态像素图层叠加,后续修改不灵活;Word 方案希望把 mask 降维成可编辑的点区域。
所以这个系统的业务目的不是单纯播放视频,而是把“视频/DICOM 数据接入、拆帧、AI 辅助分割、语义分类、标注导出”串成一个工作台。
Word 中的目标架构
Word 方案描述的理想系统包含:
- React/Vue + Konva 的高性能 Canvas 工作台。
- FastAPI 后端,使用 WebSocket 处理实时交互与任务进度。
- Celery + Redis 处理视频拆帧等长任务。
- FFmpeg/OpenCV 解析视频,pydicom 解析医学影像。
- 本地 CUDA 上的 SAM 3 推理。
- GT mask 导入后通过距离变换、骨架提取、聚类等算法降维为点区域。
- 模板库管理分类、颜色和 z-index,用于语义分割遮罩重叠裁决。
- PostgreSQL 存储项目、帧、模板和点区域数据。
当前代码已落地的部分
| 目标 | 当前代码状态 | 依据 |
|---|---|---|
| React 前端工作台 | 已落地 | src/App.tsx、src/components/*.tsx |
| Konva Canvas | 已落地 | CanvasArea.tsx、AISegmentation.tsx 使用 react-konva |
| FastAPI 后端 | 已落地 | backend/main.py |
| PostgreSQL ORM | 已落地 | backend/database.py、backend/models.py |
| MinIO 对象存储 | 已落地 | backend/minio_client.py |
| Redis 连接 | 已落地 | 用于 Celery broker/result backend,并通过 seg:progress pub/sub 转发任务进度 |
| 视频拆帧 | 已落地 | backend/services/frame_parser.py、backend/routers/media.py |
| DICOM 批量导入 | 部分落地 | 上传和解析存在,项目级体验还需完善 |
| WebSocket 进度 | 已落地 | 拆帧进度写入任务表后发布到 Redis seg:progress,FastAPI 广播到 /ws/progress |
| SAM 推理 | 部分落地 | 后端已有 SAM 2 / SAM 3 选择和真实模型状态接口;SAM 3 依赖官方运行环境,当前环境不满足时会标为不可用 |
| 模板库 | 部分落地 | 分类、颜色、z-index 能存储和编辑;重叠裁决算法未落地 |
| 标注持久化 | 部分落地 | 后端有 Annotation 表,前端已接入新增、回显、分类更新和当前帧删除;逐点几何编辑未落地 |
| COCO / Mask 导出 | 部分落地 | backend/routers/export.py;COCO JSON 前端按钮已接入,PNG mask ZIP 尚未提供前端按钮 |
当前代码尚未落地的目标
- SAM 3:当前已提供
sam3_engine.py适配入口和状态检测;要实际运行仍需安装官方facebookresearch/sam3依赖并满足 Python 3.12+、PyTorch 2.7+、CUDA 12.6+。 - Celery 异步任务队列:已注册 Celery app 和拆帧 worker task,
/api/media/parse会创建任务表记录并入队。 - GT mask 导入:当前前端没有 GT Label 导入入口,后端也没有对应路由。
- Mask 到点区域的拓扑降维:当前没有距离变换、骨架提取、HDBSCAN 等实现。
- 类别优先级融合:模板有 z-index,但没有后端融合算法。
- 撤销/重做:工具栏有按钮,但没有历史栈。
- 结构化归档保存:工作区按钮已调用
POST /api/ai/annotate保存当前未归档 mask,并通过PATCH /api/ai/annotations/{id}更新 dirty mask。
结论
当前项目已经从 UI 原型推进到“可上传、可异步拆帧、可实时查看任务进度、可浏览项目帧、可维护模板、可点/框 AI 推理、可保存标注、可导出 COCO、可查看 Dashboard 后端概览”的全栈雏形,但离 Word 中描述的完整智能标注系统还有明显差距。下一阶段最重要的是继续补齐手工绘制、撤销重做和真实语义文本分割。