Как стать автором
Обновить

Комментарии 29

Вы уже во второй статье пишете так, будто webp проприетарный и закрытый. Вас что-то не устраивает в BSD лицензии этого опенсорсного проекта?
Почему Вы так решили?
Ну например
Очень хорошие результаты показывают гугловский WebP и «свободный» BPG.

Вы явно называете один свободным, а второй гугловским, что заставляет читателя думать о закрытости WebP
Гугловский — это же практически синоним свободного)
Тем более у BPG проблема с патентами и слово свободный написано в кавычках.
Не понимаю почему вас минусуют, вполне понятно объяснили, за статью спасибо. Но советую все таки в статье изменить, что бы не было недоразумений.
Может потому, что гугловский — отнюдь не синоним свободного? У них очень даже не все проекты попадают в опен сорс.
Причём особенно «приятно», когда название «свободный» применяется к формату за использование которого нужно платить. Причём неизвестно кому и неизвестно сколько. Причём никакой гарантии того, что вас схватят за мягкое место только потому что у вас на сайте лежат картинки в формате BPG и «сопутствующий» скрипт из библиотеки libbpg нет.
Автор исправилась, и пояснила, что слово «свободный», было использовано с ироничным смыслом.
Ирония плохо передаётся через интернет, увы. А на технических ресурсах — так и совсем отвратительно.
BPG сжимает лучше на 5-10%.


Ну да

image
это корявый сайт, там png вместо bpg
вот ссылка на визуальное сравнение фотографий xooyoozoo.github.io/yolo-octo-bugfixes
Сравнивал webp с bpg с пол года назад, в большинстве случаев bpg картинка занимала меньше места, чем webp c таким же качеством на глаз :)
Хочется верить, что формат получить широкое распространение и браузеры в будущем будут его поддерживать.
Можно сказать точно что ни Chrome ни Firefox его не будут его поддерживать, по вполне очевидными причинам, ещё очень и очень долго: пока отсутствие его поддержки не заставить людей переходить на другие браузеры. То есть даже не «когда он будет использоваться на куче web-сайтов», а когда он будет «настолько распространён, что люди будут мириться со всем, что насуёт в IE Microsoft, чтобы сайты с использованием BPG работали быстрее».
Ну вот как только все браузеры будут их поддерживать — можно будет начинать шевелиться, иначе будет больше проблем, чем пользы.
Вариант декодера стороннего пока тоже рассматриваю. Работая с сервисом, который передает несколько петабайт изображений в месяц, прирост даже в 10% может быть ощутим.

Js декодер на стороне сайта/приложения, не должен принести проблем пользователю, это же не плагин какой-то ему ставить самому в систему или браузер.
Загрузил png весом в 66 килобайт (1024х768), на выходе получил 88Kb bpg и 79Kb webp.

Ну думаю, окай, загрузил 50Kb png изображение (128х128), поменьше. Получил 103Kb bpg и 5Kb webp. Всё бы ничего, но вот это 5Kb webp выглядит, как jpg с 25% качеством (именно в таком качестве jpg выдаёт ~6Kb), настолько ужасающе.

Ну в общем посмотрим-посмотрим, результаты вполне себе есть, но бежать менять png на webp везде и всюду уж точно не стоит.
WebP и сотоварищи подразумевается как замена Jpeg.
К слову, узнал что bpg поддерживает анимацию. Выходит примерно в 10+ раз легче гифок.
Как жаль, что уже есть WebM
Еще не поздно задавить, если формат настолько хорош.
Почему то всегда сравнивают только размер полученный.

Мне кажется, что один из важнейших показателей — время кодирования-декодирования. Ну, возможно, еще необходимое кол-во памяти.

Никто не видел табличку сравнительную? Я в свое время искал и не нашел.
Я думаю что это потому, что размер — достаточно объективная характеристика формата (чуть менее объективная для сжатия с потерями, но даже и там не всё так плохо), а время сжатия и количество памяти — характеристика зависящая от безумного количества переменных и меняющаяся со временем. Про jpegturbo, надеюсь, все слышали?
Безусловно, время — характиристика плавающая, потому и надо сравнительную табличку, чтобы видно было не абсолютные значения, а относительные, чтобы можно было бы хотя бы порядки понять для себя.
На современных процессорах время сжатия ничего нам не скажет. Пора уже вводить новую характеристику — энергозатратность операции. Если формат имеет на 20% лучшее сжатие, но при этом на раскодирование тратится в 5 раз больше энергии… то нафиг он такой нужен.
По хорошему, надо бы запускать алгоритм кодирование/раскодирование в профайлере для разных изображений и подсчитывать сколько и каких инструкций процессора было исполнено, потом подбить их согласно энергетическому весу каждой и получим характеристику энергоэффективности операции кодирования/раскодирования.
Время — характеристика довольно субъективная и очень грубая. Время может зависеть не только от тактовой частоты на которой работает процессор но и от самого процессора, организации его ядра и скоростей шин.
Хотелось бы все же иметь не просто суперэффективный алгоритм сжатия но еще и энергоэффективный!
Энергоэффективность зависит почти исключительно от поддержки браузером. Сравнивать аппаратно-ускоренное декодирование WebP или BPG (современный ASICи имеют блоки для ускорения декодирования и того и другого) с полифиллом на JS как-то просто глупо.
Так ведь речь идет о самих форматах, а не костылях которые приходится использовать для их поддержки в первое время. Для ПК такой вопрос не актуален, там хоть на JS можно это делать, а вот для мобильных девайсов вопрос стоит очень остро.
А для мобильных девайсов всё очень просто: «щастя» не будет. Потому как в ближайшие много лет Chrome и основанные на этом движке браузеры будут поддерживать только WebP, а Safari его поддерживать не будет, но будет, возможно, поддерживать BPG. Остальные браузеры можно не учитывать, хотя нужно посмотреть что там происходит с proxy-based браузерами типа Opera Mini и/или UC Browser — как они на всё это будут реагировать. Так что… вам придётся решать: хотите вы со всем этим связываться в принципе или нет.
Откуда оценка, что BGP на 5–10 % лучше?
Сколько человек участвовали в оценке качества? Есть ли результаты объективных метрик?

Попробовал залить картинку на i.onthe.io/webp_bpg, у меня разница в размере получилась в 7,5 раз. Такое сравнивать, ну, никак нельзя.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий