» WinDjView

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

Нельзя ли как-то исправить эту проблему - чтобы устанавливать этот флажок не требовалось?

Подробнее см. http://www.djvu-soft.narod.ru/scan/back_glue.htm

monday2000
Вы сами описали решение возникшей у Вас проблемы - включить настройку, которая применяет другой, более качественный, но и более медленный алгоритм масштабирования цветных картинок (антиалиасинг в данном случае - неправильный термин). Этот алгоритм слишком медленный, чтобы включить его по умолчанию, поэтому галочка по умолчанию выключена. В этом форуме уже поднимался вопрос об альтернативных быстрых алгоритмах масштабирования - мне они неизвестны, а других вариантов никто не предложил. Без этой галочки используется стандартное масштабирование из DjVuLibre, которое даёт результат, идентичный DjView; вполне возможно что и в плагине картинка будет точно такая же.

Добавлено:
Да, в вашем примере в DjView исходная и новая страницы будут выглядеть одинаково - так, как в WinDjView выглядит цветная страница без установленной галочки. Поэтому высказанные на Вашем сайте предположения безосновательны.

AndyZ

Цитата:

Да, в вашем примере в DjView исходная и новая страницы будут выглядеть одинаково - так, как в WinDjView выглядит цветная страница без установленной галочки.

Совершенно согласен с этим.

Цитата:

Поэтому высказанные на Вашем сайте предположения безосновательны.

Прошу прощения, это я несколько косноязычно там выразился. Я уже подправил ту статью (внизу, где про WinDjView) - чтобы выразить мысль точнее. Дело не в том, что WinDjview якобы "виноват" - а в том, что проявляется непонятная объективная проблема.

Интересно - в чём причина этой проблемы? В чём разница между "чёрно-белыми" и "цветными" DjVu-файлами в плане антиалиасинга? Неужели нет иного способа обойти проблему, кроме как применить доп. сглаживание?

Или же можно поставить вопрос иначе: почему "чёрно-белые" DjVu-файлы отрисовываются в WinDjView "чётче", чем "цветные"? Казалось бы, слой маски идентичен в обоих файлах - а вот сглаживается он почему-то по-разному. Какой-то парадокс.

Цитата:

почему "чёрно-белые" DjVu-файлы отрисовываются в WinDjView "чётче", чем "цветные"

Это очень просто - для чёрно-белых страниц всегда используется второй алгоритм, который более медленный, но даёт более хороший результат. Для чёрно-белых страниц он работает быстрее, чем для цветных, и его скорость приемлема для того, чтобы всегда использовать именно его. Ещё отмечу, что на стандартных масштабах (50,100,150,200% и др.) при разрешении документа 300/600 dpi, получается масштабирование в целое число раз, которое выполняется простым даунсэмплингом - это очень быстро, и результат выглядит хорошо.

AndyZ
Из сглаживания могу предложить такое:
Bilinear: http://www.djvu-soft.narod.ru/bookscanlib/018.htm
Bicubic: http://www.djvu-soft.narod.ru/bookscanlib/017.htm
В отличие от Вашего целочисленного алгоритма, позаимствованного из netpbm (и зависающего на больших зумах), а также в отличие от FreeImage'вских алгоритмов сглаживания эти алгоритмы являются однопроходными (а те - двухпроходные) - а значит, есть шанс, что они достаточно быстрые.

Однако мне всё равно непонятно: сглаживание - это когда из "колкого", но "чёткого" текста получается "мягкий" текст - с "размазанными" контурами. А тут всё наоборот - по-умолчанию текст имеет "размазанные" контуры, и нужно применять сглаживание, чтобы получить "чёткий" текст. Какое же это тогда "сглаживание"? Скорее наоборот - "резкость" (если по смыслу).

Сглаживание -- это переход от ломаных линий к более плавным за счет интерполяции. "Размазанность" в ч/б изображениях наблюдается из-за того, что контуры неровные.

Кстати, есть anti-aliasing-фильтры: http://en.wikipedia.org/wiki/Anti-aliasing , а есть reconstruction-фильтры: http://en.wikipedia.org/wiki/Reconstruction_filter (пример - nearest-neighbor, bilinear, bicubic).

