CuneiForm для DjVu

[monday2000]

N.M.E.

а что ж по твоему означает всё это множество цифр после title="x_bboxes?
конечно же это координаты букв))

Да, весьма вероятно. Я это, конечно же, и сам заметил с самого начала.

Просто я ещё не проверял практически - так ли это на самом деле. Элементарно не успел.

и использовать надо именно эти координаты, складывая их затем в слова или строки..

Если это окажутся действительно координаты букв - то я так и сделаю - в смысле, сложу из них слова (как опцию). Вообще в DjVu могут быть такие виды привязки OCR-данных: page, column, region, para, line, word, or char - см. http://djvu.sourceforge.net/doc/man/djvused.html . В принципе, многое из этого, если не всё, можно вытащить из hOCR - я подумаю над этим.

Проверил сейчас hocr2djvuxml на примере скана с картинкой. На удивление, сработал верно. Хотя я специально такой случай не предусматривал. А ведь там в hOCR выводится HTML -тег <img> со всеми сопутствующими последствиями.

Ещё хотелось бы проверить hocr2djvuxml на hOCR-файле, содержащем таблицы в HTML-тегах. Но для этого нужно, чтобы CuneiForm сгенерировал такой hOCR-файл - чтобы я мог иметь его перед глазами для подстройки hocr2djvuxml на него.

Ещё я добавлю отсекание парных тегов <u> и одиночного тега <br> - увидел в коде CuneiForm, что они могут быть выведены в hOCR-файл.

Конечно, hocr2djvuxml надо бы протестировать на как можно большем числе реальных сканов - чтобы выявить возможные глюки (если они есть).

[monday2000]

Я обнаружил, что djvuxmlparser не умеет вставлять в DjVu OCR-слой, детализированный по буквам.

Я сделал Файнридером распознанный DjVu, детализированный на уровне букв (а не слов, как обычно). Благо, что DjVuOCR позволяет сделать побуквенную детализацию.

Затем экспортировал из этого DjVu OCR-данные в XML посредством djvutoxml. И попытался вставить полученный XML-файл обратно в DjVu при помощи djvuxmlparser. OCR-слой не вставился.

Похоже, что такая возможность в djvuxmlparser просто-напросто не реализована.  Очень странно и нехорошо. Вот в djvused это есть, к примеру.

Я написал вчера письмо Леону Боту и Биллу Риемерзу. Пока в ответ тишина. Проблема в том, что, как я понял, Леон Боту активно недолюбливает XML - а взамен хочет, чтобы все использовали только лишь djvused и его LISP-подобный язык. Леон мне ещё ранее сказал, что он не занимается DjVuLibre XML-утилитами, а занимается ими их автор - Билл Риемерз.

Только вот иметь дело с Биллом не очень-то хотелось. Он ИМХО не слишком горит желанием лишний раз шевельнуть ... рукой ради DjVu - в отличие от Леона.

Как бы не пришлось ещё со всех дел самостоятельно делать такую фичу в djvuxmlparser...

Да и вообще, djvuxmlparser выглядит гораздо менее развитым по сравнению с djvused. Хотя, в отличие от djvused, djvuxmlparser умеет менять в DjVu-файле DPI и гамму.

Лично мне хотелось бы со временем полностью перейти от djvused к DjVuXML-утилитам (djvuxmlparser и djvutoxml). А для этого DjVuXML-утилиты нужно доразвить до возможностей djvused. Можно также и слить их в единую утилиту - это ИМХО вполне логично. Ведь djvused тоже не разбит на 2 разные утилиты.

Пускай Леон твердит, что, мол, "djvused-язык ничем не хуже, а наоборот, легче, чем XML" - всё равно куда там тягаться djvused-языку с XML! Это даже не смешно. XML имеет мировую популярность и используется настолько везде, что сам бог велел использовать его и в DjVu.

Посмотрел я ещё раз на hOCR-файлы, порождаемые CuneiForm. Да, действительно, там имеется информация о координатах каждой буквы - т.е. это OCR-слой, детализированный по буквам.

Это очень хорошо и здорово. Побуквенную детализацию можно использовать для создания "умного деспекла".

Я мог бы, пожалуй, теоретически сделать программу, которая будет удалять прямо из готового DjVu "соринки" между буквами (по принципу despeckle) - используя информацию о координатах прямоугольников, описанных вокруг каждой буквы (побуквенная OCR-детализация). Такие соринки - это те же шейпы, что и для букв используются. Эта задача во многом была бы аналогична раскраске маски (с точки зрения её запрограммирования). Правда, лучше для этого будет всё равно Файнридер использовать. CuneiForm даже для такой задачи всё равно слабоват.

