作者：馬健
郵箱：https://www.bbsmax.com/A/xl56lZZmzr/stronghorse_mj@hotmail.com發布：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！”。

（完）

總結

以上是生活随笔為你收集整理的别了，DjVu！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。