Но чем больше картинок заливается в интернет, тем острее ощущается потребность в лучшем формате. Для экономии места на сервере, для ускорения загрузки страницы и для экономии времени дизайнера.
Если измерить вес всех фотографий на странице — иногда можно получить сердечный приступ. Чем больше фотографий, тем больше весит страница и тем дольше она загружается.
Сейчас уже созданы несколько форматов, имеющих все шансы заменить и JPEG и GIF и PNG. Очень хорошие результаты показывают гугловский WebP и «свободный» BPG.
Оба формата основаны на сжатии ключевых кадров в видеокодеках. WebP работает по технологии VP8, а BPG — по HEVC (H.265).
Что такое BPG
BPG основан на технологии кодирования ключевых кадров видеокодека HEVC (H.265). Разбивает изображение на блоки разного размера, в зависимости от содержания. Поддерживает 14 бит/канал, прозрачность, метаданные, может сжимать с потерями и без. Здесь спецификация BPG на сайте разработчика.
Что такое WebP
Основан на технологии кодирования ключевых кадров видеокодека VP8 от Google. Как устроен WebP подробно описано здесь.
Поддерживает сжатие с потерями и без потерь, прозрачность, метаданные и анимацию и имеет возможность сжимать картинку без сжатия альфа-канала.
Сравнение BPG и WebP
Визуальное сравнение
Сравнение проводилось с помощью этого инструмента. Выборка: 10 картинок разного размера. Эксперимент показал, что BPG сжимает в среднем на 20% лучше, чем WebP. Хотя разброс довольно большой от 42% до 0%. Иногда разница составляла всего 1 kb, а иногда — гораздо больше. При этом визуальное качество картинки оставалось одинаковым.
Если перещелкать все картинки на этом ресурсе, то в режимах small, medium и large, мелкие детали на BPG выглядят даже четче. В режиме tiny — визуальное качество картинки лучше в формате WebP, а BPG размывает мелкие детали.
Поддержка браузерами
BPG — это opensource, но он построен на базе HEVC, который имеет множество связанных патентов. Владельцев этих патентов так много, что они даже создали группу под названием MPEG-LA. В эту группу входят Apple и Microsoft. Это объясняет почему они до сих пор не приняли формат WebP.
BPG не поддерживается ни одним браузером. Первым может стать Safari и возможно IE. WebP же распространяется по лицензии BSD и имеет поддержку в браузерах Chrome, Opera и веб-приложениях Android.
| WebP | BPG | |
| Loss | + | + |
| Lossless | + | + |
| Meta | + | + |
| Alpha | + | + |
| Encode | VP8 | H.265 |
| License | BSD | Opensource + patents |
| Support | Chrome, Opera, Android | - |
Конвертация
Чтобы внедрить BPG на сайт, нужно подключить js декодер. Конвертировать из JPEG в BPG можно с помощью ImageMagick:
convert image.jpeg image.bpg
Из других форматов в WebP можно конвертировать с помощью специальной утилиты — cwebp и обратно — декомпрессор dwebp:
cwebp -q 85 -lossless input.png -o output.webp
dwebp input_file.webp -o output.png
Также утилита может выполнять простое редактирование картинки: кроп и ресайз.
Эта статья написана благодаря одному из комментариев к статье Устройство WebP.
Конспект
- BPG кодируется по технологии видеокодека H.265, а WebP по VP8.
- BPG сжимает лучше в среднем на 5-10%.
- WebP имеет частичную поддержку браузерами, BPG пока не поддерживается вовсе.
- Встроить BPG на сайт можно с помощью JS.
Комментарии (28)
CAJAX
08.07.2015 13:53+6Вы уже во второй статье пишете так, будто webp проприетарный и закрытый. Вас что-то не устраивает в BSD лицензии этого опенсорсного проекта?
moccachin Автор
08.07.2015 13:57-2Почему Вы так решили?
egor_masalitin
08.07.2015 14:13+14Ну например
Очень хорошие результаты показывают гугловский WebP и «свободный» BPG.
Вы явно называете один свободным, а второй гугловским, что заставляет читателя думать о закрытости WebPmoccachin Автор
08.07.2015 14:19-6Гугловский — это же практически синоним свободного)
Тем более у BPG проблема с патентами и слово свободный написано в кавычках.egor_masalitin
08.07.2015 14:44+2Не понимаю почему вас минусуют, вполне понятно объяснили, за статью спасибо. Но советую все таки в статье изменить, что бы не было недоразумений.
webkumo
08.07.2015 16:08+7Может потому, что гугловский — отнюдь не синоним свободного? У них очень даже не все проекты попадают в опен сорс.
khim
08.07.2015 18:06+1Причём особенно «приятно», когда название «свободный» применяется к формату за использование которого нужно платить. Причём неизвестно кому и неизвестно сколько. Причём никакой гарантии того, что вас схватят за мягкое место только потому что у вас на сайте лежат картинки в формате BPG и «сопутствующий» скрипт из библиотеки libbpg нет.
egor_masalitin
08.07.2015 18:14Автор исправилась, и пояснила, что слово «свободный», было использовано с ироничным смыслом.
khim
08.07.2015 18:53+2Ирония плохо передаётся через интернет, увы. А на технических ресурсах — так и совсем отвратительно.
AlexPTS
08.07.2015 15:24+1Сравнивал webp с bpg с пол года назад, в большинстве случаев bpg картинка занимала меньше места, чем webp c таким же качеством на глаз :)
Хочется верить, что формат получить широкое распространение и браузеры в будущем будут его поддерживать.khim
08.07.2015 18:10+1Можно сказать точно что ни Chrome ни Firefox его не будут его поддерживать, по вполне очевидными причинам, ещё очень и очень долго: пока отсутствие его поддержки не заставить людей переходить на другие браузеры. То есть даже не «когда он будет использоваться на куче web-сайтов», а когда он будет «настолько распространён, что люди будут мириться со всем, что насуёт в IE Microsoft, чтобы сайты с использованием BPG работали быстрее».
eaa
08.07.2015 15:25+3Ну вот как только все браузеры будут их поддерживать — можно будет начинать шевелиться, иначе будет больше проблем, чем пользы.
AlexPTS
08.07.2015 20:39Вариант декодера стороннего пока тоже рассматриваю. Работая с сервисом, который передает несколько петабайт изображений в месяц, прирост даже в 10% может быть ощутим.
Js декодер на стороне сайта/приложения, не должен принести проблем пользователю, это же не плагин какой-то ему ставить самому в систему или браузер.
SerafimArts
08.07.2015 16:20+1Загрузил png весом в 66 килобайт (1024х768), на выходе получил 88Kb bpg и 79Kb webp.
Ну думаю, окай, загрузил 50Kb png изображение (128х128), поменьше. Получил 103Kb bpg и 5Kb webp. Всё бы ничего, но вот это 5Kb webp выглядит, как jpg с 25% качеством (именно в таком качестве jpg выдаёт ~6Kb), настолько ужасающе.
Ну в общем посмотрим-посмотрим, результаты вполне себе есть, но бежать менять png на webp везде и всюду уж точно не стоит.
DLag
08.07.2015 17:28WebP и сотоварищи подразумевается как замена Jpeg.
SerafimArts
09.07.2015 13:02К слову, узнал что bpg поддерживает анимацию. Выходит примерно в 10+ раз легче гифок.
den_admin
08.07.2015 21:06+1Почему то всегда сравнивают только размер полученный.
Мне кажется, что один из важнейших показателей — время кодирования-декодирования. Ну, возможно, еще необходимое кол-во памяти.
Никто не видел табличку сравнительную? Я в свое время искал и не нашел.khim
09.07.2015 04:31Я думаю что это потому, что размер — достаточно объективная характеристика формата (чуть менее объективная для сжатия с потерями, но даже и там не всё так плохо), а время сжатия и количество памяти — характеристика зависящая от безумного количества переменных и меняющаяся со временем. Про jpegturbo, надеюсь, все слышали?
den_admin
09.07.2015 09:55Безусловно, время — характиристика плавающая, потому и надо сравнительную табличку, чтобы видно было не абсолютные значения, а относительные, чтобы можно было бы хотя бы порядки понять для себя.
Alexeyslav
09.07.2015 14:52На современных процессорах время сжатия ничего нам не скажет. Пора уже вводить новую характеристику — энергозатратность операции. Если формат имеет на 20% лучшее сжатие, но при этом на раскодирование тратится в 5 раз больше энергии… то нафиг он такой нужен.
По хорошему, надо бы запускать алгоритм кодирование/раскодирование в профайлере для разных изображений и подсчитывать сколько и каких инструкций процессора было исполнено, потом подбить их согласно энергетическому весу каждой и получим характеристику энергоэффективности операции кодирования/раскодирования.
Время — характеристика довольно субъективная и очень грубая. Время может зависеть не только от тактовой частоты на которой работает процессор но и от самого процессора, организации его ядра и скоростей шин.
Хотелось бы все же иметь не просто суперэффективный алгоритм сжатия но еще и энергоэффективный!khim
09.07.2015 15:01Энергоэффективность зависит почти исключительно от поддержки браузером. Сравнивать аппаратно-ускоренное декодирование WebP или BPG (современный ASICи имеют блоки для ускорения декодирования и того и другого) с полифиллом на JS как-то просто глупо.
Alexeyslav
09.07.2015 15:23Так ведь речь идет о самих форматах, а не костылях которые приходится использовать для их поддержки в первое время. Для ПК такой вопрос не актуален, там хоть на JS можно это делать, а вот для мобильных девайсов вопрос стоит очень остро.
khim
09.07.2015 15:40+1А для мобильных девайсов всё очень просто: «щастя» не будет. Потому как в ближайшие много лет Chrome и основанные на этом движке браузеры будут поддерживать только WebP, а Safari его поддерживать не будет, но будет, возможно, поддерживать BPG. Остальные браузеры можно не учитывать, хотя нужно посмотреть что там происходит с proxy-based браузерами типа Opera Mini и/или UC Browser — как они на всё это будут реагировать. Так что… вам придётся решать: хотите вы со всем этим связываться в принципе или нет.
XaLBa
09.07.2015 12:53Откуда оценка, что BGP на 5–10 % лучше?
Сколько человек участвовали в оценке качества? Есть ли результаты объективных метрик?
Попробовал залить картинку на i.onthe.io/webp_bpg, у меня разница в размере получилась в 7,5 раз. Такое сравнивать, ну, никак нельзя.
DancingOnWater
BSD это тоже opensource