4lex4
Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору NME, все верно. Но прошли те врена ностальгии по JPEG2000 как замене JPEG. Вот смотрите: http://xooyoozoo.github.io/yolo-octo-bugfixes/#fruits&jpg=s&jp2=s При том же размере BPG дает более качественное изображение, чем даже JPEG2000, и уж тем более устаревшего JPEG. Сравните качество BPG, WebP, JPEG2000 и JPEG при разных степенях сжатия. У JPEG2000 преимущество - у него есть режим сжатия без потерь, у IW44 нет, но в данном случае (для сохранения книг и документов) оно в принципе и не нужно. Но разговор был о том, что DjVu обвинялся в порче и размытии изображений - а это неверно, при том же размере IW44 дает почти то же качество, что и PDF с JPEG2000, и лучшее, чем PDF с JPEG. Не нужно юзать стандартные профили DjVu, как делают неопытные пользователи - они устарели, современные мониторы требуют картинок в 300 DPI и с более высоким качеством сжатия - для качественных изданий и документов (для некачественных книг можно и 150), а не 100 DPI, как лет 10 назад. Размер для книг в 5Мб уже не имеет такого принципиального значения, как 10 лет назад, сейчас и 30 нормально. DjVu следует использовать исключительно для сохранения книг и документов в растровом формате, тут он обычно эффективнее, а PDF во всем остальном, ибо второй универсален, а первый нет. И не надо юзать JPEG, если есть лучший JPEG2000. Например, многие сохраняют журналы в обычный PDF, сжимая JPEG, получаем размытый текст и замусоренный фон из-за артефактов. Ведь можно сделать то же самое и с JPEG2000, который не дает таких артефактов, а при том же размере качество выше. Цитата: это произойдет в том случае, если скорость чтения данных с носителя меньше скорости "распаковки" сжатого изображения.. имхо.. всё зависит от железа.. | Все верно, но не только. От скорости алгоритма распаковки тоже зависит. Вообще имеет смысл сжимать не только изображения, но даже исполняемые файлы. Операция считывания с жесткого диска занимает в разы больше времени, чем распаковка более менее современным процессором в памяти. Вот цитата из вики про UPX: Цитата: Самое весомое и неоспоримое преимущество — ускорение считывания и запуск сжатых файлов с носителей информации, а также высвобождение дополнительного свободного пространства на внешних накопителях. К сожалению, на сегодняшний день все внешние накопители информации по-прежнему остаются самыми медленными узлами современных вычислительных систем, «тормозящими» быстродействие системы в целом, как и на заре вычислительных технологий. Поэтому нельзя не оценить эффект, возникающий при системном применении упаковщиков исполняемых файлов, таких как UPX. Вычислительная система затрачивает значительно меньше времени на считывание и распаковку сжатого файла в оперативной памяти, нежели на простое считывание этого же неупакованного файла (при считывании с внешнего накопителя время, затрачиваемое на операцию, исчисляется миллисекундами, а время на обработку данных в оперативной памяти — микро- и наносекундами). | Я лично проверял работу несжатых и сжатых LZW цветных тиффах 600 DPI. (HDD, мобильный Core i5) Пакетная обработка (одно и тоже простое действие, одни и те же изображения) в фотошопе несжатых изображений заняла более 2х часов, а сжатых LZW 20 минут. Именно операция простого открытия замедляла работу в первом случае, и жесткий диск вертело практически непрерывно. Вы легко можете это проверить. Берете цветной скан 300DPI - апсемплите допустим до 1200 DPI, один сохраняете несжатым, другой сжимаете LZW или ZIP. И смотрите, сколько времени будет открываться первый и второй. Можно накопировать каждый по 10 копий, и открывать разом, чтоб увеличить эффект и снизить погрешность измерений. Это незаметно, если файл маленький, допустим 300 DPI. Но при пакетной обработке, когда таких файлов много, разница в скорости открытия станет заметна и тут. Не забывать, что все зависит от железа: на очень старых процессорах разницы может и не быть, а то и наоборот. | Всего записей: 346 | Зарегистр. 27-01-2016 | Отправлено: 13:57 16-06-2016 | Исправлено: 4lex4, 20:34 16-06-2016 |
|