Comments 49
Если не брать в расчёт только веб, то было бы интересно увидеть сравнение с FLIF.
FLIF development has stopped since FLIF is superseded by FUIF and then again by JPEG XL, which is based on a combination of Pik and FUIF. For more information, see Jon's JXL info page or visit the JPEG XL Discord server.
К сожалению, картинки в формате
.jxlпока не поддерживаются ни одним браузером по умолчанию. Но это вопрос времени, потому что с технической точки зрения ему нет равных.
Ой как далеко не факт. Техническое превосходство это не фактор успеха формата.
Я бы сказал так, что не смотря на повсеместное распространение WebP - это не всегда идет из коробки, что сильно усложняет работу с ним, например часть сайтов все еще его не поддерживают и при публикации контента возникают сложности, мессенджеры не все воспринимают этот формат. Ну и конечно можно затронуть разработку, где Wordpress, Django не поддерживают эти форматы изначально - нужно делать действия для их внедрения. И это мы говорим про формат которому уже больше 10 лет, новые форматы пока войдут в массовое употребление - я уже на пенсии буду)
WordPress поддерживает webp из коробки
https://make.wordpress.org/core/2021/06/07/wordpress-5-8-adds-webp-support/
В Принципе RAW -> DNG (RAW) , просто еще RAW к правило родной софт лучше кушает чем тот же например Adobe Lightroom. В виду того что производитель , не сильно жаждет делится "поправками" на проявку, специфика для каждой модели камеры
Точно так же, как мы сейчас недоумеваем о причинах повсеместного сжатия в 90-е годы музыки в формат MP3 на 128 Кбит/с.
Не очень удачное сравнение, поскольку всем отлично понятно, зачем и для чего это делалось. И не только в 90-е, но и в начале нулевых. До сих пор у меня где-то валяется рабочий жёсткий диск на 40гб из тех времён :)
Через несколько лет можно будет сказать, что формат PNG окончательно устарел, поскольку разница с WebP и JPEG XL очень существенная.
WebP появился 12 лет назад, но до сих пор не поддерживается Проводником Windows из коробки (а до этого года не поддерживался из коробки и в Adobe Photoshop).
Внедрение новых форматов - очень медленный процесс.
Иначе мы бы постоянно видели разные лица, в зависимости от расстояния до лица и освещения.
Наверное не все знают, но есть люди, которые видят разные лица просто потому, что лицо сменило причёску.
Детально спецификацию JPEG XL не читал, что у него под капотом, но от Discrete Cosine Transform они вроде не отказались, а значит в любом случае будут потери в наименее значащих битах.
Что-то мне подсказывает, что если вычесть изображение одного формата (к примеру, PNG) из изображения другого формата (JPEG XL), мы можем получить некоторый шум.
Буду рад ошибиться, а то с середины 2000 за форматами и не следил)
но от Discrete Cosine Transform они вроде не отказались, а значит в любом случае будут потери в наименее значащих битах
DCT — это обычное ортогональное преобразование, то есть смена базиса. Потери происходят из-за квантования полученных значений.
Квантование в любом случае происходит, после математических вычислений получается много цифр после запятой, как их хранить? 24 битовое значение заменить на 128 битовое? так это уже не сжатие происходит.
Согласен, математически абсолютно всё верно, но в реальности мы получаем IEEE-754-арифметику и различные округления в ряде операций (к примеру, преобразования RGB-YCbCr в классическом JPEG).
Хотя квантование вносит (или может внести) на порядок больше шума.
Микроспойлер по режимам работы JPEG XL
По JPEG XL нашел интересное описание о режимах работы.
VarDCT mode, where variable-sized DCT transforms are applied and the image data is encoded in the form of DCT coefficients. This mode is always lossy, but can also be used to losslessly represent an existing JPEG image. Find an example of the JPEG XL VarDCT block size selection here.
The other mode used is modular mode, where only integer arithmetic is used, enabling lossless compression.
Последнее неожиданно радует. На досуге почитаю стандарт.
Из lossless есть еще https://github.com/phoboslab/qoi
А у png есть несколько реализаций, например fpng и rdopng, они по скорость\качество тоже будут отличаться.
На счёт qoi, перевод из png в qoi картинок из статьи приводит изменению их размера с 18.1mb до 18.3, то есть размер увеличивается на 1%.
qoi, однако, хорошо жмётся архиваторами. qoi.zip = 15.8mb (87%, то есть как OxiPNG+Zopfli), а qoi.7z = 14.9mb (82%, что лучше, чем 86% у avif, но хуже 66% у webp и 60% у jpgxl).
На том же наборе qoi+deflate64:9 даёт 15.928 MB за 4 секунды, а qoi+LZMA2fast:9 — 15.207 MB за примерно секунду
Простите, а в чём необходимость кодировать фотографии без потерь? Во-первых само словосочетание «кодировать фотографии без потерь» уже немного смешное, учитывая количество преобразований и тюнинга, которое происходит при получении цифровой фотографии. Во-вторых в чем ценность хранить шум означающий количество фотонов, упавших в конкретный пиксель сенсора (процесс случайный), если можно его отрезать и ничего не потерять?
> Ёмкость накопителей растёт в геометрической прогрессии. Через 50–60 лет люди будут гадать, зачем вообще далёкие предки в 2022 году сжимали фотографии с искажениями.
Конечно, именно поэтому чуть ли не каждый год появляются новые форматы картинок и видео с сжатием с потерями, именно поэтому вы пишете статью, как сохранить проценты на размере. А ещё фотографии же не растут в размере и их количество не увеличивается от года к году. Ну и всё, что мы делаем с фотографиями — храним их, никуда не передавая.
> Картинка в формате WebP с внешнего сайта
Но это же фотография сохраненная с потерями, а вы вроде рассказываете о форматах без потерь?
> Например, вот прогон на 94 картинках из коллекции дизайнерских работ Dribble.
Простите, извините, а где же ФОТОГРАФИИ, про которые вы рассказывали, что собираетесь хранить без потерь?
> Для теста взяли с Яндекс.Картинок первые 10 фотографий в формате PNG-24 произвольного размера и разрешения.
А с чего вы взяли, что первые 10 фотографий в формате PNG-24 не были пересохранены в PNG из формата с потерями? Вот например третья картинка из выдачи: тут видны не только артефакты JPEG, но и сильный апскейлинг.
Ёмкость накопителей растёт в геометрической прогрессии. Через 50–60 лет люди будут гадать, зачем вообще далёкие предки в 2022 году сжимали фотографии с искажениями.
Это не бесконечный процесс — все упирается в физические ограничения типа размера атома и скорости света.
Имеет ли смысл сжимать из png в webp или лучше сначала в jpeg, а потом в webp? Дизайнеры очень любят png, видимо из-за альфа-слоя, который далеко не всегда нужен
Я правильно понимаю, что в отличии от png и jpg, wepb по сути архив и возрастет нагрузка браузер пользователя? то есть выиграешь по сжатию, но увеличивается нагрузка на озу и так перегруженного скриптами сайта?
Это не работает как с архиваторами, когда вы сжимаете text.zip раром чтобы выжать ещё 5%. При любом сжатии с потерями вы получите искаженную картину на выходе. Если после jpeg вы сжимаете в webp, то для кодека webp исходным изображением станут уже искаженные от jpeg данные. Ему нужно будет не просто передать ваше исходное изображение, а как можно точнее передать весь шум, добавленный кодеком jpeg. А учитывая, что принцип действия у форматов совершенно разный, на передачу этих шумов будет потрачено даже больше битрейта, чем могло быть потрачено на исходное изображение. Ну и естественно, после этого к изображению добавятся искажения уже от самого webp. В результате вы скорее всего получите файл больше чем если бы сжимали оригинал и с двойной порцией артифактов.
Мы видимо говорим о разных вещах. Цель найти оптимум для размещения на сайте. У меня есть большие подозрения, что если конвертировать с png в webp, то например альфа-слой останется. плюс не всегда нужно отличное качество и можно пожертвовать небольшим ухудшением. я заметил, что webp-файлы после png больше. Вопрос не стоял получить на выходе файл абсолютно без потерь, вопрос стоял как получить webp, чтобы и по размерам был не велик, и значительного ухудшения не было. в отличии от статьи выше, которая носит более исследовательский характер, у меня вопрос конкретно прикладной. у меня есть страница с 20-30 превью, вопрос что лучше сгенерированные webp после png или jpg ? если внимание обратите на Google-параметры оценки качества сайта, то там оценивается не lossless
У кодека webp есть параметр quality, с помощью него вы можете управлять степенью компрессии и количеством искажений (потерь, артефактов, шумов).
> вопрос что лучше сгенерированные webp после png или jpg
Я могу только повторить то, что выше написал: после jpeg вы будете сжимать не исходное изображение, а изображение с артефактами jpeg. В этом нет никакого смысла. Вот пример из статьи, немного уменьшений чтобы было удобнее было смотреть.
Оригинал:
Сохраненный в webp q=40:
Сохраненный сначала в jpeg q=75, потом в webp q=45:
Как видите, это только добавило артефактов.
Просто подумайте логически: если бы в этом был хоть какой-то смысл, разве авторы webp не встроили бы это прямо в свой кодек?
Чтобы убрать альфа-слой, можно с тем же успехом перегнать в BMP.
Кстати, неплохим способом повысить степень сжатия является небольшое размытие изображения фильтром Гаусса.
Заметим, что исходный видео файл был, порядка, 1.9 ГБ, а опубликованное видео имеет размер, примерно, 173 МБ, при незначительной потере качества.
Это формат сжатия с потерями и графики про восприятия сжатия с потерями.
Потому что статья про форматы сжатия без потерь, а HEIC — формат сжатия с потерями.
> Зачем нужен JPEG-XL и чем он так хорош, если есть HEIC
HEIC не то, чтобы «есть», он закрыт патентами.
Потому что статья хоть большая и интересная, но несколько дилетантская. В ней есть такие шероховатости, как например очень поверхостный обзор форматов сжатия с потерями, из которой этот график и пришёл. Зачем нужно рассматривать HEIC, который не может в сжатие без потерь, в статье про сжатие без потерь? - чтобы раздуть статью.
Потому что сравнение некорректно. Ты не можешь сказать что HEIC лучше PNG, так как PNG на этом графике будет точкой в 100% качества - у него нет режима сжатия с потерей качества, а HEIC будет кривой которая не дойдёт до 100% качества; их грфики не пересекутся. Графики JPG XL и HEIC пересекаются частично, так что можно сказать что HEIC лучше, но только с оговоркой, что для сжатия со 100% качеством его применение совсем не возможно.
Вопрос - зачем сжимать 24бита цветности, когда подавляющее число воспроизводящих устройств умеют отображать только 8битный цвет, да к тому же с неполным покрытием sRGB?
Высокая битность нужна только на этапе Raw-конвертации, дальше подавляющее число изображений живёт в 8-мибитном sRGB. Даже в фотошопе 16 бит используется в исключительных случаях.
В порядке мысли. Представим, что в будущем каждый компьютер оснащён сопроцессором для обработки нейросетей (всё к тому и идёт). Может ли вытеснить lossy-сжатие по качеству lossless-файл, допустим, вдвое меньшего разрешения, который при открытии будет автоматически проходить двухкратное увеличение через утилиту вроде Topaz Gigapixel, но быстрее и в фоновом режиме?
Какие у такого подхода могут быть преимущества и недостатки? В преимуществах я вижу полное сохранение канала цветности и отсутствие визуально заметных блоков артефактов JPEG, но в недостатках — возможные артефакты нейросети («дребезг», «волна» и прочее, хорошо заметно при попытке апскейла нейросетями фотографий с деталями вариативной формы, напр-р вышивки) и заметный лаг перед открытием фотографии (сейчас — единицы секунд для 3070, через пять лет — доли секунды, но всё равно будет заметно).
QOI? Нет, не слышал.
Сжимаем изображения без потерь: какой формат выбрать?