Автор Тема: Недостатки Scan Tailor  (Прочитано 12653 раз)

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Недостатки Scan Tailor
« : 05 јРЩ 2010, 18:45:34 »
Давайте обсудим недостатки программы Scan Tailor http://scantailor.sf.net

Кое-какие недостатки уже упоминались тут на форуме - хотелось бы как-то систематизировать.

Цель данного топика я подразумеваю не в том, чтобы донести до автора программы Scan Tailor (Tulon) пожелания об улучшении Scan Tailor (СТ) (тогда имело бы смысл писать прямо в официальном форуме СТ).

Цель данного топика - показать, что назрела необходимость создания альтернативы Scan Tailor. Давайте определимся - нужна ли альтернатива СТ, и, если да, то какая?

Итак, начну перечисление недостатков:

1. СТ не даёт пользователю свободу выбора действий - навязывая пользователю строго определённую стратегию действий.

2. СТ не даёт (в общем случае) возможность сторонним программам обработать свои сканы. Пример - СТ не выдаёт субсканы переднего плана в оригинальном режиме цветности (серое или цветное).

3. СТ скрывает внутри себя, какими именно элементарными алгоритмами и в какой последовательности обрабатываются сканы. Пример: вроде бы, в СТ применяется своё выравнивание освещённости. А в каких именно случаях - непонятно. Многие ли знают, что в СТ применяется бинаризация Otsu?

4. Tulon обнародовал планы по созданию некоей своей программы, которая будет как-то напрямую сопрягаться с СТ - и генерировать DjVu прямо из СТ-вывода. Я думаю, речь идёт о чём-то на базе miniDjVu.

Однако, miniDjVu, с моей точки зрения, пока не годится для сканобработки. Её еще нужно совершенстовать на алгоритмическом уровне. Разумнее было бы Tulon заниматься совершенствованием СТ - вместо того, чтобы лезть ещё и в создание своего DjVu-кодировщика.

По интерфейсу:

5. СТ не годится для разрезки разворотов (ИМХО). Поскольку ползунки резака разрезки сканов (синие кругляши) находятся в пределах рабочей области скана. А надо - чтобы они были за её пределами (как в СканКромсаторе - СК). Поэтому, когда попадаются сканы, где левый и правый лист слишком близко расположены друг к другу на развороте - синие кругляши начинают сильно мешаться, они уже наползают на левую и правую половинки разрезаемого разворота.

6. У разрезающего развороты резака СТ нет опции "Распространить текущую позицию резака на все (опционально - через одну) нижележащие сканы". Такая опция есть в СК.

7. Что-то не в порядке с графическим движком в СТ. Если увеличить масштаб кручением колёсика, затем сдвинуть скан, "ухватив" его курсором, и далее уменьшить масштаб кручением колёсика - то в некоторых случаях скроллбары не уберутся там, где надо. К примеру, в СК, такие проблемы неведомы.

8. СТ не умеет выводить чёрно-белые 1-битные сканы со сжатием CCIT Fax G4. Вместо этого он сжимает их в LZW. :o

9. Я считаю неправильной схему имён файлов, выводимых из СТ:
0001_0001.tiff, 0002_0002.tiff, ... Во-первых, расширение TIFF не открывается в 5 портабельном Фотошопе у меня, а во-вторых - все нормальные программы по работе со сканами выдают файлы с именами вроде 0001.tif, 0002.tif, ...., 0010.tif, ...., 0100.tif. Пример - FineReader, BookRestorer. СТ-схема имён даёт одну лишь путаницу - и больше ничего хорошего.

10. Опция "Применить к" - "Ко всем страницам" и т.п. у меня не работает. Я не знаю, как заставить её работать.

11. Глядя на ленту предпросмотра на этапе вывода, невозможно понять, есть ли на таком-то скане авто-зоны. Бывает, малые куски текста ошибочно авто-определяются как зоны - и это замечаешь только уже после вывода и разбиения на субсканы.

12. В СТ нет встроенного разбиения смешанного вывода на субсканы. Это глупость уже очевидная. Пришлось сделать программы Сепаратор, ST Split.

13. В СТ нет ластика. Он крайне нужен.

Выводы:

Я бы сделал пока следующие выводы.

1. СТ нельзя рассматривать как универсальное средство "всё-в-одном" для сканобработки. СТ следует использовать лишь для выполнения отдельных этапов сканобработки. Это, пожалуй, самый важный вывод. Хотя Tulon изо всех сил отчаянно пытается чуть ли не силовым приёмом убедить всех в обратном.

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

Продукцию такой программы следует загружать в СТ, и дообрабатывать в СТ до конца.

3. Возможно, следует сделать программу для пакетной чистки ластиком сканов. В ней дообрабатывать конечный вывод из СТ.

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

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

К примеру, тот же СканКромсатор, при всех своих огромных недостатках, гораздо более "честная" программа.

В общем, СканКромсатор, конечно, плох - но и Скан Тейлор не лучше. Поэтому - выход в том, чтобы создать нечто третье. И кому-то, отличному от авторов СК и СТ.

Если кто-то хочет что-то сказать по этому поводу - прошу высказываться.
« Последнее редактирование: 05 јРЩ 2010, 18:50:53 от monday2000 »

57an

  • Постоялец
  • ***
  • Сообщений: 201
    • Просмотр профиля
    • Djvu Bookmarker on SF.net
Re: Недостатки Scan Tailor
« Ответ #1 : 06 јРЩ 2010, 17:58:16 »
Желаете пофлеймить про СТ? Ну что ж, давайте  :)

