Дополнительно > Флейм
Недостатки Scan Tailor
monday2000:
Давайте обсудим недостатки программы 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. СТ - очень коварная программа. Она опасна. В некотором смысле, она подла. Её опасность в том, что она пытается выдать себя за совершенное средство сканобработки - на самом деле таковым не являясь. Внешняя красивость вводит в заблуждение большинство новичков, вызывая у них восторг и экстаз по поводу программы. Только имея определённый опыт в сканобработке, можно "разоблачить" СТ (что я и хочу сделать).
Короче, я считаю, что нам нужна альтернатива СТ, потому что нам не нужна такая "нечестная" и "подло-лицемерная" программа. СТ - есть зло, но понять это непросто, нужен опыт.
К примеру, тот же СканКромсатор, при всех своих огромных недостатках, гораздо более "честная" программа.
В общем, СканКромсатор, конечно, плох - но и Скан Тейлор не лучше. Поэтому - выход в том, чтобы создать нечто третье. И кому-то, отличному от авторов СК и СТ.
Если кто-то хочет что-то сказать по этому поводу - прошу высказываться.
57an:
Желаете пофлеймить про СТ? Ну что ж, давайте :)
Итак, в порядке перечисления “недостатков”:
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 выше.
СТ никогда не пытался и не пытается выдать себя за совершенное средство сканобработки. Я встречал только упоминания о позиционировании СТ, как более удобного, чем СК, средства для обработки качественных сырых сканов (отчасти, в этом причина отстутствия ластика или его аналога – на хороших сканах он просто не нужен). Как показывает мой личный опыт, программа способна и на большее.
Нам такая программа нужна.
SorokaSV:
8. Imho, не особо существенно, занимают ли обработанные сканы 2%(LZW) или 1%(G4FAX) от размера необработанных сканов.
У меня FR8 отказался брать 2 из 320 LZV файлов ST. Пришлось в ирфане преобразовывать в G4.
monday2000:
Что-то никто больше кроме 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:
--- Цитировать ---Что-то никто больше кроме 57an ничего сказать не хочет...
--- Конец цитаты ---
Пока писал предыдущий пост, вот SorokaSV написал.
SorokaSV, спасибо за ответ.
Прошу всех желающих (а не только уже высказавших хоть что-то 57an и SorokaSV) высказаться по сути вопроса.
Обработка сканов - это "святое". Я здесь ни на какие "авторитеты" (Tulon?) не посмотрю - не дам им всё на полный откуп - чтобы они, что хотели, то и творили - а я чтобы даже и слова не сказал против (творимых ими безобразий).
Навигация
Перейти к полной версии