Комментарии 45
Проект полезный, обязательно буду использовать на сайтах, где более или менее серьезная нагрузка и хочется оптимизировать скорость загрузки страницы у пользователя / нагрузку на сервер.
Что касаемо повсеместного использования, то тут штука довольно спорная. Мне почему-то кажется, что бОльшая часть jpg на сайтах закодированы со стандартными настройками кодирования photoshop/GIMP (довольно интересно было бы увидеть какое-нибудь исследование на эту тему). Соответственно, для того, что бы хоть как-то распространить данный формат, нужно, что бы компании его внедрили к себе в редакторы как используемый по умолчанию.
А вот тут, боюсь, история будет будет как с APNG.
Что касаемо повсеместного использования, то тут штука довольно спорная. Мне почему-то кажется, что бОльшая часть jpg на сайтах закодированы со стандартными настройками кодирования photoshop/GIMP (довольно интересно было бы увидеть какое-нибудь исследование на эту тему). Соответственно, для того, что бы хоть как-то распространить данный формат, нужно, что бы компании его внедрили к себе в редакторы как используемый по умолчанию.
А вот тут, боюсь, история будет будет как с APNG.
На самом деле большинство изображений все-таки генерируются на сервере из исходных загружаемых пользователем изображений: во-первых так работают практически все CMS, во-вторых так работают абсолютно все веб-сервисы.
Поэтому достаточно «пропихнуть» библиотеку в стандартную поставку linux.
Поэтому достаточно «пропихнуть» библиотеку в стандартную поставку linux.
А вот тут, боюсь, история будет будет как с APNG.
Так с ним все печально из-за того, что он по умолчанию не везде работает. Как и JPEG2000, о котором в статье говорится. Firefox не поддерживает JPEG2000 нативно из-за патентных ограничений, если я все правильно помню, о чем тут говорить можно.
Из всего pipeline JPEG2000 под патенты подпадает, емнип, только стадия арифметического кодера. Поменять ее можно (алгоритмов там много), но это нужно всем основным сторонам договориться о поддержке альтернативной реализации.
Основной же массе, видимо, проще пилить классический JPEG.
Основной же массе, видимо, проще пилить классический JPEG.
Так с ним все печально из-за того, что он по умолчанию не везде работает.
А по умолчанию он не везде работает, потому что долбаные Мозилла и Гугл упёрлись рогом и каждый продвигает свой формат, забивая на поддержку формата, продвигаемого конкурентом. Как же осточертели эти многолетние бодания APNG vs. WEBP и иже с ними! Нет чтобы сделать всем хорошо и поддержать оба формата, чтобы палитровый GIF забыть как ночной кошмар в обозримом будущем. Но нет, они будут десятилетиями спорить, какой формат хуже.
Круто, но хочется услышать технические подробности: что конкретно улучшили, как добились совместимости и т.д.
Прогнал все наши джпеги в проекте через эту утилиту. Из почти 144 тысяч удалось соптимизировать 20 файлов, из них почти все — только на 1—7% и пять — 30—40.
Для остальных файлы не уменьшились или увеличились?
Стоит заметить, что это не оптимизатор джипегов, а кодер. Вполне возможно, что более заметные результаты получаться, если сжимать несжатые картинки. Ну и к тому же, они лишь анонсировали начало его разработки, так что логично что сделали они мало чего.
Осталось только добавить webkitjpeg, msjpeg и наступит счастье видимо.
В итоге будет как сейчас с видео/ аудио где каждый поддерживает то что он хочет и поэтому надо держать целый зоопарк файлов.
Из нужного реально не хватает APNG (для остальных браузеров), вот где реальная потребность, а не в экономии пары килобайт.
В итоге будет как сейчас с видео/ аудио где каждый поддерживает то что он хочет и поэтому надо держать целый зоопарк файлов.
Из нужного реально не хватает APNG (для остальных браузеров), вот где реальная потребность, а не в экономии пары килобайт.
Вы статью не читали что ли? Это не новый формат, это просто кодек, который умеет оптимизировать JPEG лучше, чем существующие. Читаться такой JPEG будет любым стандартным кодеком.
Знаем мы все эти стандартные кодеки и их поддержку — проходили. Думаете стандартный jpeg все полностью поддерживают? Тогда посмотрите как отображается jpeg с встроенным цветовым профилем в разных браузерах.
Еще можно за пример взять музыкальный формат Flac, к нему так же приблуды для еще большей компрессии, например Flakk. Только вот беда, большинство железных плееров такой формат уже не понимают и не воспроизводят.
Еще можно за пример взять музыкальный формат Flac, к нему так же приблуды для еще большей компрессии, например Flakk. Только вот беда, большинство железных плееров такой формат уже не понимают и не воспроизводят.
Мы тоже проходили. Некоторые глюки я описывал в книге «Реактивные веб-сайты». И что теперь? Ничего не менять?
не очень эффективно. Логично перейти на более современные алгоритмы (например, JPEG2000 с вейвлет-преобразованием или свободный WebP), и такая тема неоднократно обсуждалась.
Две недели назад я решил запариться, в каком же формате хранить документы на сервере. Это cканы паспортов. Тестировал фотошопом, сохраняя в jpg2000 webp (через плагин) и через for web jpg подгоняя все под один размер +-3кб.
Итог: если файл содержит нужную информацию в разных частотных областях (слабоконтрасная фотография + очень контрастный текст + контрасные линии гильоша которые не нужны) остаемся на jpg.
Jpg2000 феноменально фильтрует высокочастотные области, что проявляется в виде блюра. Низко контрастное изображение лица человека превратилось в мыло.
webp аналогично, у него свои артефакты (как от пастеризации) который аналогично мылит изображение лица.
Jpg при своих квадратных артефактах уверенно оставляет детали по всей зоне. В этом случае можно даже применить фильтр для восстановления ( больше всего нравится этот www.vicman.net/jpegenhancer/ ) и получается что… jpg уверенно обходит конкурентов при хранении данного типа документов, учитывая что конкуренты в принципе не поддаются пост обработке каким то алгоритмом для уменьшения своих артефактов.
WebP остается примерно таким же размером как и jpg, но при условии его слабой распространенности от него в моем случае будет только больше геморроя.
Вобщем то, ничего не обычного не случилось. Вейвлет так и заявляет, что он кодирует исключая высокочастотные области т.е адаптивный к изображению. (Много деталей — меньше сжатие, меньше деталей — больше сжатие) Но как быть с тем что информация важная в разных областях (перепад яркости листа с текстом)? остается старый добрый jpg.
WebP остается примерно таким же размером как и jpg
Это вы сравнивали с тем же параметром качества? А что с визуальным качеством?
Недавно думал над задачей передачи миниатюр на мобильные устройства. Поскольку мобильный интернет в некоторых регионах еле дотягивает до диалапа, то рассматриваются варианты кодирования с параметром качества JPEG вплоть до нулевого. Так вот на таких уровнях при одинаковых размерах webp показывает себя просто превосходно.
Я сравнивал не с параметрами качества, а визуально при одинаковом (примерно плюс минус 3-4кб) размере.
Вышло так, что на паспорте есть низкоконтрасные фотографии, которые убивались сильно и webp и jpg2000. А фотографии очень важная часть изображения, но кодеком она так не воспринимается. А jpg равномерно сжимает все части изображения так что там хоть и появляются блоки, но остается куча деталей.
Не сомневаюсь, что на обычных фотографиях где изображение не делиться на логические блоки как в документах каких нибудь, все будет по другому.
Вот еще раз сделал тест на обычных фотках jpg2000, webp, jpg2000 — все файлы 50kb (плюс минус 1kb)
Вышло так, что на паспорте есть низкоконтрасные фотографии, которые убивались сильно и webp и jpg2000. А фотографии очень важная часть изображения, но кодеком она так не воспринимается. А jpg равномерно сжимает все части изображения так что там хоть и появляются блоки, но остается куча деталей.
Не сомневаюсь, что на обычных фотографиях где изображение не делиться на логические блоки как в документах каких нибудь, все будет по другому.
Вот еще раз сделал тест на обычных фотках jpg2000, webp, jpg2000 — все файлы 50kb (плюс минус 1kb)
Скрытый текст
Попробовал JPEGmini — облегчил папку с пятью тысячами фоток в три с половиной раза.
платное не одобряется бро :)
Для мака есть бесплатный и отличный вариант imageoptim.com/
Написал для вас кряк для Windows версии. Исходник.
Если лень или нет возможности собирать, то устанавливаете программу, находите JPEGmini.exe поиском (%APPDATA%/Local/Apps/2.0/...), распаковываете архив в ту папку, запускаете. При запуске выберите триал, на основном экране должно быть число 99, килочество конвертаций не ограничено.
Если лень или нет возможности собирать, то устанавливаете программу, находите JPEGmini.exe поиском (%APPDATA%/Local/Apps/2.0/...), распаковываете архив в ту папку, запускаете. При запуске выберите триал, на основном экране должно быть число 99, килочество конвертаций не ограничено.
НЛО прилетело и опубликовало эту надпись здесь
Почему-то мне кажется, что с этим проектом произойдёт тоже, что и с ОгнеЛисом — сначала это будет популярно, а потом «вымрет»: появятся лучшие аналоги, и этим никто не будет пользоваться.
Эти слоупоки в Mozilla до сих пор поддержку Jpeg с Arithmetic кодированием не добавят, которое сразу даёт -20-30% выигрыша, несмотря на кончившиеся несколько лет назад патенты ( bugzilla.mozilla.org/show_bug.cgi?id=680385, Chrome тоже не лучше). Не говоря уже о современных h265 still image, который уделывает этот древний jpeg2000 ещё на 30%
h265 still image, который уделывает этот древний jpeg2000
Вы это сами только что придумали или может быть где-то есть ссылка?
en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Main_Still_Picture
Расшифровываю: по PSNR на 60% лучше Jpeg (то есть Jpeg будет весить 3 раза больше) и на 20% лучше Jpeg2000. По визуальной оценке на 43% лучше Jpeg (то есть размер почти в 2 раза меньше) и на 30% лучше Jpeg2000, на 31% лучше WebP.
Расшифровываю: по PSNR на 60% лучше Jpeg (то есть Jpeg будет весить 3 раза больше) и на 20% лучше Jpeg2000. По визуальной оценке на 43% лучше Jpeg (то есть размер почти в 2 раза меньше) и на 30% лучше Jpeg2000, на 31% лучше WebP.
Я так и думал, что контора JCT-VC здесь приложилась. Хотя с этим документом я не знаком, так что спасибо за ссылку. Дело в том, что у них в отчете не указанны параметры тестирования Jpeg2000. Я изучал один из ихних предыдущих отчетов касательно H.264 — JCTVC-L0380. Там налицо нечестный выбор параметров для Jpeg2000. H.264 выкручивают на максимум, а Jpeg2000 ставят по умолчанию. В вашей ссылке на Википедии параметры сжатия не указанны вообще. Ни о какой объективности результатов не может быть и речи.
Jpeg с Arithmetic кодированием
Читай другой формат, раз декодер требуется обновленный. Раньше тупил почему на телефнах старых не читаются jpg, не поддерживали прогрессив.
Прогоняю свои фотографии через jpegoptim, в среднем удаётся уменьшить размер на 10% без потери качества, что довольно неплохо. Если у ребят из Mozilla получится больше, то это хорошо.
Кроме того, оптимизировать размер jpeg-файлов (без потери качества) можно при помощи jpegtran из пакета libjpeg. Как-то так:
Кроме того, оптимизировать размер jpeg-файлов (без потери качества) можно при помощи jpegtran из пакета libjpeg. Как-то так:
jpegtran -perfect -copy all -progressive -optimize -outfile temp.jpegЗарегистрируйтесь на Хабре, чтобы оставить комментарий
Mozilla оптимизирует формат JPEG