Комментарии 35
Справедливости ради, форматов сильно больше.
WebP… гораздо лучше поддерживается браузерами и имеет более светлое будущее.Где же лучше-то? Ровно один браузер его понимает — Хром («Опера» сейчас тот же движок содержит).
Кое что в пользу JPG
Не забывайте, что описанные вами форматы основаны на вейвлет сжатии. Они адаптивны.
Считается, что информацию можно удалять в низкочастотных областях сильнее. Однако на практике, когда вы начинаете работать с документами, к примеру хранить какие нибудь сканы документов вроде паспортов, вы начинаете удивляться, что адаптивность сильно мешает.
На паспорте изображение фотографии слабоконстрасное само по себе по отношению к остальному яркому фону паспорта и webp просто берет и делает из фотографии несколько перетянутых между собой градиентов.
Тогда как jpg, необладая адаптивностью, равномерно сжимает картину. Да появляются квадраты, которые, кстати говоря, убираются кучей софта. То есть JPG имеет в запасах чуть чуть еще качества при необходимости.
А вообще, обратная совместимость угрохает любую новую технологию. НЕзря же мозилла там что то мутила с улучшенным кодеком JPG.
Считается, что информацию можно удалять в низкочастотных областях сильнее. Однако на практике, когда вы начинаете работать с документами, к примеру хранить какие нибудь сканы документов вроде паспортов, вы начинаете удивляться, что адаптивность сильно мешает.
На паспорте изображение фотографии слабоконстрасное само по себе по отношению к остальному яркому фону паспорта и webp просто берет и делает из фотографии несколько перетянутых между собой градиентов.
Тогда как jpg, необладая адаптивностью, равномерно сжимает картину. Да появляются квадраты, которые, кстати говоря, убираются кучей софта. То есть JPG имеет в запасах чуть чуть еще качества при необходимости.
А вообще, обратная совместимость угрохает любую новую технологию. НЕзря же мозилла там что то мутила с улучшенным кодеком JPG.
Попробуйте провести тесты с этим. Мне кажется это более перспективная технология.
Формат bpg (HEVC)
xooyoozoo.github.io/yolo-octo-bugfixes/#fruits&jpg=s&bpg=s
Здесь уже сборка от мозиллы для тестов github.com/bdaehlie/web_image_formats
bpg выглядит впечатляюще! Но тут с патентами та же история, что и с jpeg2000.
Может, у меня за много лет вглядывания в джипеги уже мозг как-то сам обучился, но на качестве tiny мне обычный совковый джипег нравится больше, чем все остальные. Да, он порождает квадраты, но по крайней мере я вижу, где детали выкинуты, все же остальные ребята выдают замыленную картинку.
Мы с вами точно одно и то же видим? Качество Tiny:
Вам больше нравится JPEG? Вы на каком расстоянии от монитора находитесь? А какой размер экрана и разрешение?
Вам больше нравится JPEG? Вы на каком расстоянии от монитора находитесь? А какой размер экрана и разрешение?
Дело говорите, BPG мылит, его работа напоминает работу фильтра от шума.
e-ivanov.ru/blog/2015/05/11/bpg
e-ivanov.ru/blog/2015/05/11/bpg
А jpg квадратит. Вы не на арфетакты смотрите, а на количество мелких деталей, которое удалось сохранить при одном размере. Какие вы ожидали увидеть артфакты. треугольные?) Конечно же новые форматы будут умными и будут восстанавливать все в чем нашли закономерность. То что имеет градиент на изображении сохраняется градиентом. И Перестаньте уж Лену эту использовать. Пленка тех лет с никакующей резкостью. На Лене тестировать кодеки сжатия не объективно абсолютно. Она мыло изначально.
WebP не использует вейвлетов, он такой же блочный как и JPEG. Но там есть несколько других улучшений, которые и дают лучшее сжатие при том же качестве.
Да, виноват. Адаптивщину в голове держал, а она у меня с вейвлетами связана.
habrahabr.ru/company/io/blog/258545/#comment_8431507
habrahabr.ru/company/io/blog/258545/#comment_8431507
+---------+--------+--------------+---------------+
| | WebP | JPEG-XR | JPEG 2000 |
+---------+---------+--------------+--------------+
| Firefox | - | - | - |
+---------+---------+-------------+----------------+
| Vivaldi | + | - | - (?) |
+---------+---------+---------+-----------+-------+
Немного посмотрел, что с поддержкой:
JPEG XR — «Открытые браузеры (например, Mozilla Firefox) являются лицензионно несовместимыми c JPEG XR. Поддержка возможна только на основе плагина, но он будет работать исключительно в Windows;» (вики)
JPEG 2000 — «всё равно не может соответствовать Debian Free Software Guidelines (тест на свободность программного обеспечения). Это может затруднить адаптацию JPEG 2000 к требованиям веба, так как это исключит свободные веб-браузеры (особо отметим браузеры, основанные на Gecko)» (вики)
«Существует также порт библиотеки libwebp под названием libwebpjs/libwebpas на JavaScript и ActionScript, позволяющий использовать WebP во всех популярных браузерах (поддержка IE6+ осуществляется с помощью дополнительного модуля Adobe Flash)» (вики)
Я так понимаю, проблема с лицензиями. Все тянут одеяло на себя, изобретая свои патентованные форматы.
| | WebP | JPEG-XR | JPEG 2000 |
+---------+---------+--------------+--------------+
| Firefox | - | - | - |
+---------+---------+-------------+----------------+
| Vivaldi | + | - | - (?) |
+---------+---------+---------+-----------+-------+
Немного посмотрел, что с поддержкой:
JPEG XR — «Открытые браузеры (например, Mozilla Firefox) являются лицензионно несовместимыми c JPEG XR. Поддержка возможна только на основе плагина, но он будет работать исключительно в Windows;» (вики)
JPEG 2000 — «всё равно не может соответствовать Debian Free Software Guidelines (тест на свободность программного обеспечения). Это может затруднить адаптацию JPEG 2000 к требованиям веба, так как это исключит свободные веб-браузеры (особо отметим браузеры, основанные на Gecko)» (вики)
«Существует также порт библиотеки libwebp под названием libwebpjs/libwebpas на JavaScript и ActionScript, позволяющий использовать WebP во всех популярных браузерах (поддержка IE6+ осуществляется с помощью дополнительного модуля Adobe Flash)» (вики)
Я так понимаю, проблема с лицензиями. Все тянут одеяло на себя, изобретая свои патентованные форматы.
Объективно WebP практически во всём лучше остальных форматов, имея вагон возможностей (анимация, альфа-прозрачность с потерями, и т. д). И при этом имеет свободную лицензию. Так почему же его не хотят встроить в другие браузеры? Ответ прост — боятся слишком большого влияния гугла на этот формат.
Чем опасно «слишком большое влияние»? И лицензия же позволяет сделать форк формата и жить без влияния гугла, если оно станет опасным.
Разработчики Firefox таки снова думают над этим bugzilla.mozilla.org/show_bug.cgi?id=856375
Да с мозиллой вообще невозможно разговаривать — они никогда не прислушиваются к мнению пользователей. Ситуация с WebP, когда баги закрывают, закрывают возможность комментирования, отказ добавить уже существующие патчи, используя различные «отмазки», показывает истинную сущность этих разработчиков. При этом воплощать механизм DRM они помчались вприпрыжку, да и механизм «Hello», завязанный на Telefonica тоже продвигают с энтузиазмом.
почему JPEG 2000, JPEG-XR и WebP все еще пасут задних
Уверяю вас, что новые форматы «все еще пасут задних» вовсе не из-за того, что они недостаточно совершенны.
Провёл эксперимент. Взял пару фотоальбомов (jpg) и пережал в JPEG2000
качество 100/1000 (визуальных изменений не обнаружено)
Фотки с Finepix HS25: новый размер в среднем 0.8 старого
Фотки с PowerShot SX120: новый размер в среднем 1.25 старого
качество 70/1000 (визуальных изменений не обнаружено)
Фотки с Finepix HS25: новый размер в среднем 0.6 старого
Фотки с PowerShot SX120: новый размер в среднем 0.9 старого
Время открытия файла jpg — почти мгновенно
Время открытия файла jp2 — от 4 до 6 секунд
Прцессор i5, софт — FastStone 5.3
Мой вывод — jpeg2k для фотоальбомов не взлетит. Открывать фотку по 5 секунд — это не комильфо.
качество 100/1000 (визуальных изменений не обнаружено)
Фотки с Finepix HS25: новый размер в среднем 0.8 старого
Фотки с PowerShot SX120: новый размер в среднем 1.25 старого
качество 70/1000 (визуальных изменений не обнаружено)
Фотки с Finepix HS25: новый размер в среднем 0.6 старого
Фотки с PowerShot SX120: новый размер в среднем 0.9 старого
Время открытия файла jpg — почти мгновенно
Время открытия файла jp2 — от 4 до 6 секунд
Прцессор i5, софт — FastStone 5.3
Мой вывод — jpeg2k для фотоальбомов не взлетит. Открывать фотку по 5 секунд — это не комильфо.
А я все жалею о APNG, который поддерживает Сафари, Фаерфокс и поддерживала классическая Опера, но Гугл не принял, чтобы свой WebP протолкнуть :(
Насчет кто жмет лучше… На фрилансерском сайте случайно обнаружил, что люди пережимают JPEG-и на сервисе kraken.io: как я понял кто-то придумал что делать с кучами видеокарт, оставшихся без дела после майнинга, разработал умное сжатие в рамках обычного JPEG, и теперь продает это как сервис. Кто-нибудь сталкивался?
Экспериментировал с методами вейвлет анализа изображения.
Мне не попадались открытые реализации JPEG2000, которые нормально бы работали с Region of Interest Coding. Хотя формат этот фомат компрессии значительно лучше даже «из коробки». Но коммерческий энкодер покупать только ради экспериментов не хочется.
Нормальная поддержка и автоматический алгоритм генерации такой маски позволил бы еще больше улучшить субъективное качество сжатия при том же битрейте.
Мне не попадались открытые реализации JPEG2000, которые нормально бы работали с Region of Interest Coding. Хотя формат этот фомат компрессии значительно лучше даже «из коробки». Но коммерческий энкодер покупать только ради экспериментов не хочется.
Нормальная поддержка и автоматический алгоритм генерации такой маски позволил бы еще больше улучшить субъективное качество сжатия при том же битрейте.
НЛО прилетело и опубликовало эту надпись здесь
Ну позвольте. Почему это трудно добавлять алгоритму адаптивность в зоне перепада яркости? Этож раз плюнуть.
Сделать маску, по ней уже сжимать.
dasl.mem.drexel.edu/alumni/bGreen/www.pages.drexel.edu/_weg22/can_tut.html
Я, конечно, допускаю свою полную глупость, но по мне игры с адаптивным jpg на моей памяти в программах были абсолютно бесполезны. Автоматических программ я не знал, а ручные ну толку от них было то по факту кроме обработки пары фоток. Все игры с пастеризация нужны в каких то уникальных случаях. На потоке если что бабахнет не то… то уж не вернешся
Сделать маску, по ней уже сжимать.
dasl.mem.drexel.edu/alumni/bGreen/www.pages.drexel.edu/_weg22/can_tut.html
Я, конечно, допускаю свою полную глупость, но по мне игры с адаптивным jpg на моей памяти в программах были абсолютно бесполезны. Автоматических программ я не знал, а ручные ну толку от них было то по факту кроме обработки пары фоток. Все игры с пастеризация нужны в каких то уникальных случаях. На потоке если что бабахнет не то… то уж не вернешся
Может быть я чего-то не понимаю, но сравнивать путем пережимания JPEG в один из этих форматов неправильно. Нужно сравнивать сжатие оригинального loseless изображения в JPEG сотоварищи.
И метрику надо вводить — оценить попиксельную разность, хотя она не всегда коррелирует с психовизуальным восприятием.
Из полезного в данном посте только знания о совместимости и о поддержке.
И метрику надо вводить — оценить попиксельную разность, хотя она не всегда коррелирует с психовизуальным восприятием.
Из полезного в данном посте только знания о совместимости и о поддержке.
Странно что гугл даже в Google Maps не поддерживает Webp для Chrome и мобильных приложений, а ведь это у одно из самых ресурсоёмких приложений с картинками. Всем было бы приятно, если бы карты потребяли меньше трафика, а спутниковый кэш Google Maps весил бы меньше. Даже 3D модели в Google Earth можно было бы ускорить, но тут проблема — в Sketchup используют только Jpeg, а дополнительное пережатие в Webp вредно для качества (пока не изобретут lossless пережатие).
А вообще жаль, что никто не вводит поддержку хотя бы арифместического кодирования в jpeg, которое позволяет lossless пережать jpg и получить 20-30% снижение размера. Патенты на это кончились уже несколько лет назад.
А вообще жаль, что никто не вводит поддержку хотя бы арифместического кодирования в jpeg, которое позволяет lossless пережать jpg и получить 20-30% снижение размера. Патенты на это кончились уже несколько лет назад.
Мы с вами встречаемся по вопросу арифметического кодирования в jpg регулярно)).
Вы почему то считаете, что если его включить, то никто ничего не заметит, а станет все быстрее загружаться. :-)
jpeg + арифмитическое кодирование = абсолютно новый формат изображения, который к jpeg не имеет никакого отношения, поскольку такие файлы мало где открываются даже сейчас.
Это как сжимать jpg каким нибудь фрактальным архиватором, переименовывать выходной файл обратно в jpg и ругаться, чтож дурни никак не догадаются включить поддержку в jpg фрактальный алгоритм сжатия. Вот бы зажили.
Я думаю, что это просто уже малоактуально. Если делать новый формат то делать его новым.
Вы почему то считаете, что если его включить, то никто ничего не заметит, а станет все быстрее загружаться. :-)
jpeg + арифмитическое кодирование = абсолютно новый формат изображения, который к jpeg не имеет никакого отношения, поскольку такие файлы мало где открываются даже сейчас.
Это как сжимать jpg каким нибудь фрактальным архиватором, переименовывать выходной файл обратно в jpg и ругаться, чтож дурни никак не догадаются включить поддержку в jpg фрактальный алгоритм сжатия. Вот бы зажили.
Я думаю, что это просто уже малоактуально. Если делать новый формат то делать его новым.
Ну так бегут года, решение лежит на поверхности, но воз и ныне там :)
Арифметическое кодирование в Jpeg — это часть стандарта Jpeg, а не новый формат, существует множество лет, и единственное ограничение раньше было в патентах. Причём перевод из обычного Jpeg в арифметический возможен полностью lossless, без потерь, так как пережимаются только таблицы квантизации из Huffman в Arithmetic. Перевод же в любой другой новый формат — webp, jpeg2000, hevc/bpg — это всегда полное пережатие с потерей качества. В мире терабайты уже существующих Jpeg без оригинальных исходников, для которых безпотерьный перевод в арифметический jpeg дал бы 20-30% на ровном месте.
Арифметическое кодирование в Jpeg — это часть стандарта Jpeg, а не новый формат, существует множество лет, и единственное ограничение раньше было в патентах. Причём перевод из обычного Jpeg в арифметический возможен полностью lossless, без потерь, так как пережимаются только таблицы квантизации из Huffman в Arithmetic. Перевод же в любой другой новый формат — webp, jpeg2000, hevc/bpg — это всегда полное пережатие с потерей качества. В мире терабайты уже существующих Jpeg без оригинальных исходников, для которых безпотерьный перевод в арифметический jpeg дал бы 20-30% на ровном месте.
Ну не знаю на счет стандарта, по факту вот фотография.
filmicgames.com/Images/Patents/bedroom_arithmetic.jpg
Она у меня не открывается:
1) Последний FF 38 репорт с 11 года. bugzilla.mozilla.org/show_bug.cgi?id=680385
2) Chrome Canary 45
3) win7 64 стандартная программа просмотра изображений
4) Photoshop CC
5) Paint
7) IE11
Открываеися только в irfanview
filmicgames.com/Images/Patents/bedroom_arithmetic.jpg
Она у меня не открывается:
1) Последний FF 38 репорт с 11 года. bugzilla.mozilla.org/show_bug.cgi?id=680385
I'm resolving this bug again for now. (Please don't read too much into «WONTFIX».) Before reopening, we'd need at least two browser vendors to commit to supporting arithmetic-coded JPEGs. Mozilla could be one of them, but we won't implement this without evidence that it's going to be interoperable in the future.
For now, the right place to go to move forward with this is on the standards mailing lists, not in this bug.
2) Chrome Canary 45
3) win7 64 стандартная программа просмотра изображений
4) Photoshop CC
5) Paint
7) IE11
Открываеися только в irfanview
А есть такие же тесты лосей?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JPEG 2000, JPEG-XR и WebP в стране упущенных возможностей