Comments 71
(по ссылкам на Хабр далеко не ходил — там Ализар и его коллега)
Lossless формат — идеальный формат для изображений? Что только не напишешь в погоне за просмотрами и комментариям.
Для обычных фотографий, где можно допустить частичные потери, лучше подходит JPEG.
Преимущество FLIF заключается в том, что он хорошо работает для разных типов изображений.
@sunnybear, вы же разработчик WEBO, вы писали книгу по оптимизации сайтов в том числе изображений. Я не понимаю, как вы можете писать такую ахинею.
Jpeg — формат сжатия с потерями. Меняя уровень потерь, который мы читаем приемлемым, мы можем получить результат хоть в 10 раз меньше, хоть в 100. FLIF — формат сжатия без потерь. Там даже в названии это написано. «Без потерь» значит не то, что «он такой клевый, что когда сжимает, не появляется потерь», а что он намеренно так сжимает, чтобы потерь не было. Это принципиально другой способ сжатия, нежели в джипеге. При всем желании мы не добьемся от Флифа приемлемого размера для многих типов изображений, где много деталей, но их сохранение один-в-один не требуется. А вы предлагаете заменить Jpeg Флифом.
Безусловно, JPEG может быть меньше FLIF. Но речь в сравнении не об этом. WebP при сравнимой качестве сжатия с потерями дает меньший размер. FLIF в некоторых случаях может дать размер еще меньше без потери качества — когда мы можем предсказать изображение с большой точностью. И задача веб-разработки — двигаться в сторону меньших по размеру представлений информации. Иначе с Марсом будет тяжело связываться :)
Прочитал статью еще два раза. Не увидел, кто я «предлагаю заменить Jpeg Флифом». Вы ничего не перепутали?
Я ничего не перепутал. Я же процитировал место, где вы перечисляете для чего применяются разные форматы, а потом ваши слова: «Флиф хорошо работает для разных типов изображений». И если бы только я что-то перепутал, еще несколько человек не оставило бы комментарии в ключе «убийца JPEG».
Комон, вы пишете техническую статью на техническом ресурсе и признаете, что ваши слова ничего не значат. Т.е. вы намеренно вводите людей в заблуждение?
Но мы пойдем дальше: какую еще практическую пользу несет формат, кроме меньшего размера для любого типа изображений?
Всё же стоит уточнить, что не для любого, а для тех, где требуется lossless. Ну или пояснить детальнее, чему именно любого, и тогда да, придётся таки полноценно сравнить с jpeg. А ещё я думаю стоит избегать глаголов в повелительном наклонении (это я уже про комментарии).
Скажите, а больше вы подобных фраз в тексте не видите?
FLIF – идеальный формат для изображений?
Работает для любого типа изображений
Преимущество FLIF заключается в том, что он хорошо работает для разных типов изображений.
«FLIF – идеальный формат для изображений?» Это вопрос. Возможный ответ — «Идеальный формат для некоторых типов изображений». Но грамотный читатель сам должен на него ответить.
«Работает для любого типа изображений.» В некоторых случаях достигается существенный выигрыш в размере. Не во всех, не всегда. Но все типы изображений можно преобразовать, чтобы понять, стоит ли использовать FLIF для них. «Полевое» использование формата даст более развернутый ответ, в каких случаях он не работает.
«Преимущество FLIF заключается в том, что он хорошо работает для разных типов изображений.» Именно так. Не всегда идеально, но работает. Хорошо работает для разных типов — и PNG, и GIF, и 16 цветов, и WebP, и JPEG. Для разных. Иногда хорошо. Работает.
Не во всех, не всегда. Но все типы изображений можно преобразовать, чтобы понять, стоит ли использовать FLIF для них.
Зачем преобразовывать в Флиф фотографии, чтобы понять, стоит ли его использовать? Для фотографий он очевидно не подходит. И это не какой-то сложный синтетический случай, это на вскидку 80% существующих на земле изображений, хранящихся в файлах.
Зачем и кому это нужно? Место сейчас стоит копейки, а восстановить данные из пожатого jpeg невозможно! Почему формат сжатия без потерь не подходит для фотографий?
Место сейчас стоит копейки
Ну да и вас есть выбор: разместить на этом месте в 5 раз больше фотографий или сохранить на память всё несовершенство матрицы, ошибки фильтр Байера и прочей постобработки, ведь это всё так важно, эти данные иначе уже потом не восстановить.
http://flif.info/lossy.html
Спасибо за ссылку, очень интересно. Авторы не совсем утверждают, что «лучше джипега», они говорят:
In our opinion, at low qualities and for photographs, dedicated lossy formats like WebP, JPEG or BPG still produce better results. However, at very high-quality, we think lossy FLIF is a better option.
Гораздо важнее, на мой взгляд, какой функционал может предложить формат. Например, WebP предлагает просто огромное множество функционала: от сжатия с альфа-прозрачностью, до анимаций.
А вот сравнения производительности я сходу не обнаружил. Да и целых две статьи (за октябрь 2015-го и сентябрь 2016-го) в разделе «публикации» наводят на мысль о нишевом характере.
Знаешь, тут я скорее на стороне нового стандарта. Так как:
- Сейчас важнее энергозатраты на передачу изображения по сети до пользователя, куда входит:
1.1 Передача сжатого изображения (т.е. нагрузка на 2/3/4/5G, расходы на расшифровывание https трафика и т.д.)
1.2 Декодирование - Вычислительные мощности последнее время серьезно выросли, а вот объем памяти на устройствах — не так. Точнее, в компьютерах он может быть вырос, однако к нам еще добавилось громадное число носимых устройств.
То есть получается, что если стандарт позволяет потратиться на кодировании, но зато экономить на хранении и передачи, то это уже плюс для IT в целом.
Ну и также наличие альфа канала и разные режимы цвета (sRGB, Y422, ещё какие-нибудь).
Y422 — это chroma subsampling? К данном формату не имеет никакого отношения, потому что во-первых он RGB, во-вторых, loseless.
Скорость сжатия практически не важна, т.к. в основном изображения декодируют, т.е. расжимают.
В фотоаппаратах и прочих устройствах получения снимков как раз таки важна (если этот формат позиционируется как совсем универсальный).
Чем ваша статья отличается от статьи годовой давности? Графики те же. КДПВ та же… А технических подробностей даже меньше, чем у Ализара.
Разве что совсем мелочь типа анимированных смайликов и курсоров через видео реализовать не получится.
В свое время микрософт забила поддерживать PNG и SVG в, тогда еще очень популярном, IE — отбросила их распространение на несколько лет.
1) Сравнительно медленный.
2) На iOS как-то странно собрался — то изображение не сможет декодировать, то сегфолтится.
Year 2017: MIP detalization reinvented.
Вопрос: почему так долго и не поздно ли уже при текущих каналах связи интернет?
В былые времена на хабре в такой статье бы написали про алгоритмы внутри этого флифа.
Но он очень медленный. Понятно, что можно много чего оптимизировать, но он даже медленнее JPEG2000, причём едва ли не в разы. Если при тесте сжатия набора картинок JPEG-LS я успевал покурить, то в случае FLIF можно успеть пообедать.
Ещё такой момент — это, похоже, near lossless алгоритм. То есть можно включить режим сжатия с потерями, но если захочется, скажем пятидесятикратного сжатия (как умеет JPEG2000), то FLIF так не сможет (по крайней мере я вроде закрутил все параметры до отказа, но сжатие с потерями там было сравнимо с JPEG-LS).
Приятный момент — он поддерживает маску регионов интереса, ну то есть можно сделать области с переменным сжатием — важные части жать без потерь, а неважные — с потерями (JPEG2000 тоже так умеет).
Есть специфические картинки, на которых он даёт может дать выигрыш (скажем, довольно большие области залиты константой), но в общем случае сравним с известными методами.
Сжатие осуществлялось несколькими «ванильными» кодеками, которые установлены у меня, конвертером ImageMagic в png и кодеком flif. Результаты в табличке.
компрессор размер время_сжатия время_восстановления
gzip 102016362 10.2 1.95
lzma 73887952 110 7
bzip2 68756125 16.5 8.1
im png 55849652 68 2.4
flif 45551350 300 31.5
Итого, FLIF жмет в 1.2 раза плотнее, чем png. Но с производительностью — абсолютная полная огурцов — в PNG изображение сжимается в 4.4 раза быстрее, а восстанавливается в 13 раз быстрее. Если учесть, что время сжатия в WEB никого кроме хозяина сайта не волнует, то имеем следующее — время, сэкономленое на доставке пользователю контента в формате FLIF за счет более плотного сжатия, будет потрачено на восстановление оригинального растра для его отображения. В моем примере разница в объеме передаваемых данных равна 10298302 байта (~10Mб), а разница во времени восстановления — 29 секунд. Это значит, что в результате от замены PNG на FLIF пользователь выиграет только в том случае, если пропускная способность сети будет 350 кбайт в секунду и меньше. Вот и все, что нужно знать о FLIF.
Да, еще кодек flif при сжатии стрипает метаданные оригинальных файлов. Соответственно, восстанавливается совершенно не то, что было сжато.
Еще в 2015 году скачал, собрал и даже установил этот кодек.
время, сэкономленое на доставке пользователю контента в формате FLIF за счет более плотного сжатия
Вот и все, что нужно знать о FLIF
Просто напомню, что FLIF, что BPG, что PIK, что другие экспериментальные форматы - они лишь показывали проблему, и не предлагались как полноценное решение.
В 2019 была представлена версия 1.0.0 формата AV1 Image File Format (AVIF), который уже предполагался как стандарт, открытый и свободный от лицензионных притязаний.
На конец 2023 года у avif поддержка в браузерах 88%, включая safari на ios.
https://caniuse.com/?search=avif
Современные ОС и софт уже тоже умеют в avif.
FLIF – идеальный формат для изображений?