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

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

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

gyra (14-11-2018 10:38): ScanKromsator / СканКромсатор (Часть 4)  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 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

   

Widok



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

Знаменитый Кромсатор для обрезки получаемых при сканировании изображений, а также для разделения страниц, очистки от мусора и т.п.  
Автор: bolega. http://bolega.hotmail.ru/.  
ScanKromsator в Википедии: http://ru.wikipedia.org/wiki/ScanKromsator
 
Аналог ScanKromsator - Scan Tailor
 
Начало обсуждения - 1 часть, 2 часть.
 
Текущая версия: ScanKromsator v6.00.5 (2,1 МБ) Настройка внешних утилит  
Предыдущая версия: 5.96.2  (файл sk.exe), утилиты к ней можно взять из v5.96.1  
 
Старые версии: Подробнее...
 

Новое в 6-й версии
Изменения в версии (5.92) + описание нового порядка обработки (с "финализацией" файлов)
Учебный пример от bolega по использованию зон


Подборка ответов bolega про работу ScanKromsator (версия 1.0.1 с закладками и сносками), 2016 г.
 
Хрестоматия материалов про СК , 2017 г.
(25 Mb, для открытия файла chm может потребоваться его разблокировать в свойствах файла, кликнув ПКМ)  
Включает, в том числе:
Видеоуроки про ScanKromsator Подробнее...
 
Обработка пикчур-зон от TelecomUral Подробнее...
 
English texts Подробнее...
 
Что делать, если ScanKromsator не делает то, что хотелось бы... И ещё bolega о том же самом...

Всего записей: 24190 | Зарегистр. 07-04-2002 | Отправлено: 18:07 30-03-2009 | Исправлено: Maz, 09:43 22-08-2018
NME



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
bolega
monday2000
а почему бы не объединять FGbz и FG44 на одной странице?.. тогда и размеры будут приемлемые, и полчанка при необходимости закрасить можно.. конечно, код немного усложнится в плане проверки на полную\частичную заливку чанка, но если FG44 действительно дает существенное преимущество в размерах файла, то может быть стоит попробывать?..

Всего записей: 1436 | Зарегистр. 26-07-2007 | Отправлено: 21:21 07-12-2010
bolega

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

Цитата:
а почему бы не объединять FGbz и FG44 на одной странице?..  

К сожалению, djvumake не позволяет это. Допускается либо одно, либо другое. Передок может быть только один.
Переделывать djulibre конечно интересное и поучительное занятие, но не для меня. Это все таки не мой профиль. Я хотел лишь приладить то, что уже есть, а не залезать в дебри djvu-кодирования, хотя это конечно и полезно.
Поэтому выход пока один: если раскрашенные зоны не пересекаются (между собой и с текстом), и имеют прямоугольную форму, то использовать FGbz (такой случай предусмотрен в последней версии djvumake), если нет - то использовать либо FG44, либо делать как делалось всегда ранее - трактовать раскрашенные зоны как обычные цветные зоны. И кодировать их либо стандартным методом (через профиль DEE), либо через метод подклейки фона.
Радует одно: даже если FG44 и больше FGbz на порядок в относительном сравнении, но в абсолютном исчислении - это несколько килобайт на страницу - это немного (по сравнению с обычными цветными зонами, которые дают десятки а то и сотни кб в BG44, в зависимости от выбранных параметров сжатия djvu).
В любом случае кодировать раскраш.зоны в FG44 выгоднее чем трактовать их как обычные цв.зоны и помещать их в BG44. Это особенно актуально если на странице одновременно имеются как иллюстрации так и раскраш.зоны. Выгода в том, что иллюстрации можно кодировать с качеством, независимым от качества кодирования раскраш.зон (там ведь обычно текст и для него качество должно быть выше чем у обычных картинок). Т.е. можно по вкусу деградировать качество иллюстраций до приемлимого, оставляя при этом высоким качество цветного текста. Благодаря тому, что физически они хранятся в разных слоях-чанках.
Кстати, при создании pdf СК также обрабатывает раскрашенные зоны особым способом: в pdf есть для этого возможности, т.е. заносит их в pdf как ч/б и вводит команду красить их при показе. Поэтому там таких проблем не возникает.

Всего записей: 4431 | Зарегистр. 09-09-2002 | Отправлено: 00:19 08-12-2010 | Исправлено: bolega, 01:39 08-12-2010
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
bolega
Напоминаю Вам ещё раз, что без автоматического распознавания зон иллюстраций вся Ваша затея не будет иметь ровно никакого смысла - поскольку СТ окажется заведомо ГОРАЗДО удобней (за счёт авто-распознавания зон).
 
Сделать поддержку авто-распознаваемых зон в СК, наверное, не так уж нереально. Тут Вам помогут и U235, и Arcand (который сделал Corel-плагин из этого алгоритма) и может даже и сам Tulon.
 
Кроме того, в отсутствие хелпа к СК и ввиду наличия разнообразных глюков в СК Ваше решение вряд ли будет пользоваться большой популярностью.
 
Хотя Ваше решение будет представлять из себя чисто академический интерес как экспериментальный пример комбайна "всё-в-одном".
 
Я сам думаю, что по-хорошему такие комбайны плохи. ИМХО задача сканобрабатывающего софта - создать из сырых сканов так сказать "оригинал-макет" будущей DjVu-книги - т.е. каждый скан облагородить и при необходимости разбить на слои (до 3 слоёв на каждый скан). Для этого в DjVuLibre существует даже специальный sep-формат - он описан тут http://djvu.sourceforge.net/doc/man/csepdjvu.html в разделе SEPARATED DATA FILE FORMAT. Такой sep-формат может быть продукцией скан-обрабатывающей программы и одновременно входным материалом для DjVu-кодировщика.
 
Такая схема даёт ИМХО наибольшую гибкость и универсальность. Sep-формат может в будущем выступить своего рода "унифицированным интерфейсом" между классом сканобрабатывающих программ и классом DjVu-кодировщиков. И тогда любой новый производитель (появись он в будущем) будет знать, что он должен либо создать SEP на выходе, либо уметь принять SEP на входе.  
 
Как говорится, "если бы SEP не было, то его нужно было бы придумать". А тут даже и придумывать не надо - создатели DjVuLibre это уже сделали за нас.
 
Можно даже представить себе программу - "sep-вьювер" или "sep-редактор" - такая тоже может понадобиться.
 
Вместо SEP можно использовать и пАры субсканов - правда, пока непонятно, как там обозначить передний план (цветность текста).

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 22:42 08-12-2010
woodyfon

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
monday2000
Знаете сколько bolega сообщений о том, чтобы в SK повилась возможность автоматически определять зоны текста и картинок, что ему как классическая музыка глухому. Я читал некоторые статьи про автосегменитрование изображения в FR в которых говорилось, что были защищены несколько диссертаций. Поэтому сегментирование - это не такая уж легкая задача. Одному человеку ее не решить - надо объединятся

Всего записей: 417 | Зарегистр. 03-08-2007 | Отправлено: 23:01 08-12-2010
bolega

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

Цитата:
Тут Вам помогут и  

За все время существования СК еще никто мне не помогал алгоритмами (не путать с советами и идеями), так что надежда только на себя. Было только одно исключение - когда U235 поделился одним алгоритмом удаления фона, который вошел в СК под именем Safe.
 

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

А я никому и никогда СК не навязывал и не навязываю.
Во-вторых, МПФ и РТ - это ваши придумки, а не мои.
 

Цитата:
Такая схема даёт ИМХО наибольшую гибкость и универсальность. Sep-формат может в будущем выступить своего рода "унифицированным интерфейсом" между классом сканобрабатывающих программ и классом DjVu-кодировщиков

Тут вам виднее. Я с этим глубоко не разбирался. Был бы в djvulibre нормальный интерфейс в виде dll тогда другое дело.
 
 
Добавлено:
Почитал я про cpaldjvu.
 

Цитата:
Sep-формат может в будущем выступить своего рода "унифицированным интерфейсом"

Никакой универсальностью тут и не пахнет. Во-первых, рассчитана на малоцветные сканы (т.к. использует палитру). Во-вторых, сам кодирует текст. А использовать djvulibre для кодирования ч/б текста - это самый неоптимальный вариант, т.к. результат получится заведомо хуже и больше, чем например, в DEE. В-третьих, МПФ делает по сути то же самое, что и cpaldjvu. Только у МПФ одно преимущество - он может использовать результат DEE.
 
Вообще, когда начинаешь пытаться глубоко применять djvulibre, появляется горькое ощущение, что в нем постоянно чего-то не хватает. То того не предусмотрели, то другого. Одна утилита может принимать параметры из тектового файла, другая почему-то нет и т.п. и т.д. Ввели в djvumake возможность раскраски, но выбор наибеднейший: только прямоугольники и только с черной маской (а если я фон хочу раскрасить?), ввод координат зон только из командной строки (это вообще глупость, а если их десятки и сотни?), ввели параметр FGbz, пишут, дайте ему файл с raw-данными, и ни слова как его получить. Некоторые опции вообще не работают. Возьмите из доки к djvused.html приведенный там пример:
djvused myfile.djvu -e 'select 3; size'
и запустите изменив имя файла на свой. Ничего не произойдет, кроме ругани на неправильный синтаксис (похоже, что -e вообще не работает, но работает -f).
И авторы б-ки похоже не очень любят что-то развивать и добавлять, того, что требует жизнь. Это странно, учитывая, что авторы - мэтры и основатели djvu. Напоминает мне одного хорошего, но глухого к реальным потребностям программиста

Всего записей: 4431 | Зарегистр. 09-09-2002 | Отправлено: 08:37 09-12-2010 | Исправлено: bolega, 09:36 09-12-2010
monday2000

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

Цитата:
Никакой универсальностью тут и не пахнет. Во-первых, рассчитана на малоцветные сканы (т.к. использует палитру).

К сожалению, да, недоглядел я - не универсален. Кстати, по спецификации DjVu, FGbz-чанк может содержать палетку до 65535 цветов (пункт "8.3.10 Foreground Color JB2 Chunk: FGbz").
 
   
 
А FG44, насколько я понимаю, не ограничен в количестве цветов (пункт "10.1 Definitions"):

Цитата:
Compound DJVU Images and Photo DJVU Images contain color or grayscale image data. Color IW44 Images contain color image data. Grayscale IW44 Images contain grayscale image data. Color image data is coded using three color components, called Y, Cb, and Cr. These correspond to the usual YCbCr color space, adjusted to facilitate transformation to the RGB


Цитата:
Вообще, когда начинаешь пытаться глубоко применять djvulibre, появляется горькое ощущение, что в нем постоянно чего-то не хватает. То того не предусмотрели, то другого.

Наверное, потому, что её делали учёные, а не практики.

Цитата:
(а если я фон хочу раскрасить?)

Пожалуйста, добавляйте на вход djvumake также и чанк BG44, и всё.

Цитата:
Это странно, учитывая, что авторы - мэтры и основатели djvu.

DjVuLibre ещё и загаживалась Лизардтеком в своё время - по словам Леона. Вообще это ИМХО тёмная история, почему DjVuLibre так неудобен.

Цитата:
Был бы в djvulibre нормальный интерфейс в виде dll тогда другое дело.

Хорошая идея. Но некому это сделать - слишком непросто. Там, впрочем, есть низкоуровневый API, описанный в файле ddjvuapi.h : http://www.djvu-soft.narod.ru/ddjvuapi.htm . И даже DLL уже тоже вроде бы есть - libdjvulibre.dll . Правда, в довесок к ней идёт куча другого малопонятного хлама - другие dll, manifest, и эта dll даёт доступ только к низкоуровневому API - что ИМХО неинтересно. Высокоуровневого API нет, насколько я знаю. Заиметь его было бы здорово, но тяжко.
 
И ещё мне не нравится, что там присутствуют libjpeg.dll, libtiff.dll, libz.dll - для поддержки обычных растровых форматов. Я бы под Windows прикрутил FreeImage вместо всего этого - куда как проще. Но Леон Боту - линуксоид, Windows даже не имеет, так что ему FreeImage был бы наоборот труднее.

Цитата:
Ничего не произойдет, кроме ругани на неправильный синтаксис  

А, ну это глюк. Замените апострофы двойными кавычками, и всё заработает. Наверное, это под Линуксом не важно.
 
Добавлено:

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

Нет, не "только с черной маской". Каждый прямоугольник может иметь любой цвет, а также, если я не ошибаюсь, можно "рисовать" два раза по одному месту (в смысле, раскрашивать текст) - имитируя тем самым зоны более сложной формы. Отрисовка идёт в порядке разбора командной строки слева направо. Т.е. можно, например, закрасить текст на пол-скана синим цветом - а потом небольшой кусочек уже синего цвета перекрасить, скажем, в красный текст - и т.д. Для этого нужно в командной строке левее указать синий прямоугольник, а правее - красный.
 
Добавлено:
bolega
Вообще-то я считаю, что для слоя переднего плана 65 тыс. цветов (как в FGbz) - вполне достаточно. Ведь это цвета не пикселей, а блитов. А, как правило, на одну страницу редко бывает более 10 тыс. блитов. Так что, если на одной странице менее 65 тыс. блитов (а в жизни так оно и будет), то тогда каждому блиту можно назначить свой индивидуальный произвольный RGB-цвет.
 
Остаётся единственный минус FGbz перед FG44 - невозможность раскраски одного блита более чем одним цветом. ИМХО этим вполне можно пренебречь. Ведь это актуально только для псевдографики, а не для букв текста.
 
А в будущем, я думаю, что в перспективе возможен даже и такой фантастический ныне вариант - разбивать один блит на нужное количество блитов - не трогая соседние. Свойства формата DjVu это не запрещают вроде бы (надо подумать, конечно, так ли это).
 
Так что я бы на Вашем месте вариант с FG44 вообще бы не реализовывал - а только с FGbz. Разве что как исключительно редко нужную фичу.

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

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

Цитата:
Пожалуйста, добавляйте на вход djvumake также и чанк BG44, и всё

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

Цитата:
А, ну это глюк. Замените апострофы двойными кавычками, и всё заработает.  

В том то и дело, что в доке это как раз не рекомендуется. Двойные кавычки ведь приходится использовать для имен файлов (там ведь могут быть пробелы в имени и без кавычек не обойтесь). А ключ -e предусматривает для некоторых последующих команд имя файла. Так что здесь действительно могут случиться неприятности, если использовать одинарные кавычки. Что говорит о том, что выбранная грамматика командной строки противоречива и неоднозначна.
 

Цитата:
Нет, не "только с черной маской".  

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

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

Это действительно есть. Я даже исходник посмотрел. Но если проанализировать хорошенько, то все это чепуха. Хотя бы потому, что для этого прямоугольники нужно описывать в строго определенной последовательности, которую может составить только человек. Представьте еще такую комбинацию: два равнобедренных трегольника, оба наклонены на 45 градусов и смотрят друг на друга (или: взять квадрат, разрезать по диагонали и чуть сдвинуть одну половинку вверх). С помощью синтаксиса djvumake вы не сможете теперь раскрасить их в разные цвета, оба блита всегда будут принимать последний заданный цвет. Это потому, что блиты хоть и не соприкасаются, но их габариты пересекаются. Теоретически это можно обойти, но в общем случае (когда в задаваемом цветном прямоугольнике много блитов) это очень сложная задача. В приведенном мною примере это сделать просто: в качестве прямоугольников задавать не габариты треугольников, а небольшие участки внутри них.  
 
Добавлено:

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

 
Да, это решило бы проблему на 100%.  
 

Цитата:
Так что я бы на Вашем месте вариант с FG44 вообще бы не реализовывал - а только с FGbz. Разве что как исключительно редко нужную фичу

Да я разве против. Но если это не даст (даже иногда) юзеру того, что он хочет, точне, иногда может дать не то, что он хочет, то как же можно использовать. Из принципа что-ли? Пусть будет непредсказуемо, но зато идейно правильно???
 
 
 
Добавлено:

Цитата:
Вообще-то я считаю, что для слоя переднего плана 65 тыс. цветов (как в FGbz) - вполне достаточно. Ведь это цвета не пикселей, а блитов. А, как правило, на одну страницу редко бывает более 10 тыс. блитов. Так что, если на одной странице менее 65 тыс. блитов (а в жизни так оно и будет), то тогда каждому блиту можно назначить свой индивидуальный произвольный RGB-цвет.  

А теперь представьте какой-нибудь фотоальбом, где для каждой страницы вполне может задействоваться все 65 тыс.цветов. И посчитайте размер палитры (для каждой страницы!) - около 200кб. И это только палитра! Уж лучше BG44 использовать.

Всего записей: 4431 | Зарегистр. 09-09-2002 | Отправлено: 15:19 09-12-2010
AndroS



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Доброго времени суток...
Столкнулся с проблемой - после обработки кростатором получаются пустые/белые страницы (Не все, но порядочно, штук 50 по-моему). Настройки выставлены типовые - как в Scan & Share написано. Резаки выставлены правильно.
С чем это может быть связано?

Всего записей: 2423 | Зарегистр. 20-05-2004 | Отправлено: 08:53 10-12-2010
bolega

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
AndroS
Скорее всего неправильно выставлены резаки. Например, скан - одиночная страница, а резаки включены все, как будто это разворот

Всего записей: 4431 | Зарегистр. 09-09-2002 | Отправлено: 09:03 10-12-2010
AndroS



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
bolega
Я как раз и написал, что резаки проверил в первую очередь. Скан - разворот.
Пользую СК 5,93 из шапки. Прилагаю файл проекта, исходники и результат: http://www.onlinedisk.ru/file/569180/ (12 Мб)
Поясните, пож-ста, чего не так у меня...

Всего записей: 2423 | Зарегистр. 20-05-2004 | Отправлено: 10:02 10-12-2010
bolega

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
AndroS
Спасибо за задание.
Прогнал его, все получилось нормально.
Возможно, у Вас какая-то старая версия СК.
Но есть одно важное замечание: у Вас включена опция merge pages (кстати, никогда не понимал, зачем люди делают по две страницы на листе, для этого ведь в любом просмотрщике, djvu или pdf, есть соответсвующая опция). Эта опция в последних версиях СК больше не поддерживается! Вместо нее следует использовать аналогичную (почти) опцию Merged page (на закладке Page->Special->More). Только нужно помнить, что в отличие от старой опции, опция Merged page page-ориентированная, т.е. может применяться к произвольным разворотам.
 

Всего записей: 4431 | Зарегистр. 09-09-2002 | Отправлено: 11:20 10-12-2010
AndroS



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
bolega
А можно ссылку на Вашу версию? Всё одно такая же ерунда.
Как уже говорил - моя версия - 5.93 из шапки темы

Всего записей: 2423 | Зарегистр. 20-05-2004 | Отправлено: 12:24 10-12-2010 | Исправлено: AndroS, 12:26 10-12-2010
shch_vg

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

Цитата:
Возможно, у Вас какая-то старая версия СК.

У меня в 5.93 (вроде последняя опубликованная версия) получились пустыми 5, 6, 8 и 9 развороты. В конце же работы еще зачем-то был задан попрос о возможности перезаписи уже имеющегося 1-го разворота. После подтверждения он был, по-видимому, перезаписан, но не изменился.
Что касается просмотра в двухстраничном режиме, то это отдельная песня .
В WinDjView для нормального (как в самой книге) просмотра необходимо, чтобы структура книги была фиксированной, а именно, начальная обложка - одна штука, перед титульным листом ОБЯЗАТЕЛЬНО наличие пустой страницы.
Зато в Foxit Reader все наоборот: наличие пустой строки перед титульным листом недопустимо, зато на первой экране - обложка и титутульнй лист.
Единственное, в чем я могу с Вами согласиться, что читать разворот с двумя страницами менее комфортно, чем отдельно каждую страницу, поэтому я тоже не вижу большого смысла делать двухстраничные сканы.
КРОМЕ одного варианта.
Сейчас я делаю журналы "Шахматы" (Рига), разворот у которых равен А4. Кроме того для ускорения работы, а также для получения визуального представления о нем (нынешние молодые вполне могли его не видеть) я сразу сканы разворотов без обработки (или практически без обработки) в СК компилирую в djvu.
Вот как раз здесь я использую опцию merge pages. Дело в том, что, как правило, 2-ю и 3-ю страницы обложки я сканирую в цвете в 150dpi, а весь текст внутри журнала в сером в 300dpi, поэтому с помощью этой опции объединяю 2-ю стр. обложки с первой страницей текста, а последнюю страницу текста с 3-й стр. обложки.
 
Добавлено:
AndroS
Об этом давно мечтают все пользователи СК .

Всего записей: 6970 | Зарегистр. 14-01-2005 | Отправлено: 12:36 10-12-2010 | Исправлено: shch_vg, 13:16 10-12-2010
AndroS



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

Цитата:
У меня в 5.93 (вроде последняя опубликованная версия) получились пустыми 5, 6, 8 и 9 развороты.

Именно так всё и происходит. Дальше есть страницы, на которых одна страница с текстом, а одна - пустая. Если бы случай был единичный, я бы руками поправил, но их существенное количество.
 
ЗЫ про добавлено: Дом. страничка ув. автора ничего не показывает...

Всего записей: 2423 | Зарегистр. 20-05-2004 | Отправлено: 12:49 10-12-2010
shch_vg

Gold Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
AndroS
Грабли в этой версии СК в опции Illumination. После ее отключения все работает, но фон, конечно, остается.
 
P.S. Версия 5.92 вообще не дружит с Illumination и заканчивает работу аварийно.
 
Добавлено:
Проверка показала, что дело не в опции Illumination, а в ее подопции Smart.
При Normal все работает, но устраивает ли Вас такой результат...

Всего записей: 6970 | Зарегистр. 14-01-2005 | Отправлено: 13:33 10-12-2010
AndroS



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
shch_vg
Понял, спасибо, буду с другими значениями Illumination баловаться...

Всего записей: 2423 | Зарегистр. 20-05-2004 | Отправлено: 13:46 10-12-2010
monday2000

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

Цитата:
Чтобы поняли о чем речь, представьте такой случай: красный текст на желтом фоне.

Так а в чём проблема? Жёлтый фон делается при помощи слоя заднего фона BG44. Единственная проблема - что слой заднего фона в DjVu может быть только один, что создаёт некоторые неудобства при создании DjVu "вручную по кусочкам".

Цитата:
Если бы djvumake умел для таких областей (для которых нет маски) сам создавать доп.блит (не сливая его с существующим, т.е. блитами текста!), то проблема была бы решена.

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

Цитата:
Что говорит о том, что выбранная грамматика командной строки противоречива и неоднозначна.

Скорее всего, это просто глюк. Попробую как-нибудь написать письмо Леону Боту на эту тему.

Цитата:
Если мне нужно раскрасить какой-то белый участок, то красить-то будет нечего - блита (маски, stencil) для него нет.

Как это нечего?! Красьте сам задний фон - т.е. нужные его участки (скажем, прямоугольные).

Цитата:
Но если проанализировать хорошенько, то все это чепуха.

Я совершенно согласен с этим утверждением. Просто никто не хотел вкладывать слишком много своего времени на совершенствование этого синтаксиса (выборочной раскраски маски) - отсюда и такой глупый вариант (этого синтаксиса).

Цитата:
А теперь представьте какой-нибудь фотоальбом, где для каждой страницы вполне может задействоваться все 65 тыс.цветов. И посчитайте размер палитры (для каждой страницы!) - около 200кб.

ИМХО это исключительно маловероятно. Это должно быть что-то вроде "рассыпанного содержимого калейдоскопа" - причём все эти объекты должны быть чёткоконтурные, чтобы претендовать на попадание в маску. Обычно такие вещи отправляются прямиком в задний фон - где им самое место. Можно же задать 100% качество заднего фона - будет очень даже прилично.
 
Это надо взять обычную страницу, каждую букву разбить на 6 частей (с белым промежутком между частями), да ещё и раскрасить каждый околок буквы в индивидуальный цвет. Или нечто вроде крупного цветного дизеринга. В любом случае, такие вещи вообще не попадут в маску (т.е. тогда уж говорить о том, чем лучше раскрасить маску - через FGbz или FG44, вообще не придётся), а уйдут в задний фон.

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

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

Цитата:
Проверка показала, что дело не в опции Illumination, а в ее подопции Smart

Я сразу заметил, что Smart портит именно эти страницы, но все-равно кое-что от текста остается, а в выложенном задании вообще все чисто.  
Кстати, а чем вызвано то, что в задании отсутствует бинаризация?
 
monday2000

Цитата:
Скорее всего, это просто глюк. Попробую как-нибудь написать письмо Леону Боту на эту тему

И еще напишите, что если в командной строке путь к djvu файлу содержит кириллицу, то утилиты не видят файл.
И заодно попросите хотя бы, чтобы координаты зон раскраски брались бы из текстового файла, а не из командной строки. Наверное, не найдется ни одного чудака, который бы вручную использовал бы эту возможность. Т.е. фича явно ориентирована на внешнюю программу, которая будет формировать командную строку, а ей удобнее сохранять этот массив зон в файл, чем формировать длинющую строку (кстати, ее предельно допустимый размер под windows не резиновый, особенно в win2000)

Всего записей: 4431 | Зарегистр. 09-09-2002 | Отправлено: 16:09 10-12-2010
shch_vg

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

Цитата:
Кстати, а чем вызвано то, что в задании отсутствует бинаризация?

Хотя этот вопрос и не ко мне, попробую отгадать ответ на него.С чем-то подобным я встречался при переводе журнала в бинарный вид. Залитые черным области тогда получались излишне ярко-черными, поэтому я при обработке старался заключить такие области в серую picture-зону, получая более мягкий для глаза вид этой области.

Всего записей: 6970 | Зарегистр. 14-01-2005 | Отправлено: 16:31 10-12-2010
NME



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

Цитата:
В WinDjView для нормального (как в самой книге) просмотра необходимо, чтобы структура книги была фиксированной, а именно, начальная обложка - одна штука, перед титульным листом ОБЯЗАТЕЛЬНО наличие пустой страницы.

вид -> расположение -> первая страница отдельно
 
bolega

Цитата:
если в командной строке путь к djvu файлу содержит кириллицу, то утилиты не видят файл.

могу сказать про djvused (т.к. пришлось погеморроиться с кириллицей именно с этой утилитой) - там проблема с кодировкой командной строки.. мне удалось выкрутиться только таким способом - созданием bat-файла

Код:
 
string Path = Application.StartupPath + "\\run.bat";
string resultPath = Application.StartupPath + "\\result.dsed";
File.WriteAllText(Path, " \r\nchcp 1251\r\ndjvused " + "%1" + " -f result.dsed -s", Encoding.UTF8);
System.Diagnostics.Process proc = new System.Diagnostics.Process();
System.Diagnostics.ProcessStartInfo psi = new System.Diagnostics.ProcessStartInfo();
psi.FileName = Path;
psi.WorkingDirectory = Application.StartupPath;
psi.Arguments = "\"" + _fileName + "\"";
psi.UseShellExecute = false;
psi.CreateNoWindow = true;
proc.StartInfo = psi;
proc.Start();
 

первый перевод строки обязателен, т.к. UTF8 создается с лишними байтами вначале (кажется, это называется BOM).. djvused ругается на первую строку, зато вторую (нужную) выполняет.. в принципе, если б утилита понимала BOM, проблем с кириллицей и ком. строкой было бы меньше..

Всего записей: 1436 | Зарегистр. 26-07-2007 | Отправлено: 00:00 11-12-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 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

Компьютерный форум Ru.Board » Компьютеры » Программы » ScanKromsator / СканКромсатор (Часть 3)
gyra (14-11-2018 10:38): ScanKromsator / СканКромсатор (Часть 4)


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

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

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru