Автор Тема: Высокоуровневая схема работы идеальной программы скан-обработки  (Прочитано 34925 раз)

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
57an
Цитировать
Если Тулон на это решится, окажется, что Ваша работа по созданию программы-разрезчика будет проделана впустую..
Нет-нет, не впустую. Создавая такую программу, мы гонимся за максимальной простотой. Так что Tulon за нами тут никак не угнаться (в рамках его подхода).
kontiky
Если у Вас возникнет вопрос: "как должна выглядеть такая программа (по разрезке)", то я бы её делал так, как это сделано в СК (а не так, как в СТ) - некий вертикальный резак, слева - миниатюры загруженных сканов на вертикальной ленте. У резака должна быть непременно фича "распространить текущую позицию резака на все - вниз (вверх)" - как в СК.

Нелишней будет и фича, чтобы когда мы на текущем скане двигаем резак влево-вправо - чтобы потом в момент перехода на следующий скан текущая горизонтальная позиция резака автораспространялась на "все вниз". Такой маленький приёмчик сильно убыстрит работу.

Переход между сканами - Page Up и Page Down, или Q и W, или [ и ] - как в СК.

Ещё важный момент: в СТ ползунок резака (синий кругляш) находится в рабочей области скана. Это ужасная ошибка. Он (ползунок) обязан быть за пределами скана - как в СК. Потому что на тесных разворотах, где нет просвета между левой и правой страницами, синий СТ-шный кругляш загораживает собой начало линии реза - и там ни хрена поэтому не видно, где выставить резак.

Программа по разрезке должна непременно уметь не только разрезать сдвоенные развороты - но и отрезать ошмёток соседней страницы (у одиночных сканов). Это, пожалуй, самое сложное, поскольку тут надо будет уметь обрабатывать "все чётные", "всё нечётные".

Также полезна будет фича (опционально группового - с ручным указанием группы) поворота на 90, 180, 270 - до разрезки.

Кроме того, возможны самые дикие смеси - из сдвоенных разворотов и одиночных сканов, да ещё и чёрти как повёрнутые (90, 180, 270). Всё это необходимо уметь обрабатывать (тем самым приводя сырьё к некоемому унифицированному виду на выходе).
« Последнее редактирование: 30 ёоЫм 2010, 12:05:20 от monday2000 »

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Цитировать
волюнтаризм
Для меня это лишь способ минимумом усилий сделать максимум функционала.
Минимум усилий - это потратить день на освоение СК - и никакой СТ тогда не нужен, следуя вашей логике ;)

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kontiky
Мне кажется, что практически Вам можно начать с чего-то наиболее простого.

Можно сделать так:

Возьмите свою программу:



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

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

А потом будете потихоньку наращивать туда возможности.
« Последнее редактирование: 30 ёоЫм 2010, 16:47:07 от monday2000 »

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Цитировать
Создавая такую программу, мы гонимся за максимальной простотой.
Я бы сказал, за удобством, понятностью и функциональностью.

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

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

Вопрос вот какой, вот есть у нас набор разворотов с резаками в пакете, как теперь получить результат? Нажать некую кнопку Process и заменить развороты в пакете на нарезанные (c возможностью дальнейшего сохранения изображений пакета на диск) или сделать что-то типа - Export и результат ложить в отдельный каталог?

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
СК: Правильно Ползунок резака за пределами скана:



СТ: Неправильно Ползунок резака в рабочей области скана:

« Последнее редактирование: 30 ёоЫм 2010, 16:48:52 от monday2000 »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kontiky
Цитировать
Сомневаюсь, что подобное нужно - иначе программа превратиться в Кромсатор.
У меня тоже нет 100% уверенности в нужности такой фичи.  ::) На первое время можно без неё вообще обойтись. Хотя она может оказаться востребованной (отрезание ошмётка соседней страницы) - например, для последующего OCR в CuneiForm. Да и вообще - работать в дальнейшем со сканами, у которых отрезан ошмёток, как-то эстетически приятней, чем наоборот (хотя, согласен, довод несолидный). В общем, об этом можно будет подумать позднее.
"Кромсатора" (в плохом смысле) всё равно не будет (или же в любом случае, зло будет минимальным).
Цитировать
Нажать некую кнопку Process и заменить развороты в пакете на нарезанные (c возможностью дальнейшего сохранения изображений пакета на диск) или сделать что-то типа - Export и результат ложить в отдельный каталог?
Нажать кнопку Process. Программа будет делать с каждым разворотом 2 кропа, создавая под каждый новый кроп новый файл. Новые файлы класть в некую папку, указанную юзером. Исходные файлы вообще в идеале никак бы не изменять (ну разве что поворот 90,180,270 - и то желательно как-то выкрутиться и всё же никак не менять исходные сканы).

Уже порезанным сканам назначать новую сплошную нумерацию вида:

0001.tif, 0002.tif, .... , 0010.tif, ... (это важная деталь). Т.е. выводная нумерация будет новой - исходная не сохранится (ошибка Tulon в том, что он пытается её (входную нумерацию) не утрачивать в выводных файлах - а это ни к чему).
« Последнее редактирование: 30 ёоЫм 2010, 17:03:28 от monday2000 »

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Нажать кнопку Process. Программа будет делать с каждым разворотом 2 кропа, создавая под каждый новый кроп новый файл. Новые файлы класть в некую папку, указанную юзером. Исходные файлы вообще в идеале никак бы не изменять (ну разве что поворот 90,180,270 - и то желательно как-то выкрутиться и всё же никак не менять исходные сканы).
Проблема в том, как быть дальше, если мы продолжим развитие программы на другие этапы постобработки...

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kontiky
Цитировать
Проблема в том, как быть дальше, если мы продолжим развитие программы на другие этапы постобработки...
А какая проблема? Эту программу уже больше мы трогать не будем. Смысл-то как раз в том, что эта программа будет делать только разрезку и больше ничего. Все дальнейшие этапы мы будем делать НЕПРЕМЕННО в другой программе - но ни в коем случае ни в этой же самой (!) Разве Вы не поняли этот самый главный момент? Я же столько лет бьюсь с СК и СТ - за реализацию этой ВАЖНЕЙШЕЙ идеи (но безуспешно).

Смысл-то весь в том, что мы весь мерзкий гадюшник (особенно отпиливание ошмётка) по разрезке разворотов канализируем в одной-единственной программе - чтобы этот гадюшник дальше не потёк во все последующие программы, отравляя своим смрадом жизнь как юзеру, так и авторам программ по сканобработке (нынешний бич как СК, так и СТ). О, как слепы были Tulon и bolega, что этого так и не поняли!

При таком подходе не страшно даже сделать отпиливание ошмётка - всё равно программа останется достаточно простой.

Дальше - всё просто: о тех сканах, что были до разрезки - забываем навсегда. Теперь берём порезанные - как если бы они были прямо из-под сканера - и дальше обрабатываем как угодно в некоей ДРУГОЙ программе (скорее всего, в СТ - по состоянию на сегодняшний день).
« Последнее редактирование: 30 ёоЫм 2010, 17:23:18 от monday2000 »

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Эту программу уже больше мы трогать не будем.
Ну у меня немного другое видение перспективы.  ;D Но на данном этапе - я полностью с вами согласен.

Давайте подумаем о том, какие форматы должна поддерживать программа? Понятно, что tiff, но какие подформаты?
« Последнее редактирование: 30 ёоЫм 2010, 18:00:38 от kontiky »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kontiky
Цитировать
Ну у меня немного другое видение перспективы.
А какое именно? Здесь, знаете ли, или Вы со мной согласны - или нет. Тут нельзя быть "немножко беременной". Либо - программа делает исключительно одну разрезку - либо и всё остальное в т.ч. (как СК и СТ). Либо так, либо этак - других принципиальных вариантов нет. Разве что допускается туда добавить Deskew и поворот 90,180,270 - получится некий смысловой аналог стадий СТ-обработки 1-3.
Цитировать
Давайте подумаем о том, какие форматы должна поддерживать программа? Понятно, что tiff, но какие подформаты?
Тут ничего хитрого. TIF - чем больше подформатов, тем лучше. Желательно CCIT Fax G4 и LZW как минимум.
Ещё BMP, JPG. Неплохо ещё GIF и PNG. TIF предполагается в качестве основного рабочего формата - т.к. потом-то продукция разрезки должна быть напрямую "понятна" СТ (который, кстати, BMP не поддерживает - а может, чего-то ещё не поддерживает - эти ограничения разумно учесть).

Какие-то ещё более экзотические форматы добавлять не вижу смысла. Нет, ну конечно, если Вы сумеете напрямую читать PDF и DjVu - это будет круто. :) Но большой нужды в этом я не вижу. ;)

Не забудьте об обязательной перенумерации на выходе - к виду 0001.tif, 0002.tif, ... , 0010.tif, ...

Надо также предусмотреть опцию выборочной не-разрезки.
« Последнее редактирование: 30 ёоЫм 2010, 19:01:40 от monday2000 »

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Либо - программа делает исключительно одну разрезку - либо и всё остальное в т.ч. (как СК и СТ).
На первом этапе - исключительно одну резку. А там - посмотрим. Если будет возможность расширять функционал программы, почему этого не сделать? При этом начальную разку можно будет использовать автономно.

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kontiky
Цитировать
Если будет возможность расширять функционал программы, почему этого не сделать?
Значит, Вы всё-таки со мною не согласились. Жаль. :(

Для "расширения функционала" следует просто сделать ещё одну программу - не трогая ту первую (для резки).

Программа для резки по замыслу производит полуфабрикат (с точки зрения последующего DjVu-кодирования) - а никак не "конечную продукцию". Для данной программы производство именно полуфабриката - единственно правильный подход. А "расширение функционала"  для программы резки - это будет фактически стремление к уходу от производства полуфабриката в направлении производства "конечной продукции". Нет, никакого "расширения функционала" допускать НЕЛЬЗЯ. Вот это действительно получится "Кромсатор" (в плохом смысле слова).
Цитировать
При этом начальную разку можно будет использовать автономно.
То есть, Вы хотите сделать программу-Wizard, где при запуске будет открываться окно с большими кнопками, каждая из которых будет загружать свой независимый интерфейс? (по типу DjVuOCR от Генчо) - т.е. как бы втиснуть несколько программ в одну? Но чтобы при этом все "подпрограммы" были фактически независимы?

Думаю, такое в принципе допустимо.
Цитировать
Если будет возможность расширять функционал программы, почему этого не сделать?
Есть ещё одна важная причина, почему это нельзя делать непосредственно в программе для резки - это усложнение интерфейса.
« Последнее редактирование: 30 ёоЫм 2010, 20:26:07 от monday2000 »

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Для "расширения функционала" следует просто сделать ещё одну программу - не трогая ту первую (для резки).
Нет смысла плодить автономные программы, многие части которых одинаковы.

Нет, никакого "расширения функционала" допускать НЕЛЬЗЯ. Вот это действительно получится "Кромсатор" (в плохом смысле слова).
Вот именно усложнения программы a la Кромсатор я постараюсь не допустить.

Цитировать
То есть, Вы хотите сделать программу-Wizard, где при запуске будет открываться окно с большими кнопками, каждая из которых будет загружать свой независимый интерфейс? (по типу DjVuOCR от Генчо) - т.е. как бы втиснуть несколько программ в одну? Но чтобы при этом все "подпрограммы" были фактически независимы?
Пока не могу сказать. На данном этапе хочу сосредоточиться именно на максимально удобном разрезании. А там уже будет видно.

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kontiky
Цитировать
Нет смысла плодить автономные программы, многие части которых одинаковы.
В общем, я вижу, что ни в чём я Вас не сумел убедить. Делайте, как хотите, в общем. Вы решили пойти точно таким же неправильным путём, что и Tulon с bolega - да ради бога.

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

kontiky

  • Новичок
  • *
  • Сообщений: 20
    • Просмотр профиля
Цитировать
Вы решили пойти точно таким же неправильным путём, что и Tulon с bolega - да ради бога.
Не вижу никакого криминала в том, что программа может делать более одного действия по сканобработке.
« Последнее редактирование: 02 °ТУгбв 2010, 19:27:33 от kontiky »