Итак, в порядке перечисления “недостатков”:

1. СТ придерживается понятной и логичной последовательности действий, в подавляющем большинстве случаев иного и не нужно.

2. СТ позволяет осуществлять вывод в режиме цветной/серый, комбинируя который со смешанным, профессионалы могут делать все что им заблагорассудится (например, выделение серого текста с помощью ST GreyText или раскраску маску с помощью ST Separator).

3. А многим ли нужно знать, что в СТ применяется бинаризация Otsu?

4. На мой взгляд, основная причина данных намерений - в отсутствии нормального freeware одноступенчатого djvu-кодера. И в том числе тем, что Вы не желаете сделать поддержку МРС непосредственно в Djvu Small.

5, 6. Предложение о сравнительном скринкасте, иллюстрирующем невозможность разрезки сканов в СТ на реальном примере все еще силе.

7. Этот момент мне тоже не нравится, но он не смертелен. Скролбары убираются перетаскиванием скана мышкой.

8. Imho, не особо существенно, занимают ли обработанные сканы 2%(LZW) или 1%(G4FAX) от размера необработанных сканов. Наоборот, лишний повод не выкладывать архив tif-ов вместо djvu.

9. Tulon меняет схему именования на L/R (правда, не уверен, что и в этот раз она Вас устроит).

10. У меня все эти опции работают. Если у Вас что-то не работает, стоит сначала сообщить об этом Tulon'у – баги СТ устраняются весьма оперативно.

11. Да, такое есть. Можно рассматривать возможность раздельного просмотра слоев, как фич-реквест к будущим версиям. Пока же наиболее правильно не выводить текстовые страницы в смешанном режиме, и внимательно (не только через ленту предпросмотра) проверять все страницы с иллюстрациями после вывода.

12. Таким образом СТ предоставляет возможность выбора - закодировать обработанные сканы без разделения (в режиме scanned или photo), либо методом раздельных сканов (МРС). К сожалению (см. п.4) для кодирования МРС пока что требуется один-два лишних шага.

13. Ластик, как растровый след от движения стирающей фигуры (прямоугольника или окружности), насколько я понимаю, действительно, вещь, слабо совместимая с концепцией СТ. В данном случае да, требуется либо дополнительно удалить грязь в tif-файлах во внешнем редакторе, либо чистить непосредственно djvu – с помощью белых аннотаций и Djvu Pal. Если устроит белая пользовательская зона, то она давно ждет своей очереди среди списка озвученных фич-реквестов СТ.

Выводы:

1. Хотите Вы или нет, но СТ уже является средством "всё-в-одном" для сканобработки. Да, менее универсальным, чем СК, и во многом осознанно менее универсальным (зато обозримым). И в этом плане СТ, если хотите, «честнее», чем СК. Если какой-то фичи в СТ нет, я просто знаю, что ее нет, и все. Если какой-то фичи нет в СК, то это значит, что я, скорее всего ее просто не нашел, и вряд ли найду.

2. См. пп. 5,6 выше.

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

Нам такая программа нужна.
« Последнее редактирование: 06 јРЩ 2010, 18:34:13 от 57an »

SorokaSV

  • Пользователь
  • **
  • Сообщений: 56
    • Просмотр профиля
    • E-mail
Re: Недостатки Scan Tailor
« Ответ #2 : 07 јРЩ 2010, 11:13:06 »
8. Imho, не особо существенно, занимают ли обработанные сканы 2%(LZW) или 1%(G4FAX) от размера необработанных сканов.
У меня FR8 отказался брать 2 из 320 LZV файлов ST. Пришлось в ирфане преобразовывать в G4.

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: Недостатки Scan Tailor
« Ответ #3 : 07 јРЩ 2010, 11:36:23 »
Что-то никто больше кроме 57an ничего сказать не хочет...  :) Все довольны Скан Тейлором?  ;D
57an
В СТ, как известно, реализован такой принцип работы: на всех стадиях обработки, (кроме последней) программа никак не изменяет обрабатываемые сканы - а лишь запоминает применённые пользователем сканобработки - с тем, чтобы реально их все применить на последней стадии ("Вывод"). Кстати - надо бы придумать какой-то термин для такого принципа обработки (для удобства обсуждения). Давайте хоть временно обзовём это "принцип выводной обработки" (ПВО).

Я считаю концепцию ПВО неверной. Из-за того, что на всех стадиях СТ не создаёт временные файлы с промежуточными результатами обработки. А такие сканы нужны -  их можно, например, передать в другую программу. И потом - именно концепция ПВО и не позволяет Tulon реализовать ластик в СТ - а ластик там крайне нужен - и причём на этапе, как минимум, "Полезная область" - для удобства работы с программой.

Цитировать
Да, менее универсальным, чем СК, и во многом осознанно менее универсальным (зато обозримым).
Вот. То есть, и Вы тоже признаёте, что СТ не годится для обработки ЛЮБЫХ сканов (в отличие от СК). Но, проблема-то в том - а как ЗАРАНЕЕ, ещё ДО начала сканобработки, определить - справится СТ с тамими-то сканами, или нет, и что делать, если не справится? (в плане качества - фуфло-то он, конечно, выдаст).

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

И, если бы я не сделал программу ST Split - с возможностью генерации передних субсканов в исходном режиме цветности - то тогда продукцию СТ можно было бы вообще выбрасывать в некоторых случаях.

Только представьте себе - понадеяться, что, "наверное, СТ сможет обработать такие-то сканы". Обработать до конца - и всё-таки убедиться: "нет, СТ не смог обработать эти сканы. Вся работа коту под хвост". Вам такая программа нужна?

