DjVu (информация за начинаещи)

Предназначение

Да предположим, че сте сканирали документ, който трябва да изпратите в електронен вид. Какъв формат ще използвате?

Ако документът е черно-бял, няма проблем — ще използвате например TIF CCITT G4 (тип компресия, която се използва и от факс-апаратите) и ще получите файл с приемлив размер. Но ако има и цветни картинки? Не можете да използвате JPEG с впечатляващата му компресия, защото всички контрастни участъци (каквито са областите с букви) ще бъдат размити. В крайна сметка ще бъдете принудени да използвате пълноцветен формат без големи загуби, за да гарантирате, че при получателят ще пристигне нещо, което много прилича на сканираното.

Именно за разрешаването на този проблем, през 1996 г. фирмата AT&T разработва формата DjVu (произнася се „дежа ву“). Както всички гениални идеи, и тази е много проста. Сканираната страница се разделя на цветни и черно-бели участъци, като цветните се кодират с алгоритъм IW44 (много напомнящ на JPEG2000, но оптимизиран за бързо декодиране), а черно-белите — чрез BZ2, който осигурява зашеметяващи резултати при кодиране на сканиран текст, но за това — малко по-късно.

Нека повторя — форматът DjVu е разработен специално за съхраняване на сканирани документи и последващото им пренасяне по електронен път. Именно поради тази причина всякакви сравнения с PDF са неуместни — PDF е векторен формат, предназначен за представяне на компютърно генерирани страници, докато DjVu е растерен формат, предназначен за представяне на сканирани страници.

Кодиране

Тъй като една картинка говори повече от хиляди думи, нека разгледаме един пример:

Слоеве в DjVu-файл

Една страница се представя чрез три слоя:

• Заден фон: пълноцветно изображение, обикновено се кодира със средна разделителна способност (100-300 dpi). Цветните картинки се помещават в този слой.

• Преден фон: пълноцветно изображение, представящо цвета на контрастните участъци (например букви). Обикновено се кодира с ниска разделителна способност (25-75 dpi).

• Маска: черно-бяло изображение, ограничаващо контурите на контрастните участъци от предния фон. Кодира се с висока разделителна способност (300-600 dpi).

Маската указва участъците от предния фон, които са видими; останалата част е прозрачна. Това се наслагва върху задния фон, като резултатът е изходната страница, представена чрез много добра компресия. Разбира се, в една страница не е задължително да присъстват и трите слоя — например при черно-бял текст е нормално да има само маска (в този случай цветът на предния слой се приема за черен), или само фон (при страница, състояща се само от картинка), както и други комбинации. Маската и предния фон се наричат обобщено „преден слой“ (foreground), а задният фон — „заден слой“ (background).

В едно от по-късните разширения на DjVu се появява възможност за указване на цвят на конкретен сегмент от маската, което позволява кодиране на малоцветни изображения само в един слой. За съжаление, до момента няма лесен и универсален начин да се възползвате от тази възможност.

В кодирането на цветните слоеве (преден и заден) няма специфични особености; важното тук е да се подбере подходяща комбинация от разделителна способност и качество на компресия, в зависимост от особеностите на изходното изображение. Цялата мощ на DjVu-форматът се проявява в кодирането на черно-бялата маска. Там се използва алгоритъм, който разбива изображението на отделни сегменти (най-често това са буквите от текста), след което ги кодира по следния начин: всеки уникален знак се записва само веднъж, а при появяването на знак, който много прилича на някой от вече кодираните, се използва запомнения, като се добавят и разликите с текущия знак. Групата от записани уникални знаци се нарича „речник“. Пример:

JB2-кодиране

Поради малкия размер на изображението съм приложил уголемен вариант, който показва разликите между кодираните знаци и този от речника.