Разница между ними мне пока непонятна.

То, что используется в WinDjView для сглаживания растровой картинки - это не anti-aliasing-фильтр - а reconstruction-фильтр. То же самое в СканКромсаторе - там для сглаживания применяются reconstruction-фильтры.

Может быть, разница между ними в том, что anti-aliasing-фильтры применяются только для векторных объектов (при их растеризации), а reconstruction-фильтры применяются только для растровых объектов? Какая-то неясность в терминологии.

Термины "сглаживание" и "антиалиасинг" относятся к ситуациям, когда нужно растеризовать векторную графику и добиться, чтобы контуры имели правильный вид. Здесь же никакой векторной графики нет: есть картинка большого размера (например, 2480x3508 пикселей - a4, 300 dpi), и производится её масштабирование до другого размера (например, 1024x1448 - fullscreen, fit width). В исходной картинке текст чёткий (он находится в битональном слое), а в отмасштабированной - зависит от алгоритма. "Размазанность" в стандартном масштабировании из DjVuLibre возникает из-за того, что оно производится в два этапа - сначала картника даунсэмплится в целое число раз (в моём примере - до 1240x1754), а затем уже применяется быстрый билинейный скейлинг. Это значительно уменьшает время работы. Если не делать сначала даунсэмплинг, то результат билинейного скейлинга и алгоритма из netpbm почти одинаков, но последний немного быстрее. Бикубический скейлинг медленнее, чем билинейный, поэтому я сомневаюсь, что он может оказаться быстрее чем алгоритм из netpbm.

Добавлено:

Цитата:

используется в WinDjView для сглаживания растровой картинки

Нет никакого сглаживания растровой картинки

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

foo
Как я понял, он память жрёт немеренно и на больших зумах зависает полностью - куда он годится.
AndyZ
Нельзя ли сделать такой алгоритм на Ассемблере - ради быстроты?

Добавлено:

Цитата:

Нет никакого сглаживания растровой картинки

Мне кажется, что по-русски это называется "интерполяционные фильтры". Хотя сущность одинаковая с антиалиасингом - добавление пикселей промежуточных цветов между чёрных зубчиков контуров объектов. Просто, получается, что если объекты - векторные - то это называется "антиалиасинг", а если растровые - то "интерполяция".

Кстати, интерполяция не обязательно подразумевает перемасштабирование - можно её делать и без него.

Есть ещё один туманный термин - Smoothing. ИМХО это не что иное, как "размытие" - см. http://www.ph.tn.tudelft.nl/Courses/FIP/noframes/fip-Smoothin.html

Интересно, чем же отличаются по смыслу Smoothing и Blurring?

monday2000
В WinDjView алгоритм из netpnm используется только при уменьшении картинки. Для увеличения применяется fast bilinear scaling из djvulibre. На больших зумах нужно много памяти для любого алгоритма: например, если у Вас страница A4 отсканированная в 300 dpi и Вы её ещё в 2 раза увеличиваете (масштаб 600% в WinDjView), то для хранения битмапа нужно 100 мегабайт памяти. Понятно, что можно хранить только части картинки, предназначенные для вывода на экран, но тогда процедура кэширования становится сложней, и на самом деле мне просто не хочется делать такую оптимизацию - оперативной памяти сейчас устанавливают всё больше и больше, поэтому это не так актуально. К тому же высокие зумы не так часто нужны при чтении книг.

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

AndyZ

Цитата:

Про реализацию на ассемблере - не так просто написать код, который будет работать быстрее, чем тот, который генерируют современные оптимизирующие компиляторы.

Почему же тогда, например, в GIMP то и дело встречаешь один и тот же алгоритм, реализованный в 2 версиях: "как обычно" и в MMX-ассемблерном виде? Да и в СК та же картина.

P.S. Небольшой оффтоп.

Цитата:

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

Вот это я и называю "графический движок" - пресловутый камень преткновения на пути массового создания народом альтернатив СК.

Цитата:

и на самом деле мне просто не хочется делать такую оптимизацию

Ага, вот и всем остальным точно также "не хочется" - потому что
Цитата:

процедура кэширования становится сложней

И именно поэтому нет полноценных альтернатив СК (СТ пока не в счёт - там нет скроллбаров).
Почему-то MS не сделал некий готовый MFC-класс с подобной функциональностью ("графический движок") - наверное, им тоже "сложно".

А почему программа печатает по одной странице, а не весь документ?

Цитата:

то для хранения битмапа нужно 100 мегабайт памяти

а кто-нибудь может подсказать *.djvu
который при максимальном масштабе потреблял бы больше 1ГБ, желетельно 1.5ГБ памяти.

AndyZ
Очень хотелось бы попросить автора внести новый режим масштабирования - по границам блока текста (идеально - с регулировкой полей по аналогии с СК). Возможно, это не составит большого труда - ведь можно прочитать Coordinate Map?

Просто решил использовать Eee PC для чтения книг - в целом очень удобно, но если в книге/статье большие поля, начинаются проблемы с центрированием/масштабированием страниц при листании (если не масштабировать, буквы слишком маленькие).

В WinDjView есть возможность менять расположение станиц?
Зачастую случается, что страница 19 слева, а 20-я справа. Хотя в бумажных книгах наоборот.

mjfuth
вы имеете в виду Вид -> Расположение -> Первая страница отдельно?

Как насчет сагитировать Андрея выставить свою программу на SF Commnity Awards? Поддержим?

Hiken

Цитата:

Поддержим?

Безусловно. В WinDjView я всегда видел маленький программный шедевр
Причем, наверное, лишь в нем одном - дело не в кол-ве строк кода, а в завершенности идеи, в глубоком знании автором всех вопросов, касающихся юзабилити, эргономики чтения, в заботе о человеке читающем... Да, именно за это я и люблю программку, пролистнувшую перед моими глазами тысячи страниц - за то, что она... не эгоцентрична. Открыта не только другим программистам, но и очевидна для каждого отдельного пользователя.
Спасибо, AndyZ

да, программка действительно офигенная

Все вот ругают MFC - а WinDjView убедительно демонстрирует, что MFC не так уж и плох.

Цитата:

вы имеете в виду Вид -> Расположение -> Первая страница отдельно?

Совершенно в дырочку! Спасибо NME
Я ещё засомневался сперва, должно же быть!

monday2000
Технологии это, конечно, важно. Но значительнее то, что получается в итоге - продукт. Так что без разницы: MFC это, Delphi или вообще чистый WinAPI.

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

MFC хорош как объектная надстройка над WinAPI, но многие вещи там приходится перекрывать и переписывать - в коде программы полно комментариев "// From MFC", где библиотечный код исправлен и дополнен. Хотя я думаю, что это свойство всех библиотек - всё надо дорабатывать напильником, идеальной пока нет В MFC программа писалась исключительно из-за того, что предыдущие пару лет я имел дело с этой библиотекой по работе.

Насчёт иконок - мне совершенно лень их искать и подбирать. Если кто-то пришлёт готовый набор, который мне понравится - то я готов их использовать.

ghosty
Цитата:

новый режим масштабирования - по границам блока текста

Идея разумная.

AndyZ
1. Cуществует неофициальная локализация вашей программы на испанский язык, правда для версии 0.5. Может вас попросить попробовать связаться с автором или разместить исходники перевода на cvs, для популяризации?
2. Сейчас история «вперед - назад» - общая для всех открытых документов (т.е. если читать одну книгу, потом другую, история будет перескакивать между ними). Еще не очень удобно, что история игнорирует прокрутку страниц (выполняемую любым образом - то ли колесиком мыши, то ли дерганием полосы прокрутки и т.п. ).

Цитата:

новый режим масштабирования - по границам блока текста

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

Вот и CuneiForm написан на MFC и посредством MS Visual C++ 6.0. А всем, видите ли, подавай теперь Qt или что-то такое.

monday2000
wxWidgets, ага

Вы так говорите, как будто кроссплатформенность -- это плохо. Кроме того, MFC по удобству использования сливала даже Borland VCL в свое время, т.к. значительно чаще приходилось спускаться на уровень API и что-то допиливать самому.

monday2000, Hiken, Griefin
Не в этой ветке, плиз.