转换为TIFF图片提示内存不足

[ilcpm]

转换以下PDF文件为TIFF时提示内存不足，但是转换为黑白的PNG就不会有这个提示

GBT 1.1-2020 标准化工作导则 第1部分：标准化文件的结构和起草规则.pdf

[Charltsing]

好奇地问一下，为什么你要转成tiff? 从图像存储的角度而言，png以及完全够用了，毕竟你这个文件不需要什么真彩。
如果是打算做电子存档，GB/T 18894-2016已经允许使用PNG格式了。

8.3.3 以文本、位图文件形成的文书、科技、专业类电子文件应按以下要求归档：
a）电子公文正本、定稿、公文处理单应以版式文件格式，其他电子文件、电子文件组件可以版式文件、RTF、WPS、DOCX、JPG、TIF、PNG等通用格式归档；

[ilcpm]

好奇地问一下，为什么你要转成tiff? 从图像存储的角度而言，png以及完全够用了，毕竟你这个文件不需要什么真彩。 如果是打算做电子存档，GB/T 18894-2016已经允许使用PNG格式了。

8.3.3 以文本、位图文件形成的文书、科技、专业类电子文件应按以下要求归档： a）电子公文正本、定稿、公文处理单应以版式文件格式，其他电子文件、电子文件组件可以版式文件、RTF、WPS、DOCX、JPG、TIF、PNG等通用格式归档；

这个文档里面的图形是SVG，但是文本层做了字体混淆复制出来全是乱码也没办法搜索，所以需要转换成普通图像然后进行OCR，对于这种纯黑白的页面，使用TIFF无损压缩存储纯黑白图像（每个像素只有0和1）是通常做法。这个文档我最后处理成900DPI的纯黑白TIFF，进行OCR并添加目录之后体积只有3.23M，审计PDF空间图像只有1.97M，甚至体积还缩小了不少。

我对具体的图像格式里的压缩算法什么的没有深入了解过，我也不清楚png如果存储纯黑白图像在参数正确的情况下是不是能达到同样的效果。我知道的是这样做是一种“最佳实践”，如果我没记错的话，不管什么位深度的png或者jpg喂给ABBYY做OCR之后，输出的时候都会被重编码，导致图像被有损压缩损失而失真，尤其如果参数设错图片被存成了jpg格式，后果我就不说了，感兴趣的话可以自己去试试看……

至于为什么要转换成图像再来OCR而不是直接对SVG的PDF进行OCR，时间久了我记不清了，我猜应该是ABBYY不支持SVG，识别之后只能变成几十M的低质量有损压缩图像（那破软件不能详细调整输出PDF的图像参数，很难伺候）。

总之大方向上就是：如果喂给ABBYY做OCR，这种黑白的只有在TIFF的黑白模式下ABBYY才不会改动图像，保证输出文件的体积；否则的话要么损失质量变成jpg，体积几十M水平，要么保证质量变成png，体积几百M水平。如果我还是没记错的话，好像在某种参数下ABBYY会把图像处理成jp2格式，体积小质量也没有jpg那么差，但是jp2的解码太慢了，在很多PDF阅读器里面滚动速度极慢（虽然我这个900DPI的文档滚动起来也很慢……但那是为了视觉观感，如果是600DPI的话滚动就很流畅）。

另外附上我处理完成的PDF供参考（有点邀功的意思了……）。
[GBT 1.1-2020][标准化工作导则 第1部分：标准化文件的结构和起草规则][OCR].pdf

[wmjordan]

之前我还能重现这个故障的。今天测试了一下，可以成功渲染所有页面。

[wmjordan]

新的版本更新了渲染PDF所用的MuPDF库。

[Charltsing]

现在国内的在线OCR比Abbyy准多了，后者也就对付一下常用的印刷体。在线OCR手写体都能做到极高的准确率。

也许你应该换一个别的pdf ocr软件，或者自己结合在线OCR接口写一个。
至于图像大小，像这种黑白图，JBIG2才是最小的。如果是16色灰度图，png也支持4bit索引，效果很好。至于256色灰度，那就基本什么格式都可以了。tif的1bit编码体积不是很理想，图像格式也太乱了些，所以至今为止你看浏览器都不支持这个格式，这都是有原因的。