Компания Samsung добавила поддержку формата изображений JPEG XL в приложение для работы с камерой, поставляемое в смартфонах Galaxy S24. Ранее в числе сторонников формата также выступили компании Apple, Facebook, Adobe, Mozilla, Intel, Krita, The Guardian, libvips, Cloudinary, Shopify и Free Software Foundation. До этого компания Google удалила экспериментальную реализацию JPEG XL из кодовой базы Chromium, мотивируя данное решение отсутствием достаточного интереса к формату со стороны экосистемы...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60467
> До этого компания Google удалила экспериментальную реализацию JPEG XL из кодовой базы Chromium, мотивируя данное решение отсутствием достаточного интереса к формату со стороны экосистемы.Под «экосистемой», видимо, подразумевается Хром.
на момент удаления из кода - decoding \ encoding был почти на уровне с AVIF, нок учей багов...
Большинство разрабов JPEG XL - именно из гугла. Как допилят - вернут. Слишком много плюшек)
Он и так был под экспериментальным флагом. Как они измерили интерес? А так, хром, добро пожаловать в отстающие. Ведь даже обычно отстающий сафари внедрил jpegxl.
Так в нем почти все функции не для тебя, а для копрорации добра, как там ваш третий манифест и печеньки поживают?
> поддержка до 4099 каналов и большой диапазон глубин цвета.Молодцы, человеки, готовитесь к интеграции в галактическое сообщество
Осьминоги различают поляризованный свет. А у рака богомола еще есть рецепторы для УФ.
А как оно в сравнении с AVIF себя показало? JPEG XL почти везде порвал AVIF)
https://tonisagrista.com/blog/2023/jpegxl-vs-avif/
Авиф принципиально не умеет в настоящий лосслесс, всегда искажает цвета, замыливает. Смысл сравнивать. По сравнению с вебп (с твиками) больше актуальных стандартизированных возможностей у формата, намного выше эффективность кодирования лосслесс, более эффективное лосси, у которого нет лестниц на градиентах. Цвета больше теряет при уменьшении качества, но на сопоставимом размере лучше. Сабж при перекодировании из жпег в лосси скрывает артефакты жпег, из жпег в лосси упаковывает пиксели более эффективно без потерь.
>из жпег в лосси упаковываетиз жпег в лосcлесс-жпег переупаковывает, если точнее
>Авиф принципиально не умеет в настоящий лосслесс
>намного выше эффективность кодирования лосслесс, более эффективное лоссиКажется, есть противоречие, не?
В первом случае речь об авиф, который нет смысла обсуждать. Во втором, про устаревший вебп.
> плавное ухудшение качества при уменьшении битрейтаОткуда в формате изображений JPEG XL битрейт? Это же статичная картинка, а не потоковое аудио/видео...
.....наличие расширенных возможностей, таких как HDR, анимация, прозрачность, режим прогрессивной загрузки.....
Не имеет отношения к анимации, автор оригинала не понимает язык на котором пишет
> Откуда в формате изображений JPEG XL битрейт?"graceful quality degradation across a large range of bitrate"
"JPEG XL is visually lossless at about half the bitrate required by JPEG, i.e. at compression ratios of around 20:1 (1.2 bpp) where JPEG would compress only around 10:1 (2.4 bpp)"
> JPEG XL is visually lossless
> visuallyА как они измеряли - вот вопрос.
Потому что, если взять H256 и новомодный AV1, то там похожие заявления, а подтверждают они их MSE метрикой, которая к мылу нечувствительна вообще.
Что-то я подозреваю, они классические жпег квадраты заменили новым прогрессивным жперИКС-ЭЛЬ мылом.
jxl это не видеокодек, вполне паритет по качеству с жпегом (лучше оригинального жпега всё ещё ничего не придумали в плане сохранения пикселей). Я могу подтвердить, что jxl-97 в несколько раз меньше размером jpeg-100 и лучше качеством, меньше дефектов, визуально отличий с оригиналом будет сложно найти даже на 2000-кратном увеличении, у jpeg-100 они будут несмотря на размер файла.
> jxl это не видеокодек, вполне паритет по качеству с жпегом (лучше оригинального
> жпега всё ещё ничего не придумали в плане сохранения пикселей). Я
> могу подтвердить, что jxl-97 в несколько раз меньше размером jpeg-100 и
> лучше качеством, меньше дефектов, визуально отличий с оригиналом будет сложно найти
> даже на 2000-кратном увеличении, у jpeg-100 они будут несмотря на размер
> файла.Понятно что не видео.
Это пример того как лучшее на бумаге не обязательно такое на практике. По этому и спрашиваю.Я не могу найти сравнения по SSIM метрике в сети. Все используют SSIMULACRA2, что не тоже самое.
По это ссылке видно https://giannirosato.com/blog/post/image-comparison/ использующей симулякру выходит что JPEG_XL в целом лучше жепега, и особенно на "очень высоком" качестве, которое обычный jpeg достичь не может. Но!!! Покажите мне SSIM метрику!
Не, рекомендую метрику PAE. Есть в Image Magick, только jpegxl там через одно место работает и кодировать надо самому референсным кодером. Эта метрика вполне совпадает с оценкой глазами, сколько я ни сравнивал. Обычно, это означает, что лучше всего будет jpegxl и следом webp с -define webp:image-hint=picture -define webp:alpha-filtering=2 -define webp:alpha-quality=100 -define webp:partition-limit=0 -define webp:use-sharp-yuv=1 (ещё может быть webp:filter-type) при понижении "качества" вебп выходит вперёд. Все остальные гораздо хуже, особенно, на "сложных" файлах.
Хочу SSIM.
GIF, JPEG и PNG хватит всем!
Мне хватало PCX (не все поймут, не многие вспомнят) в своё время.
> Мне хватало PCX (не все поймут, не многие вспомнят) в своё время.$ locate *.pcx
****
/usr/local/lib/falconseyedir/graphics/yendor.pcx$ file /usr/local/lib/falconseyedir/graphics/yendor.pcx
/usr/local/lib/falconseyedir/graphics/yendor.pcx: PCX ver. 3.0 image data bounding box [0, 0] - [799, 449], 8-bit colour, 300 x 300 dpi, RLE compressedсмотреть xv, display.. у imlib2 (feh) с этим форматом (по умолчанию) не очень, в отличие от jxl :)
PBM лучше всех. Его можно в блокноте смотреть и редактировать.
Вот только WEBP довольно быстро стал использоваться всякими крупными сервисами (Озон например) после того как известные браузеры наконец утрясли вопросы с его поддержкой. А до этого тоже говорили что ненужно и формат мертвый.
Хотя распространение вне Web, прямо скажем, незаметное.
>поставляемое в смартфонах Galaxy S24Хорошее обновление получилось:
https://www.samsung.com/ru/smartphones/galaxy-s24-ultra/compare/
А когда QOI?
QOI весело реализовывать, он как глоток свежего воздуха без наслоений легаси*. Но на этом всё. Если не играться с кодом, а использовать формат для публикации картинок, то нет радости и веселья, нет смысла.Полезнее будет ускорить декодер PNG или использовать TGA (но тоже нет в браузерах), который даже быстрее QOI, но сжимает похуже, то есть в целом тоже quite ok. Ради совместимости. Но это не весело.
* там вместо легаси наслаивается пионерство - выбрали неоптимальный порядок компонент, но менять формат уже поздно. https://github.com/phoboslab/qoi/issues/34
В Wayland используется RGBA.
На самом деле QUI настолько "известный", что формат вполне можно было бы изменить и сделать вид что ничего не было, а старые файлы пометить как формат версия 0.
Придется конечно так или иначе какое-то время тащить чтение строго варианта или по хардкору дропнуть совсем, станет популярным - никто не заметит.
>Проприетараст и копираст добавил поддержку формата изображений JPEG XL в проприетарное приложениеДавайте о каждом добавлении поддержки какого-либо формата в какие-либо прориетарные приложения делать новость на OpenNet - портале о свободном ПО.
Видимо других вариантов продать этот завязанный на облака и AI лапоть тем, у кого есть что-то хотя бы уровня S10 нет)
Это лучше avif? Если да, то чем?
Вроде со сжатием немного лучше:
https://opennet.ru/59276-jpegxl
Но так не сильно отличаются.
на encoding тратят сильно больше с avif.
jpeg xl зачастую весит чуть меньше и качество заметно лучше.
ну и последний может loseless пережать все текущие jpeg, png, gif - получив 25-30% сжатия
>на encoding тратят сильно больше с avifне соответствует действительности, avif гораздо дольше и дороже в лосси режиме, файлы получаются раздутые и с кучей дефектов, а лосслесс у него ненастоящий
>25-30% сжатия
10-99.9% сжатия, 60% экономии в среднем относительно стандартного png (оптимизированный адобовский может оказаться всего процента 3 меньше или вообще на 5% больше файл получится, но это редко такие файлы встречаются).
Для лосслесс жпег реконструкции (которая быстрая и нет буквально никаких причин хранить старые жпеги) в среднем 20%, но опять же легко и 99% может оказаться.
Оно до сих пор шакалит людей на переднем плане если высокочастотный задний фон предварительно не заблюрить? Т.е. они в 2024 году до сир пор не прикрутили открытую библиотеку для определения людей в кадре, чтобы отдавать им приоритет битрейта, а не асфальту на заднем фоне? Да там даже api такого нет, чтобы можно было передавать кодеру маску приоритета битрейта. Какой позор.
Зачем блюрить фон? С чего ты вообще решил, что рассматривать будут не фон. Видимо, именно благодаря подобным эвристикам, av1 такой шакальный и ни для чего не пригоден, да? Весь битрейт идёт на очень важные сгалюционированные гличи и мыло ничуть не спасает (оно спасает hevc в индусском исполнении).
Зачем мне идеально закодированный фон в портретном фото если лицо человека из за него всё в квадратах??? Мне на png из за этого переходить? Где маска приоритета битрейта, где простейшее определение людей в кадре при кодировании? В 2024 году, 99,98% всех фото со смартфона содержат человека на переднем плане, простое определение человека в кадре и предоставления ему приоритета битрейта уже сэкономит кучу места.
Обычно, когда люди фотографируются на фоне предметов, их можно совершенно безболезненно убрать и оставить представляющий единственную ценность фон.
Ну не у всех есть фотостудия, извините.
> Зачем мне идеально закодированный фон в портретном фото если лицо человека из
> за него всё в квадратах??? Мне на png из за этого
> переходить? Где маска приоритета битрейта, где простейшее определение людей в кадре
> при кодировании? В 2024 году, 99,98% всех фото со смартфона содержат
> человека на переднем плане, простое определение человека в кадре и предоставления
> ему приоритета битрейта уже сэкономит кучу места.Зато пейзажники одобряют. Не зря же некоторые приложения уже умеют затирать мимокрокодилов что лезут в кадр.
Если чуть-чуть понимать, как вообще происходит сжатие в JPEG - совсем чуть-чуть, не надо даже в дебри лезть - то быстро доходит, почему "блюр" - это худшее, что можно дать на вход...
> There can be multiple frames, with non-zero duration (for animation) or with zero duration (making them work more like layers in graphics software).Кэп открыл педивикию и разрешил прикрутить.
Где-то в уголке плачут бывшие ветераны мс со своим jpeg xr.
Ну хоть exfat пропихнули.
Mozilla не считает себя сторонником формата. Когда вопрос поставили ребром, получили такой ответ: "After a lot of consultation (and time, sorry), we've concluded that we are neutral on JPEG-XL" - https://github.com/mozilla/standards-positions/issues/522#is...
Они взяли AVIF:
https://opennet.ru/52871-avif
У него нет таких фич, как lossless-пережатие JPEG'ов и прогрессивная загрузка.
Lossless-режим сделан для галочки и хуже, чем в WebP и PNG (JPEG XL среди них лучший).
"Нейтральный" это значит что Мозилла пойдет по течению, если все ломанутся реализовывать и сервисы будут использовать - Мозилла тоже будет поддерживать. Если все будут дропать - Мозилла не станет бодаться и тоже дропнет.
Когда они явно против это совсем другое.
Если считать с учётом распространённости браузеров, то "все" (большинство) - это Google.Где та Mozilla, которая свой APNG пропихивала?
> Если считать с учётом распространённости браузеров, то "все" (большинство) - это Google.
> Где та Mozilla, которая свой APNG пропихивала?Ну вот собственно после APNG они и стали нейтральными по форматам. Задольбало их пихаться с Гуглем. Если не забыли, весь этот спор c APNG и WebP закончился взаимной уступкой - Мозилла сделала WebP, Гугл - APNG.
> Задольбало их пихаться с Гуглем.Так можно было бы сказать, если бы они в этот раз тоже хотели что-нибудь выторговать, но нет, с чего вдруг?
