Пишу, по большей части, про историю, свою жизнь и немного про программирование.

JBIG2

У нас в документообороте всё больше используется формат ПДФ, но с ним есть проблема — документы из некоторых сторонних организаций к нашим клиентам приходят на бумаге, по факсу или каким-то ещё подобным способом, причём объём такой корреспонденции незначительным назвать трудно.

Пока мы такие документы помещаем в ПДФ сканами в хорошем качестве в формате ДжПЕГ. Увы, это довольно расточительно. К счастью, ПДФ поддерживает не один, а целых три формата графики — ДжПЕГ, ДжПЕГ 2000 и ДжБИГ2. На последний я возлагал большие надежды.

Идея этого формата очень интересна и проста. Если у нас есть скан документа, его значимую часть в основном занимают буквы и цифры, если найти при помощи распознавания одинаковые символы, то их можно закодировать по одному разу, а в остальных местах использовать просто ссылки на них. Текстовые сканы действительно ужимаются значительно (я пробовал), тем более, что формат двухбитный (только для чёрно-белых изображений), чего для документов вполне хватает.

Ошибки JBIG2 (34.98КиБ)

К сожалению, у формата есть серьёзный недостаток, на который я тут же и наткнулся.

Алгоритм устроен так, что он подбирает не просто одинаковые символы, а похожие. Это разумно — принтеры печатают неравномерно из-за бумаги и тонера, при сканировании вносятся искажения, а при передаче факсом их становится ещё больше. Вот тут и приходит беда — кодек может перепутать похожие, но разные символы, что для документа совершенно недопустимо.

Посмотрите, у меня на скриншоте выше — оригинальный ПДФ (слева) и ПДФ, где графика перекодирована в ДжБИГ2. Как видно при кодировании были перепутаны «п» и «и», «п» и «н». Для слов в документах может это ещё и не смертельно, но для цифр в суммах — беда.

Мне неясно можно ли что-то сделать в этом месте, возможно можно подредактировать кодек так, чтобы он реагировал только на 100% совпадение, но тогда, скорее всего, пропадёт всякий смысл использовать ДжБИГ2.

Остаётся ещё вариант с ДжПЕГом 2000, но с ним возможно, выигрыш будет столь незначительным, что затраты на конвертацию просто не окупятся.

18 комментариев
Азат Аюпов 2015

Думаю, можно изменить существующий кодер или даже написать свой, с продвинутыми алгоритмами выявления совпадений, и уменьшить количество ошибок, но они всё равно останутся. К тому же, когда возможности алгоритма выявления совпадений подходят к своему пределу, в OCR-софте используются дополнительные средства, как изменение контраста изначального изображения, так и проверка правописания после распознавания. Но это нельзя (сложно) применить в jBig2-кодере.
Мне кажется, этот формат подходит для книг и статей, где ошибки некритичны, но никак не для документов.

Но! Алгоритм применяется очень широко, оказывается. http://www.computerra.ru/79247/jbig2/  — статья 2013 года в Компьютерре о баге в сканерах Xerox, в комментариях и Brother упомянуты.
Ещё похожий алгоритм применяется в .djvu-документах, где также бывают ошибки.

Евгений Степанищев (bolknote.ru) 2015

Комментарий для Азат Аюпов:

Про djvu я уже писал ( http://bolknote.ru/all/3344 ), но про ошибки не слышал.

hshhhhh.name 2015

Комментарий для Евгения Степанищева:

А почему вы не используете fine reader? Сам бог велел :).
Ошибки то тоже будут, но зато настоящий pdf!

Евгений Степанищев (bolknote.ru) 2015

Комментарий для hshhhhh.name:

Имеется ввиду их MRC что ли? Или что? Ошибки недопустимы.

Sergey Cheban (sergey-cheban.livejournal.com) 2015

На википедии пишут, что у jbig2 есть lossless mode.

Евгений Степанищев (bolknote.ru) 2015

Комментарий для sergey-cheban.livejournal.com:

Вроде как есть, да. Я пока не нашёл утилиту, в которой он бы работал.

Михаил Иванов (m-ivanov.livejournal.com) 2015

Полагаю, коллега hshhhhh.name имел в виду «почему вы не распознаете документы, а храните картинки».

Евгений Степанищев (bolknote.ru) 2015

Комментарий для m-ivanov.livejournal.com:

Потому что софта, который распознаёт на 100% не существует.

hshhhhh.name 2015

Комментарий для Евгения Степанищева:

Потому что софта, который распознаёт на 100% не существует.

Но в текущей же ситуации разницы никакой :)

Евгений Степанищев (bolknote.ru) 2015

Комментарий для hshhhhh.name:

Почему же никакой? Сейчас мы используем сканы, на сканах человек всё прочитает в точности, а он распознаёт буквы пока точнее машины, в случае сомнений он просто запросит бумагу ещё раз, тогда как программа подставит туда что-то похожее.

someone 2015

В самановсих доках упоминается ccitt — для чистых однобитных сканов group 4 отлично подходит. пыдыфами не занимался.

Евгений Степанищев (bolknote.ru) 2015

Комментарий для someone:

PDF внутри поддерживает строго определённые графические форматы. Group 4 среди них нет.

Scan 2015

Фраза «PDF внутри поддерживает строго определённые графические форматы.» неверна. PDF это контейнер, что в него положат, то он и поддерживает. Изображение кладутся в raw. Вопрос поддержки скорее касается программ просмотра PDF. Смогут ли они прочесть такой PDF? CCITT 4 часто встречается в PDF и проблем с ним нет.

Евгений Степанищев (bolknote.ru) 2015

Комментарий для Scan:

Тогда что угодно можно назвать контейнером. Я, например, внутрь JPEG могу положить GIF. Означает ли, что фраза «JPEG не поддерживает GIF» не верна? В формате PDF описаны строго определённые форматы, которые поддерживаются.

CCITT 4 часто встречается в PDF и проблем с ним нет.

Конечно нет, потому что эти изображения упомянуты в стандарте PDF.

Максим 2016

Добрый день!
FineReader поддерживает JBIG2 lossless.

Форматов изображений PDF поддерживает больше — ZIP, LZW, JPBIG2, CCIT4 FaxDecode, JPEG, JPEG2000, все они поддержаны в FineReader.

Евгений Степанищев (bolknote.ru) 2016

Комментарий для Максим:

ZIP и LZW не форматы изображений.

Максим 2016

Очень часто изображения в виде сырых данных жмутся ZIP и LZW.

Евгений Степанищев (bolknote.ru) 2016

Комментарий для Максим:

Жать можно чем угодно. Но ZIP и LZW не форматы изображений.