» Scan Tailor: Часть 2

ycheff
Если dpi были неверные, но в целом похожие на правду, то СТ их скушает без вопросов, в противном случае при загрузке должен был попросить поправить dpi проблемных страниц.

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

Можно поправить dpi в файле проекта - но это зависит от того, насколько вы умеете работать с XML.

Проблемы с DPI должны были проявиться еще на стадии задания полей - необязательно было прогонять страницы через вывод.

Можете еще посмотреть здесь

Сделал однопроходный DjVu-кодер. Работает, хотя и медленно. Делит вывод Scan Tailor на слои и вставляет их как отдельные чанки. Прошу тестировать. Зависимости: bash + getopt +mktemp, ImageMagick, DjVu Libre, minidjvu.
http://github.com/ashipunov/img2djvu

iit512

Несколько замечаний/пожеланий по скрипту:

1. Нельзя ли предусмотреть возможность указания маски, по которой будут отбираться имена файлов для обработки? Собственно, можно было бы даже жестко прописать в скрипте что-то вроде for f in *.tif* *.TIF* . А то всё-таки требование не иметь в рабочей директории ничего, кроме графических файлов, прямо скажем, весьма обременительно.

2. Как я понимаю, сейчас нет возможности отдельно задать разрешение для текстового и картиночного слоя, а между тем это ключевой момент корректного DJVU-кодирования.

3. У Вас есть опция, отвечающая за выбор уровня агрессивности, но на соответствующий параметр minidjvu и cjb2 она напрямую не влияет (фактически можно лишь включить или выключить режим сжатия с потерями). Между тем minidjvu, на мой взгляд, дает наилучшие результаты при уровне агрессивности 200 вместо умолчательных 100.

4. Насколько я могу видеть, minidjvu сейчас вызывается в одностраничном режиме. На практике это означает, что разницы между кодированием через minidjvu и cjb2 нет почти никакой (точнее, она заключается лишь в том, что в cjb2 используется более старый вариант того же кодера). Конечно, было бы гораздо интереснее задействовать многостраничный режим сжатия, но для этого придется сначала подвергать сепарации все файлы, а потом все текстовые страницы разом прогонять через minidjvu.

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

Спасибо за быстрый ответ.

Цитата:

1. Нельзя ли предусмотреть возможность указания маски, по которой будут отбираться имена файлов для
обработки? Собственно, можно было бы даже жестко прописать в скрипте что-то вроде for f in *.tif* *.TIF* . А то всё-таки требование не иметь в рабочей директории ничего, кроме графических файлов, прямо скажем, весьма
обременительно.

Я бы не сказал, что оно обременительно. Разве трудно положить в некую папку исключительно графические файлы? Это можно сделать средствами любого коммандера. К тому же, как Вы правильно подметили, уже TIFF формат имеет два обычных расширения (а может быть и *.Tiff, и *.tiFF), а мне хотелось бы, чтобы пользователь не "заморачивался" с форматами, а просто напихал бы в папку все, что переваривает ImageMagick (хоть PCX, хоть Targa). Но я подумаю.

Цитата:

2. Как я понимаю, сейчас нет возможности отдельно задать разрешение для текстового и картиночного слоя, а между тем это ключевой момент корректного DJVU-кодирования.

С этого момента поподробнее, пожалуйста Сначала я делал, как советуете Вы и monday2000 -- уменьшал размер цветного слоя перед тем, как выделить чанки. Но DjView 4 на это ужасно ругался и картинку не отображал. Тогда я плюнул и стал просто размывать. Ведь эффект-то будет почти тот же. Или нет?

Цитата:

3. У Вас есть опция, отвечающая за выбор уровня агрессивности, но на соответствующий параметр minidjvu и cjb2 она напрямую не влияет (фактически можно лишь включить или выключить режим сжатия с потерями). Между тем minidjvu, на мой взгляд, дает наилучшие результаты при уровне агрессивности 200 вместо умолчательных 100.

Спасибо! Сделаю --agression 200 для моего -a 2. А для cjb2 что сделать посоветуете? -losslevel 200 ?

Цитата:

4. Насколько я могу видеть, minidjvu сейчас вызывается в одностраничном режиме. На практике это означает, что разницы между кодированием через minidjvu и cjb2 нет почти никакой (точнее, она заключается лишь в том, что в cjb2 используется более старый вариант того же кодера). Конечно, было бы гораздо интереснее задействовать многостраничный режим сжатия, но для этого придется сначала подвергать сепарации все файлы, а потом все текстовые страницы разом прогонять через minidjvu.

Нет, если подряд идут две и более черно-белые страницы, minidjvu вызывается именно в многостраничном режиме. Попробуйте менять размер словаря, и Вы это увидите. Но для сепарированных файлов Вы правы, я не придумал, как вызывать minidjvu многостранично. Может быть, Вы придумаете? Покуда утешаюсь тем, что это не даст серьезной экономии.
А cjb2 используется для того, чтобы не инсталлировать minidjvu в том случае, если это почему-то не хочется делать.

Цитата:

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

Очень рад был бы посмотреть на Ваш скрипт.

Добавлено:
А еще у меня вопрос к U235 (иди тому, кто знает в чем дело). Новая версия скрипта LayerTailor содержит строку:
===
rem раскомментировать следующую строку, если растровые рисунки темные (учитывать
автомаску)
rem gm composite -compose Add txt\%%i cache\automask\%%i -compress Group4 txt\%
%i
===
Нет ли у кого примера такого скана? И вообще, откуда берется эта "automask"? Из скрипта это неясно.

iit512
Сейчас это совершенно не актуально, этот скрипт был написан еще тогда, когда в ST еще не было резервирования уровней 0 и 255 для черного и белого.
Automask бралась из папки проекта ST \cache\automask\.
ИМХО, оптимальный вариант это единая утилита на базе minidjvu и c44, принимающая на входе файлы сразу после ST.
Кстати, полгода назад экспериментировал с cjb2, (убрал ограничения на агресивность и добавил большую корректность при работе с буквами "и" и "н" при больших степенях сжатия) если надо, то могу выложить исходники/exe.

Цитата:

Я бы не сказал, что оно обременительно. Разве трудно положить в некую папку исключительно графические файлы? Это можно сделать средствами любого коммандера.

Просто у каждого своя собственная методика работы, и эта методика вполне может предполагать наличие в папке с обработанными сканами чего-то еще. Это могут быть еще какие-то скрипты, распознанные страницы в формате hocr или, скажем, текстовый файл с оглавлением. Кое-что из этого может быть рассчитано на другие варианты обработки того же самого материала (скажем, кодирование в pdf). Можно, конечно, и убрать всё это хозяйство из директории непосредственно перед обработкой, но делать так каждый раз будет крайне неудобно.


Цитата:

С этого момента поподробнее, пожалуйста Сначала я делал, как советуете Вы и monday2000 -- уменьшал размер цветного слоя перед тем, как выделить чанки. Но DjView 4 на это ужасно ругался и картинку не отображал.

Он ругается потому, что ему нужно, чтобы размеры маски были строго кратными размерам фона. Естественно, это требование будет нарушено, если, к примеру, мы пытаемся понизить разрешение с 600 до 300dpi при том, что обработанный скан имеет нечетное количество пикселей по высоте или ширине. К сожалению, СТ не позволяет контролировать пиксельные размеры файлов на выходе, из-за чего и получаются такие казусы.


Цитата:

Тогда я плюнул и стал просто размывать. Ведь эффект-то будет почти тот же. Или нет?

Мне кажется, это будет просто потеря качества при сохранении неоправданно большого размера. Размытие, конечно, стоит делать для избавления от растра, но никак не для уменьшения веса картинки.


Цитата:

А для cjb2 что сделать посоветуете? -losslevel 200 ?

А вот с cjb2, думаю, лучше не рисковать. Проблема в том, что там используется старая, неотрегулированная версия алгоритма, которая дает избыточное сжатие за счет некорректных подстановок. Правда, уменьшение уровня агрессии в таких случаях обычно тоже не спасает


