Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » Scan Tailor (часть 2)

Модерирует : gyra, Maz

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153

Открыть новую тему     Написать ответ в эту тему

Widok



Moderator-Следопыт
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Scan Tailor


Задача программы - пост-обработка сырых сканов книг для последующей сборки в PDF/DJVU,CBR/CBZ и т.д.
Программа обеспечивает большое удобство для использования, большую интерактивность и не меньшую автоматизацию процесса (по сравнению со СканКромсатором).
Кросс-платформенный (Windows,Mac OS, Linux) проект с открытыми исходниками.


Англоязычный топик по ScanTailor
Ветки:
Scan Tailor Plus (Vadim "DikBSD" Kuznetsov) >>>  последняя версия   (Отличия от авторской версии)
Scan Tailor Еnhanced (Petr "pejuko" Kovar) >>>  последняя версия   (Отличия от авторской версии)
Scan Tailor Featured (monday2000) >>>  последняя версия   (Отличия от авторской версии)
Scan Tailor Advanced (4lex4) >>>  последняя версия (Отличия от авторской версии); ветка develop
 
Документация:
Документация (Wiki) | Зоны картинок в ScanTailor | ScanTailor. Быстрое начало | Видеоуроки и скринкасты новых функций СТ от Tulona
Статья: Scan Tailor. Программа для обработки отсканированных книг
Видеоурок: Создание DjVu с помощью Scan Tailor (зеркало)
Использование Scan Tailor совместно с Djvu Imager (сборка djvu методом разделенных сканов)
Как собрать Scan Tailor из исходных кодов под Windows
Почему нельзя сделать сплошную нумерацию вывода


Автор проекта - Tulon. Почему его здесь не видно? .
DikBSD автор ветки ScanTailor Plus история повторяется.
Юзеры! Будьте скромнее!


Дистрибутивы, форки, дополнения

Всего записей: 24190 | Зарегистр. 07-04-2002 | Отправлено: 12:17 17-02-2010 | Исправлено: ndch, 16:47 18-07-2018
StanFreeWare

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
monday2000
см. здесь.
Есть же версия "для печати"..

Всего записей: 865 | Зарегистр. 10-01-2007 | Отправлено: 16:26 09-09-2010
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Я добавил в шапку ссылку на новую схему именования выходных сканов в СТ. Как я понял, Tulon отказался от добавления к старому имени файла через подчёркивание нового имени, а также сменил расширение выходных файлов с *.tiff на *.tif.
 
Т.е. раньше было так:
 
На входе: 0001.tif, 0002.tif, ... , 0010.tif, ....
 
На выходе: 0001_0001.tiff, 0002_0002.tiff, ... , 0010_0010.tiff, ....
 
Если было разрезание разворотов - то имена выходных файлов ещё как-то менялись (уже не помню как).
 
Теперь всё (как я понял) сильно упростилось:
 
- Если не было разрезаний, то выходные имена равны входным именам.
- Если разрезания были, то выходные имена будут выглядеть так:
 
0001_1L.tif, 0001_2R.tif, 0002_1L.tif, 0002_2R.tif, ... , 0010_1L.tif, 0010_2R.tif,....
 
По-моему, это очень разумные и хорошие изменения. Отказ от *.tiff в пользу *.tif - вообще замечательно. А прежний подход с добавлением к старому имени файла через подчёркивание нового имени я всегда считал ошибочным и неправильным. Правильно так, как сейчас - т.е. в общем случае не менять именование входящих файлов (если не было разрезки).
 
Таким образом, если не делать разрезку в СТ (а я бы всем рекомендовал именно это), то тогда проблем переименования файлов из-за СТ теперь вообще не будет!
 
Добавлено:
StanFreeWare

Цитата:
см. здесь.  

Этот пост я видел. Но ничего в нём не понял. Там же в сущности ничего не ясно - из одного лишь него.

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 16:36 09-09-2010 | Исправлено: monday2000, 16:39 09-09-2010
woodyfon

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Перейдя на версию ST? которая имеет два резака, стало проще обрезать странички, где есть только одна из страниц. Также поднялась точность определения места корешка (мне так показалось). Перестал пользоваться напрочь синими кружками для поворота резака. Отсюда и ответ на ваш вопрос: Для чего он? Для удобства. Вы иногда говорите такие вещи, что кажется вы не занимаетесь обработкой книг вообще. И по поводу разделенных сканов. Лично я этот метод не использую. Вы на каждой страничке кричите , что это должны делать все и всегда. Стало даже интересно, поэтому прошу привидите какие-нибудь доки и(или) примеры. Возможно серые (иллюстрации в оттенках серого, а текст черно-белый) и цветные (цветные иллюстрации и черно-белый(иногда на другом фоне) сканы станет обрабатывать проще и быстрее. Ну все равно не понимаю  смысл разделенных сканов, если книга в конце концов собирается в pdf-формат. Вот если собирать книгу в djvu, то несомненно имеет смысл -повышается качество инезначительно увеличивается размер. Если я прав конечно. В принципе, добавить фичу разделения обработанных страниц Tulon бы мог - это не сильно бы усложнило интерфейс даже для домохозяек. Но если не хочет тогда не требуем.
 monday2000? уверен, что ваших знаний хватило бы для осуществления такой фичи. НЕ понимаю, почему не можете это реализовать, а только требуете и советеуете.

Всего записей: 412 | Зарегистр. 03-08-2007 | Отправлено: 00:34 10-09-2010 | Исправлено: woodyfon, 00:39 10-09-2010
anagnost96

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
woodyfon
 

Цитата:
Ну все равно не понимаю  смысл разделенных сканов, если книга в конце концов собирается в pdf-формат. Вот если собирать книгу в djvu, то несомненно имеет смысл -повышается качество инезначительно увеличивается размер. Если я прав конечно.

 
Смысл разделения сканов в том, что картинки (серые либо цветные) и текст (бинаризованный) требуют разного разрешения и разных методов сжатия. В этом отношении разницы между форматами DjVu и PDF (который тоже прекрасно позволяет совместить текстовый и картиночный слои на одной странице) нет никакой. Если этого не делать, то разрешение на выходе будет либо недостаточным для текста, либо избыточным для картинок (что ведет к увеличению объема). Кроме того, при упаковке страницы в PDF придется использовать формат, не обеспечивающий эффективного сжатия текстовых данных (опять же увеличение объема). Поэтому при правильном применении сегментация безусловно способствует уменьшению размера, а никак не наоборот.
 
Соответственно, спор здесь идет не о том, нужна ли сегментация (она безусловно нужна), а о том, следует ли ее делать вручную или доверять программе. Ну а на этот вопрос уже каждый отвечает в зависимости от меры своего перфекционизма и от того материала, с которым приходится работать. У меня, например, картинки на 90% такого свойства, что никакой алгоритм сегментации с ними заведомо не справится.
 

Всего записей: 132 | Зарегистр. 01-05-2009 | Отправлено: 01:16 10-09-2010
ndch

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
anagnost96

Цитата:
Смысл разделения сканов в том, что картинки (серые либо цветные) и текст (бинаризованный) требуют разного разрешения и разных методов сжатия.

Ага, но исследуя шапку "Электронные книги: сканирование, обработка, сборка" - это обнаружишь далеко не сразу.
 
Битональный в pdf (чаще всего)- tiff g4/jbig2; в djvu - JB2
полноцветный в pdf (чаще всего)- jpeg/jpeg2000; в djvu -IW44
 
"требуют разного разрешения" - чаще да, но с оговорками.
 

Цитата:
Соответственно, спор здесь идет не о том, нужна ли сегментация (она безусловно нужна), а о том, следует ли ее делать вручную или доверять программе.

Да. Кроме того, в "Электронные книги: сканирование, обработка, сборка" было время когда обсуждалось что лучше разделенные сканы или всё же стоит понять как работает сегментер. С выводами разобравшихся, что иногда лучше сегментер DEEE, но все зависит от материала.
 
Сейчас там, наконец то , дошли до clearscan, появившемся, если не ошибаюсь в 9-м акробате.
 
Год/полтора назад всматривался в cs - заметил что он даёт неплохие результаты, хотя на вид слабее сегментера deee.
Но вполне жизнеспособный, если речь идёт за борцунство за малый размер конечного файла.
 

Цитата:
Ну а на этот вопрос уже каждый отвечает в зависимости от меры своего перфекционизма и от того материала, с которым приходится работать. У меня, например, картинки на 90% такого свойства, что никакой алгоритм сегментации с ними заведомо не справится.

Во-первых: cегментер может сегментировать по-крупному , т.е решить что всё это полноцветное изображение.
Во вторых: страницы с глянцевых журналов можно "сегментировать" - например большие желтые буквы, но практического смысла в этом мало. Т.е. разглядывая сегментированную таким образом djvu, её вес и вес iw44, а также photo-djvu(можно сказать что это iw44 в чистом виде) невольно задумываешься - нафига козе баян ?
 
Моё мнение касательно журналов/детских книг - гораздо лучше выровненный и подчищенный pdf/jpeg2000, чем кривой сильносжатый убитый криво настроенным сегментеров djvu. Из такого pdf можно сделать маленькую djvu, но не наборот.

Всего записей: 4733 | Зарегистр. 31-08-2008 | Отправлено: 09:44 10-09-2010 | Исправлено: ndch, 10:01 10-09-2010
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
woodyfon

Цитата:
НЕ понимаю, почему не можете это реализовать, а только требуете и советеуете.

Tulon'у это сделать - пара часов работы. А мне нужно будет убить неделю-две на это. Поэтому рациональнее это сделать Tulon'у. Или кому-то ещё - у меня и так полно иных задач по DjVu.
 
И потом - если появится клон СТ с желаемой фичей - то его потребуется всё время обновлять обновлениями основного СТ. А это изрядная морока. Мне пришлось бы всё забросить ради этого. Поэтому лучше уж Tulon бы сделал это сам.
 
Добавлено:
PS Всё, разобрался с тем, как работает 2 резак. Спасибо всем за пояснения.
 
2-ой резак работает так: вырезается и остаётся область между 2-мя резаками. А остальное выбрасывается (и никакое переименование выходного скана не производится).
 
Правда, пока не понял - а зачем это нужно? У одиночного разворота есть лишь один ошмёток, который нужно отрезать - не два же?
 
Добавлено:
woodyfon

Цитата:
Перейдя на версию ST? которая имеет два резака, стало проще обрезать странички, где есть только одна из страниц.

Каким образом?
 
 
Добавлено:
woodyfon

Цитата:
Вы на каждой страничке кричите , что это должны делать все и всегда.

Ну конечно же, в случае наличия на сканах книги полутоновых (цветных) фотографий, разделение сканов действительно должны делать все и всегда (в случае последующего кодирования в DjVu).
 
В противном случае получится "порча картинок" в DjVu:
 
   
 
(иллюстрация от StanFreeWare)
 
Добавлено:
anagnost96

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

Как я понимаю, это концептуальный аналог PhotoDjVu? И, наверное, размер получается сопоставимым? Интересно, что это за сжатие - которое обычно применяется в PDF? Наверное, типа JPG? Или какое-то своё? (не считая JBIG2 и JPG2000)  
 
А то замучали PDF-щики своими обвинениями, что "DjVu портит картинки", а "PDF - нет".  
 
Я просто никогда в PDF книги не делал и не представляю себе, как там и что.

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 10:58 10-09-2010 | Исправлено: monday2000, 11:10 10-09-2010
woodyfon

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Каким образом?  

Раньше приходилось пользоваться кнопками для поворота резака. Сейчас только двигаю один или два резака.

Цитата:
Или кому-то ещё - у меня и так полно иных задач по DjVu.

Какие такие задачи? Уже всё все прошли и порешали, или вы продолжаете добиваться совершенства, которого никак не достигнуть.
В темке "Электронные книги: сканирование, обработка, сборка" разделение сканов разбирается достаточно хорошо? А то новые технологии перед тем, как внедрять надо пощупать и понюхать.

Всего записей: 412 | Зарегистр. 03-08-2007 | Отправлено: 12:49 10-09-2010
anagnost96

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
monday2000
 

Цитата:
Интересно, что это за сжатие - которое обычно применяется в PDF? Наверное, типа JPG? Или какое-то своё? (не считая JBIG2 и JPG2000)  

 
Ну, как известно, PDF -- это контейнер, так что там можно упаковать почти любой графический формат в зависимости от поставленных задач. Помимо JPEG или JPEG2000, можно использовать сжатие без потерь (LZW или deflate). Можно сделать фоновое изображение индексированным и тем самым уменьшить размер (этого иногда не хватает в DjVu). Ну а для бинаризованных изображений, наверное, нет смысла обсуждать другие форматы помимо JBIG2 и G4.
 
Лично я отдаю предпочтение DjVu, но считаю использование PDF целесообразным в двух случаях: либо картинки в книге настолько ценны, что сжатие с потерями неприемлемо, либо качество текста внушает опасения, и потому его нежелательно подвергать JB2-сжатию.

Всего записей: 132 | Зарегистр. 01-05-2009 | Отправлено: 13:29 10-09-2010
StanFreeWare

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
anagnost96
А разве lossless JB2 не оставляет информацию "пиксель в пиксель"?

Всего записей: 865 | Зарегистр. 10-01-2007 | Отправлено: 13:55 10-09-2010
C0USIN



Silver Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Полезная штука Dewarping. Но делать его логичнее не на этапе окончательного вывода а перед этапом определения полезных областей.  
 
С искривлением строк бороться достаточно просто еще на этапе сканирования. Мы просто кладем книгу так, чтобы строки были параллельны лампе. Не знаю почему, но помогает.
 
В старых книгах очень часто встречаются геометрические искажения. Например строки вверху страницы и внизу не параллельны. Или съезжают в сторону. Видимо это издержки докомпьютерной технологии верстки. Вот тут то и хочется привести полезную область к прямоугольному виду.
 
Кстати, если включить деварпинг, то отключаются зоны заливки. И полезная область смещается произвольным образом.

Всего записей: 2739 | Зарегистр. 18-07-2003 | Отправлено: 16:46 10-09-2010
U235

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
C0USIN

Цитата:
С искривлением строк бороться достаточно просто еще на этапе сканирования. Мы просто кладем книгу так, чтобы строки были параллельны лампе.

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

Всего записей: 635 | Зарегистр. 14-12-2005 | Отправлено: 17:17 10-09-2010
C0USIN



Silver Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

Цитата:
буквы будут сжаты в районе корешка.  

Они в любом случае будут сжаты. Просто строки останутся параллельны.
 
Мы купили сканеры OpticBook 3600. Теперь бумага прилегает плотно по всей площади страницы и достаточно раскрыть книгу только на 90 градусов. Единственный недостаток этого сканера - мертвая зона около 5 мм с края планшета. Попадаются книги, где текст намного ближе к корешку чем положено.

Всего записей: 2739 | Зарегистр. 18-07-2003 | Отправлено: 17:37 10-09-2010
U235

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
C0USIN

Цитата:
Они в любом случае будут сжаты.

Да, но алгоритм деварпинга (в том же ST) через 3D реконструкцию не только устраняет кривизну строк, но и исправляет сжатие букв.  
При варианте сканирования когда строки параллельны лампе исправление сжатия невозможно.

Всего записей: 635 | Зарегистр. 14-12-2005 | Отправлено: 18:16 10-09-2010
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Кстати, насчёт деварпинга.
 
Может быть, мне кто-нибудь поможет разобраться с тем, как использовать Dewarping от Рамиза Зейналова? А то я его уже скомпилировал под Windows (на XP запускается) - а как пользоваться - не знаю. И Рамиз на письма больше не отвечает. Вот такой идиотизм.
 
Может, кто-нибудь просто догадается, как им пользоваться? Один ум хорошо, а два (или больше), как говорится, лучше. А может, кто-то что-то знает об этом?
 
Все подробности тут: http://www.djvu-scan.ru/forum/index.php?topic=61.0
 
Я тут уже с Tulon обменялся несколькими электронными письмами. Оказывается, Tulon не хочет сделать встроенный в СТ экспорт разделённых сканов лишь потому, что, по его мнению, это вообще не нужно. (!) Tulon надеется на автосегментацию, которая сама разделит правильно текст и картинку (поскольку текст будет уже чёрно-белым, а картинка серой - на едином скане), и считает, что так будет проще для "чайников" , чем разделять сканы и кодировать их в DjVu раздельно. Tulon говорит, что "картинки попортятся не очень", и, дескать, это приемлемо - зато, мол, "пользователю не нужно заморачиваться с разбиением сканов".
 
Я его пытаюсь убедить в обратном. Я думаю, что это очень шаткий подход - разве можно уповать на тотальную безгрешность автосегментации (или же на минимальность её ущерба)?
 
В общем, разница в наших позициях состоит в том, что я считаю, что разбиение сканов нужно делать всегда (для случая книг с полутоновыми иллюстрациями), а Tulon утверждает, что разбиение нужно делать НЕ всегда (а "только для профессионалов").
 
Кто же из нас более прав и почему?

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 15:04 11-09-2010
ndch

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Кто же из нас более прав и почему?

Какой из тебя координатор ? Забудь.
 
У Тулона есть свой взгляд и он делает то что делает.
Хватит канючить, уже который год. Отвратительно.

Всего записей: 4733 | Зарегистр. 31-08-2008 | Отправлено: 16:35 11-09-2010
anagnost96

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
StanFreeWare

Цитата:
А разве lossless JB2 не оставляет информацию "пиксель в пиксель"?

 
По идее, конечно, оставляет, но что-то не лежит у меня душа к этому способу
 
monday2000

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

 
Это выяснилось еще в те дни, когда Tulon имел обыкновение появляться на форуме. Даже и письмами обмениваться ни к чему.
 

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

 
Но ведь это же так и есть. Если текст уже бинаризован, а картинка -- нет, то разделить их никакого труда не составляет. Проблема лишь в том, что при таком методе требуется двойной ресэмплинг картинок: 300->600 dpi для вывода смешанного изображения и опять 600->300 при сегментации. Если эта процедура Вас устраивает (меня-то как раз нет), то я вообще не вижу никакого повода для недовольства.

Всего записей: 132 | Зарегистр. 01-05-2009 | Отправлено: 16:55 11-09-2010
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ndch

Цитата:
Хватит канючить, уже который год.

Что уж "хватит" - так это хватит мне "тыкать".
 
Добавлено:
anagnost96

Цитата:
Это выяснилось еще в те дни, когда Tulon имел обыкновение появляться на форуме.

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

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 10:51 12-09-2010
Dashout



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
это уже паранойя...

Всего записей: 1129 | Зарегистр. 15-01-2005 | Отправлено: 12:51 12-09-2010
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
anagnost96

Цитата:
Но ведь это же так и есть. Если текст уже бинаризован, а картинка -- нет, то разделить их никакого труда не составляет.

Я начал диалог с Tulon по поводу вопроса "встраивать - не встраивать" разделение сканов именно прямо в СТ, а не в отдельную утилиту (вроде Сепаратор и т.п.). По мере беседы неожиданно выяснилось, что этот вопрос является следствием более важного вопроса: "всегда или не всегда делать разбиение сканов". Я считаю, что "всегда" (и даже думал, что так считают все, и это само собой очевидно), а Tulon, оказывается, считает, что "не всегда". Что в большинстве случаев "и так сойдёт" (по качеству), а кому "не сойдёт" - тот разделит сканы в сторонней утилите, а зато так, мол, интерфейс проще, и "чайнику не надо заморачиваться с разбиением сканов, а напрямую кодировать СТ-вывод в DjVu Solo 3.1 - чтобы там автосегментёр сам разделил тексты в маску, картинки в задний фон" (это я своими словами пересказываю мысль Tulon'а).
 
Я, пытаясь убедить Tulon в ошибочности его взгляда ("не всегда делать разбиение") привёл ему такие преимущества разбиения "всегда" перед "не всегда":
 
1. 100% гарантия качества при последующем DjVu-кодировании. Гарантированно полное отсутствие явления "порча картинок".
 
2. Отсутствие потребности в DjVu-кодировщике, обладающим автосегментацией. Взамен используются 2 гораздо более простых DjVu-кодировщика: чёрно-белый и цветной - которые могут быть даже свободно-бесплатными и с открытыми исходниками (и за этим ИМХО будущее). Из легально-бесплатных DjVu-кодировщиков, обладающих автосегментацией, есть один-единственный DjVu Solo 3.1 - но он и старый, и неудобный, и там нет профилей кодирования, и он создаёт DjVu версии 21 (а последняя - 27), и он сделан под Windows - а на других платформах его надо запускать только через виртуальную машину.
 
3. Возможность дообработать уже разделённые сканы в любой сторонней программе - перед DjVu-кодированием. А Tulon, получается, уповает на безграничную мощь СТ (что очевидно нереально).
 
4. Tulon'у обязательно потребуется встроить в СТ ещё и Blur - для размытия картинок. Это чтобы хоть как-то прогарантировать, что при последующей автосегментации вся картинка попадёт именно в фон. Но применение Blur - это лишняя проблема: это и сложнее, и труднее (надо ж размыть точно в меру - больше размоешь - качество хуже, меньше размоешь - не добьёшься хорошей подсказки автосегментёру - куда девается "простота" для чайника!), и время это отнимает. Да ещё и Blur - это, как ни крути, тоже своего рода порча картинок - просто более слабо выраженная.  
 
Многие пользователи ведь захотят, чтобы картинки именно вообще никак не портились - при кодировании в DjVu. Им же не объяснишь, что "картинки попортятся - но не очень сильно". Они тогда на PDF переключатся, потому что, мол, "в PDF картинки не портятся".
 
5. Субъективный довод: на мой взгляд, с разделёнными сканами нагляднее работать. Там сразу видно - как я разбил исходные сканы, правильно ли, и где какие ошибки разбиения имели место. И разбитые сканы можно просмотреть в любом вьювере - а не-разбитые (но логически разделённые на чб текст и серую картинку) сканы можно посмотреть (на предмет правильности логического разбиения) только в СТ - на стадии вывод (т.е. расположение и границы Picture-зон посмотреть).
 
Добавлено:
Dashout

Цитата:
это уже паранойя...  

Лучше взгляните на свои прошлые посты.
 
Кстати, к примеру, ScanKromsator делался как раз по правильному принципу "качество в ущерб простоте". Просто у bolega ситуация вышла из под-контроля (в силу недостатка программистской квалификации).
 
Поэтому, получается, что ScanKromsator - это "правильная программа" (просто некачественная), а Scan Tailor - это "неправильная программа" (но зато качественная).

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 13:13 12-09-2010 | Исправлено: monday2000, 13:24 12-09-2010
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Получается любопытная ситуация: оценивая творение Tulon, приходится оперировать какими-то абстрактными философскими категориями. Но это полезно - заодно ведь и формулируются краеугольные принципы, которые должны лежать в основе хорошей программы по сканобработке. Пока что я насчитал такие принципы:
 
1. Способность автора поставить общественные интересы превыше личных.  
 
Некоторые подозрения в этом грехе падают не только на Tulon - но даже и на bolega (допустим, как объяснение не-появления официального хелпа к СК).
 
2. Установление КАЧЕСТВА (сканобработки) во главе угла.  
 
И только потом уже погоня за простотой программы, эргономичностью, и т.п. Вот Tulon, например, считает, что небольшая порча картинок - это приемлемо. Я же полагаю, что нет - неприемлема никакая (неконтролируемая) порча картинок. То есть, Tulon считает, что небольшая потеря качества - допустима, если за счёт этого достигается выигрыш в простоте интерфейса. Это, безусловно, дьявольский путь - ведущий в никуда.
Хорошо хоть, bolega тоже ставит качество во главе угла.
 
3. Не-ущемление свободы пользователя.  
 
У Tulon'а с этим большие, им не осознаваемые, проблемы. Ему всё время кажется, что он уже всё решил за пользователя, как ему следует делать сканобработку. Это очень серьёзная ошибка (продиктованная, как минимум, слабостью кругозора Tulon). Дело в том, что никогда, даже самая совершенная программа, не может исчерпывающе удовлетворить пожелания-запросы всех пользователей. "Свобода превыше всего" - это железная и вечная аксиома, тут и думать нечего. Практически это должно выливаться в предоставление Tulon'ом возможности привлечь сторонние программы к процессу обработки сканов, проходящих через СТ. Сейчас это очень затруднено (нужно "пропускать" желаемые стадии СТ-обработки для этого, или же разделять сканы в сторонней утилите).
В ScanKromsator с не-ущемлением свободы пользователя полный порядок.

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 17:22 12-09-2010 | Исправлено: monday2000, 17:27 12-09-2010
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153

Компьютерный форум Ru.Board » Компьютеры » Программы » Scan Tailor (часть 2)

Имя:
Пароль:
Сообщение

Для вставки имени, кликните на нем.

Опции сообщенияДобавить свою подпись
Подписаться на получение ответов по e-mail
Добавить тему в личные закладки
Разрешить смайлики?
Запретить коды


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.Board
© Ru.Board 2000-2018

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru