惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

酷 壳 – CoolShell
酷 壳 – CoolShell
H
Hacker News: Front Page
P
Palo Alto Networks Blog
T
ThreatConnect
Apple Machine Learning Research
Apple Machine Learning Research
博客园_首页
T
True Tiger Recordings
P
Privacy & Cybersecurity Law Blog
B
Blog
IT之家
IT之家
Last Week in AI
Last Week in AI
F
Full Disclosure
Hacker News: Ask HN
Hacker News: Ask HN
C
Comments on: Blog
Microsoft Azure Blog
Microsoft Azure Blog
C
Cybersecurity and Infrastructure Security Agency CISA
Microsoft Security Blog
Microsoft Security Blog
博客园 - 【当耐特】
N
News and Events Feed by Topic
NISL@THU
NISL@THU
腾讯CDC
雷峰网
雷峰网
Security Latest
Security Latest
李成银的技术随笔
M
Microsoft Research Blog - Microsoft Research
L
LangChain Blog
L
Lohrmann on Cybersecurity
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
C
Check Point Blog
Y
Y Combinator Blog
Recent Announcements
Recent Announcements
博客园 - Franky
N
News | PayPal Newsroom
V
V2EX
A
About on SuperTechFans
The Register - Security
The Register - Security
月光博客
月光博客
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Google Online Security Blog
Google Online Security Blog
MyScale Blog
MyScale Blog
Cisco Talos Blog
Cisco Talos Blog
Vercel News
Vercel News
WordPress大学
WordPress大学
C
Cyber Attacks, Cyber Crime and Cyber Security
The Hacker News
The Hacker News
IntelliJ IDEA : IntelliJ IDEA – the Leading IDE for Professional Development in Java and Kotlin | The JetBrains Blog
IntelliJ IDEA : IntelliJ IDEA – the Leading IDE for Professional Development in Java and Kotlin | The JetBrains Blog
爱范儿
爱范儿
A
Arctic Wolf
L
LINUX DO - 最新话题
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More

博客园 - strnghrs

基于图像拼接技术实现巨幅图像数字化 2025.09.26 软件更新公告 DIY书籍扫描仪简介v1.7 终于不需要用眼睛确认Acrobat吃没吃字了 VC6的几个好帮手 VC开发单实例(Single Instance)应用软件 印前PDF优化示例教程 v1.1 印前PDF的字体与色彩 印前PDF优化示例教程 分享的青苹果电子书再次更新 分享红旗出版社《家庭藏书集锦》bug修正版:内嵌字体版 分享红旗出版社《家庭藏书集锦》bug修正版 细数那些莫名其妙就被坏了名声的美食(三):炸酱面 细数那些莫名其妙就被坏了名声的美食(二):过桥米线 细数那些莫名其妙就被坏了名声的美食(一):豆汁 搭桥启示录之四:心外科病房的那些奇葩患者们 搭桥启示录之七:生当痛快,死应干脆! 搭桥启示录之六:我本凡人 搭桥启示录之五:养儿防老?您别逗了
乱谈纯黑白(二值化)图像
strnghrs · 2026-03-28 · via 博客园 - strnghrs

作者:马健
邮箱:stronghorse_mj@hotmail.com
主页:http://www.comicer.com/stronghorse/
发布:2026.03.28

目录
一、纯黑白图像的文件长度为什么这么小?
二、纯黑白图像有什么缺陷?如何克服这些缺陷?

随着CEP(ComicEnhancerPro)软件的扩散,我在readfree论坛、QQ群里都看到有人在谈把书籍扫描图像从彩色、灰度转换成纯黑白图像的好处,尤其是那惊人的文件长度变化。但也有人认为天下没有白吃的午餐,这些好处当然不会凭空掉下来,一定也会暗藏着不足。

我无意加入这种辩论,只是从我自己的实际使用经验出发,谈一下我对纯黑白图像的一些认识。本文是极方正、质朴、枯燥的纯技术文,没有任何插科打诨,不喜勿入。

一、纯黑白图像的文件长度为什么这么小?

很多人第一次见识到纯黑白图像,尤其是DjVu格式的扫描图像文件的时候,都会惊叹于其短小的文件长度(与常见的JPG、PNG等格式相比),但具体为什么会有这种压缩效果,一般人还真很难讲清楚,多半都归因于DjVu等格式真是神通广大,技术先进。

在我看来,纯黑白图像文件长度较小可以归结为两个原因。

第一个原因是需要表示的颜色信息极简化。纯黑白图像只有黑、白两种颜色,用0、1两个值即可表示所有像素的颜色,所以也被称为“二值化”图像。这两个值用一个二进制位即可表示,所以一个字节有8位,就可以表示8个像素。或者换一个说法,每个像素只需占用1/8字节。而常规JPG图像支持两种模式,一种是24位真彩色,即一个像素需要占用24位,合计3个字节才能表示所有颜色信息,R(红)、G(绿)、B(蓝)各占一个字节;另一种是256级灰度模式,每个像素需要用一个字节表示像素的灰度等级。

所以对于一幅1024×1024像素的图像,在不考虑数据压缩,也不考虑数据对齐的情况下,纯黑白图像需要消耗的存储空间=1024×1024÷8=131072字节=128KB,而24位真彩图像需要1024×1024×3=3145728字节=3072KB=3MB,256级灰度图像需要1024×1024×1=1048576字节=1024KB=1MB。简单点说,在不考虑数据压缩、数据对齐的情况下,彩色图像的空间占用是灰度图像的3倍,是纯黑白图像的24倍,所以减色非常有利于减小最终文件长度。

第二个原因是纯黑白图像具有专用的高效数据压缩算法。JPG文件的DCT(离散余弦变换)只能用于24位真彩、256级灰度,不能用于纯黑白图像。PNG文件的ZIP压缩可以用于32位、24位、16位、8位、4位、2位、1位颜色空间,所以PNG格式也可以用于无损压缩纯黑白(1位色)图像,但由于PNG采用的是通用性很好的ZIP压缩算法(没错,就是ZIP文件用的那个压缩算法,所以PNG大体上就相当于把BMP压缩成ZIP文件),在压缩效率方面还是比不过专门为纯黑白二值化图像开发的压缩算法。

到目前为止,被广泛应用的纯黑白图像的专用数据压缩算法主要有两种。其中一种是CCITT G4。这种算法是在开发电话传真机的时候发明的,目的是对传真图像进行高效压缩,以减少传输成本。所以这种算法对传真中常见的规律性文字、表格、线条比较合适,但对照片或杂乱无章的内容就不行了。一个做过传真机的朋友曾经和我说起过,有一次他们正在调试的新型号传真机在接收传真的时候突然死机,打电话过去一问,原来对面的测试部门突发奇想,把一块毛巾塞进传真机,毛巾上无规律的细毛图像,把传真机的图像处理部分憋死了。

CCITT以前的版本是CCITT G3,现在已经到了CCITT G4,但都是无损压缩,即压缩前的图像是什么样,压缩后再解码的图像仍然还是什么样,一个像素都不差。

目前TIFF、PDF文件格式对这两个版本都支持,TIFF更是作为基本要求(baseline)提出,所以CEP中一般把纯黑白图像存储为CCITT G4压缩的TIFF文件。DjVu格式理论上说也支持CCITT G4,不过换了个名字叫MMR,而且一般不用,以至于没有几个人知道这回事。超星的PDG清晰版,在压缩纯黑白文字页的时候用的也是CCITT G4,但不是标准算法,而是在标准算法的基础上进行了调整,以加强保密性。

除CCITT G4以外,纯黑白图像另外一种流行的专用压缩算法是JBig2。JBig2是正式的名称,在PDF格式标准中也是这个名字,但在DjVu格式中则被称为JB2。这种算法可以是无损的,即压缩前和压缩后的图像不会有一个像素的差异;但也可以是有损的,即好端端的一页图像,压缩完以后可能就会出现错别字,甚至部分内容神秘消失(参见再往DjVu鼓吹者的头上敲一棒子 - strnghrs - 博客园 (cnblogs.com))。

JBig2的压缩原理可以简述如下:

  1. 一幅二值化图像中,只有内容(文字、线条等)才值得存储,而纸张的白色背景没有必要存储。在显示的时候,只需要简单地先把整个页面填白,然后在上面再画出来所有内容即可。这是JBig2与CCITT G4的一个根本性区别。CCITT G4平等对待整幅图像中的所有像素,不论是内容还是背景,所以如果扩充图像的白边,CCITT G4压缩的文件长度就增大(增加不多,因为白边数据全是重复数据),但JBig2压缩的文件长度不受影响。
  2. 在内容的鉴别与存储方面,对于字母文字,算上大小写也不过就这么几十个字母,所以对页面中的内容进行分割,可以分割出大量相同或者相似的小图像(符号)。每个符号(比如字母a)的扫描图像都存储一份实在是有些浪费,不如建立一个字典,把分割出来的符号按照页面中从上到下、从左到右的位置顺序进行检查,如果在字典中没有存储过这个符号,就把符号加入字典获得新索引,否则就记下这个符号在字典中已经获得的索引。这样一来,整张页面的内容,就转换成了符号字典,及【符号的字典索引,符号在页面中的坐标位置】的列表(文件结构表)。如果有兴趣,可以用DjVuToy的“文件结构”功能,实际导出一页JB2压缩的DJVu文件结构及其符号字典,看一眼就明白我在说什么。
  3. 再采用高效的压缩编码算法,压缩存储符号字典及文件结构表,就完成了整个压缩过程。

从上面的压缩原理看,最终压缩比与符号字典密切相关,所以一般在算法实现上会采取以下两种方法继续折腾符号字典:

  1. 共享字典。对于字母文字而言,这一页与下一页、下下页用的都是同一套字母表,所以每页都建立、存储一个符号字典无疑是一种浪费,不如多页共用一个字典,就可以节省字典的存储开销。PDF、DjVu都支持多页共享字典,但一般开源软件,如djvulibre并不支持生成多页共享字典,只能生成单页字典,而商业版的djvu_sdk可以轻松生成多页共享字典。当然开源的毕竟是开源的,如果技术水平足够,改到支持多页共享字典也不是不可以,就看有多大的决心和能力。
  2. 质量系数。前面说过,创建字典时需要判断某个符号是否已经在字典中存储过,如果已经存储过就没必要重复存储,以免增加字典的空间消耗。但是对于扫描图像,每个符号其实就是一个连通域,即一堆相邻的黑色像素组成的一个小图像,那么如何判断两个小图像是否相同呢?这就涉及到JBig2图像的无损压缩与有损压缩,及有损压缩的质量系数。

无损JBig2压缩,会对符号图像进行逐像素比较,只有所有像素都相同,才会认为是两个相同的符号,否则就是不同的符号。所以无损JBig2压缩的图像,解码后的图像与压缩前完全相同,一个像素都不差,即是无损的。

有损JBig2压缩,则认为“相似”的图像就是“相同”的图像,至于“相似”与“不像”之间的边界,就靠质量系数来划分。简单点说,比较两个符号图像是否是同一个符号的时候,是允许这两个符号图像有一定差异的,只要差异在质量系数规定的范围之内,即可认为这两个符号是同一个符号。对于二值化扫描图像而言,这无疑会大大减少字典中的符号数,从而减小最终输出的文件长度。这就是有损JBig2压缩的魅力,所以有些人为了追求文件长度最小,就不管不顾地降低质量系数,最终扩大“相似”的范围。

但是有损JBig2压缩的原罪也就藏在这个“相似”中。字母文字还好说,中文别说是机器来判断,就算是最智能的人眼来判断,还经常会把相似字看错了。所以既然是“有损”,压缩后出现点错别字、丢点内容啥的,也算是正常的“损耗”,用不着怪谁。毕竟是自己约的那啥,哭着、跪着也得坚持到底。而且这种“有损”的问题是由算法的内在原理造成的,不论你用的是什么软件或代码,也不管你用的是哪个版本,只要是有损JBig2压缩,这个问题就无法完全避免,否则就成无损压缩了。

最关键的一点是,在JBig2压缩完成以后,除了与原文进行逐像素比较之外,并没有什么技术手段能够知道一页扫描文件究竟用的是有损还是无损JBig2压缩,以及有损JBig2用的质量系数究竟是多少、会不会产生错别字、有没有丢内容。所以严格来说,你拿到的所有别人用JBig2压缩的扫描文件,每一页的真实性、准确性其实只有天知道,你自己完全不可能知道。这就是为什么菜鸟对DjVu惊为天人,老鸟则避之唯恐不及。

但其实除了DjVu以外,PDF也支持JBig2压缩算法,DjVuToy就支持从DjVu到PDF的直接转换,包括多页字典。所以对于扫描版PDF,某些有精神洁癖的人也会检查是否采用了JBig2压缩,如果用了就趁早洗牌。

