Andy AO

我们可以做一个假设，通常来说译文和原文的字数不会相差太大，如果原文是100字符，译文大概率不是10个字符。 那么还建议检查行是否一致，没有办法准确检查，但可以提示**疑似高度不一致**的结果，然后进行标注，这样发现和纠正问题将更快。

> 行号是可行的。 > > > 我们可以做一个假设，通常来说译文和原文的字数不会相差太大，如果原文是100字符，译文大概率不是10个字符。 那么还建议检查行是否一致，没有办法准确检查，但可以提示**疑似高度不一致**的结果，然后进行标注，这样发现和纠正问题将更快。 > > 但是，没太理解这个描述。目前只要行数不一致就会标记成黄色，还需要**疑似高度不一致**这个条件吗？。 > > 另外，除了 ChatGPT 这种可能丢失行，Google 翻译之类的有时也会出现错误，比如翻译多行时只返回一行。 行数不一致的话，我们只知道整体有问题，因此在条目列表的UI上标注为黄色，这个是已经实现的功能。 如果查看文本的UI上有了行号的话，那么我们也想知道具体是从哪一行开始有了问题，这就需要依据假设进行猜测，这个假设可以是字符数明显不同。 猜测出来之后在对应的行上也进行标注，比如高亮或者波浪线，这样可以便于排错。

> 了解了。不过根据字符数标记问题位置感觉不太可靠，因为没有判断不同语言之间原文的译文长度比例的依据。另外，这种标记要在识别十分精准的情况下才可行，否则可能会让人疑惑。 这是一个能够极大方便排错的功能，根据我的经验，出现这种情况意味着在该位置的前方不远处，问题已经出现。 我理解你的担心，正如你所说，它会带来一些问题，不过我认为这些问题可以有解决方案，这里分享一下我的思考。 1. 有的人可能无法理解，这只是个高度疑似的提醒，我认为这可以通过不默认开启该功能来解决，这样如果有人需要的话，那么他会手动开启该功能，开启的时候就会看到该功能的名称，从而理解是什么意思 2. 译文和原文的比值也可以自定义，默认可以是0.1，也就是1:10，如果需要可以增大或减小。

发现有参数可以更改，改完之后似乎可以了，正在跑 ```bat @echo off if "%~x1"==".pdf" ( java -jar "%~dp0PDFtool.jar" -e "%~1" --max-wh=2147483647 --min-wh=100 "%~dp0realesrgan-ncnn-vulkan.exe" -i "%~1_img" ) else ( "%~dp0realesrgan-ncnn-vulkan.exe" -i "%~1" ) pause ```

 处理结果出来了，感觉有点小失望，似乎效果不是太好。 只是处理一页，看看对OCR有没有帮助吧。

OCR之后对比发现，超分辨率后反而劣化了。 不管是从肉眼上看，还是从OCR结果上看，至少对于那本PDF来说该程序没有任何的帮助。

原因是什么呢？有点好奇

@tumuyan 发现该程序的PDF导出图片的机制不行。 如果让程序自动处理PDF，那么最后做出来的结果就是劣化的，如上图所示。 可是如果使用别的软件，比如PDF-XChange Editor导出为tif文件，超分辨率结果就很好  [程序自动处理pdf会导致结果劣化.zip](https://github.com/tumuyan/SourceBook-Dataset/files/12450618/pdf.zip)

另外发现如果提升gamma，那么效果会更好 

自己先导出，然后调整gamma，最后再用这个AI超分辨率，效果相当好。  **如果能将前面两个步骤自动化就更好了**