Проблема - інь - під час кодування в DjVu
При кодуванні сканів книг у формат DjVu іноді виникає така проблема: деякі літери в файлі DjVu помилково підмінюються на інші, зовні схожі з ними літери (іноді це стосується і цифр). Найчастіше це підміна букв "і"-> "н" (або навпаки), чому ця проблема отримала назву "проблема інь" (також "ефект інь", або просто "інь" - усі ці терміни придумавAstra55 ).
Приклад проблеми "інь" у DjVu-файлі
Це досить серйозна проблема формату DjVu - і вона часом відвертає від цього формату людей, які намагаються розібратися з ним. Крім тексту, інь нерідко псує математичні та інші формули, що дуже суттєво.
Причина цієї проблеми - помилки класифікації символів у DjVu-кодувальнику, помножені на використання кодувальником "словників розділених символів" ("shared shapes dictionary", "djbz-словник").
Офіційна назва "проблеми інь" - Transposed Letters (термін, який використовується LizardTech). Ця проблема не залежить від мови тексту, що кодується в DjVu, а також вона може виникати не тільки щодо букв - але також і цифр, і взагалі будь-яких дрібних об'єктів, що повторюються на сканах.
При DjVu кодуванні зображення на скані сегментується на текст і фон, після чого текст потрапляє в шар маски, яка кодується в підформат JB2. Для зниження розміру одержуваного DjVu-файлу JB2-кодувальник розбиває все безліч сканів, що кодуються, на групи по 10-20 сканів (ця кількість регулюється параметром pages-per-dict), і створює для кожної такої групи словник розділених символів.
Якщо зображення двох різних букв візуально схожі - то при lossy-режимі кодувальник може помилково вирішити, що це та сама буква. Це особливість lossy-режиму - позначати досить візуально-близькі дрібніобрази тим самим чином - в djbz-словнику. В результаті в djbz-словнику замість двох символів виявиться один - і він буде розтиражований по всіх позиціях, які обидва символи займаються в тексті. Так і виникає помилка інь.
Описана поведінка характерна лише для lossy-режиму - тобто. "режиму із втратами даних". При використанні lossless-режиму ("безвтратного режиму") візуально-схожі образи так само позначаються у словнику "узагальненими" образами - але, на відміну від lossy, для кожного конкретного образу з тексту в словник записується "поправка" - різниця між "узагальненим" і даним чином – саме в цьому і полягає різниця між lossy та lossless, а також саме тому режим lossless принципово вільний від проблеми інь.
Можливості вирішення
На щастя, проблема інь не є непереборною. Існують два важливих методу її вирішення (все це розробивArcand ):
1. Відмова від "усереднення" символів словника
2. Боротьба з помилками класифікації символів
Розглянемо ці методи рішення докладніше.
Відмова від усереднення символів словника - це відключення режимів, у яких можуть бути помилки інь. До цього виду рішення належать такі прийоми:
1. Відмова від lossy на користь lossless. (DjVu Solo 3.1 це досягається шляхом вибору "clean", в DEE 5.1 треба виставити Text Quality як lossless).
2. Відмова від використання словника розділених символів.
3. Кодування сканів через віртуальний DjVu-принтер, а не через documenttodjvu. (ПридумавAstra55, але цей прийом - під великим питанням, тому що з теоретичної точки зору це не повинно давати бажаного ефекту).
При виборі будь-якого з цих прийомів виникнення помилок інь принципово неможливе. Однак, в обох випадках це призводитьдо відчутного зростання розміру DjVu-файлу – тому рішень цього виду слід по можливості уникати та застосовувати лише тоді, коли всі інші способи не дають ефекту.
Боротьба з помилками класифікації символів - це застосування різноманітних прийомів, спрямованих на зниження помилок класифікації символів у DjVu-кодувальнику. Сюди належить таке:
1. Зниження ступеня "жирності" тексту. Цього можна досягти різними способами: підбір особливих режимів сканування/обробки, або програмна обробка "утоньшення букв" (наприклад, в RasterID).
2. Застосування підвищуючого ресемплінгу (зручно Irfan View) з кроком 50-100 dpi (починаючи з 350 dpi, інь практично не проявляється). Як правило, ресемплінг роблять із 300 до 600 dpi.
3. Кодувати проблемні ділянки окремо, хороші окремо – з різними опціями, а потім об'єднувати їх у єдиний файл.
4. Робити трохи непропорційний ресемплінг (пікселів на 5 більше за вертикаллю).
5. Відмова від використання агресивних режимів кодування.
6. Зменшення розміру словника (це підвищує статистичні шанси правильної класифікації символів).
7. Для зображень, перетворених за схемою "300 dpi Greyscale - 600 dpi BW" використовувати параметр resolution-multiplier = 1 у профілі кодування DEE 5.1 - це знижує кількість помилок "інь" у них.
Ця стратегія боротьби з інь правильніша, ніж попередня (відмова від усереднення символів словника) - т.к. в цьому випадку ми боремося з інь не за рахунок збільшення розміру отриманого DjVu-файлу.
Витримка з хелпу до DEE 5.1
Резолюція-multiplier option зменшується (або maintains) розмір зображення для сегментації purposes. У документі експрес-сегментарі є встановлений для максимальної ефективності з зображеннями, що є 300 dpi.Якщо ви відчуваєте зображення, що є більш ніж 400 dpi, дорівнює величині 2 до резолюції-multipleer option. Якщо ви думаєте про segmenter, що він повинен skip every інших pixelів і рядок, коли його analyzes the image, thereby reducing the image's scanned resolution by half. Якщо ви відчуваєте зображення, що є нижче 400 dpi, дорівнює величині 1 до цієї опції до maintain the current resolution.
Чим дрібніший і жирніший текст, тим більше літери в ньому схожі один на одного, тим більша ймовірність інь. Ці критерії дозволяють заздалегідь оцінити скани з погляду виникнення інь.
На 600 dpi інь практично не виникає навіть за найбільш агресивного режиму DjVu-кодування. Винятком є випадок, коли книга сканується на 300 dpi Greyscale, а потім ресемплюється до 600 dpi BW. В цьому випадку можуть виникнути поодинокі помилки "інь".
додаток
Ось згадка проблеми "інь" на сайті LizardTech - у них це називаєтьсяTransposed Letters in Group 4 (G4) TIFF Text or Color Documents :
Де можна, scan at resolution of at least 300 dpi.
Якщо виконати документи з критичними номерами (e.g. фінансові доки) або від низької якості зображень (e.g. faxes), використовуйте "невеликі" опції в Advanced Text Settings в GUI версії, і "невеликі перемикання в command line".
Тобто. це найпростіше і найрадикальніше з усіх відомих нам рішень - відмова від lossy на користь lossless.