Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 63
А почему «пластиковый вид» — это плохо? Девушка на низкокачественном JPEG выглядит гораздо страшнее, чем на WebP, на мой взгляд.
Ну вот авторы решили записать это в минус, но по мне — это не плюс и не минус. Это особенность. На каких-то изображениях это выглядит лучше, на каких-то наоборот. Но в целом, лично мне больше нравится, когда границы объектов четко выделены, а не страдают от артефактов сжатия того же JPG.
Если честно, я еще ни разу не видел фотографии или картинки, на которой артефакты JPEG нельзя было бы обвети и крупно подписать «артефакты JPEG». Есть даже такая шутка-мем про врача и больного — «у вас JPEG» — помните?
Замыленная картинка — это, конечно, хуже, чем резкая, но по-моему лучше, чем синусоидально/клетчатый шум.
Замыленная картинка — это, конечно, хуже, чем резкая, но по-моему лучше, чем синусоидально/клетчатый шум.
прикол в том что квадраты еще можно подвергнуть постобработке и избавиться от них. А у синуса — нет)
по-моему лучше, чем синусоидально/клетчатый шум.А по моему худшее это замыленная картинка. Лучше квадратики и резкость, чем потеря фокуса (так воспринимается замыливание).
Худшее, чем что? Я сравнивал мыльное, но соответствующее действительности изображение с явными артефактами, которые это изображение визуально уродуют (то есть приводят в неузнаваемость).
В моем представлении идеальный алгоритм сжатия «с потерями» — это алгоритм, у которого шкала выдает картинку, в каждом случае соответствующую оригиналу, как его видит человек со всё более и более острым зрением. На минимуме всё почти неразборчиво, на максимуме — всё идеально.
В моем представлении идеальный алгоритм сжатия «с потерями» — это алгоритм, у которого шкала выдает картинку, в каждом случае соответствующую оригиналу, как его видит человек со всё более и более острым зрением. На минимуме всё почти неразборчиво, на максимуме — всё идеально.
Она на JPG 10% выглядит *ожидаемо*, то есть привычно. Опытные люди на глазок может даже назовут рейт с точностью до 5%.
Если перевести её в гиф, то искажения тоже будут существенными, но ожидаемыми.
Если перевести её в гиф, то искажения тоже будут существенными, но ожидаемыми.
Одна большая фигня с webp тем что алгоритмы адаптивности могут быть с сюрпризами. Например, скан договара со слабоконтрастной печатью будет размыт как незначительный элемент с точки зрения алгоритма. jpg квадратит, но равномерно.
ну посылают же емейлами сканы. А тут вам попадается скан со слабоконтрастной печатью… хотя печати это конечно все вата. Случай из жизни — сканы паспортов.
В новых загранах фотки часто оочень слабоконтрастные по отношению к конкрастным защитным линиям фона документа. В итоге лица сжимались в webp неимоверно сильно по отношению к конкрастным элементам. Причем поднятие качества сжатия не играло особой роли до почти максимальных настроек. А jpg — он везде jpg и пришлось его и оставить :-)
Их нет смысла хранить в tiff.
В новых загранах фотки часто оочень слабоконтрастные по отношению к конкрастным защитным линиям фона документа. В итоге лица сжимались в webp неимоверно сильно по отношению к конкрастным элементам. Причем поднятие качества сжатия не играло особой роли до почти максимальных настроек. А jpg — он везде jpg и пришлось его и оставить :-)
Их нет смысла хранить в tiff.
Есть же png как раз для таких случаев.
Есть, но я про автоматические сервисы в целом. И PNG чем будет отлтчаться от tiff? 8-битный мне не нужен. Если мы работаем с одинаковыми входными данными то и алгоритм предполагает примерно одинаковый выход, однако, хитрые алгоритмы подразумевающие адаптивность к данным изображения как готовым сжиматься сильнее или слабее чем соседняя область, может выдавать непредсказуемые результаты в пакетных режимах в отличие от jpg, который жмет одинаково везде, что в конкрастных зонах что нет.
Мы просто можем быть не готовы, что при 80% качестве webp какая то важная деталь фотографии будет замылена как «неважная».
Мы просто можем быть не готовы, что при 80% качестве webp какая то важная деталь фотографии будет замылена как «неважная».
А чем вам 8-битный PNG не угодил, когда вы пересылаете сканы документов? Там же, вроде бы, даже наличие цвета — явление опциональное…
если на изображении хоть два цвета, это не значит что png8 будет лучше) PNG вообще не катит на сканах или крупных изображениях — огромный размер файла.
Ну да. Я обычно использую JPG 75% для документов. Сканирую 360dpi, повышаю контрастность перед кодированием. Этого обычно хватает.
Есл себе и Ч/Б, то DJVU.
А до изобретения DJVU была отличная фишка для ч/б изображений. Однобитный BMP, сжатый WinRAR-ом уделывает по плотности всех. Там меньше 0.02 бита на пиксель обычно выходило.
Есл себе и Ч/Б, то DJVU.
А до изобретения DJVU была отличная фишка для ч/б изображений. Однобитный BMP, сжатый WinRAR-ом уделывает по плотности всех. Там меньше 0.02 бита на пиксель обычно выходило.
Тестирование степени сжатия это не очень интересно, ибо легко гуглится.
Гораздо любопытнее было бы почитать как работают те полифиллы, хотя бы принцип.
Гораздо любопытнее было бы почитать как работают те полифиллы, хотя бы принцип.
Если бы браузеры поддерживали арифметическое кодирование в JPEG (что вообще-то является частью стандарта), то можно было бы все существующие JPEG абсолютно без потерь в качестве уменьшить на процентов 10. Раньше это не поддерживалось из-за патентов, но все патенты на арифметическое кодирование давно истекли, поэтому разработчики браузеров могут легко поддержать это. Mozilla не хочет быть первой и говорит, что задумаются о такой поддержке, если кто-то из других производителей поддержит эту же фишку. Предлагаю проголосовать за поддержку арифметического кодирования JPEG в Edge здесь (без регистрации, можно поставить 3 голоса сразу).
И ещё, раз завёл такую тему, рекомендую проголосовать ещё за:
— поддержка сжатия Brotli в качестве Content-Encoding (Firefox и Chrome уже поддерживают в бета-ветках);
— поддержка APNG (Firefox и Safari уже поддерживают, с некоторыми анимациями справляется лучше WebP, имеет обратную совместимость с PNG);
— поддержка контейнера Ogg (они уже пообещали поддержку Vorbis/Opus, но не хотелось бы, чтобы они ограничились только контейнером WebM, музыка всё же обычно именно в контейнере Ogg идёт);
— здесь можно проголосовать за другие интересные вам возможности. Даже если вы не пользуетесь Edge. В том, чтобы Edge поддерживал все нужные фишки, заинтересованы все разработчики.
— поддержка сжатия Brotli в качестве Content-Encoding (Firefox и Chrome уже поддерживают в бета-ветках);
— поддержка APNG (Firefox и Safari уже поддерживают, с некоторыми анимациями справляется лучше WebP, имеет обратную совместимость с PNG);
— поддержка контейнера Ogg (они уже пообещали поддержку Vorbis/Opus, но не хотелось бы, чтобы они ограничились только контейнером WebM, музыка всё же обычно именно в контейнере Ogg идёт);
— здесь можно проголосовать за другие интересные вам возможности. Даже если вы не пользуетесь Edge. В том, чтобы Edge поддерживал все нужные фишки, заинтересованы все разработчики.
как мы с вами уже где то это обсуждали, не породит ли это ад среди обратной совместимости? Вроде файлы jpg но некоторые из них не будут читаться на устройствах моложе 2016 что вызовет некоторую панику поскольку ну jpg он всегда был jpg а тут вот…
Пройдёт, условно говоря, 5 лет — и такого вопроса не возникнет. Например, даже формат BMP много раз расширялся, и многие современные BMP файлы не прочитаются в Windows 98. Казалось бы, такой примитивный формат…
Сам недавно на ассемблере писал код, который формировал BMP файлы, и пришлось немного повозиться, чтобы результат был рабочим в Paint под Windows 98. Например, он понимает только BMP файлы, где строки хранятся строго в обратном порядке (от нижней к верхней), и прямой порядок не поддерживается. Многие современные программы формируют BMP файлы, которые не откроются в слишком старом просмотрщике, и как-то от этого никто ещё не пострадал :)
Сам недавно на ассемблере писал код, который формировал BMP файлы, и пришлось немного повозиться, чтобы результат был рабочим в Paint под Windows 98. Например, он понимает только BMP файлы, где строки хранятся строго в обратном порядке (от нижней к верхней), и прямой порядок не поддерживается. Многие современные программы формируют BMP файлы, которые не откроются в слишком старом просмотрщике, и как-то от этого никто ещё не пострадал :)
ну jpg этож вобще король :-) bmp то кому сдался)
Ну никто не мешает придумать под это дело другое расширение. Например, JPX. Можно туда даже более современный метод сжатия прикрутить. Основная идея — дать возможность пережать все существующие JPEG без потери качества. Я бы даже гигабайты своих фотографий пережал бы тогда в автоматическом режиме. Если пересжатие в «новый формат» будет с дополнительными потерями качества — на такое я согласиться не могу.
JPEG2000 использует вейвлет-преобразование при сжатии с потерями, поэтому конвертировать JPEG в JPEG2000 без потерь в качестве и с уменьшением объёма невозможно в принципе. Чтобы такое провернуть — в новом формате должны поддерживаться все внутренние структуры самого JPEG, просто поверх их можно сжимать более эффективным алгоритмом. Тем же арифметическим кодированием, который есть в стандарте, но который, увы, почти не поддерживается.
да фигня это. Там выигрышь то спорный. Обмен квадратов на мыло.
Как то непонятно, глядеть на JPEG скриншоты сравнения качества сжатия JPEG с WebP при этом JPEG 100% против WebP 80%. Что именно мне это должно показать?
Изобретен в 2010 и до сих пор не выстрелил, думаю это говорит о многом. Еще один JPEG2000?
Изобретен в 2010 и до сих пор не выстрелил, думаю это говорит о многом. Еще один JPEG2000?
Гугл продвинет, не беспокойтесь. Например, на ютубе у пользователей Chrome принудительно включается WebM (который, в отличие от mp4, всегда ресайзит 1920x1080 в 2048x1080 (cм. Stats for nerds в контекстном меню), хардварно не поддерживается и постоянно заикается). Мне на ноуте приходится использовать h264ify, чтобы избежать заиканий видео. Рекомендую всем, у кого подобная проблема, я уже хотел апгрейд делать своёму трехлетнему ноуту.
там PNG не jpg в картинках. А PNG (не тот что 8 битный) не имеет настроек сжатия потому он всегда 100% качеством.
Я уже писал о webp, кратко — не для всех изображений + выгода не всегда очевидна.
Статья основана на ложных предпосылках.
Не понимаю вообще смысла в продвижении формата webp. Если бы он был lossless, тогда пожалуйста.В WebP есть lossless режим. Первый же PNG по ссылке из статьи сжимается с 27 килобайт до 11 в WebP без потери качества!
Но PNG он портит вообще коварно.
Вы про эту картинку? Я её пережал в PNG без потерь и получил меньше 17 килобайт. Так что не всё так плохо у PNG. Правда, после заливки на habrastorage размер файла сильно увеличивается последним (непонятно зачем).
Было бы любопытно взглянуть на сжатый вами WebP.
Было бы любопытно взглянуть на сжатый вами WebP.
В таких тестах было бы полезным указывать использованные минификаторы для jpg/png и их настройки. А то может взяли из фотошопа png с килограммами служебной и прочей мета-информации и не максимательной степенью сжатия и радуются уменьшению размера, после перекодирования.
Иногда везло и optipng в десятки раз сжимал картинки, даже не уменьшая количества цветов, а просто выбирая более эффективную стратегию компрессии.
Иногда везло и optipng в десятки раз сжимал картинки, даже не уменьшая количества цветов, а просто выбирая более эффективную стратегию компрессии.
Интересно, как он справится с тёмными и протяженными градиентами? Кто снимает астрофото и ночные пейзажи знают как их джейпег корёжит.
А как же bpg?
Он значительно лучше webp, по-моему куда лучше переходить на него, тем более он, по сути и есть H.265.
Он значительно лучше webp, по-моему куда лучше переходить на него, тем более он, по сути и есть H.265.
Так его ж ничего не поддерживает вообще. WebP поддерживает «Хром» из коробки и всё остальное (в случае Сафари и ИЕ — если на компьютере установлен кодек) через JS (как кадр формата WebM).
да ну и что что не поддеживает. Халява незаметной не валяется долго. Это вобще не проблема. А значит, что это не халява.Круто, но решишь внедрить куда то — откати патентодержателю.
Я не понял что вы хотите сказать.
вобщем… когда технология слишком хороша и доступна, это халява. То есть профит от нее очень не хилый, рисков нет, при том что сил на внедрений почти не нужно. Это как с протоколом SPDY. Если круто и бесплатно — почему бы и не внедрить. Вот и внедрили 3 мажорных браузера и шумихи вокруг особо не было.
патенты, уй вам без рубля заплаченного.
Из вики складывается впечатление, кто кака раз с патентами у bpg всё не очень.
Формат интересный — сайт с примерами, зачастую показывает большую детализацию, чем WebP при сравнимых размерах.
Формат интересный — сайт с примерами, зачастую показывает большую детализацию, чем WebP при сравнимых размерах.
у bpg явно куда больше потенциал
В багзилле у Mozilla есть вот такой баг там есть подробности, в т.ч. про проблемы с патентами
>> WebP сжимает изображения без потерь на 26% лучше, чем PNG.
Ну да, конечно.
Открываем в Chrome http://youtube.com/, через контекстное меню логотипа в верхнем левом углу страницы вызываем «Просмотреть код» и видим, что логотип лежит в атласе по адресу http://s.ytimg.com/yts/imgbin/www-hitchhiker-vflVAomqi.webp
Скачиваем атлас.
Открываем всё тот же http://youtube.com/, но теперь в Firefox.
Через контекстное меню логотипа в верхнем левом углу страницы вызываем «Inspect element» и видим, что логотип лежит в атласе по адресу http://s.ytimg.com/yts/imgbin/www-hitchhiker-vfluKv9vH.png
Скачиваем атлас.
Барабанная дробь:
28 333 www-hitchhiker-vfluKv9vH.png
53 134 www-hitchhiker-vflVAomqi.webp
53 134 / 28 333 ≈ 1.87
Итого:
Тот же самый по содержанию атлас в формате WEBP занимает на 87% больше места, чем в PNG.
Не всё так шоколадно у WEBP с размером, как про это поёт Гугл.
Ну да, конечно.
Открываем в Chrome http://youtube.com/, через контекстное меню логотипа в верхнем левом углу страницы вызываем «Просмотреть код» и видим, что логотип лежит в атласе по адресу http://s.ytimg.com/yts/imgbin/www-hitchhiker-vflVAomqi.webp
Скачиваем атлас.
Открываем всё тот же http://youtube.com/, но теперь в Firefox.
Через контекстное меню логотипа в верхнем левом углу страницы вызываем «Inspect element» и видим, что логотип лежит в атласе по адресу http://s.ytimg.com/yts/imgbin/www-hitchhiker-vfluKv9vH.png
Скачиваем атлас.
Барабанная дробь:
28 333 www-hitchhiker-vfluKv9vH.png
53 134 www-hitchhiker-vflVAomqi.webp
53 134 / 28 333 ≈ 1.87
Итого:
Тот же самый по содержанию атлас в формате WEBP занимает на 87% больше места, чем в PNG.
Не всё так шоколадно у WEBP с размером, как про это поёт Гугл.
Не знаю, в чём прикол, но картинки на самом деле разные. Если тот же www-hitchhiker-vfluKv9vH.png перекодировать в lossless webp, то он будет занимать уже 25 КБ вместо 28.
Визуально вроде бы одинаковые.
>> Если тот же www-hitchhiker-vfluKv9vH.png перекодировать в lossless webp, то он будет занимать уже 25 КБ вместо 28.
А с какими ключами кодировали?
У меня команда
cwebp.exe www-hitchhiker-vfluKv9vH.png -o yt-new.webp
породила файл размером 53 858.
cwebp отсюда: http://downloads.webmproject.org/releases/webp/libwebp-0.5.0-windows-x64.zip
>> Если тот же www-hitchhiker-vfluKv9vH.png перекодировать в lossless webp, то он будет занимать уже 25 КБ вместо 28.
А с какими ключами кодировали?
У меня команда
cwebp.exe www-hitchhiker-vfluKv9vH.png -o yt-new.webp
породила файл размером 53 858.
cwebp отсюда: http://downloads.webmproject.org/releases/webp/libwebp-0.5.0-windows-x64.zip
Там у мозиллы 8-битный png, а webp — 32-битный, из-за этого и разница в размере. Если сконвертировать webp в png (например тут — cloudconvert.com/webp-to-png), то получится 87 кб.
Mozilla сильно сопротивляется, упираясь ногами, добавлению поддержки WebP, по неочевидным причинам. При этом внедряя поддержку DRM и используя проприетарный сервис Pocket. Вот баг для голосования (они даже комментирование закрыли, боясь разгневанных пользователей) bugzilla.mozilla.org/show_bug.cgi?id=856375
Патчи для поддержки в баге присутствуют. Так как закрыли возможность комментирования, один из вариантов продавливания — создание дубликатов этого бага.
Патчи для поддержки в баге присутствуют. Так как закрыли возможность комментирования, один из вариантов продавливания — создание дубликатов этого бага.
Mozilla очень сильно не любит этот формат и принципиально отказывается его поддерживать. Они начиная с 2011 года пишут статьи о том, что webp — отстой и ничуть не лучше уже поддерживаемых форматов (за 5 лет подобных статей наклепали более десятка).
Фактически, сейчас этот формат поддерживается только некоторыми браузерами на движке WebKit, и не более того.
Кроме того, в обсуждении на Reddit'е сторонники Mozilla советуют тем, кому без WebP никак, использовать специальные сборки Firefox-подобных браузеров, например PaleMoon, где такая поддержка добавлена.
Фактически, сейчас этот формат поддерживается только некоторыми браузерами на движке WebKit, и не более того.
Кроме того, в обсуждении на Reddit'е сторонники Mozilla советуют тем, кому без WebP никак, использовать специальные сборки Firefox-подобных браузеров, например PaleMoon, где такая поддержка добавлена.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Используем WebP сегодня