Цитата:

Нет, если подряд идут две и более черно-белые страницы, minidjvu вызывается именно в многостраничном режиме. Попробуйте менять размер словаря, и Вы это увидите.

Спасибо за разъяснение: значит, я плохо смотрел.


Цитата:

Но для сепарированных файлов Вы правы, я не придумал, как вызывать minidjvu многостранично. Может быть, Вы придумаете?

А в чем проблема? Точно так же из каждого закодированного файла извлекаем блок Sjbz, который потом объединяем с заранее подготовленным фоном. Просто делать это придется в цикле.

И, кстати, совершенно не нужно записывать трехслойные файлы с черным квадратом Малевича в качестве блока FG44. В текущей версии djvumake можно вместо этого написать FGbz=#black, что гораздо более корректно.







Добавлено:
U235

Цитата:

убрал ограничения на агресивность

Зачем же их было убирать? cjb2 и так дает избыточную степень сжатия.


Цитата:

добавил большую корректность при работе с буквами "и" и "н" при больших степенях сжатия

Если бы дело было только в этих буквах... У меня вот как-то вместо всех "i" появилась правая половинка от буквы "n" с характерным закруглением, а точки над ними сделались треугольными, поскольку кодировщику почему-то приглянулся ошметок от заглавного "E" с засечкой. Короче говоря, алгоритм безусловно требует правки, но только в сторону большей жесткости, подобно тому, как это было сделано в minidjvu.

U235:

Цитата:

Сейчас это совершенно не актуально, этот скрипт был написан еще тогда, когда в ST еще не было резервирования уровней 0 и 255 для черного и белого.

Понятно, спасибо! Кстати, а как Ваш скрипт цитировать? Я сослался на эту ветку форума, но вряд ли это правильно.

Цитата:

ИМХО, оптимальный вариант это единая утилита на базе minidjvu и c44, принимающая на входе файлы сразу после ST.

Ну так я ее и сделал. img2djvu -m 20 -l 1 [имя_папки]

Цитата:

Кстати, полгода назад экспериментировал с cjb2, (убрал ограничения на агресивность и добавил большую корректность при работе с буквами "и" и "н" при больших степенях сжатия) если надо, то могу выложить исходники/exe.

Буду очень благодарен. Особенно за исходники.
И еще вопрос к Вам: стОит ли добавлять возможность обработки через GraphicsMagick вместо ImageMagick? Сильно ли первый быстрее на критической для меня операции подсчета уникальных цветов?



Добавлено:
anagnost96

Цитата:

...но делать так каждый раз будет крайне неудобно.

OK, подумаю, как лучше. Возможно, сделаю еще одну опцию. А может, просто игнорировать все неграфические файлы?

Цитата:

К сожалению, СТ не позволяет контролировать пиксельные размеры файлов на выходе, из-за чего и получаются такие казусы.

Что же делать?

Цитата:

Мне кажется, это будет просто потеря качества при сохранении неоправданно большого размера.

Я проверял. Размер чуть выше, качество сравнимое. А если использовать convert -blur 0x2, то размер совсем невелик.

Цитата:

А вот с cjb2, думаю, лучше не рисковать.

Хорошо, не буду.

Цитата:

А в чем проблема? Точно так же из каждого закодированного файла извлекаем блок Sjbz, который потом объединяем с заранее подготовленным фоном. Просто делать это придется в цикле.

Проблема в том, что утилита однопроходная. То есть после того, как она обработала картинку (или несколько черно-белых картинок в случае minidjvu со словарем > 1), больше к файлу она не обращается. Предложенный Вами подход требует радикального усложнения алгоритма, и я пока не придумал, как это сделать.
Цитата:

можно вместо этого написать FGbz=#black

Отлично! Не знал. А в какой версии это появилось? Upd.: скачал, посмотрел. Появилось только что (15 августа). Этой версии (3.5.23) нет даже в PPA, не говоря уже о моем основном дистрибутиве (Ubuntu 10.04). К тому же ни одна утилита не выдает номера версии Я думаю, стОит подождать, тем более что экономию это даст слабую (10-15 килобайт на типичную страницу 600 dpi). Время вот сэкономит, это правда.
===
Так как насчет скрипта?

Добавлено:
И еще:
Вот я тут написал, чтобы не дублировать -- http://jurassic.ucoz.ru/forum/9-740-3344-16-1285953920

А можно ещё раз выложить версию с функцией выпрямления строк?

Цитата:

Что же делать?

Нужно приводить пиксельные размеры файлов к значениям, кратным двенадцати (для 600dpi), как это рекомендуется спецификацией djvu. Это можно сделать с помощью того же convert.


Цитата:

Этой версии (3.5.23) нет даже в PPA, не говоря уже о моем основном дистрибутиве (Ubuntu 10.04).

Ну в CVS-то оно уже больше года как было. В принципе можно и предложить людям обновиться.


Цитата:

К тому же ни одна утилита не выдает номера версии

Ну почему же. Вот я запустил djvumake без параметров, и она мне в числе прочего выдала:

DJVUMAKE --- DjVuLibre-3.5.22


Цитата:

Я думаю, стОит подождать, тем более что экономию это даст слабую (10-15 килобайт на типичную страницу 600 dpi).

Тут не в экономии дело, а в том, что просмотрщик может отказаться сглаживать текст в трехслойном файле.


Цитата:

Так как насчет скрипта?

Хорошо, выложил пока вот здесь: http://www.thessalonica.org.ru/downloads/gendjvu-shared.sh .

В отличие от Вашего, скрипт жестко привязан к определенным расширеням файлов и понимает следующие их типы:

-- *.tiff (без дополнительного расширения) -- черно-белая текстовая страница;
-- *.bg.tiff -- фоновое изображение;
-- *.fg.tiff -- цветное изображение для формирования блока FG44;
-- *.color.tiff -- полноцветное изображение, из которого djvumake сформирует блоки BG44 и FG44, используя черно-белую страницу в качестве маски;
-- *.color -- текстовый файл, содержащий спецификацию цвета (с возможным указанием зон раскраски) для передачи через опцию FGbz.

Цитата:

Нужно приводить пиксельные размеры файлов к значениям, кратным двенадцати (для 600dpi), как это рекомендуется спецификацией djvu. Это можно сделать с помощью того же convert.

Наверно, лучше всего -- добавлять белые поля, как Вам кажется? Потому что если -resize, то черно-белые компоненты довольно сильно попортятся, да и долго это. Кстати, результатом что -resize, что -border неизбежно будет то, что страницы получатся разного размера. Разве это хорошо?

Цитата:

В принципе можно и предложить людям обновиться.

Понимаю, но это не Ubuntu-way.

Цитата:

DJVUMAKE --- DjVuLibre-3.5.22

Спасибо! Не заметил этого, искал опции. Теперь можно попробовать сделать проверку версии.

Цитата:

росмотрщик может отказаться сглаживать текст в трехслойном файле.

Да, вспомнил соответствующие эпизоды с сайта djvusoft.

Цитата:

Хорошо, выложил пока вот здесь: http://www.thessalonica.org.ru/downloads/gendjvu-shared.sh

Спасибо большое! Изучу.
Тем временем я нашел путь обходить не-графические файлы в папке (просто convert ... || continue ; ) и заодно поправил агрессивность у minidjvu (спасибо Вам!), получилась version 0.9c. Придумал алгоритм, как включить черно-белые куски в поток minidjvu (см. TODO), но на реализацию и особенно отладку нужно много времени, которого пока нет.
Я подумал, что было бы хорошо еще в этот комбайн вставить вызов cuneiform и hocr2djvu, которые добавят к каждой странице еще и текстовый слой. Это будет довольно просто, поскольку все равно *.pnm-файлы присутствуют, сэкономим на конвертировании. hocr2djvu еще довольно сырой (как и cuneiform-linux-multilang), но можно просто игнорировать ошибки на отдельных страницах. С другой стороны, может быть, вообще не надо мучаться со вставкой текстового слоя? Вместо этого на основе того же cuneiform писать продвинутые плагины к desktop search engines (типа Recoll), которые будут делать OCR на лету. Это снимет множество проблем.

iit512
По поводу корректных размеров субсканов меньшего разрешения почитайте здесь.

Цитата:

Буду очень благодарен. Особенно за исходники.
И еще вопрос к Вам: стОит ли добавлять возможность обработки через GraphicsMagick вместо ImageMagick?

http://www.onlinedisk.ru/file/524821/
Единственное, там в исходниках возможно надо будет подобрать коэффициенты чуствительности к различию и-н.
GraphicsMagick вроде бы быстрее, но насколько - не знаю.
anagnost96

Цитата:

Зачем же их было убирать? cjb2 и так дает избыточную степень сжатия.

Я хотел посмотреть как ведет себя кодек при высоких losslevel, не всегда замена символов просходит при значении 200,бывает и на 180, бывает и на 240 (все зависит от скана и от шрифтов).

Цитата:

Нужно приводить пиксельные размеры файлов к значениям, кратным двенадцати (для 600dpi), как это рекомендуется спецификацией djvu.

Это где такое в спецификации? Форматом вроде бы регламентируется, что размеры ч/б слоя могут быть любыми, но есть ограничения на размеры BG44 и FG44, которые должны быть равны 1/2 .. 1/12 от размеров Sjbz, с округлением в большую сторону.
для win resizer.bat:

Код: @echo off
REM first parameter - image file name, second - scale factor;
set NAME=%1
set SCALE=%2
for /f "tokens=* usebackq" %%i in (`identify -format "%%[fx:ceil(w/%SCALE%)]x%%[fx:ceil(h/%SCALE%)]" %NAME%`) do (
set SIZE=%%i
)
convert %NAME% -resize %SIZE% new_%NAME%

Цитата:

Наверно, лучше всего -- добавлять белые поля, как Вам кажется? Потому что если -resize, то черно-белые компоненты довольно сильно попортятся, да и долго это.

Нет, конечно же не -resize: нам ведь не нужны дополнительные искажения. -border, вероятно, приемлемо, но я это делаю через -extent. Код может выглядеть примерно так:


Код:
function correct_size() {
ret=$1
dpi=$2

let "base = $dpi * 2 / 100"
let "half_base = $base / 2"
let "mod = $ret % $base"
if [ $mod -ge $half_base ] ; then
let "ret += $base"
fi
let "ret -= $mod"

echo $ret
}

width=`identify -format "%w" $file`
xdpi=`identify -format "%x" $file | sed -rn 's/([0-9]+).*/\1/p'`
WOUT=`correct_size $width $xdpi`
height=`identify -format "%h" $file`
ydpi=`identify -format "%y" $file | sed -rn 's/([0-9]+).*/\1/p'`
HOUT=`correct_size $height $ydpi`

convert $file -gravity Center -extent "${WOUT}x${HOUT}" $newname.tiff

StanFreeWare:

Цитата:

По поводу корректных размеров субсканов меньшего разрешения почитайте здесь.

Спасибо!

U235:
Так как же все-таки цитировать Ваш LayerTailor?

Цитата:

Единственное, там в исходниках возможно надо будет подобрать коэффициенты чуствительности к различию и-н.

Хорошо, буду смотреть.

Цитата:

-format "%%[fx:ceil(w/%SCALE%)]x%%[fx:ceil(h/%SCALE%)]"

Вот оно почему у меня не получалось! ceil! Bash-то просто отбрасывал десятичную часть



Добавлено:


anagnost96:

Цитата:

Код может выглядеть примерно так:

Спасибо еще раз! Но, наверное, подход U235 проще?

Цитата:

Если размер изначально был одинаковым, то и результат вычислений для каждой страницы тоже будет одинаковым.

Только для страниц, которые будут разделяться на чанки. А страницы, идущие к csepdjvu и к напрямую к minidjvu, останутся прежнего размера Наверное, я сначала попробую формулу U235, она гораздо экономнее и решает все эти проблемы, потому что ресайзить можно только цветной background-компонент.

U235

Цитата:

Форматом вроде бы регламентируется, что размеры ч/б слоя могут быть любыми, но есть ограничения на размеры BG44 и FG44, которые должны быть равны 1/2 .. 1/12 от размеров Sjbz, с округлением в большую сторону.

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

Исправил пару багов, сделал версию 0.9d. Попробую теперь потестировать с уменьшением разрешения заднего плана. Размытие, кстати, работает очень хорошо. Пожалуйста, постестируйте кто-нибудь с реальным выводом Scan Tailor. Кстати, я попробовал один небольшой проект -- получилось в два раза меньше, чем дает documenttodjvu.
Что касается до того, чтобы сделать черно-белые чанки частью потока для minidjvu, то очень не хочется превращать скрипт в двухпроходный. Посмотрим.

Цитата:

Все пожеланья принял Слон.
Опять за краски взялся он
И всем друзьям по мере сил
Слоновьей кистью угодил,
Изобразив снега, и лед,
И Нил, и дуб, и огород,
И даже мед!
(На случай, если вдруг Медведь
Придет картину посмотреть...)
(С. Михалков)

Версия 1.0 скрипта img2djvu -- http://github.com/ashipunov/img2djvu
Особенно хороша для работы с выводом Scan Tailor.
Заменяет:
1) ST Split, Layer Tailor, ST Separator
2) DjVu Imager
3) DjVu Small, DjVu Solo
4) DjvuOCR
Делает фсё. Но медленно.
Но делает.
Основан на bash + getopt, DjVuLibre, ImageMagick, minidjvu, а теперь еще и на ocrodjvu + cuneiform
Не умеет одного -- непрерывного словаря в том случае, если черно-белые страницы перемежаются с картиночными. Возможно, не умеет работать под Windows. Зато должен работать под Mac OS X.
Сыроват, тестировался мало, особенно с OCR.
Пример работы: img2djvu -m 20 -l 3 -r rus -a 1 s
(делает из папки s файл s.djvu со словарем 20 страниц, тройным даунсамплингом цветного слоя, агрессивно использует кодеры и добавляет русский OCR-слой).
Вот папка: http://rghost.ru/2831262
А вот результат: http://rghost.ru/2831268
(сканы были вполне некачественные, вынуты из плохо сделанного PDF с разрешением 200, затем обработаны Scan Tailor)
ПРОШУ ТЕСТИРОВАТЬ. Если возникают проблемы, выкладывайте, пожалуйста, на файлообменник исходную папку (или ее наименьший кусок, где еще есть проблема) + командную строку + результат (если вышло. конечно).

iit512

Ну, прошу заметить, что STA она всё-таки не заменяет, поскольку STA был придуман в первую очередь ради того, чтобы избежать двойного ресэмплинга картинок (300 -> 600 в ST и потом опять 600 -> 300 или менее при DJVU-кодировании).

Принято.

Еще вот такой вопрос: раз уж в скрипте предусмотрено распознавание текста, то нельзя ли предусмотреть выбор OCR-движка (cuneiform или tesseract)?

Я уже думал о том, чтобы включить tesseract, но меня остановило низкое (пока еще, я надеюсь) качество распознавания, отсутствие поддержки смешанных языков (для меня это критично) и в особенности странный способ производства hOCR -- через конфигурационный файл, который придется распространять вместе с моим скриптом, если я включу tesseract в движки.
Кстати говоря, если я правильно понимаю -- это Вам большое спасибо за hOCR в tesseract. Но чтобы догадаться, как его сделать, пришлось лезть в исходники (!).
===
Все впечатления -- от вчерашней свежескомпилированной версии.

iit512

Цитата:

Не умеет одного -- непрерывного словаря в том случае, если черно-белые страницы перемежаются с картиночными.

Это уже древний подход - к примеру, DjVu Sep (морально устаревшая программа) этим только и отличается от DjVu Imager, что DjVu Sep также не умела делать непрерывный словарь в подобных случаях - а DjVu Imager всегда делает такой словарь (точнее, он просто приклеивает картинки, не нарушая исходной чёрно-белой структуры DjVu).

anagnost96

Цитата:

то нельзя ли предусмотреть выбор OCR-движка (cuneiform или tesseract)?

CuneiForm OCR невозможно вставить в DjVu под Windows - можно только под Linux.

monday2000

Цитата:

CuneiForm OCR невозможно вставить в DjVu под Windows - можно только под Linux.

а можно поподробнее?

terminat0r

Цитата:

а можно поподробнее?

Вот почитайте: http://openocr.org/forum/viewtopic.php?f=2&t=46

monday2000
так ocrodjvu полностью на питоне написана. В чем проблема под виндовсом?

terminat0r
По идее проблем нет. CuneiForm нормально под Win32 (проверял под VC++) собирается, с выводом в hocr. Непонятно, что хотел сказать monday2000

terminat0r
U235
Я имел в виду, что те дистрибутивы CuneiForm под Windows, которые доступны на оф. сайте, не поддерживают вывод hOCR. Вообще их 2 штуки, вот они:

1. http://www.cuneiform.ru/downloads/cuneiform.zip (версия на момент открытия кода программы - т.е. "старая").

http://www.cuneiform.ru/downloads/setup_openocr_cuneiform_rus.exe (более новая версия - т.е. "новая").

Правда, "новая" версия поддерживает вывод в свой фирменный формат FED - который является аналогом hOCR. Вот документация к FED: http://www.djvu-soft.narod.ru/openocr.htm (я даже перевёл её на английский). По идее, можно сделать конвертер FED -> hOCR (или что-то в этом роде).

Вывод hOCR прикрутили уже линуксоиды - к своему Linux-клону CuneiForm. Но Windows-то версиям CuneiForm от этого ни холодно, ни жарко - они как не умели выводить hOCR - так и не умеют по-прежнему.

"Старая" версия не умеет распознавать более 1-страницы текста за один присест. И ещё она даже и FED не умеет выводить.
"Новая" версия фактически содержит 2 программы в одном дистрибутиве - "старую" версию плюс новую программу, умеющую делать пакетное распознавание. Именно вот эта пакетная распознавалка (фактически, это просто нечто вроде GUI к ядру распознавания) и умеет выводить FED.

Но есть одна важная проблема: по неизвестным причинам, "новая" версия почему-то распознаёт гораздо хуже "старой" (эту мысль мне сообщил модератор ZYV с форума OpenOCR). В смысле качества распознавания. (кстати, ZYV - не сотрудник Cognitive, так что он ничего толком не знает). Видно, пакетная распознавалка получилась у них кривая. Так что по идее, плясать нужно всё-таки от "старой" версии - начисто игнорируя "новую".
U235

Цитата:

CuneiForm нормально под Win32 (проверял под VC++) собирается, с выводом в hocr.

Так это здорово и замечательно! Я лично об этом мог только мечтать - поскольку совершенно не имел и не имею времени пытаться перекомпилировать CuneiForm.

Расскажите, пожалуйста, подробнее - как Вы это компилировали, по шагам (например, на форуме openocr.org), ну или хотя бы - выложите готовую к применению CuneiForm под Windows, умеющую выводить hOCR (надеюсь, она с визуальным интерфейсом и поддержкой пакетного распознавания?). Это будет просто здорово.

iit512
img2djvu? Сделайте, плиз портабельный экзешник со всеми включенными компонентами, чтобы сразу натравить на папку с картинками и получить результат. А то этот текстовичок не внушил мне никакого почтения. Хотя я всё закаяал и установил, как требовалось. Ни интерфейса, ни опций, ни возможности что то контролировать... А пока что я считаю это концептуальной возможностью, но не полноценным решением.

Правильно ли я понял, что Вы запустили скрипт (он запускается именно на папку с картинками) и не получили DjVu? Какие конкретно ошибки возникли? Или Вы все-таки получили DjVu?

Цитата:

ни опций, ни возможности что то контролировать

Есть множество опций. Прочитайте, пожалуйста README -- это очень короткий текст, и с примерами.