原帖地址：http://www.comicer.com/stronghorse/water/software/djvu886.htm

别了，DjVu！

作者：马健
邮箱：[e-mail]
主页：http://www.comicer.com/stronghorse
发布：2010.05.21

目录
一、DjVu技术
二、掌握DjVu技术的人
三、玩DjVu的人
四、小结
跋：我与DjVu

谨以此文纪念与DjVu打交道4周年！
================================朴素的分隔线================================

在DjVuToy公开发布后，曾经有某位专业从事扫描外包的朋友问我对DjVu前途如何看待，我当时的回答是：如果DjVu的现状得不到改变，在商业应用方面就没有任何未来可言，只能沦为扫描电子书爱好者手中的玩物。

这个所谓的“现状”，指的就是：一项还算不错的技术，落到了一帮糟糕的人手里。

这篇文章其实就是那次谈话的一个整理，纯属一家之言。

一、DjVu技术

我说DjVu技术“还算不错”，是因为：
1、DjVu基于ISO/IEC 16485 MRC（Mixed Raster Content）模型，在图像分层、图像编码方面有一些独到之处，因而造就了DjVu“压缩率高”的名声，其中的原因我在《DjVu转PDF》的第二章“理论”部分已经详细描述过，此处从略。
2、由于专门定位于扫描文档，不考虑文字显示，因此在DjVu标准规范中可以省略字体等内容，直接用UTF-8编码表示可检索的隐藏文字内容，比PDF等格式更简洁一些。

但是DjVu技术也并非完美无缺：

1、扫描分辨率与有损压缩的误码率
DjVu在压缩文字部分时通常采用JB2压缩，可以是无损，也可以是有损。在有损情况下，如果扫描分辨率不足，可能会因为误码而导致生成的DjVu出现错别字，因此在我见过的DjVu相关技术文档中，都强调扫描分辨率不要低于300 DPI。误码的原因、实例见《DjVu转PDF》一文。
从目前的情况看，汉字的误码率要高于字母文字。

2、缺乏对灰度图像的支持
在分辨率不足（低于200 DPI）的情况下，如果强制要求简化成黑白二色，可能会出现文字残缺的情况，而采用灰度图像（如16级灰度），则可以在文件长度与显示效果之间取得平衡，这也是PDG大图版的做法。但不幸的是，DjVu格式本身对灰度图像支持匮乏：
a) 如果转换成单层DjVu，采用JB2压缩显然会出现上面说的笔划残缺问题，采用IW44压缩则在大压缩比下会模糊。
b) 转换成双层DjVu明显不行，因为双层DjVu要求每个shape只能有一种颜色，而灰度图像每个字有多级灰度。
c) 转换成三层DjVu，灰度信息靠底层图像提供，在采用大压缩比（大比例缩图、低码率）情况下，文字会出现模糊，甚至成为灰灰的一团。
解决办法不是没有，不过麻烦一点，效果如何要看技术和运气：放大（如从150 DPI放大至300 DPI）、处理后减色成黑白二色、转换成JB2压缩的单层DjVu。

3、对MRC模型支持的局限
DjVu基于ISO/IEC 16485 MRC三层模型，但是没有考虑该模型的Stripes、N层模型等扩展情况，因此插图如果在整个页面中所占比例不大，经过大比例压缩再放大显示后，插图看起来总是模模糊糊的，影响观感。

4、批量处理难以摆脱人工干预
DjVu文件的压缩率、生成后的视觉效果等，其实与图像类型的准确识别有很大关系。这里说的“图像类型的准确识别”，就是指在碰到一副扫描好的静态图像后，准确判断出应该转换成单层、双层还是三层DjVu，并确定各层的压缩比。这种判断在很大程度上是一种经验值，所以在商业DjVu制作软件中，都有N多种预设值，需要人工进行挑选，以获得最佳效果。换句话说，如果所有文档不分青红皂白都按三层（document）进行转换，碰到前面说的灰度图像时难免会哭笑不得。这些都给完全自动化批量DjVu生成带来了困难。而商业应用看重的恰恰是这种能力。

5、先天不足、内外有别的格式标准
在我看来，DjVu其实不应该算是一种“文档格式”，而应该算是一种“图像格式”，因为与PDF等文档格式比起来，欠缺的东西实在太多，包括多格式文本、矢量图、多媒体、脚本、交互表单、权限控制、安全鉴别等等，所以只适合表示扫描图像，而不适用于常规文档。但即使这样，DjVu格式本身也不是完全公开的格式（open format），如最新的“安全DjVu”（SDJVU）格式，就只有DjVu格式的商业拥有者Celertem公司才有，也只被该公司及其关系公司所提供的产品所支持，其他细节外界未知，所以被讥讽为“published format”，原帖地址：
http://www.djvu.org/forum/phpbb/viewtopic.php?t=422
该贴作者jrile是原PlanetDjVu社区的创始人兼站长，在DjVu社区也算大名鼎鼎。

6、工具与支持的匮乏
在现在这个时代，除非有MS Office这样的强势，否则一种文件格式的推广应用，离不开开源社区的强力支持。但是目前DjVu基本上算不上是一种开放的格式，除了前面说的文档格式标准混乱外，最新、最好的DjVu格式生成工具、SDK都掌握在Celertem公司及其关系公司手里，这些都是要钱的，而且还很不便宜。
目前与DjVu相关的免费、开源的东东，最终都可以追溯到djvulibre（http://sourceforge.net/projects/djvu/）的身上，理论上这个项目由DjVu的商业拥有者（最早是AT&T，然后是LizardTech）维护，但是实际上，与真正商业化的SDK相比，差得远了去：
a）djvulibre不具有最核心的功能——图像分层功能，基本上只能制作单层DjVu，如果需要制作三层DjVu，则需要用其他代码或工具解决图像分层问题。仅此一条，就可以保证商业SDK不会被免费的djvulibre所取代。
b）对于JB2压缩，djvulibre不具有共享字典生成能力，生成的DjVu文件可能会比采用商业SDK生成的DjVu文件更大。
c）我以前看到的文档曾说djvulibre的源代码出自LizardTech代码库，与该公司发行的商业SDK采用的源代码相同，但是真正找了LizardTech发行的商业SDK一编译，才知道不是这么回事：SDK说明文档会告诉你，此djvulibre非彼djvulibre；编译器则会告诉你，你获得的djvulibre源代码与商业SDK使用的djvulibre源代码相比，少了好些东西。
d）不知道是有意还是无意，尽管djvulibre声称采用了智能的内存管理模式，但是实际用过的人都知道，这套源代码的内存漏洞多到数不清（我自己花了4年时间补洞），以致于我不相信任何一家稍有常识的商业软件公司会基于这套源代码，开发自己的商业应用。
e）djvulibre源代码是基于GPL的，这也在一定程度上堵塞了它的商业应用之路。
f）djvulibre前后两任的拥有者（LizardTech、Celertem）对该社区的支持并不多，如我前面说过的内存漏洞问题，几年前就有人提出，但是一直死不认账。对其他DjVu相关社区的支持就更是没有，如jrile在关闭PlanetDjVu社区后，选取了该社区中的部分帖子，以《The Future of DjVu - Revisited》为题发布在djvu.org社区：
http://www.djvu.org/forum/phpbb/viewtopic.php?t=526
在这个帖子中，他对DjVu的种种看法，足以吓到一般人。

除上述缺陷外，从技术上讲，DjVu格式本身并不是不可替代的：DjVu所依赖的ISO/IEC 16485 MRC三层模型，同样可以应用到PDF上，并达到相似的压缩比与视觉效果，详见我写的《DjVu转PDF》一文。

有趣的是，djvulibre从v3.5.21开始，在Ddjvu例子中也加入了DjVu转PDF功能，但采用的是libtiff的tiff2pdf源代码。换句话说，是先把DjVu转换成TIFF，然后再转换成PDF，支持CCITT G4、JEPG、zip压缩。这样的转换方式，不仅完全不管MRC三层模型，而且丢失了原JB2、IW44压缩的高效率，转换出来的PDF自然会增肥许多，然后某些人又可以振振有词地说：你看，DjVu转换成PDF以后就是会变大吧！

所以，DjVu技术尽管不错，但也仅仅是“还算不错”。

二、掌握DjVu技术的人

DjVu格式于1996年由AT&T提出，所以文件的头4个字节就是“AT&T”。

AT&T在DjVu上的投入并不多，这一点从AT&T发布的源代码和SDK可以看出。2000年时DjVu格式被倒卖给了LizardTech，一家专注于文档扫描的公司。

LizardTech对DjVu文件格式规范、djvulibre的贡献有目共睹，遗憾的是几年后也撑不下去了，2007年被日本的Celertem所收购。但奇怪的是，在Celertem公司产品主页（http://www.celartem.com/en/products/）、下载主页（http://www.celartem.com/en/download/）上，Document Express的版本似乎有点老，最新版似乎在另外一家公司caminova的产品页（http://www.caminova.jp/en/products/?src=products2.aspx）、下载页（http://www.caminova.jp/en/downloads/），所以我怀疑现在真正掌握DjVu技术的是新公司caminova，celartem不过是在玩资本运作。

最新版DjVu SDK也由caminova发行，但是在该公司的对外http网站（http://www.caminova.jp/en/）上找不到，只能通过https跳墙进去：
https://www.caminova.net/en/downloads/

还真是一堆不知所谓的公司啊……

三、玩DjVu的人

由于上述种种原因，DjVu在商用领域一直发不起来，但在某些地下扫描电子书界，却受到追捧。

追捧的原因很简单：地下扫描的电子书都需要通过互联网进行分享，因此对文件大小非常敏感，而且出于个人兴趣而去扫描电子书，要比拿钱完成扫描工作的更敬业，很少有低于300 DPI的，甚至鼓励用软件放大到600 DPI（详见《The Scan and Share tutorial》）。在这样高的分辨率下，字母文字用DjVu能获得极高的压缩率，有损JB2压缩出现错别字的概率也极小。

个人扫描电子书进行分享，当然不太可能去购买昂贵的商业DjVu软件，也不会在DjVu技术上花太多心思，所以我说是在“玩”DjVu。

俄罗斯的cracker世界闻名，据我所知“玩”DjVu玩得最出彩的也是俄罗斯的电子书界。而从我了解的情况看，俄罗斯cracker对DjVu SDK的兴趣不大，认为这个东东始终比商业软件慢个几拍，因此更热衷于使用商业DjVu制作软件，如果需要定制，也宁愿从最新版商业软件中摘取自己所需要的部分，最简单的例子就是DjVu Small。

受国外地下扫描电子书界影响，国内也有人跟风在玩DjVu。但是从我接触到的情况看，国内扫描电子书很少有能到300 DPI的，印刷、扫描效果也较国外差，在这种情况下采用有损JB2的影响目视可见。至于把16级灰度PNG格式的大图版PDG直接转换成DjVu，更是技术白痴的经典表现，我连笑话的心思都懒得起了。

四、小结

总之，在目前的情况下，向商业客户推荐采用DjVu格式保存扫描文档，算不上是一种很负责的行为，所以我最终劝那位从事扫描外包的老兄还是先等等看。

至于只是想“玩”，那就玩吧，注意保存好原始扫描格式就行，另外JB2尽量选无损压缩，插图或彩页的压缩比也别太狠。

当年列宁同志有个著名论断：出于贪婪的目的，资本家甚至会把用来绞死他们的绞索都买给我们。如果对DjVu片面追求压缩比，早晚也会往自己的脖子上亲手套一根绞索。

跋：我与DjVu

我与DjVu打交道，始于2006年开始接触PDG，因为当时流行快速版PDG，而解密后的快速版PDG = PDG文件头 + DjVu文件体。

不过有趣的是，在快速版PDG中，对JB2压缩的黑白文字部分没做什么改变，对采用IW44压缩（核心是小波压缩算法）的彩色图像却上下颠倒、颜色互换（红色、蓝色互换），所以碰到彩色的快速版PDG，直接从解密后的文件体提取出DjVu数据存盘，用DjVu浏览器看起来很别扭，只能颠倒回来后重新压缩一遍。

出现这种情况的原因不得而知，我猜测与某公司声称自己“掌握了小波压缩技术”有关，不做点手脚怎么证明自己“掌握”了？当然也可能仅仅是软件开发人员自己糊涂，搞不清RGB与BGR的区别。另外SSREADER的软件开发人员似乎并未对djvulibre的编译选项进行优化，导致DjVu解码效率有点低，不过快速版本来像素尺寸就不大，所以感觉不明显。

虽然在我刚接触PDG的时候，快速版PDG盛行一时，甚至有人提出“宁要快速版，不要清晰版”，但随着一批真正对技术感兴趣的人的努力，快速版PDG的真相逐步被揭开，尤其是有人提出因为在低分辨率下采用有损JB2压缩导致出现错别字的证据后，至少在readfree内，没人再去公开追求快速版了。

在接触PDG后不久，我接触到了DjVu电子书的另外一个重要来源——CADAL（又称“中美百万”）。从CADAL里我确实找到了一些PDG所没有的书籍，但CADAL以在线浏览为主，离线浏览并不便利。为此，我开始开发DjVuToy软件，这个软件最初的几个功能其实都是为从CADAL下载的书籍服务的。但是在CADAL开始往页面中添加水印，并采用大比例IW44压缩文字页面后，我终于忍无可忍，从此对CADAL再无丝毫兴趣。

离线浏览DjVu时，我注定不会去用IE插件，所以选择了WinDjView。但在用WinDjView浏览了一些书后，感觉白花花一片的背景也很难受，所以咬牙在UnicornViewer中加入了对DjVu的支持。

我有时候会帮朋友、同事找一些资料，但总有那么一些人不愿意使用不熟悉的浏览器，非要我把DjVu转换成PDF。随着我对DjVu的原理有所了解，感觉采用常规打印方式，或先转成通用图像格式再转成PDF的方式，对于DjVu的MRC模型、JB2压缩、IW44压缩都是一种亵渎，至少是一种不负责任的行为。为此，我花费了大半年的业余时间，研究DjVu转PDF的方法，核心思想就是尽量无损，并保持数据流长度基本一致。最终的成果就是《DjVu转PDF》一文，及DjVuToy中的“转PDF”功能。

这个过程让我对DjVu、PDF格式有了自己的理解，从此再不相信国内某些鹦鹉学舌的胡说八道，坚定了从此告别DjVu，转向PDF的决心。但其中有一根刺始终让我耿耿于怀：当时我始终不掌握图像分层技术，因此通用图像格式直接转PDF，始终达不到转DjVu的压缩率。

这个时候，某些无私的帮助出现了，终于有了DjVuToy中的“DjVu制作”功能。该功能也许与最新版的DjVu商业软件相比还有差距，但与早期版本的商业制作软件相比也不差什么了。

至此，我与DjVu的缘分终于圆满了，所以本文题目叫做“别了，DjVu！”。

（完）