MuriyaTensei

音频格式是不是不对？

解决了，使用 ``` pip uninstall torch -y pip uninstall torchvision -y pip uninstall torchaudio -y pip install torch==1.10.0+cu113 torchvision==0.11.0+cu113 torchaudio==0.10.0+cu113 -f https://download.pytorch.org/whl/torch_stable.html -i https://pypi.mirrors.ustc.edu.cn/simple/ ``` 完全按照版本安了一遍就没问题了

虽然有提示 trans_chatgpt:api_url:355 - API URL does not contain '/v1': https://ark.cn-beijing.volces.com/api/v3, please ensure it's the correct URL. 但是能工作（不过命令窗口被警告刷屏比较严重） 期望能有个开关能取消这个报错，或者把警告的匹配规则稍微改宽一点

[cirosantilli](https://github.com/cirosantilli) changed the title 《greedy people》

其实把翻译当前页转化成在当前页运行（执行勾选的内容）就挺好的 > 之前也有人反馈过，加这个也不是很难，不知道为啥作者一直没动静… > > default.mp4 提个pr（）

> [208c09d](https://github.com/dmMaze/BallonsTranslator/commit/208c09d9b2222f906a4e706fb19afec227fbaa78) 加了 None 和 Source translator，一个返回已有翻译，一个返回原文。OCR 里要翻译的话可以直接往 textblock.translations 写翻译结果 感谢作者，更得很快。 不过发现实际应用现在面临最主要的问题还是一个是速度慢，一个是文字顺序经常出问题。 还没去仔细看源码，不知道是不是给llm传的图像粒度太细了导致的。因为我记得现在的文字检测是单排字，这样对于传统ocr效果确实好很多。但是不知道为什么这样文字顺序会出问题，是膨胀导致意外覆盖了更多文字的原因吗。 这个部分不知道有没有机会优化

> > 还没去仔细看源码，不知道是不是给llm传的图像粒度太细了导致的。因为我记得现在的文字检测是单排字，这样对于传统ocr效果确实好很多。但是不知道为什么这样文字顺序会出问题，是膨胀导致意外覆盖了更多文字的原因吗。 > > 单排字参考 mit 系列模型，整块识别参考 MangaOCR，现在项目里那个 llm OCR 就是整块识别的。顺序出错可能是你 OCR 不支持日漫那种从右到左的顺序，可以把图截出来直接喂给它看看结果 事实上如果在本地单独使用效果非常好，即使混编也可以有很高的准确率

> 单排字参考 mit 系列模型，整块识别参考 MangaOCR，现在项目里那个 llm OCR 就是整块识别的。顺序出错可能是你 OCR 不支持日漫那种从右到左的顺序，可以把图截出来直接喂给它看看结果 @dmMaze 但是目前实际使用BallonsTranslator中发现准确率还可以，有些排版问题可能是传的图偏小，llm对于单排文字的横排竖排判断错误，这部分影响不大，属于可考虑优化的内容。 现在最影响使用的是速度太慢，十分钟大概只识别了50个框，事实上即使在本地手动一个一个截图，每个框应该也不需要10s，并且使用的api并发应该是不低的，我基于相同api开发的小说翻译插件可以十几个线程一起跑，高并发的情况下效率非常高

> > 还没去仔细看源码，不知道是不是给llm传的图像粒度太细了导致的。因为我记得现在的文字检测是单排字，这样对于传统ocr效果确实好很多。但是不知道为什么这样文字顺序会出问题，是膨胀导致意外覆盖了更多文字的原因吗？ > > 单字参考mit系列模型，整块识别参考MangaOCR，现在排的llm OCR就是整块识别的。顺序错误可能是你OCR不支持日漫那种从右到左的顺序，可以把图截出来直接喂给它看看结果 还是期待在效率上能有优化，我又试了下，现在识别准确率（或者识别翻译一体化）的效果已经很让人满意了，如果效率问题解决，真的可以大批量跑汉化了 目前制约传统方法的，就是ocr准确率不高需要再人工校对一次翻译效果才比较理想。如果这部分解决，60分能直升80分