404 - Unable to load website

Он слишком медленный, чтобы включить его по умолчанию, поэтому галочка по умолчанию выключена. Ранее уже поднимался вопрос об альтернативных быстрых алгоритмах масштабирования - мне они неизвестны, а других вариантов никто не предложил. Без этой галочки используется стандартное масштабирование из DjVuLibre, которое даёт результат, идентичный DjView; вполне возможно что и в DjVu-плагине картинка будет точно такая же.

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

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

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

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

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

About uCoz web-service

Community

Contacts

Legal information

Метод подклейки фона

Введение

Краткое описание метода

Пример работы алгоритма

Инструкция по примеру:

Проблема с WinDjView

Заключение