DjVu 這個格式有什麼好處，有什麼前途？
做一回搬運工，貼出來。下面是馬健先生（老馬）的文章《別了，djvu!》別了，DjVu！
作者：馬健
郵箱：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格式本身也不是完全公開的
格式（openformat），如最新的「安全DjVu」（SDJVU）格式，就只有DjVu格式的商業擁有者Celertem公司才有，也只被該公司及其關係公司所提
PlanetDjVu ? View topic
供的產品所支持，其他細節外界未知，所以被譏諷為「published
format」，原帖地址：
該貼作者jrile是原PlanetDjVu社區的創始人兼站長，在DjVu社區也算大名鼎鼎。
6、工具與支持的匱乏
在現在這個時代，除非有MS
Office這樣的強勢，否則一種文件格式的推廣應用，離不開開源社區的強力支持。但是目前DjVu基本上算不上是一種開放的格式，除了前面說的文檔格式
標準混亂外，最新、最好的DjVu格式生成工具、SDK都掌握在Celertem公司及其關係公司手裡，這些都是要錢的，而且還很不便宜。目前與DjVu相關的免費、開源的東東，最終都可以追溯到djvulibre（SourceForge.net: Invalid Project
/djvu/）的身上，理論上這個項目由DjVu的商業擁有者（最早是ATT，然後是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社區後，選取了該社區中的部分帖子，以《TheFuture of DjVu - Revisited》為題發布在http://djvu.org社區：
PlanetDjVu ? View topic
在這個帖子中，他對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年由ATT提出，所以文件的頭4個位元組就是「ATT」。
ATT在DjVu上的投入並不多，這一點從ATT發布的源代碼和SDK可以看出。2000年時DjVu格式被倒賣給了LizardTech，一家專註於文檔掃描的公司。LizardTech對DjVu文件格式規範、djvulibre的貢獻有目共睹，遺憾的是幾年後也撐不下去了，2007年被日本的Celertem所收
購。但奇怪的是，在Celertem公司產品主頁（http://www.celartem.com/en/products/）、下載主頁（http:
//http://www.celartem.com/en/download/）上，DocumentExpress的版本似乎有點老，最新版似乎在另外一家公司caminova的產品頁（Caminova -&> Cuminas transition
/products/?src=products2.aspx）、下載頁（http://www.caminova.jp/en/downloads
/），所以我懷疑現在真正掌握DjVu技術的是新公司caminova，celartem不過是在玩資本運作。https://www.caminova.net/en/downloads/
最新版DjVu SDK也由caminova發行，但是在該公司的對外http網站（Caminova -&> Cuminas transition）上找不到，只能通過https跳牆進去：
還真是一堆不知所謂的公司啊……三、玩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！
搜一下老馬對 djvu 的觀點吧，很全面了。
推薦閱讀：
※如何在ppt轉成pdf的時候不犧牲動畫效果？
※Mac怎麼在PDF中使用三指取詞？
※有沒有迅捷PDF編輯器的註冊機或者破解版？
※有沒有什麼好方法下載ISSUU上面的pdf資源！？