综上所述,“纯黑白图像的文件长度更小”这句话,其实是包含了两层意思的,如果在面临选择时内心太过贪婪,或者干脆就是纯粹的人穷志短,就很可能会一念天堂,一念地狱。

二、纯黑白图像有什么缺陷?如何克服这些缺陷?

纯黑白图像的好处除了上面说的文件长度比较小以外,还有黑白分明(废话,不是黑就是白)等优点,但这些优点反过来,也就对应了纯黑白图像的缺陷:

1、只适合表示文字、表格、线条等内容,不适合表示彩色、灰度插图。

所以如果用CEP处理扫描书籍,最好把封面、插图页面,与正文页面分开,使用不同的处理参数。在PDG清晰版中,这些页面也是分开的,纯文字页面采用CCITT G4压缩,封面、插图页面用JPG。

如果非要用纯黑白表示灰度图像,理论上说也不是不行。用黑色网点的疏密程度模拟不同的灰度,即可用纯黑白表示出灰度图像,就好像以前老报纸上印刷的满是网点的照片一样。这种技术在专业上一般称为半调(halftone),挂网点的算法一般称为抖动(dither),有兴趣的可以看《ComicEnhancerPro 系列教程 附录一:CEP处理之颜色与通道》、《ComicEnhancerPro 系列教程 教程七:减色与抖动》。

2、如果在电脑屏幕上1:1看,容易发现纯黑白图像的笔画、曲线或斜线的边缘出现毛刺、锯齿等,笔画还会出现粘连、间断,图像放大看以后效果可能会更惨,比普通灰度图像放大后的效果还更差。

归根结底,这个问题的根本原因还是在于非黑即白,文字、线条的边缘处缺乏中间灰度作为过渡,参见《ComicEnhancerPro 后记:扫描版电子书籍的常见问题》。

用CEP去除毛刺相对容易,参见《ComicEnhancerPro 教程十七:二值化图像去毛刺》。解决笔画粘连、间断则一般要几个参数联合使用:

  • 笔画粘连通常出现在低分辨率图像中,所以解决的第一步通常是放大。如果是在经典界面中通过“缩放”操作,最多只能放大到200%,如果是在“书籍处理”界面中通过“版面”操作,则没有这种限制。
  • 放大以后,用“高斯锐化”可以有效消除笔画粘连现象。如果锐化后出现麻点、锯齿等,可以用高斯模糊+Wolf算法解决。
  • 二值化算法常用的有Otsu、Wolf等。选择Wolf算法,通过改变它的窗口尺寸,及适当增加高斯模糊半价,可以解决笔画断裂、锐化后的锯齿等,使笔画、线条更加光滑。Wolf的窗口尺寸不是闭着眼睛胡乱选的,CEP甚至专门为此提供了像素级的测量功能,详见CEP帮助文件中的说明。

纯黑白图像放大后比较惨,但缩小后显示却很赞,因为大多数常用浏览器,包括Acrobat、UV等,在缩图时都会自动把纯黑白图像缩为256级灰度图像,通过相邻像素补上边缘处的中间过渡灰度。所以改善纯黑白图像显示效果最简单的方法,其实是先高倍放大原始扫描图像,然后再转换成纯黑白。在国外曾经很流行的《The Scan and Share tutorial version 1.07》中,就建议用300 DPI进行灰度扫描,然后用软件放大处理到600 DPI的纯黑白图像。scantailor等软件就是按照这个思路来设计的。但现在毕竟技术已经发展了,600 DPI也可能不够。以平常最常见的32开(787×1092mm,1/32)书籍计算,页面宽度13cm,在300 DPI下是1535像素,在1920宽度的显示器上窗口最大化显示,已经需要进行图像放大了,所以超星把300 DPI就称为“清晰版”,其实是针对显示器分辨率还是1024×768甚至800×600时期的技术。如果放大到600 DPI,13cm宽度折合3071像素,差不多能撑到4k显示器了。但如果将来再进步到8k显示器呢?所以我自己处理纯黑白的时候,一般都是900 DPI打底,1500 DPI也不是没有用过,参见《“伪·高清”制作二例 - strnghrs - 博客园 (cnblogs.com)》。好在如前所述,纯黑白图像的无损压缩算法效率本来就比较高,所以即使放得很大,但文件长度相比其他格式仍然很节省。

总之一句话,介绍CEP的纯黑白模式却不提图像放大,就是在耍流氓,碰到了直接一口吐沫喷过去就好。