run_recognition方法能不能返回命中图片名称 #496
Comments
|
还有关于执行速度的, MaaDebugger执行pipeline的速度很明显比程序快, 是因为不是使用原生调用的原因吗? 换c或者java会快点吗? |
|
log发一下，debug/maa.log |
|
maa.log
|
|
feature match是要慢一点的，而且图片还这么多。计算密集型，python 你开线程应该没什么用 如果这些图片大小不会变的话，可以用 template match 其实我更建议你直接训练一个 yolo 的模型然后用 nn detect |
|
为啥你需要一个截图的线程，我没太看明白 CustomRecognition run 里本身就是带了一张图片的， |
|
run_recognition 不返回命中的名称是设计如此，我们认为单个节点内所有图片等价，如果他们不等价，应该拆分成多个节点 |
图片大小倒是不会.变, 不过截图太多了一些图片大小不好控制(那个骰子是动画的并且有7个点数, 为了准确点我截了十多张图片...). 用template match会报一些图片太大,roi太小. 如果要使用template match只能扩大roi. 扩大的话就会识别到其他格子中....所以我就用了feature |
因为我不是用的CustomRecognition, 我是这样调用的(我看示例项目里的阴阳师是这样调用的...) img = context.tasker.controller.post_screencap().wait().get()
recognition_blue_result = context.run_recognition(self.recognition_blue_title,
screenshot,
self.recognition_blue)因为每个格子(5*3)都需要识别对应格子是什么骰子, 为了节省点资源就共用一张图片 |
报错？不会的，说明你的图或者 json 写的有问题，发一下看看 |
没用 CustomRecognition 吗那这个 context 哪来的？ |
不知道为啥我的资源图片比实际的图片大点... 我是用ImageCropper截的
报的是 |
CustomAction的context...我看yys是这样用的. 不符合规范吗 |
没看明白，100和120分别是哪个？log 也发一下 |
不是太好，但也行 但是你说的截图线程是？ |
|
我们先理一下逻辑，这个画面期望是要怎么识别，然后需要怎么点击操作？具体说一下 |
就这个图片. 120117是用ImageCropper截出来的, 100100是我定的roi |
120*117，ImageCropper 你是怎么使用的，自己手动截了一张图，然后放进 src 文件夹？怎么截图的呢 |
|
@moomiji 我感觉这里文档还要改一下，确实没看见哪里说自己截图要手动 resize（ https://github.com/MaaXYZ/MaaFramework/tree/main/tools/ImageCropper |
大部分是ImageCropper从运行时动态获取的, 小部分是从debug日志中拿的. 因为我不知道mumu的截图在哪所以只可能会有这2种图片 |
|
ImageCropper 你有改过它的什么参数吗？ |
|
这是核心需求 
|
window_size = (720, 1280) # 竖屏
# window_size = (1280, 720) # 横屏 |
截图线程是循环调用一个直接触发的pipeline, "screenshot": {
"action": "Custom",
"custom_action": "screenshot_action",
"pre_delay": 0,
"post_delay": 0
}custom_action class ScreenshotAction(CustomAction):
def run(self,
context: Context,
argv: CustomAction.RunArg) -> bool:
"""
截图线程
"""
img = context.tasker.controller.post_screencap().wait().get()
logging.debug("ScreenshotAction post_screencap")
# 存到全局变量里, 由其他线程直接识别
RDContext.set_screenshot(img)
return True |
|
你把多线程的逻辑去掉就没这个问题了（ 控制器一次只能进行一个操作，有一个执行队列，截图在等 swipe 这些操作执行完 |
|
不光 swipe 会阻塞截图，截图也同时会阻塞 swipe。 直接用最普通的方案就好了，一个 custom action 中，截图 -> 识别 -> 滑动操作 不过更优解是在 custom recognizer 中截图并识别，返回识别成功与否，custom action 中直接执行动作 |
识别这里你也不用开线程，图像识别是计算密集型，python 的 GIL 开线程没有提升的（应该是吧，我也不是特别懂 python 假设 15 个格子每个都可能有 5 种情况，这里的比较优的方案可能是，对 15 个 ROI 每个分别跑 5 个 run_recognition TemplateMatch，每个里面都只有一张模板图片，然后你写点逻辑判断下命中的是哪个，比较朴实无华（ 如果不是 5 种情况而是 50 种情况，可以考虑用 nn classify，可能会快一点 |
应该不是swipe和截图抢占, 我测试了单独开截图线程占用时间也是400毫秒左右. 不过截图问题不大, 后面我试试换java掉用会不会快点~ |
后续换TemplateMatch试试, nn classify对我来说有点难= =没有人工智能和深度学习基础... |
|
新鲜出炉的 nn classify 文档，有兴趣可以试试 |
|
/Users/cgb/PycharmProjects/MaaRandomDicePy/venv/bin/python /Users/cgb/PycharmProjects/MaaRandomDicePy/main_v4.py 进程已结束，退出代码为 0 提示json错误, 但我已经更新了项目代码. 下面是项目结构 |
|
expected 要的是数字，传 index |
按照文档试了一下, 现在脚本勉强可用, cpu和执行速度在可控范围内~ |
|
关于 nnclasify 的问题可以另开一个 issue，这个我先关了。你训练集有多少数据？ |
训练数据在59个. 每个骰子最少7张图片. 其实应该不怪模型. 因为骰子会随机射出子弹(颜色不一样)子弹途径骰子.会干扰到模型的判断. 我看了下文档, 没有随机噪点的训练场景 这是子弹途径骰子的图片...人眼都不一定能识别😂 |
|
训练集有点少，最好可以写个自动截图+裁剪的小脚本，自动抓一下图片。拿 MAA 的技能识别举例子（不知道你有没有用过？），我们一共用了3w张图片。 理论上神经网络的识别准确率是可以超越人眼的 |
如上面图片, 每个骰子都可能出现在5*3的格子中
我试过识别整个放置区, 效果不太好.
现在是开15个线程识别对应格子, 里面又会识别蓝红2种骰子(2次run_recognition)通过得分确认骰子是红还是蓝,
而每次run_recognition会消耗大约1秒的时间, 完整识别红蓝骰子需要耗时2秒左右. 而且还会把其他骰子识别成我需要操作的红蓝骰子.
比如下面的就经常识别成蓝骰子
再开线程不开可行因为cpu已经到90多了, 而在现场内多执行run_recognition实时性又会大大降低
或者还有其他解决方案吗?
The text was updated successfully, but these errors were encountered: