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

Цитата:

И в версии 5.91 теперь есть все, чтобы такой черный ящик пользователю предоставить: залил в него сканы, проверил расстановку резаков,

вот только про расстановку резаков , конечно проект закрыт, но тут are упоминал, что на конвейре ошибок с резаками почти нет...

VadimirTT

Цитата:

вот только про расстановку резаков , конечно проект закрыт, но тут are упоминал, что на конвейре ошибок с резаками почти нет...

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

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

Цитата:

что на конвейре ошибок с резаками почти нет

Да, так и есть. Я объясню, почему. Это становится ясно, если посмотреть на исходники. Там реализован обучающийся алгоритм. Все выполняется в 2 этапа. На 1-м этапе определяется контур и высчитыватеся средний для всей книги. На 2-м этапе (проходе) контур каждой страницы корректируется (как именно, писать не буду), исходя из "обученного" контура (он то для книги в реальности постоянен, что и позволяет это проделать). Метод замечательный, но в ск не применим. Для его работы требуется обработать книгу за 1 раз (на это собственно ориентированы все алгоритмы в конвейере); если бы так было в ск, то результаты драфта были бы разными в зависимости от того, сколько было задано страниц отдрафтить. Я решил, что это неприемлимо. Есть и другие отличия, например в конвейере сразу отсекается крупный мусор, после чего контур определить становится гораздо легче. В кромсаторе этого делать нельзя, ведь если резаки ставить так, как будто мусора нет, то при просмотре окажется что они стоят всегда на мусоре. Чтобы было понятно: убрали мусор, ура, контур легко определить. Но. Вернули мусор обратно (это ведь драфт, и резаки нужно показать на исходном скане, а не очищенном), и оказалось, что мусор теперь там, где резаки, которые теперь ничего толком не отрезают. Поэтому алгоритм расстановки резаков в ск намного сложнее - ему требуется их расставить в реальных условиях - при наличии черных полос и грязи (которые иногда очень трудно отличить от иллюстраций или линий таблиц), или еще хуже, наползании всей этой нечисти прямо на текст. Втиснуть резаки между текстом и мусором, особенно на развороте или при сильном наклоне, очень трудная задача

bolega
Извините за "провокационный" вопрос А Вы сами какую программу (программный пакет) назвали бы лучшей на сегодняшний день в плане обработки книжных сканов?

ghosty
Странный вопрос...
Я ведь пользуюсь только одной Поэтому другие я плохо знаю, а посему сравнивать мне трудно. Одно скажу - мне нравится, что все они - разные! Т.е. это не клоны, и не слизанные друг у друга. Хотя многим (не буду тыкать пальцем) хочется видеть во всех прогах одну, похожую на FR (вроде как идеал юзабилити). Но если они все будут как близнецы, тогда зачем вообще их разрабатывать??
CT мне кстати нравится оригинальным подходом ко всему (но я не считаю, что она более юзабильная чем sk, и со временем, чем более ближе она станет к своему предназначению, чем с большим количеством отклонений столкнется автор, тем более сложным будет интерфейс, от этого никуда не денешься, как бы это кому-то не нравилось) . Будет оригинальность - будет значит и будущее у нее.

ghosty

Цитата:

А как же требование простоты и доходчивости для простого народа? Кромстор.Лайт и тому подобное?

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

Цитата:

Не понял идеи.

Я об этом не раз уже говорил. Сразу после сканера имеем либо сдвоенные сканы, либо одиночные с ошмётком соседней странцы сбоку. SAS и Вы предлагаете сразу их загрузить в СК, нажать кнопку Draft kromsate, и дальше
Цитата:

Если сканы представляют собой развороты (две страницы на листе), то в открывшемся окне ставим галку Split pages.

Я же предлагаю следующее:
1. Загрузить сырые сканы в СК.
2. Разрезать сдвоенные развороты (или отпилить ошмётки, если это случай одиночных сканов) и попутно применить deskew. То, что получится, я называю "унифицированные сканы" - т.к. для них уже не существует физического (а есть только логическое) понятия "левый" и "правый" скан.
3. Выгрузить унифицированные сканы из СК и закрыть СК.
4. Открыть СК, загрузить унифицированные сканы (а они будут в greyscale 300 dpi) и продолжить дальнейшую обработку, как обычно (draft kromsate и т.п.).

Смысл унификации:
1. Возможность упростить интерфейс сканобрабатывающей программы (не нужны группы опций для левой и правой страницы).
2. Юзеру проще работать по 1-й странице, чем по 2 сразу.

Добавлено:
bolega

Цитата:

тем более сложным будет интерфейс, от этого никуда не денешься

Можно деться - выход в том, чтобы вместо одной большой программы сделать несколько маленьких - очень узкоспециализированных, чтобы каждая маленькая программа отвечала за конкретный этап сканобработки:
1. Сканирование - программа №1.
2. Унификация - программа №2.
3. Выравнивание освещённости - программа №3.

Дальше - тот блок операций, разделить которые по отдельным программам пока затруднительно:

4. Выделение картинок - СК
5. Бинаризация - СК
6. Кромсание - СК
7. Слияние картинок - СК

monday2000
вообщето простому юзеру совсем не хочется разбираться с зоопарком программ, ему надо одна с большой кнопкой, с профилем от ghosty кромсатор к этому приближается .

Кстати, по поводу картинок - мне пришла в голову такая идея:

Для каждого TIF-скана можно хранить информацию о количестве и координатах полутоновых картинок на нём (и вообще любых его зон) в метаданных данного TIF-скана! И при кромсании можно просто корректировать эти координаты по соотв. алгоритму (этот алгоритм уже есть в СК 5.91).
Тогда всё сильно упрощается: этапы 4-7 уже можно без проблем разбить на отдельные программы - важно лишь то, чтобы на каждом этапе метаинформация не терялась (или нужным образом корректировалась).

Добавлено:
VadimirTT

Цитата:

вообщето простому юзеру совсем не хочется разбираться с зоопарком программ

А иного выхода нет - ИМХО.
Посмотрите на DjvuOCR: это же несколько программ в одной фактически. Я не говорю, что надо сделать именно так - но идея, думаю, понятна. Можно в виде некоего визарда - как в Ashampoo Uninstaller- и перебрасывать там выходную папку с предыдущего этапа как входную для последующего - чтобы юзер не задумывался о её местонахождении.

bolega

Цитата:

Я ведь пользуюсь только одной

Ну я-то думал, Вы все же откуда-нибудь черпали вдохновение Пользовались другими пакетами.
Просто мне также не известно ничего о крутых "промышленных" пакетах обработки сканов. Вроде как, они должны быть - ведь западные электронные библиотеки чем-то подобным пользуются, и получается у них очень неплохо (особенно у JSTOR). Но что это за ПО, загадка. Может быть, тоже СК


Цитата:

Практически я представляю себе это типа Википедии - идёт основной текст (простой-доходчивый-"на уровне чайника"), снабжённый редкими гиперссылками

Не надо ничего усложнять. Мне кажется, что даже тот текст, который есть, можно сделать еще лаконичнее. Уж если Лайт, так Лайт!


Цитата:

Licht, mehr Licht!!

(c) Goethe

Возник вопрос по поводу ресемплинга. Когда я делаю ресемплинг от 300 до 600 дпи, то на 300-400 страничной книге размер djvu файла у меня получаеться около 4Мб, что терпимо для выкладки в инет. Но сейчас мне попались книги по 800 страниц, и я подозреваю, что размер djvu файла вырастет соответственно вдвое.

Отсюда вопрос, как добиться преемлемого размера djvu файла? Делать понижающий ресемплинг от 600 до 300 дпи? Вообще отказаться от ресемплинга до 600 дпи в ущерб качеству?

Еще один смежный вопрос. Я тут собрался слить сканированные файлы (300dpi gray) на двд матрицы, в архив, и с ужасом обнаружил, что файлы книги в 400 страниц занимают больше гигабайта. Обнаружил, что сканирую я в bookpilot в tiff без сжатия, а это, как оказалось, чревато. Тем не менее, tiff сжатие в zip позволяет уменьшить размеры файлов сканов на 40%. Уже лучше, но тоже немало. Кроме того, подозреваю, что и обработка в sk таких сжатых файлов замедлиться
А как вы храните архивы сканов?

kontiky

Цитата:

Возник вопрос по поводу ресемплинга. Когда я делаю ресемплинг от 300 до 600 дпи, то на 300-400 страничной книге размер djvu файла у меня получаеться около 4Мб, что терпимо для выкладки в инет. Но сейчас мне попались книги по 800 страниц, и я подозреваю, что размер djvu файла вырастет соответственно вдвое.

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


Цитата:

Отсюда вопрос, как добиться преемлемого размера djvu файла? Делать понижающий ресемплинг от 600 до 300 дпи? Вообще отказаться от ресемплинга до 600 дпи в ущерб качеству?

Здесь уже все зависит только от стоящих перед Вами задач. Что для Вас важнее? Малый размер? Качество книги? А может быть, скорость декодирования?
К примеру, старое ценное издание лучше оставить в 600dpi (а совсем редкое, ветхое и вовсе не стоит переводить в B/W). И в этом случае вовсе не важно, сколько будет занимать файл. В особых случаях и использование DJVU может оказаться кощунством.
А какой-нибудь компьютерный мануал на английском языке в принципе смело можно кодировать и в 300dpi. Хотя особой разницы в размере между 300 и 600 в этом случае ожидать не приходится. Если же этот мануал на русском, то при 300dpi все еще возможны ошибки подстановки при кодировании.
Поэтому общая рекомендация - приводить сканы к 600dpi. И привыкать, что размер, если этот критерий действительно важен, зависит, в первую очередь, от качества обработки.

Цитата:

А как вы храните архивы сканов?

Не храню. После того, как выжимаю из оригинала все соки, выкидываю его

Цитата:

Кроме того, подозреваю, что и обработка в sk таких сжатых файлов замедлиться

Помнится, bolega говорил, что СК любит LZW

To All: Да, хотелось бы сказать, что профиль по умолчанию, использованный в "сборке" - не является предметом моей творческой фантазии, но лишь попыткой объединить опыт всего коммьюнити %) Многочисленные обсуждения в этом и соседнем топиках не прошли даром. Спасибо, друзья!

Я узнал по эл.почте у manfred формулу расчёта размеров фона в FSD (при его делении):

Цитата:

Подскажите, пожалуйста, формулу, по которой вычисляются размеры уменьшенного заднего фона.

Lф = ceil( Lм / n ),
где
ceil - округление в большую сторону ( т.е. ceil( 1.001) = 2 )
L - длина или ширина
n = 2-12

или так:

Lф= int( (Lм+(n-1))/n )
int - округление отбрасыванием дробной части
Пример:

Lм = 2345
n = 3
Lф= ceil( 2345/3 ) = ceil( 781.666 ) = 782

или

Lф= int( (2345+3-1)/3 ) = int( 2347/3 ) = int( 782.333 ) = 782

Добавлено:
kontiky

Цитата:

я подозреваю, что размер djvu файла вырастет соответственно вдвое.

Не могли бы Вы проделать такой эксперимент и выявить - на сколько всё-таки размер вырастет?

Цитата:

Отсюда вопрос, как добиться преемлемого размера djvu файла? Делать понижающий ресемплинг от 600 до 300 дпи? Вообще отказаться от ресемплинга до 600 дпи в ущерб качеству?

Надо искать варианты. Никто этого точно пока не знает. ИМХО нужно пробовать всякие обработки в Matlab и Corel PHOTO-PAINT. Размытие, сглаживание, контраст, гамма, и т.д. Мне тоже кажется, что 2-х кратное увеличение размера файла - это слишком дорогая цена за качество (при апсемплинге). Но пока что, видимо, прийдётся её платить - раз ничего лучше пока ещё не придумано. Почитайте это: http://abab.front.ru/CorelScan.RAR .

Цитата:

А как вы храните архивы сканов?

Я не храню именно сырые сканы - т.к. на 1 DVD помещаются сырые сканы всего лишь от двух книг. Храню их в виде CCIT FAX G4 - хотя, понятно, толку от этого почти никакого. Подождём популяризации Blu-ray. А там подоспеют диски на 300 ГБ-1 ТБ - см. http://lenta.ru/articles/2008/07/08/pioneer/ .

Цитата:

Отсюда вопрос, как добиться преемлемого размера djvu файла? Делать понижающий ресемплинг от 600 до 300 дпи? Вообще отказаться от ресемплинга до 600 дпи в ущерб качеству?

Надо искать варианты. Никто этого точно пока не знает.

Как же так! . Этот вопрос уже поднимался (тут мне ghosty не даст соврать ) и его принципиальное решение ИМХО найдено. В случае нормальных по качеству книг (советской полиграфии) типичное сжатие при грамотной обработке составляет 7-9 кб/стр (на выходе 600 дпи). Наилучшее сжатие для сканированной книги я получал где-то в районе 6,5 кб/стр. Наибольшего известного мне сжатия достиг bolega. Если не ошибаюсь, около 6 кб/стр. ИМХО это почти теоретический предел сжатия сканированных книг обычного содержания и формата.
Об увеличении сжатия. Главное - сглаживание контуров, которое достигается комплексным применением фильтров (размытие, контурная резкость, сглаживание).
На плохих по качеству книгах сжатие у меня достигало ~14 кб/стр. Не думаю, что 300 дпи в этом случае дало бы значительный выигрыш в сжатии (10 кб/стр это не выигрыш по сравнению с ухудшением читабельности).
Теперь про 300 дпи vs 600 дпи. Буду говорить о нормальных и хороших по качеству книгах. Различие в размере и, соответственно, в сжатии здесь не квадратичное и даже не линейное, а скорее логарифмическое . Представьте себе, что вы кодируете электронную книгу, в которой только текст, т.е. словарь символов невелик. Основной вес ИМХО будет приходится на координаты символов, по сравнению с которым вес словаря это мелочь. Получается, что в этом случае сжатия при 300 дпи и 600 дпи будут весьма близки (если исходить из предположения, что вес координат в дежавю не зависит от дпи). В случае сканированных книг, кодируется еще разница (отличие от словарного символа). Это даст прибавку в сжатии и 600 дпи будет уже больше проигрывать 300 дпи. Однако, по сравнению с качеством это цена невелика. Судите сами, книга 400 стр при сжатии 9 кб/стр будет весить меньше 4 мег. Пусть при 300 дпи она будет весить 3 мега. Ну и что, зато читабельность у 600 дпи на порядок выше.

Arcand

Цитата:

Судите сами, книга 400 стр при сжатии 9 кб/стр будет весить меньше 4 мег. Пусть при 300 дпи она будет весить 3 мега.

Это теория. А на практике Вы пробовали сделать 2 варианта - 300 и 600 - и сравнить размер? По-моему, на практике размер 600 в среднем в 2 раза больше, чем размер 300 (Книга - ЧБ).

Цитата:

Об увеличении сжатия. Главное - сглаживание контуров, которое достигается комплексным применением фильтров (размытие, контурная резкость, сглаживание).

А есть ли где-то конкретная методика, которую можно почитать?

Смысл в том, что методика апсемплинга, изложенная в ScanAndShare (с Blur + Sharpen), приводит к 2-х-кратному росту размера DjVu. Это слишком много - надо что-то придумать, как побороться с таким ростом файла. Добавить к методике sas-апсемплинга ещё и какие-то предварительные обработки типа размытие, контурная резкость, сглаживание? И в чём их делать - Corel PHOTO-PAINT - не очень-то подходящая для большинства кандидатура...

Я смотрю, что о двойном увеличении размера djvu говорят уже как о состоявшемся факте, хотя никто проверок так и не провел. Вот так и рождаются мифы.
По моему опыту, эта цифра намного ниже (при условии нормальной обработки). Были даже случаи, когда размеры оставались практически прежними, и один раз даже стало меньше (за счет сглаживания). Но определенно утверждать это как об аксиоме не берусь, т.к. то были единичные случаи из моей практики. Единичные, потому что я 300dpi на дух не переношу

monday2000
Цитата:

Это теория. А на практике Вы пробовали сделать 2 варианта - 300 и 600 - и сравнить размер? По-моему, на практике размер 600 в среднем в 2 раза больше, чем размер 300 (Книга - ЧБ).

Во первых, мне это не интересно . В любом случае - плохая или хорошая книга - буду делать 600 дпи. Говорить про 300 дпи книги могут только новичьки , перубеждать их мне скучно и не интересно, есть мозги и глаза - увидят, поймут.
Во вторых. Я непосредственно не сравнивал, за ненадобностью - первые несколько книг я сделал в 300 дпи, их сжатие ~9-10 кб/стр. Не буду скрывать, есть неансы: невысокое качество обработки и небольшой размер словаря. Думаю, можно выжать 6-7 кб/стр. На 600 дпи получил бы на глаз около 8 кб/стр. Выводы я давно сделал - на 300 дпи поставил жирный крест!

Цитата:

А есть ли где-то конкретная методика, которую можно почитать?

Важна идея
Цитата:

Главное - сглаживание контуров, которое достигается комплексным применением фильтров (размытие, контурная резкость, сглаживание).

Делайте там, где Вам удобнее.


Добавлено:
kontiky
Цитата:

А как вы храните архивы сканов?

Раньше в tif LZW, сейчас вынужденно (сканирую в БукПилот) в jpg 100%. На матрицу входит ~3-4 книги. Сохраняю еще spt (SK), скрипты (Корел) и готовые сканы. Все это при необходимости позволит мне быстро переделать книгу. Пока такого случая не было

bolega

Цитата:

Я смотрю, что о двойном увеличении размера djvu говорят уже как о состоявшемся факте

Я говорю исключительно о методике, изложенной в ScanAndShare. Если делать строго по ней, то получается столь большое увеличение.

bolega
Arcand
Дайте, если можно, конкретную методику (в дополнение к изложенному в ScanAndShare методу "апсемплинг 300-600 с Blur + Sharpen") - которую можно было бы отобразить, скажем, в ScanAndShare - в целях внижения размера DjVu.

monday2000
Цитата:

Arcand, может Вы неправильно решили, что:

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

Я декомпилировал documenttotodjvu и msepdjvu и увидел все опции.

Цитата:

Что такое "disable halftone detection" я пока не понял - кто-нибудь знает?

Из справки
Цитата:

The disable-halftone option disables halftone detection. Halftone detection is useful when you convert dithered images, such as scanned newspaper articles. If the input image does not contain dithering, specify this option to decrease encoding time and reduce the output file size.

Т.е. эта опция предохраняет от порчи dithered рисунки - чтобы точки не пропадали. Я заметил, что сетки таблиц и координатные сетки на графиках из точек сильно страдают при кодировании lossy (т.е. с потерями). Только при lossless точки не пропадают.

Цитата:

Нет ли у кого-нибудь исходника программы pnmtodjvurle

Здесь

All
Могу внести свои три копейки в возникшее обсуждение вопроса 300 или 600 dpi.
Начинал обработку (все последующее относится к обработке шахматной литературы) с 300, стремясь делать книги меньшего размера, но довольно быстро перешел на 600, т.к. визуально текст выглядит заметно приятнее.
Сейчас делая книгу в 600, некоторые выкладываю и в 300, так что некоторой информацией о соотношении размеров обладаю. Правда все варианты 300 я сейчас делаю из полученного варианта 600 простым даунсемплингом (с ухудшением текста), но не думаю, что получил бы существенное отклонение, если бы сразу делал только в 300.
Еще одно замечание о соотношении размеров 300 и 600 dpi.
На мой взгляд не очень корректно сравнивать варианты СПЕЦИАЛЬНОЙ обработки книги. Если после достаточно длительной и утомительной подборки нужных параметров обработки да еще с привлечением дополнительных программ удается получить какой-то приемлемый вариант, то совсем неочевидно, что это можно будет делать для большинства книг.
Теперь мои наблюдения:
3642 KB - 7031 KB
1429 KB - 3306 KB
2898 KB - 6259 KB
3939 KB - 7556 KB
2454 KB - 6538 KB
1980 KB - 4166 KB
2110 KB - 4452 KB
2543 KB - 6003 KB
3217 KB - 7052 KB
3008 KB - 5943 KB
4279 KB - 8971 KB
3493 KB - 9061 KB
4322 KB - 11961 KB
5532 KB - 12271 KB
10100 KB - 18981 KB
7760 KB - 16567 KB
3625 KB - 8384 KB
4231 KB - 8411 KB
1798 KB - 5323 KB
4862 KB - 9501 KB
4656 KB - 9032 KB
Еще раз повторяю, здесь преведены результаты моей обработки 21 книги в двух разрешениях. Основная книга делалась в 600 dpi, затем из нее простым даунсемплингом получалась книга в 300 dpi. Сжатие при компиляции книги в 600 dpi близко к максимальному.
P.S. Несмотря на преведенные результаты для себя (а практически все книги я делаю для себя) я делаю только в 600 dpi, но тем не менее варианты в 300 dpi скачиваются тоже довольно активно.
Стоит сделать некую поправку на наличие в книгах большого количества шахматных диаграмм, размер которых, ВОЗМОЖНО(?), уменьшается сильнее при даунсемплинге.

kontiky
Цитата:

А как вы храните архивы сканов?

Я храню свои сканы на ДВД. Уже набралось 27 дисков по 4700 мб.
Говорить о количестве книг, помещающихся на ДВД некорректно, т.к. книги бывают разных размеров. Я получаю сканы разворотов в программе vuescan, сохраняющей эти развороты в lzw tiff (с ними Кромсатор работает отлично, замедлений не замечал), кроме того перед сканированием есть возможность задать зону сканирования, в которую все, что выходит за пределы разворота, в скан не попадает. Средний размер тифа разворота, сжатого в LZW, составляет примерно 6 мб.
Т.о. на ДВД в 4700 мб можно записать порядка 780 разворотов, т.е. 1560 страниц.

Цитата:

Раньше в tif LZW, сейчас вынужденно (сканирую в БукПилот) в jpg 100%. На матрицу входит ~3-4 книги.

Да. Очень печально, что БукПилот не умеет сразу сохранять в tiff lzw или tiff zip

Добавлено:
shch_vg
У вас в первом столбике размер книги в 300pdi, а во втором - в 600?

Добавлено:
bolega

Цитата:

Я смотрю, что о двойном увеличении размера djvu говорят уже как о состоявшемся факте, хотя никто проверок так и не провел.

Посмотрите результаты shch_vg - увеличение размера в два и более раза. У меня же книга при 300 dpi "весила" 1.1Мб, а при 600 dpi - 4.1Мб. Однако, это для книги с цветной обложкой.

kontiky

Цитата:

Да. Очень печально, что БукПилот не умеет сразу сохранять в tiff lzw или tiff zip

Это конечно добавляет лишней работы. Но особой проблемы я не вижу. Я сразу же в СК задаю команду File->recompress... и всех делов.

Добавлено:

Цитата:

Посмотрите результаты shch_vg

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

bolega

Цитата:

Но особой проблемы я не вижу. Я сразу же в СК задаю команду File->recompress... и всех делов.

Спасибо! Именно то, что душа просила

monday2000

Цитата:

Я говорю исключительно о методике, изложенной в ScanAndShare. Если делать строго по ней, то получается столь большое увеличение.

Это догадка или факт? Если факт, то пожалуйста пример на обозрение.
Более года назад я вам отвечал что получается у меня при нормальной обработке http://forum.ru-board.com/topic.cgi?forum=93&topic=1615&start=1180#10

kontiky

Цитата:

У вас в первом столбике размер книги в 300pdi, а во втором - в 600?

Конечно!

Цитата:

Однако, это для книги с цветной обложкой.

У меня ВСЕ приведенные книги в обоих разрешениях с цветными обложками (абсолютно одинаковая прибавка для обоих разрешений). Вам стоит найти вариант минимального размера обложек при минимальных потерях в качестве.
bolega

Цитата:

диаграмм там очень много, и я подозреваю, что они плохо ужимаются

Но в 300 dpi они, получается, ужимаются гораздо лучше, либо много теряют при даунсемплинге, хотя на взгляд потери при понижении разрешения для диаграмм не больше, чем потери в тексте.


Добавлено:
bolega

Цитата:

Но надо сказать, что шахматные книги - это довольно специфические книги

Очень легко проверить на другого сорта книгах. Я импортирую книгу в 600 dpi DJVU в Кромсатор, затем, убрав цветные обложки, на закладке Page жму правую клавишу мыши и в контекстном меню выбираю Clear all options & mark all. Затем на закладке Files в списке DPI выбираю 300 dpi и вперед!
Через 2-3 минуты уже можно компилировать - желающие могут проверить на чисто текстовых файлах.

shch_vg

Цитата:

Но в 300 dpi они, получается, ужимаются гораздо лучше, либо много теряют при даунсемплинге

Ни то, ни другое. Они все попадают в словарь как есть (я так подозреваю, т.к. маловероятно, что кодек сможет их различить), а посему размер их отличается уже в квадрате (если не учитывать сжатие, а если учитывать - то вдвое т.е. по сути увеличивается вдвое кол-во строк, то, что и длины у них разные, особо уже не влияет, т.к. сжатие это нивелирует), и поэтому вносит значительный вклад в djvu, тем самым скрадывая другие разницы между 300 и 600.

Что-то я никак в толк не возьму - кому нужна эта грошовая экономия? Да хоть в 10 раз файл больше будет, размер это далеко не самый важный параметр для книги. Качетсво обработки и комфорт при чтении - вот главное. И ухудшать вдвое качество из-за каких-то надуманных соображений - глупость несусветная.
Книга либо нужна, либо нет и потратить лишнего траффика на 10р в худшем случае - это мелочь по сравнению с удобством чтения.

Alexx S

Цитата:

Что-то я никак в толк не возьму - кому нужна эта грошовая экономия?

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

Alexx S
Одни на Ferrari ездят, а для других и велосипед роскошь!
Я, например, некоторые книги выкладываю в двух разрешениях, чтобы человек имел свободу выбора - либо похуже, но по ТРИ, либо получше, но по ПЯТЬ.

shch_vg
Цитата:

либо похуже, но по ТРИ, либо получше, но по ПЯТЬ.

Может наоборот - пожуже, но по ПЯТЬ (книг), либо получше, но по ТРИ (книги) .

Предлагаю компромисс - хорошо делать книги в 600 дпи, и нет проблемс

В общем, еще раз:
В 95% случаев рекомендуется 300 Grey -> 600 BW
Есть случаи, когда приходится делать 600 Grey -> 600 BW
И есть случаи, когда вполне хватает 300 Grey -> 300 BW

Arcand, вот Вы, к примеру, не стали бы оцифровывать... плакат во всю стену с большим количеством текста в 300->600, правильно? Сделали бы 150->150, а то и еще меньше. Букварь какой-нибудь с буквами на полстраницы тоже не стали бы делать 300->600. Вполне себе нормально смотрится английский крупный шрифт при 300dpi. У меня у самого книг в 300dpi, по-моему, никогда не было (если только в самом начале 1-2), но я допускаю, что таковые могут быть, и читаться они будут нормально.

Помню, читал статьи разные по эргономике чтения. Так там самым высоким разрешением в предъявляемых сканах был 300dpi, который и назывался оптимальным. Хотя было это давно. Если вы можете различить в обработанных символах пиксели (в лупу), это еще не значит, что читатель проклянет вас - уверен, что во многих случаях он этого просто не заметит.

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

Как инструкция-то? Можно уже в шапку вносить, или еще что-нибудь исправить/прояснить?