[monday2000]

Леон Боту прислал мне ответ. Приведу его вместе с моими вопросами:
1. Не могли бы Вы попросить Билла Риемерза, чтобы он исправил этот баг?

Dream on. The problem is not that he does not want but that he does not have time.
Many parts of the library, including the xml code, have been rewritten by LT without paying attention to the maintenance cost. For instance the xml system has tweaks designed to work around bugs of the early lizardtech plugins and the error message files are essentially dead wood.
This is not acceptable in my book.
I do not have time to deal with that.

2. Если этот баг исправлю я - Вы внесёте исправление в DjVuLibre?

Then I would name you the official maintainer of the xml tools with long term mission to disentangle it from the library.
For instance djvutoxml could work using the ddjvuapi.
For djvuxmlparser, things are not very clear yet...

3. Я объяснил Леону, что мне не нравится djvused-язык - я предпочитаю XML, и мне не нравится использование Python в hocr2djvused.

Ah. Some people like xml, some people like python :-).
All of them are a mystery to me.

4. Я спросил Леона, почему DjVuLibre не использует STL - ведь тогда с DjVuLibre было бы привычнее работать.

When we wrote djvulibre in the late 90s, the c++ compilers where nowhere as mature as now, and the stl implementations were buggy, incompatible with each other, and not usable with threads. Thread support in g++ was so bad that we had to write our own threading code and patch the compiler.

5. Как пример, я написал, что до сиз пор путаюсь в этих самодельных классах GUTF8String, GNativeString и т.д.

But the basic problem here is thread safety. 
Djvulibre uses thread safe smartpointers in many places, including strings, to make many classes, including the strings, thread safe with minimal use of locks.
This is not for performance, but when you ask other developpers to lock things, they inevitably create deadlocks that are hellish to debug.
Thread safety in stl strings is still a problem..

Meanwhile the GNativeString/GUTF8String and all the internationalization is one of these LT catastrophies. The initial code had a single string class that was understood as an array of bytes, not an array of chars.

Hope it helps.

- L.

Ответ, в общем, как видно, весьма неутешительный. Ясно, что никто из них не поможет мне исправить djvuxmlparser. У Билла "нет времени", а Леон просто не любит XML в принципе.

Прийдётся действовать самостоятельно. То есть, самому попытаться исправить djvuxmlparser. Только непонятно, как же потом внести исправление в DjVuLibre-djvuxmlparser. Ну ладно, как-нибудь разберёмся.

Оказывается, внутри DjVuLibre всё весьма негладко. Как говорит Леон, там есть немало проблемного неоптимального кода.

[monday2000]

Новая версия:

hocr2djvuxml

Версия:  v1.1.

Скачать:

http://www.djvu-soft.narod.ru/soft/hocr2djvuxml.rar  (127 КБ)

Исходники - внутри.

Прежняя версия по линку http://www.djvu-soft.narod.ru/soft/hocr2djvuxml_v1_0.rar удалена - я решил теперь все версии выкладывать по единому линку - так проще.

Что нового:

- Добавлено форматирование по параграфам PARAGRAPH.

- Добавлена детализация по словам WORD и по буквам CHARACTER. Прежняя детализация по строке LINE убрана (за ненадобностью). По умолчанию детализация теперь делается на уровне WORD.

- Добавлена поддержка многостраничного DjVu.

- Пробел в конце строки обрезается (если он есть).

Синтаксис:

hocr2djvuxml [-char] <hOCR_path> <DjVuXML_path> [<DjVu_page_name>]

-char - включение режима побуквенной детализации.

<DjVu_page_name> - внутреннее имя файла страницы многостраничного DjVu-файла, которую мы обрабатываем. Предназначено для выборочной обработки отдельных страниц многостраничного DjVu-файла. Жаль, что нельзя к ним обращаться по номеру страницы - а только по имени файла.

Побуквенная детализация пока не имеет смысла - т.к. djvuxmlparser её не поддерживает. Буду думать, как сделать её поддержку там.

[monday2000]

Залез сейчас на скорую руку в исходник - djvuxmlparser.cpp . Действительно, обработка CHARACTER-детализации даже не реализована вообще. Как видно, это было сделано с подстройкой на текущий (на тот момент) LizardTech DjVu-плагин. Вот какой коммент я увидел в коде:

// the plugin thinks there are only Pages, Lines and Words
// so we don't make Paragraphs, Regions and Columns zones
// if we did the plugin is not able to search the text but
// DjVuToText writes out all the text anyway

Немного посмотрев код, я увидел, что саму работу по внедрению любой мета-информации делает модуль DjVuTXT. Причём и djvuxmlparser, и djvused оба лишь просто вызывают этот модуль - для непосредственной обработки DjVu мета-текста. Просто djvuxmlparser обращается не ко всем возможностям DjVuTXT - по сравнению с djvused.

Это обстоятельство даёт некую смутную надежду на возможность реализации нужного функционала в djvuxmlparser. Надо лишь суметь вызвать из djvuxmlparser соответствующие функции из DjVuTXT.

Сложная, конечно, задача - но деваться некуда. Возвращаться к использованию djvused я уже не хочу.

[monday2000]

Я сделал патч для djvuxmlparser, реализующий побуквенную детализацию (!). Занёс его на сайт DjVuLibre в раздел патчей:

https://sourceforge.net/tracker/?func=detail&aid=3122379&group_id=32953&atid=406585

Сообщил Леону Боту и Биллу Риемерзу.

Проверил - вроде нормально работает. Посмотрим, как отреагируют Леон с Биллом (если отреагируют). Исправление довольно простое по сути - так что вероятность его правильной работы высока ИМХО.

[monday2000]

Пришёл ответ от Билла Риемерза:

Hi,

Character detalization was deliberately left out of the code, as it was
felt the need for it was extremely small, but the extra overhead is
significant.   However, that does not mean I opposed to adding it if, it
meets a real world need.   Can you briefly describe why you need this?
Also, can you supply the change as a unified diff, as it makes it easier
to visually verify the change?

Leon, what are your thought on this change?

Bill

Я ему ответил, что побуквенную детализацию умеет выдавать любая нормальная OCR-программа, и поэтому даже и не надо задумываться, зачем именно это может быть нужно. Плюс привёл 2-3 конкретных возможных применения этой фичи.

Я ему даже diff сделал и отправил - чтобы ему не к чему было теперь придраться.

[monday2000]

Мне пришло 2 письма.

1. Письмо Леона Боту к Биллу Риемерзу (копия мне)

I am not against it, provided that it does not break anything.
For instance I wouldn't like character details
to suddenly appear in files that are not supposed to contain it.
What do you think of the patch (pretty short in itself).

- L.

2. Ответ Билла Риемерза Леону Боту (копия мне)

The patch looks good to me.   I could not write anything better.   Personally I am in favour of the change.   However, I should state why it was originally left out, since the people involved in making that decision are not here to speak for themselves.

The whole purpose of DjVu is document compression.   I good part of data compression is deciding what data to keep, and what can safely be discarded.   Within the functionality of DjVu, there is really no need to know the coordinates of an individual character.   The bounding boxes given by the typical OCR engine are not accurate enough to do a better job highlighting, copying the text, etc.   The storage of the coordinates in the text layer is not that efficiently done, so storing this data makes the compression ratio significantly worse with no real gain.   If you want the coordinates for something like despeckling, or some other image processing purpose it is better to perform the operation in pre-processing rather than to add the data to the document itself.

What I had proposed at the time, was we allow character coordinates to be specified, however, we make a flag that has to be enabled for it, so people don't just add in the extra data by accident...   However, it was viewed that no OCR vendor would be willing to just throw away the data.   So every OCR implementation would end-up including the unnecessary data.  This opinion is actually supported by monday2000's comment:

 "The main reason why is that all the decent OCR programs can output the CHARACTER-detalized OCR-info. So I don't need to think "why" - if the OCR-producers decided that it is needed than it's enough for me."

If we applied that type of thinking to DjVu, we would only do lossless encoding.  The whole idea of lossy compression is throwing away data you don't really need.   Having it is not a good enough reason to keep it.

Mainly because open source is all about allowing choices.   Just because I want to discard data, does not mean someone should be forced to discard it.  I find I sometimes apply monday2000's thought process myself when lossy encoding.   For example, when I create MP4's from DVD's I will include an extra audio track for the original audio track on the DVD.   Certainly, that reduces my compression ratios.   However, I choice to keep the data because the extra 10% file size is a small price to pay to have that data available should I need it in the future to re-encode to a different format.   I could well see someone wanting to do the same with DjVu.   Keep the coordinates, if for no other reason so that they have it should they decide to convert to another format that requires it in the future.   Also, some OCR engines are much more accurate about character bounding boxes than others.   If one is using a fairly accurate OCR engine, then they could well use the character coordinates for some nifty real time viewing effects.   

However, I do think we need either a command line switch or a macro wrapping for the patch.   Otherwise we will find people who are relying on the automatic discarding of this data to get smaller DjVu files will suddenly have larger files.   Most of them will not even know why.

Bill

Я написал им обоим, что считаю излишним добавление специального ключа командной строки в djvuxmlparser, который будет разрешать включение побуквенных координат. Потому что уровень детализации - пословный или побуквенный - целиком определяется видом XML-файла, подаваемого на вход djvuxmlparser. Пусть это у юзера болит голова по поводу правильности составления именно такого XML-файла, который ему нужен.

Короче, Билл что-то тут пытается мудрить на ровном месте. Хорошо хоть, он не возражает против добавления моего патча.

[monday2000]

Мне пришло письмо от Леона Боту:

Ok. I just committed the changes in CVS.
I also changed the DTD to mention the character tag.
Curiously the xml output already had code for this tag.
- L.

Вот исправление: http://djvu.cvs.sourceforge.net/viewvc/djvu/djvulibre-3.5/libdjvu/XMLParser.cpp?r1=1.13&r2=1.14

Я перекомпилировал djvuxmlparser с этим исправлением:

http://www.djvu-soft.narod.ru/soft/djvuxmlparser.rar  (253 КБ)

Теперь djvuxmlparser официально поддерживает побуквенную детализацию.

[monday2000]

Я нашёл ещё 2 бага в djvutoxml. Добавил их описание в раздел BUGS сайта DjVuLibre:

https://sourceforge.net/tracker/?func=detail&aid=3124541&group_id=32953&atid=406583

Не работает опция --page и её нельзя ставить первой опцией.

Написал письмо Биллу Риемерзу с просьбой устранить их.

[monday2000]

Интересная заметка: http://habrahabr.ru/blogs/linux/109052/

[monday2000]

Билл молчит. Я сам исправил эти 2 бага и отправил diff уже не только Биллу, но ещё и Леону.

[monday2000]

Оказывается, Леон подправил тогда ещё и файл DjVuOCR.dtd:

http://djvu.cvs.sourceforge.net/viewvc/djvu/djvulibre-3.5/share/djvu/pubtext/DjVuOCR.dtd?r1=1.1&r2=1.2

[N.M.E.]

А вот обновлённая  версия djvused:

http://www.djvu-soft.narod.ru/soft/djvused.rar  (700 КБ)

Синтаксис такой: djvused sample.djvu -u -e 'output-txt' > 1.txt

Это скомпилированные мною экзешники в MS VC++ 6.0. Готовы к работе и никаких dll не требуют.

содержит баг - при запуске с командой dump для ОДНОСТРАНИЧНОГО файла копия этого файла создается в корне диска с каким-то левым именем..
да и синтаксис вывода в авторской версии немного другой..

[monday2000]

N.M.E.

при запуске с командой dump для ОДНОСТРАНИЧНОГО файла копия этого файла создается в корне диска с каким-то левым именем..

Спасибо за подсказку! Это очень старый и широко известный баг. Я его смог воспроизвести. Причём в djvused из DjVuLibre 3.5.23 этот баг не проявил себя - значит, там он уже пофиксен.

Такой баг будет нелегко устранить. Дело в том, что я использую исходники DjVuLibre 3.5.17 - поскольку они компилируются в MS VC++ 6.0. Все более поздние релизы DjVuLibre предназначены для более современных компиляторов.

Поэтому я не могу так просто сказать Леону об этом баге - он же скажет "возьмите последний релиз и скомпилируйте". Буду думать, как его устранить в моей версии djvused.

да и синтаксис вывода в авторской версии немного другой..

Синтаксис поддерживается одинаковый - я же взял djvused.cpp из CVS и скомпилировал - поэтому у меня не может быть какой-то иной синтаксис. У меня работают оба варианта:
djvused -u -e output-txt sample.djvu > 1.txt (леоновский)
djvused sample.djvu -u -e 'output-txt' > 1.txt (это я использовал)