Комментарии 29
BSD это тоже opensource
Вы уже во второй статье пишете так, будто webp проприетарный и закрытый. Вас что-то не устраивает в BSD лицензии этого опенсорсного проекта?
Почему Вы так решили?
Ну например
Вы явно называете один свободным, а второй гугловским, что заставляет читателя думать о закрытости WebP
Очень хорошие результаты показывают гугловский WebP и «свободный» BPG.
Вы явно называете один свободным, а второй гугловским, что заставляет читателя думать о закрытости WebP
Гугловский — это же практически синоним свободного)
Тем более у BPG проблема с патентами и слово свободный написано в кавычках.
Тем более у BPG проблема с патентами и слово свободный написано в кавычках.
Причём особенно «приятно», когда название «свободный» применяется к формату за использование которого нужно платить. Причём неизвестно кому и неизвестно сколько. Причём никакой гарантии того, что вас схватят за мягкое место только потому что у вас на сайте лежат картинки в формате BPG и «сопутствующий» скрипт из библиотеки libbpg нет.
BPG сжимает лучше на 5-10%.
Ну да
это корявый сайт, там png вместо bpg
вот ссылка на визуальное сравнение фотографий xooyoozoo.github.io/yolo-octo-bugfixes
вот ссылка на визуальное сравнение фотографий xooyoozoo.github.io/yolo-octo-bugfixes
Сравнивал webp с bpg с пол года назад, в большинстве случаев bpg картинка занимала меньше места, чем webp c таким же качеством на глаз :)
Хочется верить, что формат получить широкое распространение и браузеры в будущем будут его поддерживать.
Хочется верить, что формат получить широкое распространение и браузеры в будущем будут его поддерживать.
Можно сказать точно что ни Chrome ни Firefox его не будут его поддерживать, по вполне очевидными причинам, ещё очень и очень долго: пока отсутствие его поддержки не заставить людей переходить на другие браузеры. То есть даже не «когда он будет использоваться на куче web-сайтов», а когда он будет «настолько распространён, что люди будут мириться со всем, что насуёт в IE Microsoft, чтобы сайты с использованием BPG работали быстрее».
Ну вот как только все браузеры будут их поддерживать — можно будет начинать шевелиться, иначе будет больше проблем, чем пользы.
Вариант декодера стороннего пока тоже рассматриваю. Работая с сервисом, который передает несколько петабайт изображений в месяц, прирост даже в 10% может быть ощутим.
Js декодер на стороне сайта/приложения, не должен принести проблем пользователю, это же не плагин какой-то ему ставить самому в систему или браузер.
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 везде и всюду уж точно не стоит.
Ну думаю, окай, загрузил 50Kb png изображение (128х128), поменьше. Получил 103Kb bpg и 5Kb webp. Всё бы ничего, но вот это 5Kb webp выглядит, как jpg с 25% качеством (именно в таком качестве jpg выдаёт ~6Kb), настолько ужасающе.
Ну в общем посмотрим-посмотрим, результаты вполне себе есть, но бежать менять png на webp везде и всюду уж точно не стоит.
Почему то всегда сравнивают только размер полученный.
Мне кажется, что один из важнейших показателей — время кодирования-декодирования. Ну, возможно, еще необходимое кол-во памяти.
Никто не видел табличку сравнительную? Я в свое время искал и не нашел.
Мне кажется, что один из важнейших показателей — время кодирования-декодирования. Ну, возможно, еще необходимое кол-во памяти.
Никто не видел табличку сравнительную? Я в свое время искал и не нашел.
Я думаю что это потому, что размер — достаточно объективная характеристика формата (чуть менее объективная для сжатия с потерями, но даже и там не всё так плохо), а время сжатия и количество памяти — характеристика зависящая от безумного количества переменных и меняющаяся со временем. Про 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 раз. Такое сравнивать, ну, никак нельзя.
Сколько человек участвовали в оценке качества? Есть ли результаты объективных метрик?
Попробовал залить картинку на i.onthe.io/webp_bpg, у меня разница в размере получилась в 7,5 раз. Такое сравнивать, ну, никак нельзя.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
WebP vs BPG