- 博客(6)
- 收藏
- 关注
RSS订阅原创 从 OpenCV 模板匹配到 YOLO：TFT 截图识别模块的一次升级
在前几篇文章中，项目已经完成了 TFT 阵容顾问的资源构建、英雄识别、装备识别和截图路由层。旧方案主要依赖 tft_screen_capture.py，通过 OpenCV 完成六边形边框检测、HSV 直方图粗筛、灰度 NCC 模板匹配等流程。这套方案的优点是实现清晰、依赖轻、CPU 即可运行，但随着识别场景变复杂，它的上限也逐渐暴露出来：截图来源不统一、边框颜色变化、英雄头像缩放、UI 遮挡、无框截图等情况都会影响识别稳定性。因此，本阶段项目开始引入新的识别引擎：tft_yolo_clip.py。
2026-05-24 13:01:42
159
原创 云顶之弈截图路由层：四种游戏界面如何自动分流（detect_screenshot_mode 实现拆解）
在前几篇文章中，我们已经完成了 模板资源构建（）、英雄识别与装备识别（中的模板匹配链路）。这些能力解决的是：在已知头像区域的前提下，判断“这是谁、带了什么装备”。但真实使用时，用户上传的并不只有 DataTFT 棋盘图，还可能是 结算横排图、大厅阵容羁绊八人表、战绩回顾双棋盘 等完全不同版式。若仍用同一套六边形边框检测 + 棋盘逻辑，就会出现框检不到、玩家行数错乱、英雄大面积漏检等问题。本文聚焦与统一入口。说明项目如何在毫秒级内判断这是哪种游戏界面，再分发到四条识别管线；
2026-05-17 12:28:39
349
原创 用 OpenCV 实现云顶之弈装备识别：从英雄框到装备 ID 的工程化拆解
上一篇文章中，我们已经完成了云顶之弈截图中的英雄识别：系统可以从截图中定位英雄头像区域，并通过 HSV 颜色直方图粗筛 + 灰度 NCC 精匹配识别出英雄 ID。但对于一个真正可用的 TFT 阵容分析系统来说，只知道“场上有哪些英雄”还不够。装备同样决定阵容强度，例如主 C 是否有三件套、前排是否有坦装、高费卡是否空装等。本文继续基于 tft_screen_capture.py 和整个项目代码，重点拆解装备识别是如何实现的。相比英雄识别，装备识别更像是英雄识别链路的下游扩展：识别英雄是谁。
2026-04-29 14:21:11
405
原创 用 OpenCV 实现云顶之弈英雄识别：从截图到英雄 ID 的完整拆解
这个项目的英雄识别模块，本质上是一套基于 OpenCV 的模板匹配系统。它并不是简单地拿截图和模板硬比对，而是先通过截图模式判断和候选框检测缩小识别范围，再通过 HSV 颜色直方图筛出候选英雄，最后使用灰度 NCC 做精匹配，并输出英雄 ID、位置和置信度。完整英雄识别链路可以总结为：英雄模板加载-> 截图模式判断-> 英雄头像定位-> 头像区域裁剪-> HSV 粗筛候选英雄-> NCC 精匹配确定英雄 ID-> 输出结构化识别结果。
2026-04-27 18:16:40
324
原创 设计与实现一个通用 LLM 客户端：Anthropic 与 OpenRouter 双通道设计
随着大语言模型技术的快速发展，越来越多的智能问答系统、推荐系统和辅助决策系统开始集成第三方大模型接口。为了提升系统的可扩展性与可维护性，本文设计并实现了一个统一的大语言模型客户端 LLMClient。该客户端采用面向对象思想，对 Anthropic 与 OpenRouter 两类模型服务进行统一封装，实现了模型选择、API Key 解析、消息请求发送以及异常处理等功能。该设计降低了业务层与底层模型接口之间的耦合度，提高了系统在不同运行环境下的适配能力，为后续扩展更多模型提供了良好的基础。
2026-04-20 17:09:54
386
原创 从赛季数据到模板图库：深入解析 tft_fetch_assets.py和TFT 截图识别的资源构建链路
在TFT 阵容顾问项目里，tft_fetch_assets.py 不仅一个“下载图片”的脚本，如果把整个项目串起来看，该文件承担的是 模板资源构建器 的角色。它上游连接 tft_data_manager.py 生成的赛季数据，下游直接服务 tft_screen_capture.py 的 OpenCV 模板匹配，是截图识别链路里非常关键的一层。
2026-04-12 16:10:35
523
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人