» ScanKromsator СканКромсатор (Часть 2)

kontiky
http://forum.ru-board.com/topic.cgi?forum=5&topic=24351&start=1180#11

Arcand

Цитата:

У меня после этого все работало.

Странно. У меня это не сработало.

Я нашёл другой вариант. Есть такая консольная утилитка - tiff2rgba.exe из пакета LibTIFF. Вот она:

http://rapidshare.com/files/133239463/tiff2rgba.rar.html (8 КБ)

Она перекодирует 8-битный серый тиф в 32-битный цветной режим. Вот как выглядит теперь обработка:

Цитата:

tifftopnm 0001.tif | pnmtodjvurle > foreground.rle
tiff2rgba 0001.sep.tif 0001.rgba.tif
tifftopnm 0001.rgba.tif > background.ppm
copy /b foreground.rle+background.ppm output.sep
csepdjvu output.sep demo.djvu
del foreground.rle background.ppm output.sep 0001.rgba.tif
pause

А раньше было так:

Цитата:

tifftopnm 0001.tif | pnmtodjvurle > foreground.rle
tifftopnm 0001.sep.tif > background.ppm
copy /b foreground.rle+background.ppm output.sep
csepdjvu output.sep demo.djvu
del foreground.rle background.ppm output.sep
pause

Теперь можно серые "разделённые сканы", полученные в СК 5.91, напрямую дежавючить по МРС (метод разделённых сканов - "МРС") - без каких-либо промежуточных перекодировок в Irfan View.

Правда, эта утилитка tiff2rgba.exe при первом запуске вызвала глюки в отрисовке некоторых окон винды - но теперь работает без нареканий.

Добавлено:
Интересно, что программа FSD by Manfred, как я понимаю, использует для этой же цели консольную утилиту ppmtoppm.exe из набора NetPBM. Я пока не смог воспроизвести работу (в нужном нам направлении) ppmtoppm.exe без FSD, поэтому пока предлагаю юзать tiff2rgba.exe из пакета LibTIFF для конвертации "на-лету".

Добавлено:
Кстати, у меня получилось уменьшить разрешение фона в МРС. Это делается по формуле, приведённой в http://djvu.sourceforge.net/doc/man/csepdjvu.html :

Цитата:

The dimensions (width and height) of the background image must be obtained by rounding up the quotient of the foreground image dimensions by an integer reduction factor ranging from 1 to 12. Assume, for instance, that the width of the foreground is 2507 and the reduction factor is 3. The width of the background image will be the integer ratio (2507+2)/3.

Т.е. прибавляем к длине 2, делим на 3 и округляем до целого. То же самое для ширины. DPI не меняем. Я это проделал в Irfan'е на пробу. Действительно получается солидное снижение размера. И ещё интересно поиграть с параметром -q 72+11+10+10 - если 2 последние 10-ки заменить хотя бы на 5-ки (а можно и вообще убрать) - фон сильно размыливается и размер DjVu ощутимо уменьшается и т.д.

Добавлено:
У FSD нет пакетного режима работы - т.е. нельзя получить на выходе набор готовых одностраничных МРС-дежавюшек.

По поводу разницы между csepdjvu и msepdjvu: FSD даёт возможность подцепить любую из этих 2 утилит. В отличие от сsepdjvu, msepdjvu имеет дополнительные возможности: качество кодирования маски (без потерь, почти без потерь, консервативное, с потерями, агрессивное), словарь, и disable halftone detection. Ничего из этих 3 параметров у csepdjvu нет.

Что такое "disable halftone detection" я пока не понял - кто-нибудь знает? Параметр "качество кодирования маски" пробовал менять - и пока никак не ощутил его влияние - результат одинаковый, какое бы значение я ни выбрал.Arcand, может Вы неправильно решили, что:

Цитата:

-jSSS - качество кодирования маски, где SSS: lossless, quasilossless, conservative, lossy, aggressive. Например -jaggressive.

Откуда Вы это взяли? Может, на самом деле SSS имеет другие возможные значения?
А вот параметр "словарь" реально работает - если создать посредством FSD многостраничный DjVu, то msepdjvu вставляет Indirection chunk'и (iff) - чего csepdjvu при тех же условиях не делает.

Хотя необходимость создавать именно многостраничные МРС-DjVu ИМХО под вопросом: наиболее часто нужно сделать лишь множество одностраничных МРС-DjVu для вставки их в многостраничный ЧБ DjVu - т.е. полутоновые страницы, как правило, единичны в большинстве книг.

Добавлено:
Что ещё хорошо в FSD - это возможность выбора Background quality в процентах и делителя фона - это даёт очень гибкий механизм регулирования размер/качество.

В поле "Выходной файл" нужно всегда указывать конкретное имя будущего DjVu-файла - если просто указать выходную папку, то программа выдаст ошибку "Ошибка при запуске... Вероятно, кривые тифы" - на самом деле, тифы нормальные.

Добавлено:
В целом, ИМХО метод разделённых сканов (МРС) - на данный момент наилучший практический вариант для обработки полутоновых рисунков в ЧБ бумажных книгах - подходящий для массового использования простыми чайниками. Только FSD немного сложноват пока, не имеет хелпа и не работает в групповом режиме. Но это решаемо, конечно.

Альтернативный способ обработки полутоновых рисунков, предлагаемый Arcand - с помощью Corel PHOTO-PAINT и профиля кодирования my_scan600 для documenttodjvu.conf (всё это описано в http://abab.front.ru/CorelScan.RAR ) ИМХО пока что слишком экзотичен - и совсем неприменим для массового использования, т.к. требует умения и желания работать с Corel PHOTO-PAINT. Вот если бы удалось реализовать, скажем, в Scan Tailor ту же самую обработку, что делается сейчас в Corel PHOTO-PAINT - тогда, быть может, эта методика смогла бы стать массово-применимой.

Метод разделённых сканов, как можно убедиться, даёт значительно меньший размер DjVu, чем при тупом кодировании всей страницы, содержащей полутоновый скан, посредством phototodjvu.exe.

Как я понимаю, МРС, также как и phototodjvu.exe, использует метод кодирования с44 - с одинаковыми опциями типа -q 72,83,93,103. Только вместо делителя фона у МРС у phototodjvu.exe можно насильственно снизить разрешение (в DjVu Small 0.3.1. в опциях параметр "DPI" с плюсиком).

Т.е. разница между МРС и phototodjvu.exe исключительно лишь в площади скана, кодируемой вейвлетным алгоритмом с44, не так ли? Но для относительно малых по площади скана полутоновых рисунков это явно имеет большой смысл.

В общем, чисто с практической точки зрения - нужно улучшать FSD by Manfred (либо сделать аналогичную утилитку) - чтобы МРС стал по-настоящему популярным.

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

monday2000
Какое отношение все это имеет к СК? Есть же топик по сканированию.

К сожалению, tiff2rgba.exe опять глючит - контекстные меню файлов в Проводнике стали отображаться чёрным. Увы, видимо, прийдётся от неё всё-таки отказаться. Надо бы поискать что-то взамен.
vitaly1

Цитата:

Есть же топик по сканированию.

Я там не могу писать - у меня запрет на пост в EBookz, а заводить 2-ой ник - пошлое занятие. Поскольку всё это немного относится и к СК (связка СК 5.91 + FSD) - я написал сюда. Надо же как-то делиться полезной информацией.

Добавлено:
Ура, я нашёл вариант: нужно использовать NetPBM-утилиту pgmtoppm. Вот она:

http://rapidshare.com/files/133290950/pgmtoppm.rar.html (6 КБ)

(Все остальные утилиты доступны тут: http://www.djvu-soft.narod.ru/scan/low_color_djvu.htm .)

А вот и новый синтаксис:

Цитата:

tifftopnm 0001.tif | pnmtodjvurle > foreground.rle
tifftopnm 0001.sep.tif > background.pgm
pgmtoppm rgb:ffff/ffff/ffff background.pgm > background.ppm
copy /b foreground.rle+background.ppm output.sep
csepdjvu output.sep demo.djvu
del foreground.rle background.ppm background.pgm output.sep
pause

Теперь серые МРС-сканы прямо из СК 5.91 можно обрабатывать этими командами. Это как вариант, альтернативный FSD (про который, кстати, неизвестно, как он внутри себя работает).

Предложенный вариант годится только для серых МРС-сканов - для цветных это не подойдёт, там нужен немного иной вариант.

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

Я разобрался с синтаксисом, который использует FSD by Manfred - т.е. способ прямой конвертации МРС:

Цитата:

tifftopnm 0001.tif | pnmtodjvurle > foreground.rle
tifftopnm 0001.sep.tif | ppmtoppm > background.ppm
copy /b foreground.rle+background.ppm output.sep
csepdjvu output.sep demo.djvu
del foreground.rle background.ppm output.sep
pause

Т.е. при такой обработке также можно напрямую обрабатывать МРС-субсканы, полученные из СК 5.91. Дополнительно используется NetPBM-утилита ppmtoppm. Это решение ИМХО более изящно, чем найденное мною - потому что, скорее всего, оно универсально - т.е. годится как для серых тифов, так и для цветных.

Добавлено:
В FSD by Manfred в параметре page resolution следует указывать DPI ЧБ-субскана (точнее, 1-го субскана) - чтобы в полученном DjVu записались правильные значения dpi.
Параметр disable halftone detection пока ИМХО реально не нужен - непонятно, что он делает.

Добавлено:
Сейчас заметил в FSD влияние foreground quality = агрессивное. Действительно, текст маски чуть-чуть отличается на вид от самого себя при foreground quality = без потерь (некоторые буквы +- 2-4 пикселя), а размер DjVu стал на 1 КБ меньше.

Добавлено:
Я думаю, что если опция disable halftone detection не представляет из себя что-то особо важное - то тогда можно полностью отказаться от использования msepdjvu в пользу сsepdjvu - ради лицензионной чистоты. Полезностью опций pages per dictionary и foreground quality (которых нет у сsepdjvu) ИМХО можно пренебречь совершенно безболезненно (для большинства книг, где сканы с полутоновыми рисунками можно по пальцам перечесть). Может быть, msepdjvu и потребуется для цветных книг - но для обычных ЧБ-книг с полутоновыми рисунками достаточно ИМХО и csepdjvu.

Добавлено:
Вопрос по СК 5.91: нельзя ли как-то избавляться из самого СК от отдельно нарезанных картинок, имеющих имена вида "pic.0001", после создания пар МРС-субсканов (вида 0001-0001.sep)? Ведь эти файлы-картинки ("pic.0001") всё равно потребуется вычищать вручную перед кодированием - это лишнее неудобство.

Добавлено:
Пожалуй, прийдётся теперь писать простенькую утилиту для решения этой задачи. Эта утилита должна делать следующее:

1. Просмотрит папку с покромсанными после СК сканами.
2. Выберет из неё все нарезанные отдельно картинки ("pic.0001") и МРС-субсканы ("0001-0001.sep").
3. Создаст внутри папки со готовыми сканами новую папку и переместит (именно переместит - а не скопирует) туда всё из п.2.

Эта операция нужна для отдельной обработки простых ЧБ сканов в сторонних программах - например, выравнивание кривых строк в BR 4.1 (это делается с ЧБ сканами) или же пакетное кодирование их в DjVu. А после выпрямления кривых строк в BR 4.1 можно эти ранее вырезанные картинки обратно вставить в соответствующие места ЧБ сканов - в СК 5.91 есть фича Add zone from file.

У меня наконец дошли руки опробовать методику повышающего ресемплинга с одновременным применением Blur и Sharpen - как описано в ScanAndShare 1.07. В тесте использовался СК 5.91.

Я обработал группу 400 dpi grey-сканов до 600 dpi grey (с применением Blur и Sharpen). Затем обе контрольные группы бинаризовал в Irfan View и задежавючил с профилями Very-aggressive-400 и Very-aggressive-600.

Да, визуальная читабельность у DjVu-600 получилась ощутимо лучше, чем у DjVu-400. Но размер возрос в 1,8 раза. Т.е. можно сделать вывод, что рост размера DjVu в результате применения этой методики из ScanAndShare практически равен (чуть больше) увеличению DPI - т.е. это прямая линейная зависимость. DPI возрос в 1,5 раза, а размер DjVu - в 1,8 раз. Значит, при исходных сканах 300 dpi размер DjVu на 600 dpi вырастет более чем в 2 раза.

Получается, что эту методику не стоит применять всегда и всем - а только для плохих 300dpi-сканов. ИМХО взамен лучше добавить в WinDjView больше сглаживающих фильтров - эффект будет почти таким же (т.е. как и от применения этой методики из ScanAndShare). Сейчас в WinDjView используется "родной" сглаживающий фильтр, который предоставляет DjVuLibre плюс можно ещё дополнительно включить сглаживающий фильтр, исходники которого взяты из NetPBM - но он не очень-то хорош - немного тормознутый и на больших зумах вообще зависает.

monday2000
Я сделал выбор в пользу повышающего ресемплинга (с 300 дпи до 600) и проигрыше в размере djvu файла. По-моему, сейчас разницы что 1.5Мб, что 4Мб - без разницы.

monday2000
"Не корысти ради..."
1. при формальном увеличении с 300 до 600, размер увеличивается квадратично, а не линейно, т.е. в 4 раза.
2. можно сравнить этот учебник по геометрии, какие фильтры в WinDjView помогут?
_http://infanata.ifolder.ru/7505172
_http://rapidshare.com/files/2608812/geometrya.rar
3. помнится, смотрел Ваш скан книжки про атомные тепловозы, по мне, качество было среднее, опять же, никакие фильтры в WinDjView это уже не исправят, не говоря уж если распечатать, там глаза сломаешь.
4. плохие сканы - могила исправит, а не фильтры в WinDjView.
5. не надо людей толкать на кривое сканирование, а то потом никакие фильтры в WinDjView уже не спасут.
6. при применении инструкции, идет комплексное использование возможностей кромсатора, и никакие фильтры в WinDjView не порежут страницы, не выровняют их, не отбросят автоматом большую часть грязи, а максимум размоют текст на экране.

monday2000

Цитата:

Я обработал группу 400 dpi grey-сканов до 600 dpi grey (с применением Blur и Sharpen).

В инструкция ScanAndShare речь идет о 300dpi исходниках. И это важно! Во-первых, результат получается как будто сканировали на 600, а во-вторых, сами знаете, каковы затраты времени при сканировании на 300 и 600. Никто особо не исследовал, насколько метод хорош для 400dpi, ведь 400 - это уже само по себе неплохо.
И конечно же,VadimirTT прав в том, что исходный размер увеличивается квадратично, а не линейно, а выходной после обработки - всего лишь линейно

Я лишь хотел установить факт - увеличивается ли размер DjVu по этой методике, и, если да, то насколько/во сколько раз.
bolega

Цитата:

а выходной после обработки - всего лишь линейно

Т.е. размер DjVu увеличивается примерно в 2 раза - после такой обработки с 300 на 600 - я правильно понял? Об этом в ScanAndShare не сказано ни звука. Я не говорю, что эта методика плохая. Читабельность действительно резко улучшается. Я лишь пытаюсь понять, стоит ли улучшение читабельности 2-х-кратного роста DjVu-файла. Скорее всего, не всегда.
VadimirTT

Цитата:

по мне, качество было среднее,

По мне - тоже. Там были бледные малоконтрастные сканы - книжка старая. Но мне попадались ЧБ-DjVu-300-учебники 2005-2006 годов - идеально-читабельные, с приятными на вид жирненькими буквами.

Цитата:

4. плохие сканы - могила исправит, а не фильтры в WinDjView.

Сравните изображение серых сканов в СК с включённым и с выключенным фильтром.

Добавлено:
bolega
Что такое Create sub-task и Create out-task в 5.91?

ИМХО для нормальной работы по методу разделённых сканов нужно следующее от СК:

1. Внутри выходной папки "out" создавать вложенную папку (например, "split_scans"), куда переместить по окончании работы из папки "out" пары разделённых сканов и отдельно-вырезанные картинки.

2. В папку "split_scans" клать task-файл "split_scans.spt", содержащий следующую информацию:

- имена и количество файлов в папке "split_scans".
- координаты отдельно-вырезанных картинок на тех сканах, откуда эти картинки были вырезаны.

И чтобы можно было повторно открыть СК 5.91, выбрать "split_scans.spt", и произвести слияние картинок с белыми фонами, равными по размеру исходным цельным сканам (опция Create separate files for non-bw zones) - для МРС.

Всё это нужно для того, чтобы можно было во внешних программах обрабатывать раздельно как отдельно-вырезанные картинки, так и те ЧБ-сканы, откуда эти картинки были вырезаны.

monday2000
Странная у вас логика, хотите установить факт, но берете не 300 dpi, как в инструкции, а 400 (кстати, неизвестно еще, это оптическое разрешение или интерполированное сканером). Берете не 10-20 книг, как требуют законы статистики, а всего лишь одну, и в результате рождаете очередную непроверенную "истину"
Так почему все-таки избрали 400dpi-скан? Откройте тайну, ведь в море сканов это можно сказать уникальный случай использования такого dpi. Не кажется ли Вам, что для установления закономерности избрали самый неподходящий и самый нетиповой пример.

bolega
У меня поломался сканер. А сканы я взял, какие были (400). Разрешение - оптическое. Одного опыта - мало, но для грубой прикидки достаточно. Надеюсь, кто-нибудь ещё проделает такой опыт.

Добавлено:
Ещё раз: в ScanAndShare ни звука не сказано о том, растёт ли DjVu файл от такого апсемплинга, и если растёт - то насколько. В этом и ошибка - такие вещи следует писать обязательно - чтобы люди могли выбирать, применять ли такой приём, или нет. Книга размером то ли в 6 МБ, то ли в 12 МБ - согласитесь, есть разница.

monday2000
дело не в защите кромсатора или методики или еще чего, но уже давно можно считать за постулат, что поползновения делать сканы в 300 (как и в 400), а также пропаганду того, что могут быть случае когда и так сойдёт, нужно выжигать каленым железом и никаких дискуссий тут даже и допускать нельзя, т.е. положил ноги на стол - получи ложкой полбу.

VadimirTT

Цитата:

уже давно можно считать за постулат

Это, мягко говоря, не совсем корректная ИМХО точка зрения. Так давайте тогда вообще в Pdf сканировать - он же популярнее DjVu. Лучше подумать о том, как всё делать на 300dpi и получать хорошее качество при этом. Не нравится 300 - давайте 400. Но 600 - это уж слишком - для общего-то случая. Цена 600-ста слишком велика получается.

ИМХО 600 годится только для паршивых исходных сканов. Если сканы хорошие - то и 300 сойдёт (естественно, при грамотной обработке).

Вы тут себя бейте ложкой хоть по лбу хоть по другим местам - а людей Вы этим не заставите апсемплировать 300 -> 600 - ведь большинству, разумеется, не захочется это делать за счёт 2-х-кратного роста размера DjVu - это ежику ясно.

Цитата:

Что такое Create sub-task и Create out-task в 5.91?

Ответ был на предыдущей странице или около того


Цитата:

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

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

Кстати, в опциях sk и сейчас есть опция "удалять pic-файлы после слияния". По умолчанию она отключена. Это то, о чем Вы просили ранее

bolega
Вот представьте, у меня уже есть в СК 5.91 покромсанные ЧБ-сканы с Picture-зонами. И я хочу их все скопом пропустить через BR 4.1 - выпрямить искривленные строки. Я же не могу в BR 4.1 напрямую загрузить out-папку - прийдётся сначала вручную убрать из out-папки вырезанные картинки. А потом обратно вставить. И при этом не выкидывать исходные сканы, из которых всё это было накромсано (а то spt-файл не откроется), хотя зачем они уже нужны. Что же делать? Всё руками перемещать туда-сюда?

Добавлено:

Цитата:

Кстати, в опциях sk и сейчас есть опция "удалять pic-файлы после слияния".

Она не работает.

Цитата:

ведь большинству, разумеется, не захочется это делать за счёт 2-х-кратного роста размера DjVu - это ежику ясно.

Большинству вообще не то что делать сканов не хочется, читать много букавок противно. А для многих предел совершенства - chm и rtf (тьфу 3 раза).

Добавлено:

Цитата:

Она не работает

Работает

monday2000
Единственная причина делать в 300 это скорость сканирования, но теперь, благодаря кромсатору, мы избавлены от этого, скорость сканирования в гр.серого равна ч/б, а там несколько необременительных для человека операций и на выходе замечательный скан в 600, причем, на мой взгляд, это даже лучше, чем непосредственное сканирование в 600 ч/б за счет автоматического убирания мусора в процессе выравнивания освещенности скана и более продвинутой бинаризации.

Цитата:

Я же не могу в BR 4.1 напрямую загрузить out-папку

Загрузите файлы, начинающиеся с "pic"

VadimirTT
Да о чём Вы вообще говорите? Я Вам о РАЗМЕРЕ пытаюсь втолковать, а Вы мне о скорости. Главный смысл DjVu - это размер. И, если мы на это решим плюнуть - тогда вообще всё обессмысливается. Давайте тогда просто покромсанные тифы распространять в PDF по 100 МБ файл - ведь это же
Цитата:

на выходе замечательный скан в 600

.

Всё, убедили, да здравствует 96 дпи! Ура товарищи!
Кстати, я во все свои сканы ещё и OCR слой запихиваю, не обременяет ?

bolega

Цитата:

Загрузите файлы, начинающиеся с "pic"

Так мне нужно наоборот - все, отличающиеся от начинающихся с "pic". Нельзя ли добавить в СК полный пользовательский контроль над этими вещами? Потребность ИМХО ощутимая. Какие-нибудь 3 галки типа "помещать все pic во вложенную папку", "помещать все sep во вложенную папку", "помещать все парные pic во вложенную папку". По-умолчанию все 3 категории помещать во вложенную папку - это удобно как для последующего DjVu-кодирования, так и для отдельного кодирования МРС-сканов. Я-то могу, скажем, подкорректировать DjVu Small так, чтобы он отсеивал на входе все "левые" файлы (да и FSD можно аналогично подправить) - только вот BR 4.1 уже не подправишь.

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

Добавлено:
VadimirTT
Как вариант, можно попробовать сканировать на 300 dpi grey - и попытаться применить те кореловские обработки, о которых говорил Arcand в http://abab.front.ru/CorelScan.RAR - размытие, сглаживание зазубренных контуров, и т.п. Только не делать повышающий ресемплинг! Если такой вариант окажется эффективным - то просить реализовать соотв. кореловские обработки, скажем, в Scan Tailor. Это, понятно, трудно - но не нереально.

monday2000

Цитата:

говоря, нет механизма архивного хранения pic-файлов и парных им "обезкартиночных" сканов

Как это нет?? На это и команда create out-task. После нее исх. файлы можно выбросить. В получившемся файле можно при желании легко увидеть ко-ты картинок.
Насчет относительных путей - хорошая идея. Сделаю как опцию. Это и сейчас есть, но только для create sub-task.

---

monday2000
Вот, провел микроэксперимент, взял идеальный случай - страница из векторного pdf, выдрал в 600 дпи, сделал ресайз в 300, обе странички пожал в djvu, разница в размере 87%, но стоит ли это того, как стала страничка выглядеть?
_http://slil.ru/26022598
и это, повторяюсь, идеальный случай, при сканировании разница в качестве будет катакстрофически увеличиваться, в то время как размеры слегка сблизятся.
и вообще, пусть Вам не нравится кромсатор, вид из окна или того хлеще путин, это Ваше личное дело, но в вопросе 600 vs 300 не может быть компромисса, если бы это говорил кто то еще, мне на самом деле было бы пофиг, но в данном случае, пойдет писать губерния - мол сам понедельник на 300 благословил, а то что он сделал такие глубокие выводы походя клацнув пару раз мышкой на материале завалявшимся в корзинке это уже будет за скобками.
насчет всемогущего корела, который нам поможет, если запустить кромсатор, то можно понаблюдать преинтереснейшую картину, там отображается последовательность выполнения операция, вначале идет выравнивание. потом ресайз и только затем применение всех остальных фильтров, с чего бы это ?
никаких причин за 300 нет, кроме ставшей неактульной скорости сканирования, я бы никогда не стал бы страдать и сканить в 600.

VadimirTT
Хорошо, давайте сделаем так: пусть по-умолчанию Ваш способ будет считаться основным при создании DjVu. Всё-таки, как ни крути, хорошая читабельность - это гораздо важнее, чем возрастание размера DjVu в 2 раза. Прийдётся, видимо, пойти на такую жертву (возрастание размера DjVu) - ведь паршиво-читаемая, но зато маленькая по размеру DjVu-книга действительно годится только для OCR-ения. 300dpi в самом деле маловато - 400 ещё куда ни шло.

Но всё же полностью отказываться от сканирования и дежавючения на 300 dpi ИМХО преждевременно. Надо всё равно искать и исследовать пути отказа от апсемплинга. Я действительно видел качественные книги на 300 dpi - если попадётся, выложу образец. Т.е. новые книги, только что купленные в магазине, на хорошей белой бумаге (не макулатурной, а типа мелованной) и с чётким шрифтом можно пробовать делать на 300dpi - так я и буду рекомендовать народу.

monday2000
1. ещё раз, я не пропагандирую мой не мой способ, я за 600 дпи и никаких гвоздей.
2. может договоримся, что как только Вы выложите мифическую качественную (а не из разряда и так сойдет) книгу в 300, и народ одобрит, только после этого Вы будете начинать упоминать о гипотетической возможности делать в 300.

VadimirTT

Цитата:

2. может договоримся,

Хорошо, сделаем так. Эта книга у меня где-то на двд есть.

Добавлено:
bolega
Я ещё раз подумал насчёт разных папок и ИМХО нашёл наиболее оптимальный вариант: достаточно просто делать в папке out вложенную ("split_scans") и туда всегда и во всех случаях класть pic-файлы, парные им "обезкартиночные" сканы и sep-тифы - т.е. все 3 вида "особенных" "картиночных" тифов. Т.е. не надо делать галки
Цитата:

3 галки типа "помещать все pic во вложенную папку", "помещать все sep во вложенную папку", "помещать все парные pic во вложенную папку".

- а использовать "split_scans" постоянно, когда есть хоть один из 3 особенных видов.

Опция по удалению pic-файлов по-моему не нужна - FSD всё равно игнорирует такие файлы - т.е. pic-файлы ничему не мешают.

Зато в случае, если SK будет делать папку "split_scans", саму папку out можно будет напрямую подавать и на DjVu-кодирование, и на выравнивание кривых строк.

Единственный минус такого решения - что делать, если захочется выровнять кривые строки у файлов, парных pic-файлам (и находящися в папке "split_scans")? В этом случае выравниванием кривых строк у этих файлов можно просто пренебречь для простоты. Либо чисто вручную тогда уже это проделать.

Ещё мелкий вопрос: почему pic-файлы имеют вид "pic.0001"? Лучше пусть называются "0001.pic" - аналогично "0001.sep" и в папке они тогда будут сортироваться по имени около парных им.

Добавлено:

Цитата:

Как это нет?? На это и команда create out-task. После нее исх. файлы можно выбросить.

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

Добавлено:
VadimirTT
Упор на хорошую читабельность ИМХО особенно актуален в свете грядущей популяризации E-Ink читалок (потому что можно ожидать через 2-3 года широкоэкранные читалки - вместо нынешнего 6-дюймового издевательства (см. про журнал Esquire). Сейчас DjVu-книги скорее всего используются лишь для эпизодического заглядывания туда как в справочное пособие. Может быть, E-Ink-устройства сделают формат DjVu популярнее на Западе.

Давайте попробуем поставить очередную точку в обсуждении вопроса, в каком разрешении сканировать

1. Да, режим сканирования 300dpi в полутонах серого подходит примерно для 70-80% случаев.
2. Но: это утверждение не исключает тех самых 20-30% частных случаев, в которых решение необходимо принимать ad hoc.
2.1. В этих случаях следует учитывать:
2.1.1. Качество печати;
2.1.2. Размер наименьшего шрифта.

Пример №1 (возможно, не совсем удачный, но ничего другого в голову не приходит):
Букварь, напечатанный на мелованной бумаге. Т.е. самый крупный кегль, хорошая печать – можно сканировать хоть в 150dpi в полутонах с последующим апсемплингом до 300dpi.

Пример №2 (реальный из жизни, хотя тоже несколько «экзотичный»):
Любое (в том числе и современное) издание древних текстов, особенно древнегреческих. Т.н. аппарат, приводимый на каждой странице текста, в котором перечисляются варианты написания отдельных слов в разных папирусах, дан очень мелким шрифтом, а специфика греческих символов – в большом количестве тонких перемычек, а также мелких диакритических знаков. Даже в случае хорошей печати (а обычно это очень хорошая печать) при сканировании в режиме 300dpi grey перемычки пропадают, а диакритики «слипаются» друг с другом. Поэтому такие книги приходится сканировать в режиме 600dpi grey.