Пользуясь случаем, я хочу обвинить лично Tulon в том, что он на самом деле движим исключительно личными честолюбивыми амбициями - ему, как я думаю, очень хочется стяжать славу "великого покорителя сканобработки" (нечто подобное) - вместо того, чтобы исходить из интересов дела (как это все мы делаем).

Я во всех его действиях отчётливо прослеживаю такой мотив.

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

Ярчайший пример: почему, спрашивается, Tulon, не сделал в СТ функциональность "Сепаратор"? Это что, так, что ли, трудно? А я скажу, почему: а всё потому, что он умышленно старается затруднить применение таких программ, как DjVu Imager и DjVu Small, к обработке сканов, получаемых из СТ - поскольку Tulon хочет сделать свои аналоги DjVu Imager и DjVu Small. (опять - "не делиться славой").

Tulon хочет "всё подмять под себя" и "ни с кем не делиться славой".

Если бы он был реально в состоянии это сделать - ради бога, вперёд.

Но, конечно, у него просто физически не хватает сил на это - вот он и лепит всякую залипуху (СТ), отчаянно, порой путём обмана и фальсификаций, пытаясь выдать дерьмо за конфетку. Вот он брался сделать свой dewarping - не получилось. Что ж, тем хуже для dewarping'а - "а заткнёмся-ка мы теперь о dewarping навсегда, и сделаем-ка вид, что никакой dewarping и вообще не нужен. По крайней мере, не сделаем ничего, чтобы допустить Book Restorer с совместной работе с СТ".

Но реальность не желает подчиняться амбициям Tulon. И в результате страдает ДЕЛО.  СТ получается однобоко-некачественным. А как ещё может быть, если Tulon ставит себя цель "втереть очки", а не "решить проблему со сканобработкой". Как говорится, почувствуйте разницу.

Вот тот же bolega, вне всякого сомнения, всегда ставил перед собою цель "решить проблему со сканобработкой". Потому я и называю СК "честной" программой.

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

Суть преступления Tulon в том, что нельзя ставить свои личные амбиции превыше общих интересов (а он делает именно это).

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

Граждане, вас обманывают со Скан Тейлором. Долой Скан Тейлор. Да здраствует альтернатива Скан Тейлору!

Цитировать
4. На мой взгляд, основная причина данных намерений - в отсутствии нормального freeware одноступенчатого djvu-кодера. И в том числе тем, что Вы не желаете сделать поддержку МРС непосредственно в Djvu Small.
Да ну это абсолютно невозможно - сделать такое. Как же Вы это не понимаете? То есть, возможно - но вредно и неправильно. Это называется "вредный универсализм". Правильно делать только так, как я - сначала отдельно кодируем чёрно-белый DjVu, затем, совершенно отдельно вставляем в него иллюстрации. Такая и только такая схема имеет право на жизнь - всё остальное будет мерзким суррогатом (видимо, нечто такое Tulon и хочет сделать).

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: Недостатки Scan Tailor
« Ответ #4 : 07 јРЩ 2010, 11:50:44 »
Цитировать
Что-то никто больше кроме 57an ничего сказать не хочет...
Пока писал предыдущий пост, вот SorokaSV написал.

SorokaSV, спасибо за ответ.

Прошу всех желающих (а не только уже высказавших хоть что-то 57an и SorokaSV) высказаться по сути вопроса.

Обработка сканов - это "святое". Я здесь ни на какие "авторитеты" (Tulon?) не посмотрю - не дам им всё на полный откуп - чтобы они, что хотели, то и творили - а я чтобы даже и слова не сказал против (творимых ими безобразий).

57an

  • Постоялец
  • ***
  • Сообщений: 201
    • Просмотр профиля
    • Djvu Bookmarker on SF.net
Re: Недостатки Scan Tailor
« Ответ #5 : 07 јРЩ 2010, 14:25:43 »
SorokaSV,
LZW черно-белые tiff - это реакция Tulon на просьбы трудящихся.
Похоже, однозначного решения данной проблемы нет. Только пункт в опциях - тип сжатия 1битных сканов. Либо перекодирование отдельным шагом.

monday2000,
Еще раз повторяю - чудес СТ никогда и никому не обещал. Не подавайте фуфло на вход - не получите фуфло на выходе. Как получить не фуфло на входе - см. советы по сканированию в вики-документации к СТ.
У Вас-то самого есть еще что сказать именно по-существу, кроме майских лозунгов про злого непослушного Tulon'а, который-де позарился на Ваш кусочек пирога? :)

Кстати, по мере возрастания опыта, уменьшается и перфекционизм в отношении постобработки. В большинстве случаев для разделенных сканов с растровыми иллюстрациями я уже нахожу вполне допустимой схему 600dpi для текста, разрешение растра (120 или 150 dpi) для иллюстраций. Тем более, что с учетом сглаживания на экране небинаризованный (попавший в иллюстрации) 150 dpi текст выглядит практически так же, как бинаризованный 600 dpi.

Т.е. все чаще хватает функционала FSD+msepdjvu с его парой-тройкой опций для настройки.

Это к вопросу об "суррогатности" одношагового МРС-кодера.

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: Недостатки Scan Tailor
« Ответ #6 : 11 јРЩ 2010, 15:50:26 »
57an
Цитировать
У Вас-то самого есть еще что сказать именно по-существу, кроме майских лозунгов про злого непослушного Tulon'а, который-де позарился на Ваш кусочек пирога?
Давайте подведём некоторые итоги (т.е. я скажу "по-существу").

Я затеял это обсуждение с одной целью: показать наличие проблемы. Возможно, мне не вполне это удалось - вопрос всё же довольно тонкий. Может, просто с первого раза такие вещи не находят широкого общественного понимания. Думаю, я ещё не раз вернусь к этой теме - стараясь всякий раз подобрать наиболее убедительные примеры. Я "нутром чую", что СТ - это "не то", но объяснить это окружающим непросто.

Зачем мне нужно "доказать, что СТ - плохой"? А для одной цели - открыть желающим дорогу в плане создания иных книгосканировочных программ. Ведь сейчас все словно зазомбированы этим СТ, и вроде как "нет смысла" делать кому-то иную программу по сканобработке.

А смысл - есть, и это главный вывод.

Можно ли исправить СТ? Быть может. Я бы предложил следующее:

1. Убрать из СТ стадии 1. Исправление ориентации и 2. Разрезка страниц. Взамен сделать отдельную программу, и в ней разрезать развороты (со сплошным перенумеровыванием выводных файлов).

2. Сканы, прошедшие стадию 3. Компенсация наклона, сохранять на диск как промежуточные файлы (автоматически внутри самого СТ). Это позволит, во-первых, получить желающим программу для пакетного визуального Deskew. А во-вторых, и это самое главное - см. далее п.3.

3. Реализовав п. 2, На стадии 4. Полезная область делаем ЛАСТИК. И чистим им сканы, сохранённые на диск после 3. Компенсация наклона - с тем, чтобы уже на почищенных ластиком сканах определять полезную область.

4. На стадии 6. Вывод сделать функционал "Сепаратор" + опцию вывода переднего субскана в сером/цветном.

Такова программа-минимум, как можно было бы исправить СТ. Это, конечно, не жёсткая схема - а лишь идея на концептуальном уровне. Но, думаю, Tulon никогда этого не сделает.
Цитировать
Не подавайте фуфло на вход - не получите фуфло на выходе.
А это невозможно. Сколько есть книг, которые как ни сканируй - всё равно получишь низкокачественные сканы.
Цитировать
Т.е. все чаще хватает функционала FSD+msepdjvu с его парой-тройкой опций для настройки.

Это к вопросу об "суррогатности" одношагового МРС-кодера.
Ну я так и знал, что Вы именно так и рассуждаете - именно отсюда "растут ноги" Вашей идеи "скрестить DjVu Small и DjVu Imager". Такие убеждения - это настоящий "корень зла". Tulon-то рассуждает точно также - и это главное, почему СТ обречён "в исторической перспективе" на крах. Нельзя так рассуждать - нужно как раз наоборот. Потому что, откуда Вам знать, что на 10 тыс. "типовых" случаев сырых сканов не встретится один такой, который не впишется в общие рамки? Tulon и Вы этим пренебрегают - потому что так, конечно же, проще - но это дьявольская "простота" - ведущая в ад, если можно так выразиться.
Цитировать
который-де позарился на Ваш кусочек пирога?
Да пусть зарится - я не возражаю. Я лишь возражаю против использования miniDjVu. Нельзя miniDjVu использовать - по крайней мере, пока. Только после гипотетического радикального математического-алгоритмического улучшения.
То, что он "позарился" (как Вы выразились) - это действительно так. Вместо того, чтобы думать об улучшении СТ (что крайне необходимо), он стремится захватить как можно бОльшую долю "рынка" DjVu-книгосканирования.

Подобное я воспринимаю как действия, диктуемые личным честолюбием - а не интересами дела. Возникает вопрос:

И какого ж хрена Вы лезете в создание своего DjVu-кодёра - когда Ваш СТ ещё пока что ниже плинтуса?

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

К тому же - Tulon не просто хочет "захватить рынок". Он же заодно пытается оттуда вышвырнуть другие программы - путём того, что умышленно и специально делает СТ максимально несовместимым что с DjVu Small+DjVu Imager, что с Book Restrorer 4.2.1. Это ли не есть подтверждение нездоровых честолюбивых амбиций? Напоминает кукушонка, который, будучи подброшенным в гнездо, выкидывает яйца птенцов приёмных родителей.

СТ делать - это ж надо годами, кропотливо как bolega, вылизывать каждую мельчайшую мелочь. "Галопом по европам" не выйдёт.

Конечно, Tulon не в силах чисто физически сделать много высококачественных программ - но честолюбие-то гложет, ему, как я понимаю, захотелось "доминировать" (его желание создать свой DjVu-кодёр) - вот он и пытается "втереть очки", что якобы "так и надо" и "этого качества достаточно".

В нашем деле нельзя рассуждать понятиями "доминирования". В нашем деле нужно уметь подчинить личные амбиции и честолюбие интересам общего дела. Я, к примеру, всегда именно так и поступаю - и потому-то такие, как Tulon, меня не могут не возмущать (тщеславные честолюбцы). И продукция таких людей, как показывает практика, почему-то всегда в конечном итоге идёт всем во вред.
« Последнее редактирование: 11 јРЩ 2010, 16:18:21 от monday2000 »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: Недостатки Scan Tailor
« Ответ #7 : 13 јРЩ 2010, 11:25:12 »
Обнаружился ещё такой момент:

Качество бинаризации, которое делает СТ, оказалось недостаточным. Я сравнил СТ-бинаризацию с бинаризацией Book Restorer - оказалось, что СТ производит более тонкие (худосочные) буквы, нежели чем Book Restorer. После BR текст выглядит таким, приятно-жирным, чётким-пречётким. СТ порождает ощутимо более тонкие буквы. Вроде мелочь - а всё же имеет значение.

СТ, думаю, имеет слишком малый диапазон порога бинаризации - даже после его расширения до +-30. Это ещё одно проявление ложно понятой "простоты" использования программы. А может - дело не только в одном лишь пороге - может, Оцу-бинаризация вообще не самое лучшее. Много ли Tulon над ней экспериментировал? Может, разумнее сделать в СТ несколько видов бинаризации - на выбор пользователя?

И ещё такое у меня возникло соображение: со слов Tulon он проживает сейчас в Лондоне. Я думаю, это тоже негативно влияет на качество СТ. Tulon декларирует, что делает СТ "для домохозяек" - и я думаю, что имеются в виду именно западные "домохозяйки" - а не русские.

Другими словами, Tulon, живя "там", невольно погружён в ту культурную среду, и невольно подстраивается под вкусы и возможные запросы именно пользователей американо-западного толка.

Ведь именно им так и надо - попроще, попримитивней, и не нужно им слишком уж хорошее качество (потому что они вообще гораздо более ленивые ИМХО). Западный обыватель в массе своей гораздо более туп и убог, нежели чем российский.

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

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: Недостатки Scan Tailor
« Ответ #8 : 13 јРЩ 2010, 18:56:28 »
Есть и ещё одно соображение, почему нужно делать альтернативу СТ:

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

Я думаю, что число программ по сканобработке следует довести до 5-10. Нельзя допускать такой обречённости, как сейчас: или - СК, или - СТ. Всё. По-другому - никак, "хоть в петлю".

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

К примеру, того же bolega никак не обвинишь в недобросовестности. Совершенно очевидно, что СК делался с целью "решить проблему сканобработки" - а не "снискать себе лавры великого решателя проблемы сканобработки" (как поступил Tulon).

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

В общем, Tulon постоянно пиарит (в нехорошем смысле) свой СТ.

И ещё Tulon постоянно пытается разного рода шулерскими приёмами "подогнать" реальность под свой СТ - а реальность что-то ну никак под СТ не "подгоняется". :) Реальность оказалась "почему-то" гораздо сложнее и многограннее, чем этот примитивный СТ.

Поэтому, необходимо, чтобы следующий человек, начиная делать программу по скан-обработке, с самого начала поставил бы себе цель не "стяжать лавры", а "решить проблему со сканобработкой".
« Последнее редактирование: 13 јРЩ 2010, 19:01:41 от monday2000 »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: Недостатки Scan Tailor
« Ответ #9 : 15 јРЩ 2010, 22:12:48 »
Выскажу свои соображения по поводу функционала разделения сдвоенных разворотов.

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

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

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

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

А всё это из-за того, что и bolega, и Tulon ложно понимают понятие "простота программы". Им кажется, что "всё должно быть в одной программе" - якобы в этом и заключается "простота".

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

"О, как здорово!" - скажут bolega и Tulon. :) "Это же как просто! - Не надо иметь целых 2 столовых прибора вместо одного!"  "Мы не хотим "заморачиваться" с отдельной ложкой и отдельной вилкой - боже мой, какая сложность - мы хотим одну единую ложко-вилку!" :)

Tulon скажет "Я делаю столовые принадлежности для домохозяек - которые не хотят "заморачиваться" с отдельной ложкой и отдельной вилкой - поэтому я сделал простую и удобную единую ложко-вилку". :)

Вот именно так bolega и Tulon понимают понятие "простоты". Ну разве не бред? Что можно после этого сказать об этих людях и об их видении мира? :) Как минимум, просто пожать плечами... И вот ТАКИЕ люди делают нам программы для сканобработки...

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

На что Tulon мне ответил примерно следующее: "а меня не волнуют проблемы пользователей CuneiForm - меня волнует только СТ".

Только теперь я уже понимаю - что это было ещё одно проявление нехорошего честолюбивого эгоизма Tulon. Да он просто боится, чтобы СТ никто не "оттеснил на 2 план", т.е. Tulon всеми силами старается не допустить использования СТ в качестве вспомогательного средства сканобработки - чтобы не потерять "пальму первенства" - и ради этого он готов пуститься во все тяжкие - пиар, пренебрежение реальными интересами дела, и т.п. Такое поведение я рассматриваю на грани преступного.

Да что там "вспомогательного средства сканобработки" - Tulon просто панически боится вообще, чтобы ЛЮБАЯ сторонняя программа прикасалась к сканам, проходящим/прошедшим СТ - вот до чего его довело его болезненное честолюбие!

Есть тут ещё один подлый момент: когда просишь у Tulon "сделайте то-то", он говорит "я очень занят, у меня нет времени, я устал". "Мне приходится делать сложные вещи, и я от этого сильно устаю".

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

Но тут не всё так просто - тут надо посмотреть повнимательнее. На самом-то деле моя просьба вычленить функционал разрезания сдвоенных разворотов в отдельную программу должна сильно ОБЛЕГЧИТЬ жизнь Tulon - поскольку это привело бы к РАДИКАЛЬНОМУ упрощению программного кода СТ! Но Tulon "прикидывается чайником", и тут выставляя дело так, якобы "он устал от выполнения сложных по реализации запросов пользователей".

Такое поведение Tulon я расцениваю как мелкую подлость - на самом-то деле он таким путём маскирует истинную причину не-выделения в отдельную программу функционала по разрезанию страниц - это его честолюбивая боязнь "утратить пальму первенства".

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

Почему же, спрашивается, на горно-обогатительной фабрике не сделают один-единственный большой аппарат, сочетающий в себе все простейшие операции по обработке руды - по жёсткой схеме? Tulon бы так и поступил - сказал бы, что так "проще". И что итоге? Да вверг бы горно-обогатительную фабрику в огромные убытки - когда пришлось бы его "чудо-аппарат" выкидывать - а взамен делать всё, как было - т.е. ряд простейших аппаратов. Хотя нет - никто бы ему просто не позволил сделать подобное там.

В философии работы горно-обогатительной фабрики заложен большой смысл. Он в том, чтобы последовательно-итеративно, всё более и более, на каждом этапе обработки УНИФИЦИРОВАТЬ входящую руду - постепенно приводя её к "общему знаменателю". Причём, за счёт "элементарности" и независимости каждого отдельного аппарата достигается максимальная гибкость и совершенство процесса унификации руды. И только уже унифицированный рудный полуфабрикат можно вписать в рамки некоей жёсткой схемы по финишной обработке руды.

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

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

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

Именно поэтому я и говорю о том, что нужен некий новый человек - кто сделал бы ещё одну программу по сканобработке. Подразумевая при этом, что такой человек должен, в отличие от Tulon, с самого начала поставить общественное превыше личного, и засунуть свои честолюбивые амбиции в одно место (а иначе ничего путного не получится).
« Последнее редактирование: 15 јРЩ 2010, 22:40:19 от monday2000 »

57an

  • Постоялец
  • ***
  • Сообщений: 201
    • Просмотр профиля
    • Djvu Bookmarker on SF.net
Re: Недостатки Scan Tailor
« Ответ #10 : 16 јРЩ 2010, 00:30:29 »
Самое интересное в СТ, что можно почти любую предложенную вами задачу решить в виде патча проекта СТ (как общеизвестно, это обычный XML-файл). По данному принципу, например, работают мои утилиты ST Output Only и ST Outliner.

Хотите сделать только бинаризацию - загружайте сканы в Output Only (или сделайте ее не-NET аналог), а получившийся пройденный до 5 стадии с нулевыми углами поворота и размером полезной области в размер скана проект грузите в СТ и бинаризуйте уже его.

Не нравятся неровные границы автоопределенной области изображений - берете ST Outliner (или пишете его
не-NET аналог), и на базе информации о проекте и содержимого папки automask автоматически создаете прямоугольные пользовательские зоны, обводящие авто-зоны. Кстати, в данной программе заложена почти половина логики, которая могла бы потребоваться, не придумай U235 механизм LayerTailor.

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

Сила СТ в том, что он дает программисту практически все необходимое для обхода своих недостатков (даже надуманных).

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

Аналогичный XML-подход есть, например, в opensource векторном редакторе Inkskape.
« Последнее редактирование: 16 јРЩ 2010, 17:38:11 от 57an »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: Недостатки Scan Tailor
« Ответ #11 : 16 јРЩ 2010, 11:06:05 »
57an
Это, конечно, хорошо - что имеется подобный выход из проблемных ситуаций. Однако, это, как выражается Tulon, "костыльный" подход. Почему бы сразу не сделать всё, как надо?

Я мыслю себе правильное решение следующим образом:

Некто создаёт и хорошо документирует класс - "графический движок". Допустим, под MFC. Причём документирует на уровне программиста.

Другие программисты портируют этот класс на другие платформы - Qt, .NET, и пр. - перенося на эти платформы принципы, изложенные в исходном классе.

Готовый класс удобно оформить в виде, скажем, подключаемой dll.

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

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

Сделать такой класс ИМХО весьма непросто - это длительная, тяжёлая и крополивая работа программиста. Даже Tulon'у это не удалось сделать - у него графический движок глючит (в плане отрисовки скроллбаров). Кстати - Tulon долгое время не хотел делать скроллбары - и как раз потому, что он чётко понимал, что не сможет сделать полноценный графический движок - но вместо того, чтобы честно сказать "я не могу сделать полноценный графический движок - на уровне такового в СК", Tulon лицемерно заявил, что, дескать, "скроллбары не нужны" (я уже из этого заявления понял тогда ещё, что Tulon за птица такая на самом деле). Просто Tulon'у очень не хочется признавать недостатки СТ - и он всеми путями (любыми правдами-неправдами) старается увернуться от ситуаций, могущих высветить несостоятельность СТ. Меня давно уже это лживое лицемерие Tulon'ское раздражает как минимум.

А конечно - приятнее и легче заграбастать себе все "вкусные вершки" (в виде в целом работающей, но имеющей глюки с графическим движком программы) - чем долго и нудно возиться с неприятными "корешками" - (в виде отладки графического движка). "Легче" оставить в серьёзно недоработанном виде графический движок - но зато, сделав в результате "вроде-бы-программу", "срубить" при этом благодарности полчищ малограмотных юзеров, которые не слишком-то будут во всём разбираться, и примут всё за чистую монету. Вот такое мошенничество мелкое с СТ мы имеем. Кстати, поползновение Tulon сделать свой DjVu-кодёр укладывается ровно в ту же самую логику.

Полноценный графический движок удалось создать bolega в СК. Я, кстати, недавно поинтересовался - сам ли он его сделал - или взял уже готовый из коммерческой библиотеки ImageLib Corporate Suite 6.0 - она лежит у меня тут: http://djvu-soft0001.nxt.ru/imagelib_corp_suite_6_0.rar , а офф. сайт тут: http://skylinetools.com/imagelib/index.html . СК базируется именно на этой графической библиотеке. Я думаю, на её крякнутой версии - хотя bolega утверждает, что на легально купленной. Будь та библиотека легально купленной - в СК имелось бы уведомление "программа имеет такую-то лицензию, и работает на базе такой-то библиотеки". Потому что практически все графические библиотеки имеют такое обязательное лицензионное требование, что если ты её используешь, ты обязан явно об этом прописать где-то в своей программе (типа в окошке "About").

Но bolega мне не ответил - сам он делал графический движок - или взял уже готовый. Да я и не знаю - а есть ли в той библиотеке такой готовый графический движок?

Я предполагаю, что bolega всё-таки взял уже готовый движок. Почему я так думаю? У меня такие соображения:

1. bolega мне не сказал: "да, это я сам сделал такой графический движок".

2. Сколько существует бесплатных открытых просмотрщиков растровой графики (список тут: http://www.djvu-soft.narod.ru/bookscanlib/) - НИ ОДИН не имеет достаточно качественного графического движка. Да что там - даже иные коммерческие программы имеют дрянной графический движок! (типа http://www.recogniform.com/image-processing.htm ). Неужели они все такие дураки, а вот один bolega оказался такой умный?

3. bolega писал, что СК v1.0 он сделал за один месяц, когда болел. Я думаю - сделать столь качественный графический движок за один месяц - крайне затруднительно. Чтобы сделать графический движок за столь малый срок - надо определённо уже заведомо иметь приличный багаж весьма специфических знаний из области программирования растровой графики, да ещё и быть опытнейшим программистом (на уровне автора WinDjView - кстати, самый крутой программист из всех тех, кто из нашего круга. Tulon и рядом не стоял).

4. bolega совершенно не похож на опытнейшего программиста. Он, скорее, похож на талантливого дилетанта в области программирования. А как ещё объяснить столь нарочито-бездарное качество интерфейсного оформления СК? Ни один настоящий программист не допустил бы подобного кощунства - его просто вывернуло бы наизнанку. К тому же СК изобилует глюками (и поныне) - и bolega явно не в силах их устранить.

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

Так вот - когда такой класс - графический движок появится - тогда и появится массовое общественное создание самых разнообразных программ по сканобработке. И тогда смысл "захватывать нишу программ сканобработки" для какого-нибудь такого Tulon начисто утратится - зачем, если таких СТ-подобных программ будут десятки, и такие как Вы, 57an, легко сможете писать свои собственные программы по сканобработке.

Вот это и будет наиболее грамотным решением проблемы программ по сканобработке. Такое решение надёжно застрахует нас от всякого рода амбициозных честолюбцев.

Другая сторона вопроса - создание банка повторно используемых алгоритмов сканобработки - но это уже гораздо проще, чем проблема графического движка. И тут я даже уже успел предпринять некие шаги - см. мой проект BookScanLib http://www.djvu-soft.narod.ru/bookscanlib/ .

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: Недостатки Scan Tailor
« Ответ #12 : 19 јРЩ 2010, 16:26:13 »
Tulon написал в главном топике по СТ что он "уходит в форума" http://forum.ru-board.com/topic.cgi?forum=5&topic=32945&start=300#20 .

Я хотел бы высказать своё мнение относительно этого события.

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

Так откуда же берётся эта "невыносимая нагрузка"? Неужели так должно быть всегда - при создании любой популярной программы по сканобработке? И что же Tulon делать, чтобы решить эту проблему?

Давайте посмотрим повнимательнее на проблему.

1. Так откуда же берётся эта "невыносимая нагрузка"?

Как известно, Tulon провозгласил, что он делает "программу для домохозяек". Идея вроде бы хорошая. Но так ли всё просто?

Я думаю, здесь есть как минимум одна проблема: ИМХО на сегодняшнем уровне развития алгоритмики создание "программы для домохозяек" НЕВОЗМОЖНО. Эта цель - недостижима, и попытка всё же достичь её может привести только к истощению своих сил (моральных и физических).

Дело в том, что, как ни старайся - а проще определённого (и весьма не-низкого) уровня сложности любая программа по качественной сканобработке быть НЕ МОЖЕТ. Пока не может. Может, сможет лет через 5-10 - когда мы объединёнными усилиями не разработаем достаточно "умные" и "автоматические" алгоритмы.

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

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

2. Неужели так должно быть всегда - при создании любой популярной программы по сканобработке ("невыносимая нагрузка")?

Тут уместно сравнить Tulon с bolega - точнее, с теми временами, когда bolega активно занимался разработкой СК.

Я не припоминаю, чтобы bolega хоть когда-либо говорил, что у него "невыносимая нагрузка". А всё потому, что bolega, в отличие от Tulon, никогда не "гнался за престижем", и не пытался создать пресловутую "программу для домохозяек".

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

- Идеология "выводной обработки" (когда реальные изменения сканов - только на последнем этапе). (ИМХО в корне неверная идеология - по крайней мере так, как это сделано в СТ).
- Отображение сканов "виртуально порезанными" на всех стадиях после разрезки (с "прятанием ошмётка соседней страницы на одиночном скане (!!! - какое безумие)").
- Потоко-безопасные алгоритмы

Понятное дело - именно все эти излишние "красивости" и потребляют 70-80% от трудозатрат Tulon. Без всего этого можно запросто обойтись - но тогда ведь программа уже не будет такой "красивой" - а это будет само-укол честолюбию Tulon - так что "нет, уж лучше 100 раз пожаловаться на судьбу и на таких нехороших пользователей". :)

3. И что же Tulon делать, чтобы решить проблему "невыносимой нагрузки"?

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

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

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

Просто я ожидал, что bolega сам "прозреет" (а я ему помогу ;D), и сам "перекроит" свой СК - с целью выкинуть всё плохое, и оставить хорошее. Но с СК это не получилось - потому-то и появилась на свет моя статья http://www.djvu-soft.narod.ru/kromsator/alternative.htm - наполовину побудившая Tulon сделать СТ.

Если продолжить аналогию с завоеванием космоса, то можно вспомнить, как он (космос) завоёвывался: небольшими шагами, с многочисленными экспериментами, опираясь на каждом шаге на уже тщательно испытанный и железно опробованный предыдущий шаг (вместо Tulon'ской авантюрной бешенной гонки).

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

Но я сомневаюсь, что Tulon сможет пойти на это (и это его характеризует как человека, не так ли?).

А все остальные меры - вроде "ухода с форума" - так это так, только курам на смех. :) "От себя не убежишь", как говорится.
Цитировать
Странно ли, что тебе нет никакой пользы от странствий, если ты повсюду таскаешь самого себя?
Сократ в передаче Сенеки

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: Недостатки Scan Tailor
« Ответ #13 : 09 °ТУгбв 2010, 21:41:41 »
Некоторые соображения относительно СТ.

Интересно - почему же Tulon в своё время не захотел ввести в СТ модификации от аnagnost96 (вывод разделённых сканов)?

Кто-нибудь помнит - говорил ли Tulon что-нибудь по этому поводу, чем он объяснял своё нежелание ввести модификации от аnagnost96 в СТ?

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

Я думаю, что это была не случайность. Это так было специально задумано Tulon'ом.

Смысл всего этого в том, что Tulon очень не хотел, чтобы продукцию СТ было легко и просто обрабатывать в программах, сделанных не им самим.

Зато Tulon заявлял, что он хочет сделать своё miniDjVu-GUI. Скорее всего, Tulon рассчитывал передавать продукцию СТ ("неразделённый" на пары передний-задний субскан СТ-вывод) напрямую в этот самый miniDjVu-GUI - и уже там внутри производить разделение СТ-вывода и раздельно кодировать полученные пАры субсканов в DjVu (в неких программах, произведённых Tulon).

Я считаю такой подход Tulon'а неприемлемым. Во-первых, это называется "тянуть всё одеяло на себя". Это неэтично - в нашем "книжном" DjVu-сообществе принят как раз диаметрально противоположный - "коллективистский" подход (который даёт огромные экономические преимущества перед "индивидуализмом").

Во-вторых, это вредно для дела - одному Tulon на куски не разорваться, чтобы сделать идеальную программу, а других он старается не допустить к процессу (политика "собака на сене"). Ну сами посудите  - это же просто физически нереально - во всех случаях жизни суметь обработать сканы внутри СТ столь хорошо, чтобы их после СТ можно было сразу напрямую кодировать в DjVu. Одному человеку, в рамках одной программы, никогда чисто физически не потянуть реальное достижение подобной цели. Tulon просто довёл ситуацию до абсурда - "сам не гам, но и другому не дам".

Раз уж он такой индивидуалист - тогда пусть не претендует на содействие других людей в развитии своей программы. Так будет честней.

Вывод:

На основании всех этих рассуждений можно сделать один-единственный правильный вывод:

Время показало, что СТ - это не та программа, которая нам всем нужна. И никогда ею не станет. Это важно чётко понимать и не питать никаких иллюзий в отношении Tulon. Не стоит надеяться, что когда-нибудь в "светлом будущем" СТ вдруг станет "правильной" программой. Не станет. Никогда. Ведь для этого Tulon нужно будет стать своего рода "анти-Tulon" - а вероятность такого события ничтожна.

Пришло время для того, чтобы появиться некоей совершенно новой - пока абсолютно неведомой - "правильной" программе по сканобработке, автором которой будет, естественно, некий не-Tulon.

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

И после появления такой программы СТ сможет (и должен будет) уйти на заслуженный отдых. А главное - в тот момент времени это станет очевидно решительно всем.
« Последнее редактирование: 09 °ТУгбв 2010, 21:48:55 от monday2000 »

don555

  • Пользователь
  • **
  • Сообщений: 71
    • Просмотр профиля
    • E-mail
Re: Недостатки Scan Tailor
« Ответ #14 : 24 БХЭвпСам 2010, 02:49:23 »
Пробовал обрабатывать книги прогой СТ.
Минусы такие.
1. Очень долго обрабатывает страницы из серого в чёрно-белый.
2. Как только изменил структуру одной страницы, то есть вероятность, что и остальные начнут заново обрабатываться.
3. Возня с полями ужасная. Занимает много времени.
4. Фотографии получаются очень бледными, не такими как BR.
5. Ещё один минус такой. Вот, например, отредактировал книгу в BR. Начинаю бросать странички с фотографиями, которые вышли из BR без компрессии с “Best” на djvu small-foto.
Сделал, скажем, файл djvu под названием 001. Затем идут несколько страниц с текстом, прошедшие BR –G4-битонал. Бросаю на djvu small -битонал. Называю файл 002. Потом опять скартинками-003 и т. д.
После этого мне нужно соединить эти файлы в один. Для этого я пользуюсь прогой DocumentExpressEnterprise. Так вот, после обработки книг через СТ., прога DocumentExpressEnterprise показывает ошибку и не соединяет файл.
Вот это минус
6. Нет ластика.
Поэтому мне пока удобней работать с БР