Сами се досещате, че при чист изходен скан кодираният файл ще е с много малък размер, защото буквите ще са почти сходни, докато при по-некачествено изображение — например блед печат, неподходящи настройки при сканиране и т.н. — големината на кодирания файл ще нараства пропорционално на разликите. За по-фина настройка на кодирането е предвиден параметър, който указва каква част от разликите да се вземат предвид — в режим „lossless“ се записват всички разлики, а в режим „aggressive“ — нито една. Някои JB2-кодери използват по-интелигентен алгоритъм и записват в речника не първия появил се уникален знак, а неговата „средна“ стойност, определена по статистически признак измежду всички появявания на този знак в кодирания текст, което води до значително подобряване външния вид на текста (защото моментните дефекти в някои букви биват „замазани“ от по-често срещаните коректни начертания).

В началото форматът е разрешавал в един файл да се съхранява само една сканирана страница. В последствие се появява възможност за пакетиране на няколко страници в един файл, като новият тип получава името „bundled“, а старият — „indirect“. Като следствие от това се появява и възможността кодиращите програми да съставят един речник на символите от няколко поредни страници, което допълнително намалява размера на изходния файл. За съжаление потребителите много често злоупотребяват с тази възможност, като дефинират речник, обхващащ цялата книга. Защо това е некоректно, е друга тема; за момента приемете на доверие, че нормалните стойности за речника са 10-20 страници.

Сегментация

Както беше показано по-горе, процесът на кодирането в DjVu включва три етапа: разделяне на сканираното изображение на цветни и черно-бели участъци, кодиране на цветните участъци чрез IW44 и кодиране на черно-белите чрез JB2. Именно разделянето на изображението (терминът е „сегментиране“) предизвиква най-големите проблеми при кодиране. Обикновено инструкциите за изготвяне на DjVu включват пример с множество черно-бели страници и една цветна — тоест, типичната книга (без илюстрации) с обложка — като се обяснява как се кодират черно-белите страници, как се кодира обложката и накрая — как се слепват двете части. Да, но тази схема не работи при страници със смесено съдържание — текст и картинки.

Тук влиза в действие сегментаторът. За съжаление изкуственият интелект още не е изобретен, затова автоматичното разделяне на страниците на текст и картинки почти никога не работи както трябва. В това отношение сегментацията много прилича на оптичното разпознаване на символи (OCR) — може да разпознаете даден текст и директно да го публикувате (без редакция), но ще е наивно да смятате, че всичко в него е коректно. Ето един пример:

• 

  Оригинален файл

• 

  Автоматично сегментиран DjVu

Първата картинка е оригиналното изображение, втората — кодираният DjVu-файл (кодирано е със 100 dpi, затова е леко размазано). Обърнете внимание на плътните синкави участъци в перата на шапката — сегментаторът ги е разпознал като сходни зони и ги е изпратил в предния слой, а не в задния, както би трябвало да бъде.

Втори пример — тук сегментаторът е объркан поради пресичането на текста и орнамента, поради което е изпратил буквите „И“ и „К“ в задния фон, което си личи по лекото им замъгляване и избледняване:

Грешки в сегментиране на текст

Авторите на DjVu-програмите са много добре запознати с този проблем, затова са се опитали да го тушират чрез различни настройки — един стандартен кодировчик с автоматичен сегментатор има повече от 40 параметъра, управляващи дейността му, което на практика го превръща в напълно неизползваем продукт. Затова всички, които често се занимават с изготвяне на DjVu-книги, предпочитат ръчно да разделят изходните изображения. Всъщност по-правилният израз е „полуавтоматично“, защото специализираните програми за обработка на сканирани изображения като ScanKromsator и ScanTailor имат механизъм за отделяне на участъците, които сте маркирали като картинки, в отделни файлове, след което те могат да бъдат кодирани в правилния слой. Дори са разработени специфични програми, които улесняват разделното кодиране и последващото слепване на слоевете в крайния DjVu-файл.

Профили

В предишната точка споменах за множеството настройки на сегментатора. Като добавим към тях и настройките на двата кодировчика, задачата по пренастройка на програмата за кодиране например от цветно към черно-бяло се превръща в дейност, подходяща единствено за мазохисти. Затова разработчиците са предвидили няколко готови набора от настройки за най-често срещаните схеми за кодиране, които се наричат „профили“. Във всичките ми известни програми за кодиране тези профили са записани във външен файл, което ви дава възможност да ги коригирате според собствените си предпочитания и дори да добавяте нови профили за специфични задачи.

Най-честият набор от профили включва „Photo“, „Scanned“, „Clear“ и „Bitonal“. Профилът „Photo“ е предназначен за кодиране на страници, съдържащи само картинки; „Scanned“ — за сканирани комбинирани изображения (тексти и графика); „Clean“ — същото като „Scanned“, но за компютърно генерирани страници (което предполага чист фон и еднообразни букви); „Bitonal“ — за страници, съдържащи само текст. Разбира се, изборът на конкретен профил не ви ограничава до вградените в него настройки; в общия случай можете да промените който и да е параметър, за да постигнете по-добри резултати.

Други възможности

• OCR. Форматът DjVu поддържа създаването на OCR-слой — скрит текст, който може да бъде копиран от потребителя или да бъде използван за търсене по думи. Тъй като предназначението му е чисто спомагателно (най-вече за търсене), при изготвянето му не се извършва редакция на разпознатия текст. Ако качеството на разпознаване е много лошо, просто не се добавя OCR-слой; редакцията е напълно излишна, защото в този случай е по-уместно да създадете някой от текстовите формати, а не DjVu — нека припомня, че форматът е предназначен да представя сканирани страници, а не чисто текстова информация.

• Съдържание. Поддържа се йерархично съдържание с неопределен брой нива. Няма проблем с използването на кирилица при съставянето му.

• Хипервръзки. Произволен фрагмент от DjVu-страницата може да бъде зададен като препратка към друга страница, и дори към страница в друг файл. Тази възможност се използва най-вече за по-голяма интерактивност при изобразяване на страницата със съдържанието на книгата.

• Анотации. Допуска се добавянето на няколко вида анотации — графични и текстови, с различно начертание. Те се записват в самия файл и стават неделима част от него. В последствие могат да се изтрият без да предизвикат неприятни странични ефекти.

• Метаданни. В началото форматът не поддържа метаданни, но в момента се поддържат три варианта: PDF DocInfo, XMP и BibTex. Последните два варианта все още не са утвърдени и са в тестов стадий.

Програми

Какви са наличните възможности в момента? Можем да разделим кодировчиците на две групи, които условно ще наречем „универсални“ и „единични“, в зависимост от това дали включват в себе си автоматичен сегментатор или не.

Към универсалните спадат documenttodjvu и msepdjvu. Първият представлява ядрото на всички визуални системи, предлагани на пазара, включително безплатния DjVu Solo и платените му наследници Document Express Editor (съкратено DEE). Тези програмни пакети са просто визуална обвивка около documenttodjvu, който извършва всички дейности по сегментацията и кодирането. Вторият (msepdjvu) пък е ядрото на всички виртуални принтери, които се предлагат отделно от визуалните системи. Защо за двете дейности се използват различни кодировчици — нямам никаква представа. Но е факт, че работят по различен начин, най-вече в областта на сегментацията на малоцветни изображения.

Интересно е да се отбележи, че програмата documenttodjvu е с размер около 2 мегабайта. Предлаганият към нея графичен интерфейс също не е голям, но за да се осигури възможност за вграждане на OCR-слой, към дистрибутива е добавен и пакета за оптично разпознаване IRIS, при което общият размер нараства до 50, 80, а понякога и до 190 MB — в зависимост от включените в дистрибутива езици за разпознаване. Затова често се разпространяват орязани версии, от които е премахната възможността за OCR; а има и програми като DjVu Small, които включват само documenttodjvu и прост, но функционален графичен интерфейс към него.

От единичните кодировчици можем да споменем пакета DjVu Libre, който разполага с почти пълен набор от конзолни програми за работа с DjVu-файлове — за кодиране чрез JB2 и IW44, за „слепване“ на кодирани слоеве в една DjVu-страница, за обединяване на няколко DjVu-файла в един, за извличане на страници и/или слоеве от DjVu-файл, както и за извършване на някои допълнителни операции. Има и самостоятелни кодировчици, сред които най-известен е minidjvu (JB2-кодировчик), който въпреки бавната си работа генерира впечатляващи резултати.

Има и доста програми, изпълняващи дейности, които не са предвидени от стандартните обработчици; чрез които съответното действие се извършва по-бързо и по-интуитивно, или които просто са заместители на функции от комерсиалните пакети. Такива са например програмите за имплантиране на OCR-слой (чийто автор е българин; браво, Генчо!), за добавяне/редактиране на съдържание, анотации, препратки и т.н.

Колкото до програмите за разглеждане на DjVu-файлове — и там има достатъчно голям избор, при това само от безплатни програми. Към пакета DjVu Libre се предлага самостоятелен браузер; LizardTech също предлага безплатна добавка към интернет-браузерите, която отваря DjVu-файлове, но за Windows (и Mac) препоръчвам да се използва WinDjView (или съответно MacDjView), тъй като е далеч по-удобна и интуитивна за работа от другите програми.

Лъжички катран

Е, и в света на компютрите не може да има перфектни неща. Ето малко допълнителни факти, наблюдения и лични впечатления, които развалят общата картинка и пречат на утвърждаването на DjVu като масов стандарт.

• JB2-кодиране: Тъй като критериите за определяне сходството на два символа са доста размити, при кодиране с параметър „lossy“ и надолу можете да видите ефект на заместване на дадена буква с друга; най-често се проявява при сканове на 300 dpi. В текстове на кирилица това се случва с буквите „и“ и „н“, поради което руснаците наричат тази замяна „ефектът «ин»“. Ако промените настройките на кодировчика така, че да кодира с по-малко загуби, или използвате източник с по-голяма разделителна способност (600 dpi), този ефект изчезва.

• Некоректен OCR: Вероятно поради недобро познаване на наличните средства за работа с DjVu, в интернет се разпространява инструкция за кодиране с OCR-слой, чрез която изображенията на буквите са припокрити (и съответно унищожени) от текста, разпознат от OCR-програмата. И тъй като (както беше обяснено по-горе) никой не редактира скрития текст, това довежда до унищожаване на цели страници от документа. Типичен (и то реален!) пример:

Некоректно поставен OCR-слой

• Сложност: Потребителят е мързелив. Той не иска да „следва наново“, а да пусне програмата, да й зареди сканираните изображения и да получи готов DjVu-файл. За съжаление на сегашния етап това е невъзможно. Ако изходният материал е със строго разграничени страници — само цветни и/или само черно-бели — кодирането е сравнително елементарно, макар че и там има скрити подводни камъни, на които можете да се натъкнете. Но ако се появи страница със смесено съдържание, масовият потребител или се отказва от използването на DjVu, или започва да твори глупости — използване на автоматично сегментиране, което води до повреди в изображенията; използване само на Photo-режим, което води до ненужно нарастване размера на крайния файл (и до неуместни коментари от вида на „ама че скапан формат — получих дори по-голям файл“); кодиране на щрихови рисунки в режим „Bitonal“, което води до препълване на речника и т.н., и т.н.

• Липса на възможности: За съжаление не всички ситуации, които се срещат в изходните сканове, могат да се автоматизират. Например в момента няма „чиста“ схема за кодиране на малоцветни изображения със застъпващи се сегменти, или за кодиране на текст, разположен върху цветен фон. Подобна е ситуацията и с цветния текст, макар че по тази тема има разработени някои „патерици“, на които да се опрете при обработката.

• Метаданни: Да, форматът поддържа метаданни, но за какво са ми, след като само DjView4 (от пакета DjVu Libre) ги визуализира? Всички останали програми ги пренебрегват напълно. Освен това (колкото и да рових) така и не успях да намеря списък с допустимите елементи в DocInfo; основните не включват неща като „сканирал“ и т.н.

• Сложен OCR: Да, форматът поддържа OCR-слой. Само че за да добавите такъв, трябва да осигурите текстов файл, в който да има списък с всички думи и техните координати, при това — групирани по редове, зони, страници и т.н. Доколкото знам, само TesseractOCR може да генерира сходни файлове, но качеството му на разпознаване не е особено високо. ABBYY FineReader осигурява много по-добре разпознат текст, но не предлага запис във формат, годен за преобразуване. Един заобиколен вариант е да се използва програмата на Генчо, която на базата на проект от FineReader генерира такъв файл и дори го имплантира в крайното DjVu, но тя работи само с FineReader 7, 8 и 9, а освен това дава неочаквани грешки в някои специфични страници от проекта.

• Собственици: Политиката на собствениците на DjVu-формата е много неясна. AT&T продават технологията на LizardTech, която се опитва да я използва за комерсиални цели, но в последствие я предава на родителската фирма Celartem, която от своя страна (през 2009 г.) я предава на Caminova. Както казва един от активните участници в DjVu-общността, „… човек остава с впечатлението, че този формат е някакъв горещ картоф, от който всички се чудят как да се отърват по-бързо“. И още малко цитати от същия източник:

… задават следния въпрос: „Ако DjVu е толкова хубав формат, защо на Запад на практика никой не знае за него, а използват само растерен PDF?“ Отговорът е прост — както често се случва в живота, добрият продукт не винаги взема връх над посредствения. Работата е там, че корпорацията Adobe има в пъти по-големи финансови възможности от собствениците на DjVu-формата. Аналогична ситуация се получава и с други продукти […]

Освен това самите собственици имат голяма вина за непопулярността на DjVu на Запад. Дълги години те следваха напълно вяла и аморфна пазарна политика. Да започнем с това, че често не отговаряха на електронните си писма (дори на известни западни DjVu-деятели, а не само на мен). После — те произвеждаха (и продължават да го правят) нелепи и глупави програми за работа с DjVu (свръхскъпи, огромни по размер и т.н.). Колко вреда нанесе например шизофреничната идея с виртуалните принтер-касети за всички DjVu-програми (това беше преди няколко години) — накратко, те искаха да накарат потребителите да плащат индивидуално за всяка създадена DjVu-страница! Слава богу, че тази глупост умря от естествена смърт и сега комерсиалните DjVu-програми се активизират просто чрез въвеждане на сериен номер.

Собствениците на DjVu-формата и до ден-днешен не са публикували спецификациита на версиите. А това е нещо елементартно — така да се каже, „а“-то и „б“-то на нормалния бизнес. […] Също така дълги години нямаше пробна версия на DjVu SDK за свободно изтегляне (която се появи неотдавна — след дългогодишно прекъсване).

Има още едно съществено обстоятелство: Caminova не предоставя безплатен SDK за декодиране на DjVu (и редакция на анотации). Тази функционалност влиза в платения DjVu SDK, което, очевидно, силно затормозява популяризирането на DjVu-формата. […]

Леон Боту, един от създателите на DjVu-формата, се изказа за политиката на LizardTech (тогава тя притежаваше правата върху DjVu-формата) по следния начин: „They are cutting the hen that lays the golden eggs“, което в превод означава „Те колят кокошката, която снася златни яйца“.

Няма какво повече да се добави. Комерсиалните програми наистина са проектирани доста глупаво — там дори липсва елементарната възможност да посочиш различен профил за отделните страници, затова се налага да правиш отделни DjVu-та (по едно за всеки преход между профилите) и после да ги слепваш, което води до загуба на оптимизацията на речника. А неофициалните програми са насочени най-вече към хората, които знаят какво правят и как точно да го постигнат, затова не са по силите на „редовия“ потребител.

Приятно и безпроблемно DjVu-кодиране! :-)

Mandor

януари, 2011 г.