» ScanKromsator СканКромсатор (Часть 2)

bolega

Цитата:

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

Имееться ввиду в режиме просмотра свойства picture zone? Возможно, это было бы неплохо.
Кстати, можно узнать в чем разница между picture zone и dither zone?
И еще вопрос, если я найду алгоритм автоопределения picture zones, есть шанс увидеть его в SK? Для меня сейчас расстановка picture zones - самая длительная ручная операция в SK ;(

kontiky

Цитата:

Имееться ввиду в режиме просмотра свойства picture zone?

Нет. В окне просмотра результатов, т.е. когда зона уже вырезана и над ней надо пошаманить в профессиональном редакторе


Цитата:

И еще вопрос, если я найду алгоритм автоопределения picture zones, есть шанс увидеть его в SK?

Смотря в каком виде найдете. У меня есть немало статей на эту тему. Но как правило, они из разряда "возьмем такой-то трехэтажный интеграл, применим такую-то частотную фильтрацию (и идет ссылка на ее описание, опубликованное в совершенно недоступном журнале), сделаем свертку, применим wavelet-преобразование" и т.п. Даже если во всем этом разобраться теоретически, то на практическое воплощение понадобится еще пару лет.

bolega

Цитата:

Смотря в каком виде найдете.

Вроде, у U235 было некое готовое решение.

bolega
Есть исходники уже свободной OCR CuneiForm. Вроди там есть сегментация изображений. Есть даже какая-то стыковка с Delphi и набор статей по технологиям, применяемым в этой OCR.

bolega
OK. Спасибо.


Цитата:

А tolerance задается Clear Options->Magic clear->Color threshold for magicwand.

т.е. magic wand применяется все же в Result View

у меня почему-то получилось его применить в основном окне, а в выходном (result view) как ни бился не получилось

Или надо было еще на какаую-то иконку нажать?


Цитата:

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

на мой взгляд очень полезная функция

Тогда и мой вопрос, под каким номером сохраняется picture-zone, становится не актуальным :glad:


Цитата:

Кстати, в новой версии я добавил еще одну опцию,

полезно.
вот бы еще в меню пункты на русском языке заменить на англицкий :rolling eyes:
(а то у меня только вопросики видны)
1) File->Options>Processing->Priority
2) Draft kromsate -> Options -> в самом низу слева
3) Zones -> Picture zone -> два предпоследних пункта
4) Пояснения в Service -> Corect DPI ...
5) Последний пункт в контекстном меню, которое выпадает при клике на один из резаков
Copy current position to -> ...

Добавлено
Опа. А у меня событие.
1000 постов.
Не прошло и года

bolega

Цитата:

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

Было бы очень полезно.


Цитата:

Смотря в каком виде найдете. У меня есть немало статей на эту тему.

А что с DjvuOCR? там вроде сделали функцию извлечения координат зон из файла проекта Файнридера

ghosty

Цитата:

Вроде, у U235 было некое готовое решение.

Вот оно

Цитата:

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

Мой голос "за".
Лично для меня некоторые вещи удобнее делать в Шопе, например.

bolega
C появлением DjVu Sep v1.0 мои последние предложения по СК становятся, надеюсь, ещё более понятными и необходимыми.

Главная идея в том, чтобы полностью избавить юзера от каких-либо перетасовок по сортам выходных (из СК) сканов. После появления DjVu Sep v1.0 остаётся лишь слегка подправить DjVu Small - чтобы автоматом отсеивал на входе нежелательное.

В перспективе будет так: кромсаем в СК сканы с картинками, получаем на выходе папку out. Подаём эту папку (прямо как есть, без отсева картинок) сначала на вход DjVu Small - получаем книжку без картинок. Затем подаём на вход DjVu Sep эту же самую папку out (тоже как есть, без отсева простых сканов) + книжку без картинок, полученную в DjVu Small. DjVu Sep генерит DjVu-картинки (через МРС) и вставляет их автоматом в эту книжку без картинок - получаем готовую DjVu-книжку с картинками.

Но папку out не подашь на вход, скажем, Book Restorer, в виде "как есть" (содержащую смесь разносортовых сканов) - поэтому я и прошу реализовать в СК мои последние предложения по СК.

