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

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

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

Maz (10-01-2024 10:45): Scan Tailor (часть 3)  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 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 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200

   

Widok



Moderator-Следопыт
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Предыдущие части: Часть 1
Scan Tailor


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


Англоязычный топик по ScanTailor
 
Ветки:
Scan Tailor (ncraun) >>>  последняя версия
Scan Tailor Experimental (Tulon) >>>  последняя версия (обсуждение на DIY Book Scanner)
Scan Tailor Plus (Vadim "DikBSD" Kuznetsov) >>>  последняя версия (отличия от авторской версии)
Scan Tailor Еnhanced (Petr "pejuko" Kovar) >>>  последняя версия (отличия от авторской версии)
Scan Tailor Featured (monday2000) >>>  последняя версия (отличия от авторской версии)
Scan Tailor Universal (trufanov-nok) >>>  последняя версия (обсуждение на publ.lib.ru)
Scan Tailor Advanced (4lex4) >>>  последняя версия (отличия от авторской версии)
Scan Tailor Advanced (актуальный форк) >>>  история версий
 
Документация:
Документация (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 | Исправлено: Maz, 10:43 10-01-2024
derrikF



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

Цитата:
а полезная область не двигается...

работа на стадии Полезная область итак автоматом совершается... после автомата идёт ручная работа... ручная работа помогает определить ошибки работы автомата и поправить... в зависимости от качества скана, ручная работа может быть долгой или же быстрой... вчера, проект из 120 страницы вывел очень быстро потому что печать была качественной и поэтому полезная область корректно расставилась автоматом и работать не надо на этой стадии... но вот когда страницы не очень чистые, то приходится отсортировать страницы по высоте/ширине и править вручную полезные зоны из-за ошибочных захватов, или же номера страниц не будут захватываться из-за их нестандартной реализации в книге, ибо я делаю книги качественно, хотя читаю чисто я...
 
на стадии Поля другая работа - лично мне она нужна в основном для того чтобы на всех страницах по возможности сделать одинаковые поля на страницах... на этой стадии есть несколько ошибок, которые по правилам каких-то умельцев были ведены, но я иду своим путем, а не как вы выразились, "сила привычки" другого человека…
 
итак, на стадии  Поля могут быть такие проблемы:
некие умельцы предлагают все страницы ровнять по обложкам - чушь какая-то, зачем делать поля большого размера, логичнее же обложку немного обрезать, обложку раз посмотрел и все, а страниц та много, главное чтобы они были приятны постоянно для глазу... для меня глупо делать ... поэтому как вы представляли на последнем скрине, то тот пример мне будет говорить, что у меня либо размер обложки учитывается, поэтому у меня поля большие получаются, либо на стадии Полезная область ошибочные области с большим захватом либо грязи либо контент какой-нить особенный либо еще что-нить... поэтому я на стади Поля делаю сортировку и смотрю особенность контента.. например, в чем ошибочность может проявляться - часто когда много сносок, то на нескольких страницах высота страниц таких будет больше чем все остальные... поэтому я на таких страницах, которые хорошо будут показаны при сортировке по высоте/ширине, правлю вручную поля, если проблема с высотой, то я чисто оставляю поле вверху, а для остальных полей на таких страницах я значения обнуляю, тое сть, я иду на то, что поля на нескольких страницах будут слишком маленькие, зато на всех страницах будут стандартно... например я делал книгу в 550 страниц, и там как раз были 10 страниц с некорректной версткой сносок на таких страницах и у меня был выбор - или сделать чтобы все 540 страниц были с большими полями внизу страниц, а только 10 страниц с корректными поля по всем краям, либо только 10 страниц с почти отсутствием полей внизу, но зато все остальные страницы будут выглядеть стандартно, и такую проблему нельзя увидеть на стадии Полезная область, именно исключительно на стадии Поля... после правки таких страниц с чем-то нестандартным, поля сами на всех страницах будут почти одинаковые и практически работа на этой стадии закончена - остается только несколько страниц выравнить по центру вручную, несколько страниц по вверху...  
нестандартным контентом может быть также сильный перекос на страницах из-за сканирования, в таком случае иду как и описал, просто делаю на таких страницах поля меньшего размера сортирую страницы по высоте/ширине, выделяю несколько страниц, и для них применяю особые значения полей и проблема со средним значением полей будет решена...
 
для чего я привожу пример как работаю я - ваше желание, чтобы на стадии Поля показывались реальные значения полей, для меня не имеет смысла, я как раз должен сделать правки на стадии Поля чтобы подвести поля на всех страницах именно к тому значению которое я задал, я для всех книг (за исключением единиц) делаю поля 6/8... всё, я быстренько подгоняю на этой стадии к этому значению, и делаю вывод изображений, зачем мне тратить уйму времени, как вы говорите, это для меня не понятно...
 
лучше бы избавились книгоделы от манеры подгонять размер полей страниц под обложки, нежели ожидать что будут показываться реальные размеры полей, которые не должны показываться на этой стадии...
 
я уверен, что 4lex4 поэтому и не может понять что вы от него хотите, ибо не поймет что хотите вы, ибо проблем та нет здесь...
 
так что я могу только посоветовать вам пересмотреть свою работа с помощью данной проги и радоваться жизни, либо ожидайте чуда просвещения ума разраба, либо того, что он еще скажет по этому поводу...
 
это я написал не для того, чтобы сейчас была развязана полемика, а чтобы вы увидели, что проблемы, по моему мнению, нет на этой стадии в вопросе значений полей...
 
я говорю это как мнение, потому что я не разраб, поэтому отнеситесь к этому именно как к мнению, а претензии/пожелания/отчеты о багах адресуйте исключительно 4lex4

Всего записей: 235 | Зарегистр. 25-02-2007 | Отправлено: 09:10 20-02-2018 | Исправлено: derrikF, 09:11 20-02-2018
TelecomUral

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
На win7 не удалось создать проект. Не даёт файл bmp перенести в область "Files In Project". Сделал из bmp png - пожалуйста.

Всего записей: 3047 | Зарегистр. 15-07-2010 | Отправлено: 15:25 20-02-2018
4lex4

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

Цитата:
некие умельцы предлагают все страницы ровнять по обложкам - чушь какая-то, зачем делать поля большого размера, логичнее же обложку немного обрезать,

Нет, правильно будет не обрезать, а изменить масштаб обложки, не трогая при этом dpi. Это можно сделать ресемплингом или фичей выравнивания масштабированием, которая появится в СТА 1.1.0, ну или простым трюком.
Проблема ресемплига - двойная модификация изображения - одна на стадии выхода после СТ, вторая сам ресемплинг графическим редактором.
Этого можно избежать, обманув СТ, установив для обложки DPI = DPI * коэффициент, где коэффициент = физическая ширина обложки / физическая ширина страницы. Таким образом мы получим обложку равного со страницами размера, без обрезаний, и без двойной модификации растрового изображения.
 


VidelSamogO, спасибо за коллекцию плагинов, разберусь в них чуть позже.
 


TelecomUral, самый подходящий вариант для сканов - tif. Сделать поддержку bmp можно, но мне это не интересно, ибо лишняя зависимость. Делать как truf не буду, ибо у него для простого считывания dpi нужна полная загрузка изображения в память, что неправильно и медленно. Тут нужна нормальная либа, чтоб считать метаинформацию без загрузки изображения, ну или самому написать такой код по спецификации bmp, на что я свое время тратить не буду, ибо bmp не пользуюсь.

----------
ScanTailor Advanced v1.0.16 | Пожертвования

Всего записей: 346 | Зарегистр. 27-01-2016 | Отправлено: 15:35 20-02-2018 | Исправлено: 4lex4, 16:10 20-02-2018
tlotr

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Выскажусь, пожалуй, от имени молчаливого большинства, хоть никем и не уполномочен. Всё с шагами и полями нормально и интуитивно понятно. Не надо тут ничего менять.
 
derrikF

Цитата:
некие умельцы предлагают все страницы ровнять по обложкам

 
Думаю, что это предлагают  изготовители подшивок журналов, где обложка не отличается от прочих страниц по размеру, но это - вырожденный случай.
 
Есть ещё вариант, когда страница обложки имеет отличный по ширине размер от прочих страниц. Это может быть связано с тем, что скан обложки включает в себя корешок, а после этого ровнять страницы на размер обложки уже бред. Я не к тому, что делать подобные страницы обложки единственно правильно или неправильно, а к тому, что подобный подход имеет право на жизнь.  
 
При наличии же обложки книги без корешка было бы логично её отмасштабировать под прочие страницы, хотя тот же WinDjview и, кажется, Acrobat reader прекрасно сделают это сами. За линуксовые вьюверы не поручусь. Когда лет десять назад сидел в никсах, такой возможности ни у одной программы я, вроде бы,  не видел, но зуб не дам.  
 

Цитата:
я иду на то, что поля на нескольких страницах будут слишком маленькие, зато на всех страницах будут стандартно

 
Мне пришлось как-то вступить в полемику с людьми, отстаивающими идею того, что электронный вариант книги должен быть идентичен по оформлению оригинальной печатной версии. Я придерживаюсь иного мнения.

Всего записей: 85 | Зарегистр. 16-09-2009 | Отправлено: 15:42 20-02-2018
BKSRU

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
derrikF
Дважды внимательно прочитал. Но честно скажу, не все понял. Либо потому, что опыт не велик работы с этой программой, либо просто пока не привык штаны через голову одевать.
 
Хорошо по порядку попробую описать свою последовательность и как хотелось бы работать:
- Беру скан с сети. Ну в общем то сегодня не плохой попался. Довольно стандартный, не кривой.
- Резка, компенсация наклона - тут без претензий.
- Полезная область. С натягом без претензий. Хотя уже тут есть, что хотелось бы увидеть. Но это подождет. Здесь раз прогнал на автомате.  
- По поводу обложек. Обложки выравниваю, сохраняю и вывожу из проекта.
- Поля, вот тут уже больше всего претензий. Много карандашных пометок. Хорошо, ставим по возрастанию ширины и срезаем пометки, пока не остановимся на нужном размере. Так же с высотой. Вот здесь и напрашивается возможность регулировки полезной области на этой стадии, что бы не скакать с Полей на Полезную область.
Затем смотрим несколько страниц, типа титул, содержание... и подравниваем их.
Все если не страдать перфекционизмо, сойдет и так. Не беда, что края скачут.
Можно поправить, но новичку надо привыкать (зачем, хоть убейте не понимаю) к кривой навигации. Вместо 4х кнопок нас ждет 8, черт знает как работают.
Простая операция, но словно в космос ракету запускаем.
 
Нужны четыре кнопки: вверх/вниз/влево/вправо и возможность видет реальные поля. То, что мы видим сейчас в окошке Поля, вовсе не поля. Это только вводит в заблуждение. Что бы никого не вводить в заблуждение, лучше назвать - Желаемые поля. Проблему не исправит, но хоть обратят на это внимание и зададутся вопросом, а собственно зачем?
Мы можем задать реальный формат, соответсвенно должны иметь возможность видеть реальные поля и менять их с помощью четырех кнопок. Вот и все. Куда проще? Т.е. что то вроде окна Выравнивание. Только перекрестье и информационные окошки размеров полей. На самом деле здесь можно тщательно продумать и упростить навигацию.
 
И с чего вы решили, что такая информация не дает вам работать как и прежде? Она как раз показывает все проблемы. И позволяет ускорить навигацию полезной области за счет большей интуитивности и простого контроля. Хоть с помощью стрелок клавиатуры.
Здесь можно только мечтать о возможности клавиатурной (вспомогательная) навигации контента/кадра как у плееров вплоть до масштабирования.
 
P.S. Не покушаюсь на ваши привычки. Просто хотелось бы иметь более простую опциональную альтренативную навигацию.
В книгоделании считаю себя новичком, хотя и не мало их сделал используя различные инструменты. Книги с разнообразным форматированием. И это позволяет делать выводы как работа могла бы быть ускорена. Хотя стадия начального макетирования довольно важная и трудозатратная для перфекционистов. И собственно мне не ясно как такой способ можно считать идеальным? Видимо от того, что не видели альтернатив и настолько привыкли, что не представляем иные варианты.
 

Всего записей: 1558 | Зарегистр. 29-01-2009 | Отправлено: 16:23 20-02-2018 | Исправлено: BKSRU, 16:43 20-02-2018
TelecomUral

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

Цитата:
Сделать поддержку bmp можно, но мне это не интересно, ибо лишняя зависимость.

Не вопрос, я просто не знал об этом ограничении в софте. Думал что баг. Конечно, лучше всего тиффы.
Кто-то там выше просил графсхемку процесса изготовления малоцветки и т.п. Присоединяюсь. Вроде всего-то десяток кнопочек на закладке output, но правильно их нажать выходит не всегда. Неочевидно.

Всего записей: 3047 | Зарегистр. 15-07-2010 | Отправлено: 16:46 20-02-2018
derrikF



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
4lex4
разговор не про обложки, а про пример который представлен, на котором были большие поля по ширине, и я сказал по какой причине такое может быть...
 
а как кто делает обложки, это вопрос который даже не стоит поднимать...  
 
речь просто была поднята о том, что бредово реализован этап Поля, ибо не указываются реальные, хотя так и не понятны зачем такое...
 
так что самое лучшее с нашей стороны просто предлагать идеи, а разраб будет определять полезность и возможность реализации, ибо нам остает только принять будет что будет нам предложено...
 
повторюсь - если 4lex4 посчитает это полезным/возможным, то это будет, но лучше не надо сразу так говорить, что он не видит, или кто-то другой, вследствии слепоты от привычки...
 
итак, 4lex4 - я считаю инструмент удобным и полезным и претензии не имею
 
но у других свое мнение...

Всего записей: 235 | Зарегистр. 25-02-2007 | Отправлено: 17:00 20-02-2018 | Исправлено: derrikF, 17:01 20-02-2018
BKSRU

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
derrikF
Не стоит думать, что программист все видит и понимает. Это далеко не так. Он может обобщить наработки других. Конечно ему принимать решение о целесообразности тех или иных предложений. Но тот кто молчит, отсиживаясь, расчитывая, что без меня разберутся не прав. Возможно я черезчур категоричен. Но если я что то делаю, то сначала так и получается, через чур сложная система, затем срезаю все лишнее.  
Все, что нужно:
 
- Возможность двигать скан относительно формата. Задание предполагаемых полей я вовсе не исключаю при этом. Они как раз необходимы для расчета формата, исходя из наибольших размеров полезной области.
- Четыре кнопки: вверх/вниз/влево/вправо и возможность видеть реальные поля. Конечно же должна остаться возможность прижима полезных областей к краям формата из расчета заданных предполагаемых полей.

Куда уж проще.
 
Все, теперь мы можем быстро и интуитивно выравнивать скан, видя происходящее. Особенно если будет возможность менять шаг перемещения и выставлять базовые направлящие. Такая систем не зря повсеместно распространена.
Повторяю, что альтернативу можно реализовать ОПЦИОНАЛЬНО. Пусть каждый решает как ему удобно работать.
 
Надеюсь коротко и ясно пояснил для всех. И хотелось бы услышать мнемние многих заинтересованных, что именно нравится, а что нет. И почему именно? А не по принципу, не нравится, потому, что привык, так сойдет и на том спасибо... Это не обсуждение. Это именно привычки.
Что не так с предложенной концепцией? Чем она хуже существующей? Может я все таки чего то не понимаю или сам излагаю не ясно.

Всего записей: 1558 | Зарегистр. 29-01-2009 | Отправлено: 17:34 20-02-2018 | Исправлено: BKSRU, 17:53 20-02-2018
tlotr

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
BKSRU
Помимо "Нравится" или "не нравится" есть ещё и "не понимаю".  
 
Простейший пример. Вот у меня есть сканы книги. Все блоки текста там выровнены и одинаковы. В существующей концепции я задаю размеры полей, которые хотел бы видеть для левых и правых страниц, после чего отсматриваю с пристрастием страницы максимальных и минимальных размеров - скорее всего там на полях есть мусор или пометки и из-за этого страница стала больше или СТ не распознал где-то текст и порезал его как мусор.  
 
Как в вашем алгоритме у меня будет осуществляться работа если я уже задал формат? Выглядит так, что мусор на полях страниц так и останется, я о нём даже не узнаю, если не буду специально присматриваться.  

Всего записей: 85 | Зарегистр. 16-09-2009 | Отправлено: 18:07 20-02-2018
BKSRU

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

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

Видимо я как то действительно не ясно излагаю. Не посягаю на принципы поиска неточностей  и автоматику.  
 
Мы все так же задем желаемые поля и просматриваем наибольшие размеры исправляя неточности.
Только мнимые/желаемы поля вовсе не обязательны, что бы их было видно. Они только вносят путанницу. Ну если уж без них туго, то можно сделать отключаемыми.
 
Речь только об информативности и способе навигации скана относительно формата. Способы работы останутся прежними.
 

Всего записей: 1558 | Зарегистр. 29-01-2009 | Отправлено: 18:33 20-02-2018 | Исправлено: BKSRU, 18:35 20-02-2018
tlotr

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
BKSRU
Я честно пытаюсь понять.
 

Цитата:
Только мнимые/желаемы поля вовсе не обязательны

Чем же в приведённом примере будут отличаться "мнимые" поля в существующей реализации СТ от предложенных вами "реальных"?
Моя цепочка рассуждений такая (поправьте, пожалуйста, если где-то я не то понял):  
1. Ширина блока текста остаётся неизменной в обоих вариантах сиречь константа.
2. Ширина страницы, как я понимаю, в вашем случае задаётся заранее, в существующей реализации она меняется в зависимости от заданных "мнимых" полей;
3. Таким образом сами "реальные" поля будут в предложенной вами концепции варьироваться для того, чтобы компенсировать разницу между шириной распознанного блока и шириной страницы;
 
При вёрстке подобных книг я устанавливаю "мнимые" поля с краёв страниц в нужное мне значение (например, 15), а со стороны корешка - в ноль для левых и для правых страниц. Таким образом у меня поля блок выровнен и никаких неудобств я не испытываю и не вижу перерасхода в шагах и движениях мышкой.  
 
Где мне тут нужно двигать скан по формату? В чём принципиальное отличие в приведённом примере "мнимых" полей от "реальных"? Или этот пример не годится для демонстрации разницы в подходах?

Всего записей: 85 | Зарегистр. 16-09-2009 | Отправлено: 18:58 20-02-2018
alpopo



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
BKSRU
Поясню свой подход к полезным областям и полям:
1)Скажем имеем скан (картинки) книжки формата А5 на картинках А4.
Или имею стихи в книжке формата А5, которые занимают по пол страницы.
Или фото книжки А5 с полями гораздо шире формата страницы
2)В результате обработки хочу, (скажем для стихов) иметь минимальный размер страницы, чтобы и в эл.книжке что-то было видно. Да и вообще при обработке хочу лишние (неинформативные) белые поля сканов (фото) обрезать вне зависимости от исходного реального размера страницы книги(А5). Мне исходный реальный размер страницы знать вообще незачем.
3) Выделяю полезную область по нужным мне блокам текста (на хорошем скане автоматом)
4)На этапе Поля задаю отступ границы будущей страницы  от блока текста. После прогона по всем страницам на экране видим полезную область и "мнимую" по вашей терминологию границу страницы для самого большого блока текста. Делаю проверку в сортировке по максимальной ширине и высоте.
5) делаю ВЫВОД "мнимых" страниц
 
При таком подходе зачем мне знать реальный размер книжной страницы (особенно для фото-сканов) и зачем мне двигать по столу страницу?

Всего записей: 1430 | Зарегистр. 02-08-2008 | Отправлено: 21:27 20-02-2018
newquaker

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Народ, объясните будьте добры. Книга сфоткана постранично, с меняющегося расстояния. Соответственно чтобы в сабже были одинаковые поля - нужно играться с dpi, выставляя его на каждую фотку, измеряя по 6 строк на каждой - от 400 до 600 dpi, в среднем 450.
Вопрос, каким инструментом можно это выровнять автоматически?  
Я пока придумал на глаз смотреть поля на фотке, где поля меньше - складывать в одну группу, где больше- в другую, где средние в третью. Потом каждой группе назначить своё разрешение, и в тейлоре уже на каждую группу выставить dpi. Может быть есть другие варианты? Благодарю.

Всего записей: 714 | Зарегистр. 26-03-2005 | Отправлено: 01:58 21-02-2018
anagnost96

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
newquaker
 
Если книга снималась с рук (т. е. разрешение скачет непредсказуемо), то я делаю так: загружаю файлы в ST, указываю произвольное (но достаточное) разрешение, вывожу в режиме цветной/серый с обрезкой полей под ноль (и по возможности также с выравниванием строк). Полученные файлы с помощью ImageMagick (пойдет любой инструмент, допускающий пакетную обработку изображений) масштабирую под желаемую ширину текстового блока, одновременно задавая правильное разрешение. То, что получилось, снова загружаю в ST и обрабатываю уже в нормальном режиме. Специальной обработки требуют страницы с нестандартной шириной (титулы, заголовки частей), но таких обычно немного.
 
Есть иная ситуация, когда книга снимается со штатива, и при этом является достаточно толстой, чтобы по мере перелистывания существенно изменилось расстояние от объектива, а вместе с ним и разрешение. Тогда делаю так: замеряю разрешение для первой и последней страницы (разница может быть порядка 30dpi), а потом запускаю скрипт, который для всех остальных страниц выставляет разрешение путем интерполяции между двумя крайними значениями.

Всего записей: 132 | Зарегистр. 01-05-2009 | Отправлено: 02:22 21-02-2018
BKSRU

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

Цитата:
Моя цепочка рассуждений такая (поправьте, пожалуйста, если где-то я не то понял):  
1. Ширина блока текста остаётся неизменной в обоих вариантах сиречь константа.

В общем да, если ее можно назвать неизменной. Ширина все таки варьирует даже для книг с простым форматированием: точность определения границ; перекосы блоков, которые фактически не реально поправить; опять же выступающий хвостик f..., да и у левой границы бывают выступающие хвостики. От сюда и бессмыслица с мнимыми полями. Они становятся не реальными. Фактически из 500 страниц, только две страницы с реальными размерами. У одной высота, у другой ширина. Реально может быть и больше совпадений , но это не меняет положение дел.
По этой причине точно регулировать положение полезных областей довольно нудно. Только приблизительно. Кого то это устроит, кого то нет. Но можно кое, что сделать в этом плане по моему мнению. Для этого стоит продумать совместно более удобную и интуитивную концепцию начального макетирования страниц. Начальным макетированием называю расположение полезной области относительно формата.
 

Цитата:
2. Ширина страницы, как я понимаю, в вашем случае задаётся заранее, в существующей реализации она меняется в зависимости от заданных "мнимых" полей;

Да в общем то так же ширина меняется в зависимости от заданных желаемых полей. Можно и в ручную. Все как сейчас.
 

Цитата:
3. Таким образом сами "реальные" поля будут в предложенной вами концепции варьироваться для того, чтобы компенсировать разницу между шириной распознанного блока и шириной страницы;

Они будут варьироваться точно так же как и при нынешней реализации, но информацию выводить лучше о них. Сами же желаемые поля лучше сделать отключаемыми, кому это понадобится. Мне лично они не нужны, только путают. При новой концепции итак будет ясно где они совпадают, а где нет. И таким образом, что бы выравнивать полезную область относительно формата (который выставлен либо автоматом в зависисмости от заданных желаемых полей, либо в ручную) достаточно всего четыре кнопки, регулирующих поля сверх/сизу/слева/справа. И это более просто и понятно сразу даже для новичков. Это так же как управлять кадром в плеере. Да собственно куда ни кинь всюду эти простые принцыпы. И не спроста. Зачем здесь усложнять ситуацию.
 

Всего записей: 1558 | Зарегистр. 29-01-2009 | Отправлено: 05:03 21-02-2018
4lex4

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

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

Да, надо переписывать инструкцию и готовить примеры, плюс писать скрипты для image magick и новые экшены для шопа, чтоб пользоваться новой фишкой оригинальный фон для изготовления djvu с комплексным цветным фоном, но мне щас влом, ближайшее время потрачу на подготовку версии 1.1.0.
Пользуйтесь пока что подсказками интерфейса (секунду подержать мышь над элементом) и разбирайтесь методом тыка, ну или кидайте проблемные картинки на форум.
 


derrikF, нужно потестить develop ветку. Особое внимание обратить на сортировку. По идее все должно быть стабильным и без багов.

----------
ScanTailor Advanced v1.0.16 | Пожертвования

Всего записей: 346 | Зарегистр. 27-01-2016 | Отправлено: 17:44 21-02-2018 | Исправлено: 4lex4, 17:55 21-02-2018
TelecomUral

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
4lex4
Я в общем-то не соображу только, на какой слой работают сегментатор и постеризатор. Передний или задний. Внутреннюю логику взаимосвязи блоков не вижу. Понимаю, что зоны пилят скан на два слоя. Но к какому куску галочки пристёгивают постеризатор, и откуда возникает нужда в оригинальном bg - загадка. Выкопировал себе всё, что вы про это написали - неувязочки получаются. Должны по логике работать на передний - чтобы оставить в нём малоцветку рядом с чб шрифтом. Но оригинальный фон-то тогда лишняя фича. А если постеризатор пристёгивается к фону - то на этом листе фона нельзя будет получить обычную фотку. Если ориг-фон нужен чтобы закрыть эту неувязку, то как потом делать совмещение малоцветки в заднике и чб шрифта передника.
Влом сейчас всем, весна скоро.

Всего записей: 3047 | Зарегистр. 15-07-2010 | Отправлено: 20:16 21-02-2018
4lex4

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
TelecomUral, я знаю, что я делаю, там все логично и нет ничего лишнего.
 
Естественно сегментер и постеризатор работают для переднего фона и не трогают картинки.
Постеризатор, как отдельный независимый компонент, может быть применен к полноцветному изображению для различных целей, но только в цветном режиме. Это для тех, кто пилит пдфники, ибо за рубежом djvu намного меньше пользуются. В смешанном режиме постеризатор всегда работает на передник и только в комбинации с цветовым сегментером.
 
Фишка оригинальный фон не для этого. Допустим есть страница с цветным фоном, цветным текстом и картинками. Фишка оригинальный фон позволяет разделить изображение на 3 слоя, а не на 2: картинки, передник и этот фон. К фону нужно применять фильтры вроде поверхностного блюра, которые не могут быть применены к картинкам, а также, обязательный шаг, избавится от дырок, оставшихся от передника - это важно для уменьшения размера background слоя в djvu, ибо вейвлетовые алгоритмы сжатия лучше всего работают с градиентными изображениями, а эти дырки являются высокочастотным компонентом. Затем с помощью пакетного комбинирования изображений объединяем обратно фон и картинки, скрипт для этого и надо написать. А потом кодируем передник-малоцвет и скомбинированный фон+картинки в djvu.
Вообщем, тут просто нужен пример.
 
Второе, это фичей можно вытащить контуры (пример с гиперболоидом), причем правильно, а не как вы это делали. Вы получили огромное увеличение размера djvu после того, как вытащили черные линии из гиперболоида из-за непонимания, как работает сжатие в djvu.  
Фишка оригинальный фон резервирует оригинальный белый, а белым являются только вырезанные компоненты с передника, поэтому мы можем в граф. редакторе применить выделение по белому и убрать эти дырки и мусорные соседние пиксели, получатся чистые линии в результате, причем с помощью цветого сегментера можно сохранить их цвет.  
 
Пример на вашем гиперболоиде ниже.

Всего записей: 346 | Зарегистр. 27-01-2016 | Отправлено: 21:08 21-02-2018 | Исправлено: 4lex4, 01:28 22-02-2018
derrikF



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

Цитата:
нужно потестить develop ветку.

ок...
 
сейчас обрабатывал новый проект (но в master версии, так получилось, поздно зашел на форум, так бы тестил новую develop, но кое-что потестю), возникли некоторые вопросы
 
1. в проекте 417 страниц, разрезанные по полам... на стадии Полезная область только на 4 страницах показыватюся звездочки - на двух обложках и на двух пустых страницах, на остальных нет звездочек... вопрос из проекта к проекту - зачем эта функция? как она работает? оно при чем здесь пустые страницы? или так легче определить ошибочный автоматический сильный наклон, что иногда бывает? отклонение на стадии Компенсанция наклона почти понятна, но не совсем - политика не ясна, ибо страница с наклоном 0,50° или -0,69° помечана звездочкой а со значением -0,62° или -0,50° нет... как идёт подсчет, для чего - словно как в джунглях... может кто-нить объяснит по доходчевее?
 
2. обратил внимание на последних проектах, что полезная область по всем краям стала всегда отступать на определенный запас... на англ форуме вам кто-то в скрине показывал что обрезаются края букв... поэтому теперь будет отступать с запасом границы полезной области от крайних букв? теоретически, это хорошо, просто надо знать, тогда придется немного свои правила обработки немного изменить...
--------------------------------------------------------
 
проверил новый develop - сортировка в проекте с разным dpi работает, сортируется правильно... вывожу остаток страниц в новом проекте, вроде бы с dpi проблем нет в выходных файлах, вылетов нет, но это страницы просто с текстом без картинок...  
 
Добавлено:
новый elf стал меньше на 40 кб... это нормально? обычно всегда больше становился...

Всего записей: 235 | Зарегистр. 25-02-2007 | Отправлено: 21:53 21-02-2018
4lex4

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
TelecomUral, пример использования фичи на вашем гиперболоиде:
 
Без извлечения контуров (114.6 KB)
С извлечением контуров (58.3 KB)
 
В примерах, которые вы мне присылали, без извлечения контуров было 144 KB, и с извлечением контуров 184 KB, то есть все наоборот, получился прирост размера вместо сжатия. Вы извлекли контуры неправильно.
 
А вы говорите оригинальный фон ненужная фича. Это вариант использования этой фичи в комбинации с цветовым сегментером для извлечения контуров. Основное же ее назначение я уже описал - сканы с цветным сложным фоном (4й пример (г) в инструкции).
 
Вот папка со слоями, чтоб разобраться.
Кому интересно, исходник в инструкции, пример в)
 
(желтый и розовый прямоугольнички фона дорисовывать не стал, ибо это незначимо, вы сами это можете сделать в фотошопе, они дадут прирост 1-2кб максимум. Синий вверху сам сегментировался цветовым сегментером в СТА, поэтому оставил его. Если его переделать в шопе под ручной идеально ровный, djvu будет весить еще меньше).
 
Что как делал по шагам объясню в инструкции, когда ее перепишу, щас на писанину нет времени и настроения.

PS: Обновил экшены для шопа.

 



derrikF, спасибо за тест, https://en.wikipedia.org/wiki/Standard_deviation
 
Для 2й стадии я просто неправильно подобрал порог, звездочки стали слишком чувствительны.
Основное назначениие для 2й стадии - помечать очень подозрительные страницы, значения угла поворота у которых очень сильно различается от других страниц. (обычно это обозначает сбой авто-компенсации поворота на таких страницах).  
Поправлю.
Для остальных стадий тоже самое. На 4й стадии авто-алгоритм может захватить мусор, и размер полезной области увеличится по сравнению с другими страницами, или наобот, что-то пропустить - такие страницы должны помечаться звездочкой.
Вообще мне нужно откалибровать эту штуку, сделаю это завтра для всех стадий.
 

Цитата:
новый elf стал меньше на 40 кб... это нормально? обычно всегда больше становился...
 

Не могу ничего сказать. Если все работает - значит нормально.

----------
ScanTailor Advanced v1.0.16 | Пожертвования

Всего записей: 346 | Зарегистр. 27-01-2016 | Отправлено: 22:40 21-02-2018 | Исправлено: 4lex4, 06:06 22-02-2018
   

Страницы: 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 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200

Компьютерный форум Ru.Board » Компьютеры » Программы » Закладки » Scan Tailor (часть 2)
Maz (10-01-2024 10:45): Scan Tailor (часть 3)


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

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru