别了，DjVu！
作者：馬健
郵箱：stronghorse_mj@hotmail.com
發(fā)布：2010.05.21
目錄
一、DjVu技術(shù)
二、掌握DjVu技術(shù)的人
三、玩DjVu的人
四、小結(jié)
跋：我與DjVu
謹(jǐn)以此文紀(jì)念與DjVu打交道4周年！
=======================樸素的分隔線======================
在DjVuToy公開發(fā)布后，曾經(jīng)有某位專業(yè)從事掃描外包的朋友問我對DjVu前途如何看待，我當(dāng)時的回答是：如果DjVu的現(xiàn)狀得不到改變，在商業(yè)應(yīng)用方面就沒有任何未來可言，只能淪為掃描電子書愛好者手中的玩物。
這個所謂的“現(xiàn)狀”，指的就是：一項(xiàng)還算不錯的技術(shù)，落到了一幫糟糕的人手里。
這篇文章其實(shí)就是那次談話的一個整理，純屬一家之言。
一、DjVu技術(shù)
我說DjVu技術(shù)“還算不錯”，是因?yàn)?#xff1a;
1、DjVu基于ISO/IEC 16485 MRC（Mixed Raster Content）模型，在圖像分層、圖像編碼方面有一些獨(dú)到之處，因而造就了DjVu“壓縮率高”的名聲，其中的原因我在《DjVu轉(zhuǎn)PDF》的第二章“理論”部分已經(jīng)詳細(xì)描述過，此處從略。
2、由于專門定位于掃描文檔，不考慮文字顯示，因此在DjVu標(biāo)準(zhǔn)規(guī)范中可以省略字體等內(nèi)容，直接用UTF-8編碼表示可檢索的隱藏文字內(nèi)容，比PDF等格式更簡潔一些。
但是DjVu技術(shù)也并非完美無缺：
1、掃描分辨率與有損壓縮的誤碼率
DjVu在壓縮文字部分時通常采用JB2壓縮，可以是無損，也可以是有損。在有損情況下，如果掃描分辨率不足，可能會因?yàn)檎`碼而導(dǎo)致生成的DjVu出現(xiàn)錯別字，因此在我見過的DjVu相關(guān)技術(shù)文檔中，都強(qiáng)調(diào)掃描分辨率不要低于300 DPI。誤碼的原因、實(shí)例見《DjVu轉(zhuǎn)PDF》一文。
從目前的情況看，漢字的誤碼率要高于字母文字。
2、缺乏對灰度圖像的支持
在分辨率不足（低于200 DPI）的情況下，如果強(qiáng)制要求簡化成黑白二色，可能會出現(xiàn)文字殘缺的情況，而采用灰度圖像（如16級灰度），則可以在文件長度與顯示效果之間取得平衡，這也是PDG大圖版的做法。但不幸的是，DjVu格式本身對灰度圖像支持匱乏：
a) 如果轉(zhuǎn)換成單層DjVu，采用JB2壓縮顯然會出現(xiàn)上面說的筆劃殘缺問題，采用IW44壓縮則在大壓縮比下會模糊。
b) 轉(zhuǎn)換成雙層DjVu明顯不行，因?yàn)殡p層DjVu要求每個shape只能有一種顏色，而灰度圖像每個字有多級灰度。
c) 轉(zhuǎn)換成三層DjVu，灰度信息靠底層圖像提供，在采用大壓縮比（大比例縮圖、低碼率）情況下，文字會出現(xiàn)模糊，甚至成為灰灰的一團(tuán)。
解決辦法不是沒有，不過麻煩一點(diǎn)，效果如何要看技術(shù)和運(yùn)氣：放大（如從150 DPI放大至300 DPI）、處理后減色成黑白二色、轉(zhuǎn)換成JB2壓縮的單層DjVu。
3、對MRC模型支持的局限
DjVu基于ISO/IEC 16485 MRC三層模型，但是沒有考慮該模型的Stripes、N層模型等擴(kuò)展情況，因此插圖如果在整個頁面中所占比例不大，經(jīng)過大比例壓縮再放大顯示后，插圖看起來總是模模糊糊的，影響觀感。
4、批量處理難以擺脫人工干預(yù)
DjVu文件的壓縮率、生成后的視覺效果等，其實(shí)與圖像類型的準(zhǔn)確識別有很大關(guān)系。這里說的“圖像類型的準(zhǔn)確識別”，就是指在碰到一副掃描好的靜態(tài)圖像后，準(zhǔn)確判斷出應(yīng)該轉(zhuǎn)換成單層、雙層還是三層DjVu，并確定各層的壓縮比。這種判斷在很大程度上是一種經(jīng)驗(yàn)值，所以在商業(yè)DjVu制作軟件中，都有N多種預(yù)設(shè)值，需要人工進(jìn)行挑選，以獲得最佳效果。換句話說，如果所有文檔不分青紅皂白都按三層（document）進(jìn)行轉(zhuǎn)換，碰到前面說的灰度圖像時難免會哭笑不得。這些都給完全自動化批量DjVu生成帶來了困難。而商業(yè)應(yīng)用看重的恰恰是這種能力。
5、先天不足、內(nèi)外有別的格式標(biāo)準(zhǔn)
在我看來，DjVu其實(shí)不應(yīng)該算是一種“文檔格式”，而應(yīng)該算是一種“圖像格式”，因?yàn)榕cPDF等文檔格式比起來，欠缺的東西實(shí)在太多，包括多格式文本、矢量圖、多媒體、腳本、交互表單、權(quán)限控制、安全鑒別等等，所以只適合表示掃描圖像，而不適用于常規(guī)文檔。但即使這樣，DjVu格式本身也不是完全公開的格式（open format），如最新的“安全DjVu”（SDJVU）格式，就只有DjVu格式的商業(yè)擁有者Celertem公司才有，也只被該公司及其關(guān)系公司所提供的產(chǎn)品所支持，其他細(xì)節(jié)外界未知，所以被譏諷為“published format”，原帖地址：
http://www.djvu.org/forum/phpbb/viewtopic.php?t=422
該貼作者jrile是原PlanetDjVu社區(qū)的創(chuàng)始人兼站長，在DjVu社區(qū)也算大名鼎鼎。
6、工具與支持的匱乏
在現(xiàn)在這個時代，除非有MS Office這樣的強(qiáng)勢，否則一種文件格式的推廣應(yīng)用，離不開開源社區(qū)的強(qiáng)力支持。但是目前DjVu基本上算不上是一種開放的格式，除了前面說的文檔格式標(biāo)準(zhǔn)混亂外，最新、最好的DjVu格式生成工具、SDK都掌握在Celertem公司及其關(guān)系公司手里，這些都是要錢的，而且還很不便宜。
目前與DjVu相關(guān)的免費(fèi)、開源的東東，最終都可以追溯到djvulibre（http://sourceforge.net/projects/djvu/）的身上，理論上這個項(xiàng)目由DjVu的商業(yè)擁有者（最早是AT&T，然后是LizardTech）維護(hù)，但是實(shí)際上，與真正商業(yè)化的SDK相比，差得遠(yuǎn)了去：
a）djvulibre不具有最核心的功能——圖像分層功能，基本上只能制作單層DjVu，如果需要制作三層DjVu，則需要用其他代碼或工具解決圖像分層問題。僅此一條，就可以保證商業(yè)SDK不會被免費(fèi)的djvulibre所取代。
b）對于JB2壓縮，djvulibre不具有共享字典生成能力，生成的DjVu文件可能會比采用商業(yè)SDK生成的DjVu文件更大。
c）我以前看到的文檔曾說djvulibre的源代碼出自LizardTech代碼庫，與該公司發(fā)行的商業(yè)SDK采用的源代碼相同，但是真正找了LizardTech發(fā)行的商業(yè)SDK一編譯，才知道不是這么回事：SDK說明文檔會告訴你，此djvulibre非彼djvulibre；編譯器則會告訴你，你獲得的djvulibre源代碼與商業(yè)SDK使用的djvulibre源代碼相比，少了好些東西。
d）不知道是有意還是無意，盡管djvulibre聲稱采用了智能的內(nèi)存管理模式，但是實(shí)際用過的人都知道，這套源代碼的內(nèi)存漏洞多到數(shù)不清（我自己花了4年時間補(bǔ)洞），以致于我不相信任何一家稍有常識的商業(yè)軟件公司會基于這套源代碼，開發(fā)自己的商業(yè)應(yīng)用。
e）djvulibre源代碼是基于GPL的，這也在一定程度上堵塞了它的商業(yè)應(yīng)用之路。
f）djvulibre前后兩任的擁有者（LizardTech、Celertem）對該社區(qū)的支持并不多，如我前面說過的內(nèi)存漏洞問題，幾年前就有人提出，但是一直死不認(rèn)賬。對其他DjVu相關(guān)社區(qū)的支持就更是沒有，如jrile在關(guān)閉PlanetDjVu社區(qū)后，選取了該社區(qū)中的部分帖子，以《The Future of DjVu - Revisited》為題發(fā)布在djvu.org社區(qū)：
http://www.djvu.org/forum/phpbb/viewtopic.php?t=526
在這個帖子中，他對DjVu的種種看法，足以嚇到一般人。
除上述缺陷外，從技術(shù)上講，DjVu格式本身并不是不可替代的：DjVu所依賴的ISO/IEC 16485 MRC三層模型，同樣可以應(yīng)用到PDF上，并達(dá)到相似的壓縮比與視覺效果，詳見我寫的《DjVu轉(zhuǎn)PDF》一文。
有趣的是，djvulibre從v3.5.21開始，在Ddjvu例子中也加入了DjVu轉(zhuǎn)PDF功能，但采用的是libtiff的tiff2pdf源代碼。換句話說，是先把DjVu轉(zhuǎn)換成TIFF，然后再轉(zhuǎn)換成PDF，支持CCITT G4、JEPG、zip壓縮。這樣的轉(zhuǎn)換方式，不僅完全不管MRC三層模型，而且丟失了原JB2、IW44壓縮的高效率，轉(zhuǎn)換出來的PDF自然會增肥許多，然后某些人又可以振振有詞地說：你看，DjVu轉(zhuǎn)換成PDF以后就是會變大吧！
所以，DjVu技術(shù)盡管不錯，但也僅僅是“還算不錯”。
二、掌握DjVu技術(shù)的人
DjVu格式于1996年由AT&T提出，所以文件的頭4個字節(jié)就是“AT&T”。
AT&T在DjVu上的投入并不多，這一點(diǎn)從AT&T發(fā)布的源代碼和SDK可以看出。2000年時DjVu格式被倒賣給了LizardTech，一家專注于文檔掃描的公司。
LizardTech對DjVu文件格式規(guī)范、djvulibre的貢獻(xiàn)有目共睹，遺憾的是幾年后也撐不下去了，2007年被日本的Celertem所收購。但奇怪的是，在Celertem公司產(chǎn)品主頁（http://www.celartem.com/en/products/）、下載主頁（http://www.celartem.com/en/download/）上，Document Express的版本似乎有點(diǎn)老，最新版似乎在另外一家公司caminova的產(chǎn)品頁（http://www.caminova.jp/en/products/?src=products2.aspx）、下載頁（http://www.caminova.jp/en/downloads/），所以我懷疑現(xiàn)在真正掌握DjVu技術(shù)的是新公司caminova，celartem不過是在玩資本運(yùn)作。
最新版DjVu SDK也由caminova發(fā)行，但是在該公司的對外http網(wǎng)站（http://www.caminova.jp/en/）上找不到，只能通過https跳墻進(jìn)去：
https://www.caminova.net/en/downloads/
還真是一堆不知所謂的公司啊……
三、玩DjVu的人
由于上述種種原因，DjVu在商用領(lǐng)域一直發(fā)不起來，但在某些地下掃描電子書界，卻受到追捧。
追捧的原因很簡單：地下掃描的電子書都需要通過互聯(lián)網(wǎng)進(jìn)行分享，因此對文件大小非常敏感，而且出于個人興趣而去掃描電子書，要比拿錢完成掃描工作的更敬業(yè)，很少有低于300 DPI的，甚至鼓勵用軟件放大到600 DPI（詳見《The Scan and Share tutorial》）。在這樣高的分辨率下，字母文字用DjVu能獲得極高的壓縮率，有損JB2壓縮出現(xiàn)錯別字的概率也極小。
個人掃描電子書進(jìn)行分享，當(dāng)然不太可能去購買昂貴的商業(yè)DjVu軟件，也不會在DjVu技術(shù)上花太多心思，所以我說是在“玩”DjVu。
俄羅斯的cracker世界聞名，據(jù)我所知“玩”DjVu玩得最出彩的也是俄羅斯的電子書界。而從我了解的情況看，俄羅斯cracker對DjVu SDK的興趣不大，認(rèn)為這個東東始終比商業(yè)軟件慢個幾拍，因此更熱衷于使用商業(yè)DjVu制作軟件，如果需要定制，也寧愿從最新版商業(yè)軟件中摘取自己所需要的部分，最簡單的例子就是DjVu Small。
受國外地下掃描電子書界影響，國內(nèi)也有人跟風(fēng)在玩DjVu。但是從我接觸到的情況看，國內(nèi)掃描電子書很少有能到300 DPI的，印刷、掃描效果也較國外差，在這種情況下采用有損JB2的影響目視可見。至于把16級灰度PNG格式的大圖版PDG直接轉(zhuǎn)換成DjVu，更是技術(shù)白癡的經(jīng)典表現(xiàn)，我連笑話的心思都懶得起了。
四、小結(jié)
總之，在目前的情況下，向商業(yè)客戶推薦采用DjVu格式保存掃描文檔，算不上是一種很負(fù)責(zé)的行為，所以我最終勸那位從事掃描外包的老兄還是先等等看。
至于只是想“玩”，那就玩吧，注意保存好原始掃描格式就行，另外JB2盡量選無損壓縮，插圖或彩頁的壓縮比也別太狠。
當(dāng)年列寧同志有個著名論斷：出于貪婪的目的，資本家甚至?xí)延脕斫g死他們的絞索都買給我們。如果對DjVu片面追求壓縮比，早晚也會往自己的脖子上親手套一根絞索。
跋：我與DjVu
我與DjVu打交道，始于2006年開始接觸PDG，因?yàn)楫?dāng)時流行快速版PDG，而解密后的快速版PDG = PDG文件頭 + DjVu文件體。
不過有趣的是，在快速版PDG中，對JB2壓縮的黑白文字部分沒做什么改變，對采用IW44壓縮（核心是小波壓縮算法）的彩色圖像卻上下顛倒、顏色互換（紅色、藍(lán)色互換），所以碰到彩色的快速版PDG，直接從解密后的文件體提取出DjVu數(shù)據(jù)存盤，用DjVu瀏覽器看起來很別扭，只能顛倒回來后重新壓縮一遍。
出現(xiàn)這種情況的原因不得而知，我猜測與某公司聲稱自己“掌握了小波壓縮技術(shù)”有關(guān)，不做點(diǎn)手腳怎么證明自己“掌握”了？當(dāng)然也可能僅僅是軟件開發(fā)人員自己糊涂，搞不清RGB與BGR的區(qū)別。另外SSREADER的軟件開發(fā)人員似乎并未對djvulibre的編譯選項(xiàng)進(jìn)行優(yōu)化，導(dǎo)致DjVu解碼效率有點(diǎn)低，不過快速版本來像素尺寸就不大，所以感覺不明顯。
雖然在我剛接觸PDG的時候，快速版PDG盛行一時，甚至有人提出“寧要快速版，不要清晰版”，但隨著一批真正對技術(shù)感興趣的人的努力，快速版PDG的真相逐步被揭開，尤其是有人提出因?yàn)樵诘头直媛氏虏捎糜袚pJB2壓縮導(dǎo)致出現(xiàn)錯別字的證據(jù)后，至少在readfree內(nèi)，沒人再去公開追求快速版了。
在接觸PDG后不久，我接觸到了DjVu電子書的另外一個重要來源——CADAL（又稱“中美百萬”）。從CADAL里我確實(shí)找到了一些PDG所沒有的書籍，但CADAL以在線瀏覽為主，離線瀏覽并不便利。為此，我開始開發(fā)DjVuToy軟件，這個軟件最初的幾個功能其實(shí)都是為從CADAL下載的書籍服務(wù)的。但是在CADAL開始往頁面中添加水印，并采用大比例IW44壓縮文字頁面后，我終于忍無可忍，從此對CADAL再無絲毫興趣。
離線瀏覽DjVu時，我注定不會去用IE插件，所以選擇了WinDjView。但在用WinDjView瀏覽了一些書后，感覺白花花一片的背景也很難受，所以咬牙在UnicornViewer中加入了對DjVu的支持。
我有時候會幫朋友、同事找一些資料，但總有那么一些人不愿意使用不熟悉的瀏覽器，非要我把DjVu轉(zhuǎn)換成PDF。隨著我對DjVu的原理有所了解，感覺采用常規(guī)打印方式，或先轉(zhuǎn)成通用圖像格式再轉(zhuǎn)成PDF的方式，對于DjVu的MRC模型、JB2壓縮、IW44壓縮都是一種褻瀆，至少是一種不負(fù)責(zé)任的行為。為此，我花費(fèi)了大半年的業(yè)余時間，研究DjVu轉(zhuǎn)PDF的方法，核心思想就是盡量無損，并保持?jǐn)?shù)據(jù)流長度基本一致。最終的成果就是《DjVu轉(zhuǎn)PDF》一文，及DjVuToy中的“轉(zhuǎn)PDF”功能。
這個過程讓我對DjVu、PDF格式有了自己的理解，從此再不相信國內(nèi)某些鸚鵡學(xué)舌的胡說八道，堅(jiān)定了從此告別DjVu，轉(zhuǎn)向PDF的決心。但其中有一根刺始終讓我耿耿于懷：當(dāng)時我始終不掌握圖像分層技術(shù)，因此通用圖像格式直接轉(zhuǎn)PDF，始終達(dá)不到轉(zhuǎn)DjVu的壓縮率。
這個時候，某些無私的幫助出現(xiàn)了，終于有了DjVuToy中的“DjVu制作”功能。該功能也許與最新版的DjVu商業(yè)軟件相比還有差距，但與早期版本的商業(yè)制作軟件相比也不差什么了。
至此，我與DjVu的緣分終于圓滿了，所以本文題目叫做“別了，DjVu！”。
（完）
轉(zhuǎn)載于:https://www.cnblogs.com/stronghorse/p/4913417.html
總結(jié)
- 上一篇： windows内核中杀任意进程，可杀36
- 下一篇： MessageBox只弹出一次