Добавлено:
Если же мои предложения не будут реализованы, то прийдётся делать доп. утилитку для тасования файлов для BR, FR и т.п. - это лишнее усложнение жизни юзерам.

monday2000
Цитата:

C появлением DjVu Sep v1.0 мои последние предложения по СК становятся, надеюсь, ещё более понятными и необходимыми.
...
поэтому я и прошу реализовать в СК мои последние предложения по СК

Вы с упорством, достойного лучшего применения, ломитесь в открытую дверь. Еще просите эту дверь открыть.
Для создания книги методом разделенных сканов требуется СК (или Корел) - для получения разделенных сканов - и FSD v1.2 (с msepdjvu) - для их кодирования.
Техника всего этого простая и не требует ручной работы, за исключением создания пикчер зон в СК (или маски для рисунков в Корел)

Только после обработки книги заметил, что некоторые страницы сдвинуты относительно друг друга.
Page v.align был выставлен на автоматический режим.
Все страницы (их текстовая часть) реально по вертикали одинакового размера, но на некоторых страницах текст был, по-видимому, был выравнен по верхней границе, на некоторых по нижней.

Можно ли как-то, не обрабатывая страницы, передвинуть на них текст?

(Т.е., н-р, страница была обработана с применением Page v.align = T, а мне надо выравнять ее по низу, избегая повторной обработки.)

Olive77
В режиме Result View: в контекстном меню - Special -> Select Book Size. Далее сдвинуть выделенный блок можно двумя способами:
1) В контекстном меню выбираем Move Selection и тянем выделенный фрагмент куда нужно. Теперь либо в контекстном меню нажимаем Merge, либо просто щелкаем мышкой за пределами выделенного фрагмента.
2) В контекстном меню выбираем Shift Image, выбираем, в каком направлении и насколько нужно сдвинуть фрагмент, нажимаем ОК.

Вообще, было бы здорово, если бы можно было в режиме RV выравнивать блок текста по странице автоматически.

Arcand

Цитата:

Для создания книги методом разделенных сканов требуется СК (или Корел) - для получения разделенных сканов - и FSD v1.2 (с msepdjvu) - для их кодирования.

Бессмысленно. Я уже раза три сказал ему то же самое, воз и ныне там...

ghosty
одно открытие за другим

Вот если бы еще были guiding lines как в powerpointe.
Сейчас наличиствующий в SK ruler с этой задачей не справляется.

Olive77

Цитата:

Вот если бы еще были guiding lines как в powerpointe.

Не очень хорошо помню. Зачем это нужно?

ghosty
плюс минус 10 - 20 пикселей погоду, конечно, не делают, но,
на мой взгляд, эти направляющие линии добавляют удобство при необходимости сдвигания изображения.

Н-р, выставил направляющие линии по краю текста на одной странице и применяя операцию Shift Image на других страницах сразу видно, насколько далек результат от идеального.

Народ - не знаю обсуждалось ли но вот вопрос. Как-то решил ранее обкромсаные книги где страницы соединял, разделить постранично. И обнаружил одну неприятную особенность - При Draft kromsate на некоторых страницах резаки расставляются по тексту со сдвигом обычно по абзацу, обрезая текст до красной строки. Как этого избежать (не проверять же всё постранично).

И еще на страницах с мелкими номерами снизу резак часто их обрезает - этого избежать можно.

niccolo
Я не очень хорошо понял, что именно у Вас происходит, но могу предположить, что если Вы уже кромсали этот материал, то координаты блока текста примерно одинаковы. Если так, то можно определить фиксированные координаты определенных резаков для всех страниц книги: по правому щелчку мыши на ползунке резака вызываем контекстное меню и в нем выбираем Copy current position to... (далее по вкусу).

ghosty - спасибо - это простое решение мне известно. Иногда я его использую иногда забываю. Поэтому хотелось бы забить какую либо галочку и забыть. По старой памяти мне кажется, что фиксированная позиция резака сказывается потом на ширине полей страниц? Иногда это крайне критично для меня (например для наложения блоков в ФР).

По номерам страниц - тоже иного решения нет?

niccolo

Цитата:

По старой памяти мне кажется, что фиксированная позиция резака сказывается потом на ширине полей страниц?

Нет, вы путаете с отключением функции Automargin для отдельного резака. Т.е. на ширине полей фикс. позиция не скажется.


Цитата:

По номерам страниц - тоже иного решения нет?

Есть, просто этот вопрос я не заметил Чтобы избежать обрезки отдельно стоящих номеров страниц (как правило, это происходит, когда номера слишком удалены от блока текста, смещены относительно него), нужно в окне DK поставить галочку safe top/bottom. Если даже это не помогает, то увеличить вертикальную чувствительность на закладке Advanced.

Arcand

Недостатки FSD v1.2:

1. Если на входе у него несколько пар субсканов - то на выходе он создаёт один многостраничный DjVu-файл. А нужно создавать ворох одностраничных DjVu-файлов. Это довольно-таки неудобно - предполагается, что ли, вручную разбирать результат на отдельные страницы?
2. Не умеет автоматически вставлять полученные DjVu-картинки в DjVu-книгу-без-картинок.
3. Не работает под Win98.
4. Спотыкается на нерегулярных тифах.
5. Значение делителя фона=12 на самом деле неработоспособно.
6. Использование msepdjvu ИМХО нецелесообразно - разумнее обойтись csepdjvu - т.к. это позволяет сохранить лицензионную чистоту.
7. Не позволяет юзеру создать свой профиль (а только напрямую указать extra params).
8. Имеет закрытые исходники.
9. Не имеет внятной лицензии.
10. Не позволяет подбирать параметры кодирования индивидуально для каждой пары субсканов.
11. Не имеет функции просмотра результата - что существенно при подборе параметров кодирования.
12. Не имеет списка загруженных на обработку пар субсканов - и соответственно, не может никак ими индивидуально управлять (добавлять-убирать, ставить инд. параметры, набирать пары субсканов из разных папок).

DjVu Sep v1.0 - это почти то же самое, что и FSD v1.2, но без указанных недостатков. Я в курсе, что и FSD v1.2 (как и DjVu Sep v1.0) умеет автоматом отсеивать на входе "ненужные" файлы.

DjVu Sep v1.0 задумывался просто как более удобный в работе инструмент - аналогичный уже существующему.

Добавлено:
Мои последние предложения по СК в сущности, не затрагивают ни FSD v1.2, ни DjVu Sep v1.0. Их смысл - максимально упростить взаимодействие СК и таких программ, как FR, BR и пр (в случае, когда СК производит на выходе разделённые сканы). А тогда уже я мог бы подкорректировать любым нужным образом что DjVu Sep, что DjVu Small (чтобы "подогнать" их точно под изменившийся СК).

Добавлено:
bolega
Для Picture-зон можно сделать глубину цвета по-умолчанию Color 24bit - т.к. для DjVu не существует понятия "Gray". Сейчас режим по-умолчанию - Gray.

monday2000
Цитата:

Недостатки FSD v1.2:

Вы это серьезно. Такие претензии к скромной GUI утилитке для автоматизации кодирования методом разделенных сканов.

Цитата:

8. Имеет закрытые исходники.
9. Не имеет внятной лицензии.

Ха-ха . Откройте fsd.hta в блокноте и Вы увидете весь код. Какая к черту лицензия! Остальные пункты также вне критики. В частности, в настройках FSD можно указать, какой кодировщик использовать - msepdjvu или csepdjvu.

ЗЫ: Один недостаток все же есть . Насколько помню, FSD не может кодировать один скан. А мне, например, нужно закодировать только обложку. Приходится пользоваться батниками.

Arcand

Цитата:

Ха-ха . Откройте fsd.hta в блокноте и Вы увидете весь код.

Верно. Не обратил внимания.

Цитата:

Вы это серьезно. Такие претензии к скромной GUI утилитке для автоматизации кодирования методом разделенных сканов.

А почему бы и нет? Вполне бывают книги, содержащие множественные полутоновые иллюстрации - не одна, не две, не три - а 2-3 десятка, причём в разных местах книги. FSD ИМХО недостаточно удобен для работы с ними - поэтому я и предложил свой вариант подобной утилиты. Я пытаюсь приспособить МРС под "глупого" юзера.

Цитата:

Насколько помню, FSD не может кодировать один скан

Не понял этого. И FSD, и DjVu Sep оперируют исключительно парами субсканов. Из одной пары получается одна DjVu-картинка. Одну пару FSD умеет кодировать (как и множество пар).

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

Цитата:

1. Если на входе у него несколько пар субсканов - то на выходе он создаёт один многостраничный DjVu-файл. А нужно создавать ворох одностраничных DjVu-файлов. Это довольно-таки неудобно - предполагается, что ли, вручную разбирать результат на отдельные страницы?

Добавлено:
Я сильно сомневаюсь, что FSD способен действительно популяризовать МРС. А вот DjVu Sep без сомнения это сделает.

monday2000
Цитата:

Не понял этого. И FSD, и DjVu Sep оперируют исключительно парами субсканов.

Я давал ссылки, которые ИМХО полностью объясняют работу msepdjvu. В частности там было
Цитата:

msepdjvu кодирует в дежавю файл специального формата - sep-файл. sep состоит из страниц, каждая из которых в свою очередь состоит из маски в формате bw-rle (черно-белая) или color-rle (gray или color) и фона в формате ppm. Из них обязательна только маска. Если маска пустая, то она должна быть обязательно в формате bw-rle, иначе msepdjvu вылетает с ошибкой.

Т.е. страница для кодирования может содержать только файл маски без файла фона. Обложка в случае кодирования в msepdjvu у меня состоит только из одного файла - файла маски. FSD требует минимум два тифа.


Добавлено:

Цитата:

1. Если на входе у него несколько пар субсканов - то на выходе он создаёт один многостраничный DjVu-файл. А нужно создавать ворох одностраничных DjVu-файлов. Это довольно-таки неудобно - предполагается, что ли, вручную разбирать результат на отдельные страницы?

Здесь не вижу проблемы. Берете, например, плагин и сохраняете дежавю постранично. Полная автоматика с кибернетикой

Arcand

Цитата:

FSD требует минимум два тифа.

Можно воспользоваться phototodjvu в данном случае. Там есть те же опции. Практически это можно проделать в DjVu Small (В DEE сложнее, там нет опций, а только профиля).

Цитата:

Берете, например, плагин и сохраняете дежавю постранично.

Делать больше нечего. Проще взять DjVu Sep, который это делает сам.

Добавлено:

Цитата:

Вполне бывают книги, содержащие множественные полутоновые иллюстрации

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

monday2000
Цитата:

Можно воспользоваться phototodjvu в данном случае. Там есть те же опции.

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

Цитата:

Проще взять DjVu Sep, который это делает сам

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

Arcand

Цитата:

DjVu Sep это кот в мешке, че он там делает большой вопрос

Ничего, народ разберётся, чего он там делает. Кто хочет, пусть использует FSD - на здоровье.

Цитата:

загнать ее в маску

Понял. Действтельно, phototodjvu тут не пойдёт. Может быть, сделаю эту фичу в следующей версии DjVu Sep.

Добавлено:

Цитата:

как Вы все запутали с разделенными сканами

Вот теперь-то как раз всё и распутается.

Если у кого есть какие вопросы, пишите в ПМ. Читать этот форум сил уже нет В какой-то альманах превратился.

bolega
Не расстраивайтесь, это сезонное.

To All:
Давайте уже закругляться с оффтопом, действительно?

ghosty


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

bolega

Цитата:

Если Вы считаете, что и в BR возникнут (якобы) трудности с файлами после SK

Да.

Цитата:

Тот, кто пользуется BR, не пользуется SK.

Но ещё остаётся FineReader.

Цитата:

Ваши пожелания я не принимаю.

Хорошо, я, быть может, сделаю спец. примитивную утилитку для тасования файлов.

Цитата:

Поскольку я совершенно запутался в последних спорах

Всё на самом деле очень просто:

1. Я предложил подстроить СК под FineReader (или BR) более оптимальным образом - для случая разделённых сканов.

2. В случае, если СК изменится в данном направлении, я берусь подстроить и DjVu Small и DjVu Sep под изменившийся выход из СК - как бы этот выход ни видоизменился бы.

Вот и всё.

Короче, "цена вопроса" - делать или нет утилитку для тасования файлов "после СК" под FR (избирающую в отдельную папку все сканы, подлежащие распознаванию). Делать это не хочется, т.к. это будет лишний шаг для юзеров.