Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	+/–
Сообщение от opennews (??), 10-Июн-23, 13:41
Компания Apple включила по умолчанию в бета-версии браузера Safari 17 и движке WebKit поддержку формата изображений JPEG XL, от поддержки которого в Chrome в прошлом году отказалась компания Google. В Firefox поддержка формата JPEG XL доступна в ночных сборках (включается через image.jxl.enabled = true в about:config), но Mozilla пока сохраняет нейтральную позицию в вопросе продвижения этого формата... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59276
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

2. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	+13 +/–
Сообщение от Аноним (2), 10-Июн-23, 13:47
У Гулага просто есть своя карманная вебп. Она получше авиф и прочей дряни, но тоже уг. А у JXL конкурентов не существует, это Гулаг думает, что евоный шлак способен конкурировать, но он просто выставляет себя на посмешище в очередной раз.
Ответить | Правка | Наверх | Cообщить модератору

Часть нити удалена модератором

	11. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	+6 +/–
	Сообщение от Аноним (11), 10-Июн-23, 14:16
	1) По пункту webp vs jpegxl анон полностью прав. JXL технологичней кодирования ключевых кадров из VP8. 2) По пункту очередного обсёра гугла. Непонятно упорство гугла, когда формат royalty-free, это да, с этим не поспоришь. А по поводу "очередности" обсёра. Это доля (участь) корпораций делать всякие волны и плюсы, и тащить их до полных похорон, сохраняя хорошую мину при плохой игре и итогах этой игры.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	–2 +/–
	Сообщение от Гогольмоголь (?), 10-Июн-23, 18:19
	>2) По пункту очередного обсёра гугла. Непонятно упорство гугла, когда формат royalty-free, это да, с этим не поспоришь. И чо? Вот жупег изначально тоже типа халявный, а потом выяснилось, что там запатентованные алогритмы Ты штоли будешь плотить, если патентный тралл на подет на Гугл?)))
	Ответить | Правка | Наверх | Cообщить модератору

	73. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	+/–
	Сообщение от Аноним (73), 10-Июн-23, 22:47
	Во время JPEG были более технолоничные форматы сжатия с потерями. Про убогий GIF я вообще молчу. Да и PNG недалеко ушёл — о божечки, мы придумали жать изображение в ZIP! Но. Ведь аноним всё сделал для поддержки более лучших форматов?
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	87. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	+4 +/–
	Сообщение от iZEN (ok), 11-Июн-23, 12:22
	> Да и PNG недалеко ушёл — о божечки, мы придумали жать изображение в ZIP! Формат PNG не только имеет поддержку сжатия без потерь, но и неограниченноую палитру цветов, прозрачность (альфа-канал), гамма-коррекцию, цветовую коррекцию (ICC). Это растровый формат, в котором можно сохранять промежуточные файлы двумерной растровой графики для последующего редактирования.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	–3 +/–
	Сообщение от Аноним (73), 12-Июн-23, 12:07
	Клёво, а в анимацию умеет? Как промежуточный формат — вы шутите? Или его реально так кто-то использует?
	Ответить | Правка | Наверх | Cообщить модератору

	112. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	+/–
	Сообщение от Аноним (112), 13-Июн-23, 18:45
	> Клёво, а в анимацию умеет? Да, через формат на его основе известный как APNG. Интересно тем что даже декодеры не понимающие именно APNG видят сие как валидный PNG из первого кадра в файле. В основном мозилла продвигала но хром APNG тоже умеет уже много лет. > Как промежуточный формат — вы шутите? Или его реально так кто-то использует? Вполне вариант - а что, lossless же и сжатие умеет. Меньше места чем цатимегабайтные простыни без сжатия занимает. И хотя это обычный zlib, за счет префильтров не так уж и плохо жмет многие виды картинок. Но, конечно, не фоточки - это больше для lineart/computer generated/etc.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	+/–
	Сообщение от Аноним (40), 10-Июн-23, 19:34
	> Гулаг думает, что евоный шлак Большинство разработчиков формата JXL из Google.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	46. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	–1 +/–
	Сообщение от Аноним (2), 10-Июн-23, 20:02
	Не знаю как там насчёт формата, но как минимум половина (и вроде даже лучшая лосслесс половина) это кодер целиком взятый с гулаговского кладбища мёртвых проектов, поэтому отношение сотрудников отчасти можно понять.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	+2 +/–
	Сообщение от совсем не аноним (?), 10-Июн-23, 20:13
	скоро выходит Jpeg ai, опять все переписывать
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	85. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	+2 +/–
	Сообщение от Аноним (85), 11-Июн-23, 10:38
	посмотрел несколько тестов кодирования. интересовали результаты jpeg xl и wepb. Да, jpeg xl оказался эффективней (около 6% преимущество), но вот скорость кодирования webp оказался существенно лучше -- примерно в 8 раз быстрее. Думаю, в некоторых случаях это довольно существенно.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	92. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	+/–
	Сообщение от Аноним (2), 11-Июн-23, 19:47
	Вебп очень плох в плане сохранения качества в пересчёте на размер. И вебп2 не намного лучше. Но главная беда это ограничения формата и кодера. На практике, там далеко не 6%. Насчёт скорости не скажу, png тоже медленный.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	+/–
	Сообщение от VladSh (?), 12-Июн-23, 13:33
	В некоторых случая да. Но браузер предназначен для отображения, т.е. для декодирования. И если скорость декодирования не отличается в худшую сторону, то не вижу причин, чтобы не включить поддержку.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	111. "В Safari 17 и WebKit включена поддержка формата изображений JPEG XL"	+/–
	Сообщение от Аноним (112), 13-Июн-23, 18:41
	> У Гулага просто есть своя карманная вебп. Она получше авиф и прочей > дряни, Yolo!!! WebP это по сути I-фреймы из кодека VP8 в упрощенном формате файла. На память об этом умеет только YUV и только с субсэмплингом. High-bitdepth, RGB цветовые пространства и прочие глупости не умеет принципиально. Так что даже для фоточек не предел мечтаний. Ну да, поэффективнее жыпега. Но с тех пор был VP9. А потом - на его основе (точнее, на основе прототипа VP10) - в смеси с Thor и Daala - появился AV1. Чьи I-фреймы стали - только подумайте - AVIF. То-есть AVIF чисто технически является дальним потомком WebP. Улучшенным по всем мыслимым параметрам. И как раз специально сделан менее карманным - чтобы и остальные внедрили поддержку охотнее. Что они и сделали.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
Сообщение от Аноним (3), 10-Июн-23, 13:50
Вдруг webp станет никому не нужен? Подскажите, а webp придумали не потому, что его сделать можно просто выдернув кусок из webm-потока и подправив заголовок?
Ответить | Правка | Наверх | Cообщить модератору

	8. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (11), 10-Июн-23, 14:07
	webp - это контейнер RIFF (некоторая обвязка) над алго сжатия, которые применяются для кодирования ключевых кадров (I-frame, keyframe), для декодирования которых не нужны другие кадры (Intra-coded) кодека VP8.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
	Сообщение от Аноним (12), 10-Июн-23, 14:24
	Так это выдернутый ключевой кадр из VP8, засунутый в webp контейнер, или нет? Я имею в виду, не могли ли этот формат придумать и внедрить для оптимизации формирования миниатюр на YouTube? Знаю, что YT всё видео перекодирует, но у них такие объёмы, что даже маленькое улучшение, вроде экономии на формировании миниатюр, может дать сколько-то денег.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 10-Июн-23, 15:12
	>Так это выдернутый ключевой кадр из VP8, засунутый в webp контейнер, или нет? Я не специалист, но судя по тому, что я видел, что говорят про WebP/HEIF/AVIF - это именно выдернутые ключевые кадры. Придумали их всё же не ради миниатюр, а ради вторичного использования имеющегося кода и аппаратного ускорения видео. Отсюда проистекают ограничения этих форматов (маленькое разрешение, ограниченный выбор сабсэмплинга, ограниченная битность каналов и т.д.). Зато очень дешёвое good enough решение.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (112), 13-Июн-23, 18:49
	> про WebP/HEIF/AVIF - это именно выдернутые ключевые кадры. Ну да. И к тому же AV1 (AVIF ключевой кадр AV1) сильно эффективнее чем VP8 (WebP - ключевой кадp VP8) и как он может быть хуже чем предок решительно не понятно. К тому же умеет сильно больше форматов.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 13-Июн-23, 19:24
	Непонятно только теоретикам. Он дефективный и артефачит на пустом месте, больше искажает цвета. Собственно, я жду, когда av1 уже окончательно загнётся, большей мерзости я ещё не встречал (он превзошёл в свой мерзости и никчёмности vp9). Есть слабые надежды, что av2 исправит ситуацию, но это не в ближайшие годы. Так что vp9 в вебе с нами надолго. Ну а jxl вообще первый реальный кандидат заменить jpeg за 30 лет. И png с webp заодно полностью заменить способен.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
	Сообщение от Аноним (112), 13-Июн-23, 22:32
	> Непонятно только теоретикам. Он дефективный и артефачит на пустом месте, больше искажает цвета. Больше чем YUV с субсэмплингом то? :))) С RGB-скрина десктопа какого? Ну да, конечно, а вы их местами не попутали? Потому что VP8 даже чисто теоретически не способен нормально воспроизводить вид допустим RGB-based скринов с компа, хоть там тресни. Практически, на скринах содержащих мелкий цветной текст, VP8 вытворяет полный кошмар. Просто за факт конверсии в дурной телевизионщиковый YUV с субсэмплингом как формат пикселей. А других форматов VP8 никогда не умел, это его главное ограничение. > Собственно, я жду, когда av1 уже окончательно загнётся, большей мерзости > я ещё не встречал (он превзошёл в свой мерзости и никчёмности vp9). Вот это я понимаю - ретардизм в терминальной стадии как он есть. Упереться рогом в телевизионщицкий YUV с субсэмплингом на компе и считать его венцом творения. При том что он вообще в принципе не способен нормально передать допустим цветной мелкий текст из-за вот этого самого субсэмплинга и убогого колорспейса у телевизионщиков из тепло-ламповых эпох. Хотя, возможно, этому анонму заходили блеклые мутные картинки с севших совеццких кинескопов и поэтмоу четкие сочные картинки где все детали идеально вызывают отвращение? > Есть слабые надежды, что av2 исправит ситуацию, но это не в ближайшие годы. Хватит пургу гнать, а? Или давайте пруфскрины - с воспроизводимым описанием как и чего. Потому что описать как VP8 ушатать я вот тут описал. И это весьма воспроизводимо, особенно на красном, сиреневом и тому подобном тексте (субсэмплинн YUV такое жестче всего рушит). > Так что vp9 в вебе с нами надолго. AV1 так то - superset оного. Чисто технически. И я уж не знаю чем вы его кодировали что он хуже выглядел, штатным libaom он явно лучше VP9 по всем пунктам. Единственный вариант который я знаю как вообще AV1 получить хуже VP9 это взять доисторический FFMPEG - он там уже умел high-bidepts и YUV 4:4:4 для VP9, но не умел для AV1. Но это было чертову кучу времени назад когда поддержка AV1 в ffmpeg отставала от VP9. В актуальных версиях он легко покажет мастеркласс по качеству VP9. Впрочем I-фреймов VP9 никогда не было как картинок в вебе. > Ну а jxl вообще первый реальный кандидат заменить jpeg за 30 лет. На мой вкус AVIF куда как реальнее. > И png с webp заодно полностью заменить способен. Png таки заметно иная щтука - это по сути массив пикселей как есть сжатый zlib. Сразу в RGB формате чаще всего и без субсэплингов и прочего доисторического телевизионщицкого крапа. В видео этот крап еще имеет какой-то смысл, т.к. уменьшает объем данных и там это актуально, но даже там - допустим гуры с doom9 советуют для этих кодеков форсить YUV 4:4:4 и HBD. Даже если это медленнее и данных больше, качество картинки сильно лучше. Хлам типа YUV 4:2:0 должен умереть. А vp8 как раз ничего иного не умеет и каким макаром для вас он лучше получается - загадка природы. Для computer-generated скринов это вообще непотребно, допустим. И уж точно не замена png в этом качестве.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 13-Июн-23, 23:34
	Именно так, обычный cwebp+sharp_yuv на пару порядков лучше обычного libaom в плане цветопередачи 8 битного цвета (во всяком случае без chroma=444 и matrix_coefficients=0, которые делают применение avif сомнительной затеей). Ну, это факт. Он не галюционирует, например. Цветопередача в лосси НИЧЕМ не хуже таковой у jpeg. И есть лосслесс режим. А у avif его нет.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (112), 14-Июн-23, 22:10
	> Именно так, обычный cwebp+sharp_yuv на пару порядков лучше обычного libaom > в плане цветопередачи 8 битного цвета (во всяком случае без chroma=444 Кривая цветопередача в основном заслуга subsampling самого по себе. И в этом плане aom vs vp8 вполне симметричен - и VP9 был лучше из-за вот этого в том числе. Просто 8-бит YUV 4:2:0 в принципе не способен нормално передать "компьютерные" картинки. А если учесть что конверсия RGB -> YUV с разрядностью менее 10-12 битов на составляющую lossy сама по себе... Как-то это катить может только с "фотографическими" картинками, и даже там - если знать что искать, находится влет. Что AV1, что VP8, что любой другой кто subsampling сделал. Даже на фотах. Фоты обычно грузятся с матрицы в байеровском формате и это ближе к RGB по смыслу, хоть и не совсем оно. Так что YUV вообще... не особо в тему. Особенно 4:2:0. И именно поэтому vp8 и пролетает, он другого просто не умеет. В случае мувика vs aom, жать мувик через 10 или 12-бит code path, как 4:4:4 медленнее, и это аргумент "против" идеи (кому интересно см дискуссию на doom9.org). Но вообще при этом лучше работают все предикторы, нет потерь на конверсиях, и даже на 4:2:0 мувиках за счет большей точности получается парадокс: файл и меньше по весу и лучше выглядит! (для обоих одинаковый Q ессно). В случае единичной картинки - нет смысла экономить нагрузку на проц, используя телевизионщицкие YUV обрубки вообще. Это глупо. > и matrix_coefficients=0, которые делают применение avif сомнительной затеей). Коэффициенты можно и не трогать имхо. А вот HBD path без subsampling - мастхэв для большинства картинок. Особенно "компьютерных". Они нормально только в RGB-колорспейсе выглядят ессно. > Ну, это факт. Он не галюционирует, например. Цветопередача в лосси НИЧЕМ не хуже > таковой у jpeg. И есть лосслесс режим. А у avif его нет. Как нет? Даже у AV1 который видео - он есть. А уж у его I-frame и подавно. Плюс-минус точность конверсий разумеется (лишняя причина хотеть HBD codepath). И вот так он - весьма такая мощная и кондовая штука на самом деле. И уж не VP8 с ЭТИМ рубаться, он вообще HBD и 4:4:4 не умеет, как и RGB-колорспейс в нормальном виде. И вот тут гугл явно поспешил, выбрав именно ЭТО для webp. А вот AVIF от этих бестолковостей пролечен - как и AV1.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Анонус (?), 10-Июн-23, 15:16
	> Так это выдернутый ключевой кадр из VP8, засунутый в webp контейнер Если совсем точно, то в AVI-контейнер (хотя RIFF применяется в довольно многих форматах медиафайлов).
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	116. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (112), 13-Июн-23, 22:44
	> Если совсем точно, то в AVI-контейнер (хотя RIFF применяется в довольно многих > форматах медиафайлов). Вообще-то этот контейнер называется как раз RIFF. AVI файлы является частным случаем оного контейнера. Есть и другие. Скажем, WAV - тоже частный случай RIFF контейнера. Но другого, по набору чанков с AVI имеет мало общего. Есть и некоторые иные RIFF-based контейнеры а также несколько иных форматов в этом стиле, когда идет FOURCC-идентификатор, длина, и данные такого размера, возможно, с вложенными аналогичными структурами. Более того - PNG также следует этому паттерну, он не RIFF (его первый тэг как раз PNG) но идея остается. И кстати ISO BMFF (известный многим как "mp4") использует весьма похожие идеи, хотя там конкретное представление чанков немного отличается в деталях.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
	Сообщение от Аноним (45), 10-Июн-23, 19:56
	>Так это выдернутый ключевой кадр из VP8, засунутый в webp контейнер Так точно.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

5. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
Сообщение от Аноним (5), 10-Июн-23, 13:58
Лучше бы они вместо того чтобы высказываться высылали бабулесы в Гугл. Вот это был бы совсем другой разговор.
Ответить | Правка | Наверх | Cообщить модератору

	10. "В Safari 17 и WebKit включена поддержка формата изображений ..."	–1 +/–
	Сообщение от Тот_Самый_Анонимус__ (?), 10-Июн-23, 14:14
	Лучше бы ты вместо своего высказывания денег перевёл нуждающимся.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
	Сообщение от Аноним (5), 10-Июн-23, 14:59
	Перевёл твоя очередь.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Тот_Самый_Анонимус__ (?), 10-Июн-23, 22:46
	> Перевёл твоя очередь. Пфф, без пруфов не катит.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (95), 11-Июн-23, 23:14
	Отправил бабулю в гугл, с ней все будет в порядке?
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	106. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Абрахимн Ибо Гуглин (?), 13-Июн-23, 09:13
	Хапроий бабушка, научим golang, обучим играть go, наймем разрабатывать alphago
	Ответить | Правка | Наверх | Cообщить модератору

	107. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (107), 13-Июн-23, 15:20
	Еще бы, иначе сможешь неплохо поднять баб(осов) за эйджизм и сикхизм
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

6. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
Сообщение от Аноним (5), 10-Июн-23, 13:59
И вообще анимированный jpeg сразу в гарбедж без раздумий.
Ответить | Правка | Наверх | Cообщить модератору

	7. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
	Сообщение от Аноним (2), 10-Июн-23, 14:07
	Там с анимациями не очень пока емнип. Но вот типичная гифка 100 кадров 5-10 гигабайт, с этим вполне может конкурировать уже сейчас. Одна из киллер фич сабжа это быстрое лосслесс перекодирование уже существующих жпегов с потерями (чтобы получить хороший результат, исходник должен быть без потерь), на моём опыте 20-40% экономии в среднем (до ~99%) и этот тот же жпег остаётся.
	Ответить | Правка | Наверх | Cообщить модератору

	9. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 10-Июн-23, 14:10
	Но кстати повторное лосси кодирование не уменьшает размер (некуда уменьшать), но способно спрятать жпег артефакты получше альтернатив.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
	Сообщение от Аноним (12), 10-Июн-23, 14:25
	Абсолютно. Есть же видеокодеки для такого.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	14. "В Safari 17 и WebKit включена поддержка формата изображений ..."	–1 +/–
	Сообщение от Аноним (2), 10-Июн-23, 14:31
	MJPEG хороший кодек, но всё же подустарел.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "В Safari 17 и WebKit включена поддержка формата изображений ..."	–1 +/–
	Сообщение от Аноним (25), 10-Июн-23, 15:02
	Он хорош двумя вещами: 1) низкая вычислительная сложность 2) отсутствие межкадрового сжатия, что полезно, когда недопустимо "додумывание" кодеком деталей изменений в кадре. Что делает его идеальным для, например, автомобильных видеорегистраторов. В остальном он, прямо скажем, лучше только полного отсутствия сжатия и сжатия видео без потерь универсальными компрессорами типа Deflate и ко.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Бывалый смузихлёб (?), 11-Июн-23, 09:46
	Попробуй-ка на мелком маломощном устройстве с мизером памяти организовать видеотрансляцию С MJPEG это вполне получается Разве что звука нет. Но и частота кадров получается неплохой
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	96. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (95), 11-Июн-23, 23:19
	Проблема Mjpeg в том что аппаратного ускорения нет, хотя раньше софт умел, не знаю что изменилось, но теперь просмотр потока с ip камеры что под linux что под windows жрет процессор как не в себя.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Бывалый смузихлёб (?), 12-Июн-23, 05:07
	Там в чём-то другом может быть проблема По крайней мере, уж если какой-нибудь есп-32 тянет получение кадров с камеры, их обработку и отправку, то для ПК сложностей вообще быть не должно. Разве что камер много или на компе происходит перекодирование в другой формат
	Ответить | Правка | Наверх | Cообщить модератору

	104. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (95), 12-Июн-23, 15:32
	Нет, проблема именно в том что теперь аппаратного ускорения видео mjpeg нет, ни в браузерах ни в приложениях, даже если например использовать ip камеру в качестве камеры для Скайпа декодирование идёт на процессоре, это началось когда в windows 10 внедрили frame server, а в linux не знаю когда и по какой причине.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (112), 13-Июн-23, 22:47
	> Попробуй-ка на мелком маломощном устройстве с мизером памяти организовать видеотрансляцию > С MJPEG это вполне получается > Разве что звука нет. Но и частота кадров получается неплохой Частота кадров получается неплохой только если битрейта завались. Поскольку inter-frame сжатия нет как класса, вместо того чтобы слать дельту между кадрами оно весь кадр заново шлет. По поводу чего приличный FPS требует дочерта бандвиза сети. Мягко говоря.
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	20. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (5), 10-Июн-23, 15:01
	Даже сам эпл у себя на сайте делает анимации плавных переходов или разворотов простыми видеофайлами и у них нормально получается.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	34. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (34), 10-Июн-23, 16:35
	>By today (Oct 2022), we still can only use <img src=".mp4"> on Safari. If you want to make MP4 files work like GIFs on other browsers, you might wanna use <video autoplay muted loop>. https://stackoverflow.com/questions/60114243/using-videos-in...
	Ответить | Правка | Наверх | Cообщить модератору

	118. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (112), 13-Июн-23, 22:51
	> Даже сам эпл у себя на сайте делает анимации плавных переходов или > разворотов простыми видеофайлами и у них нормально получается. Кроме того момента что реклама делающая это же самое но нагло и бесяще всех достала, так что не любой браузер вообще разрешает автовоспроизведение видео и на этом направлении можно хлебнуть горя и глюков.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

16. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
Сообщение от Аноним (25), 10-Июн-23, 14:47
Всё-таки есть что-то подозрительное в том, что JPEG XL использует в качестве целевой метрики Butteraugli производства тех же самых разработчиков и большую часть своего преимущества в качестве обосновывает именно на превосходстве в этой метрике, а при сравнении с помощью простого и понятного PSNR, которому сто лет в обед, сливает конкурентам, в том числе очень старым типа JP2.
Ответить | Правка | Наверх | Cообщить модератору

	24. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 10-Июн-23, 15:09
	Что подозрительного? Имеет значение только визуальное качество и PSNR это очень плохая метрика для оценки потерь. Если сравнивать качество, то Peak Absolute Error чуть получше, но тоже не идеал. На зуме лосси выглядит плоховато, когда меньше q96, но зависит от источника тоже. Могут быть небольшие артефакты на краях, у конкурентов артефакты намного хуже. q97 очень близко к pixel-perfect. При этом, размер этого q97 аналогичен jpeg q93 который с кучей атрефактов идёт без вариантов. Кое-что не жалко и в q94 пожать, разница будет не видна, если не включать 800-кратный зум. К лосслесс претензий быть не может.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 10-Июн-23, 15:18
	Подозрительное оно тем, что Butteraugli сложный (и их собственный — конфликт интересов же), а PSNR — простой. Согласен, что PSNR — не лучшая метрика, но сложные метрики демонстрируют большую хрупкость на нестандартных (не предусмотренных разработчиками) изображениях, ИМХО. На r/jpegxl периодически появляются темы про то, что их visually lossless не такой уж и visually lossless на изображениях.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Cucumber (?), 10-Июн-23, 21:37
	Можно просто своими глазами сравнить, jpegxl явно лучше гугловского webp, соревнуясь только с avif https://storage.googleapis.com/demos.webmproject.org/webp/cm...*1:1&JXL=t&AVIF-AOM=t&subset1
	Ответить | Правка | Наверх | Cообщить модератору

	69. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (69), 10-Июн-23, 21:53
	Быть лучше webp не так уж и трудно, так как это довольно старый формат с ограничениями типа "только 4:2:0 сабсэмплинг". Как он в сравнении с JP2? В моём ограниченном исследовании WebP проигрывал ещё более старому JP2. Avif, кстати, в PSNR превосходен и в вышеупомянутом исследовании обходил JP2. Я не удивлюсь, если одной из причин, почему гугл выбрал его — это то, что он очень хорош в классической метрике и ему не нужны новоиспечённые метрики, придуманные разработчиками самого формата.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (123), 14-Июн-23, 20:27
	Jpeg XL однозначно лучше Jpeg 2000 в любых пресетах: https://twitter.com/jonsneyers/status/1532771586381688833 С точки зрения Jpeg Group, он заменяет 2000 и нет смысла больше смотреть на него, после появления XL.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 15-Июн-23, 14:27
	Снейерс и Клаудинари, проводившие это исследование — одни из разработчиков и популяризаторов JXL, так что я отношусь с изрядной долей скепсиса к их утверждениям из-за неизбежного конфликта интересов. Всегда можно подобрать такой корпус изображений и такую метрику, что победит "нужная" сторона. Это же касается и Google с AVIF (в чём собственно их и обвиняют Снейерс et al., занимаясь ровно тем же, только ещё и изобретя самоиспечённую метрику Butteraugli), но сейчас речь не о них. Вообще, почти все дифирамбы JXL исходят от: • его разработчиков (что понятно и естественно); • неискушённых людей, которые судят о качестве формата преимущественно по его способности лосслесс дожатия JPG файлов и лосслесс сжатия, но практически не используют его лосси возможности. Отсутствие реакции (мало-мальски обширных исследований) от компетентных третьих сторон наводит на мысль о том, что реальная востребованность этого формата в области лосси сжатия не так уж и велика. >С точки зрения Jpeg Group, он заменяет 2000 и нет смысла больше смотреть на него, после появления XL. Не думаю, что это так: на сайте самой JPEG (https://jpeg.org/) JP2 идёт сразу за JPEG, а JPEG XL где-то в конце списка вместе с другими, ещё менее известными форматами. https://jpeg.org/jpeg2000/index.html указывает, что для JP2 было выпущено 15+1 частей функций формата, в то время как для JXL только 4 (https://jpeg.org/jpegxl/index.html). Описание JXL довольно чётко позиционирует его как замену JPEG на массовом рынке, в то время как JP2 позиционируется как "the Swiss Army knife of image codecs", то есть стандартизированный формат, который умеет не только то, что востребовано масс-маркетом, но и очень специфические вещи, которые востребованы в узких нишах (вроде 3d изображений и т.п.)
	Ответить | Правка | Наверх | Cообщить модератору

	133. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 15-Июн-23, 14:31
	>частей функций формата частей стандарта, конечно
	Ответить | Правка | Наверх | Cообщить модератору

	134. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (134), 15-Июн-23, 15:08
	> • неискушённых людей, которые судят о качестве формата преимущественно по его способности лосслесс дожатия JPG файлов и лосслесс сжатия, но практически не используют его лосси возможности. Даже если вот просто с этим согласиться закрыв глаза на... всё, то всё равно получается, что он способен заменить JPG (причём с заметным профитом) и при этом еще быть на уровне со всеми остальными современными конкурентами в категории lossy. В совокупности со всеми остальными преимуществами, он скорее всего сейчас лучше всех подходит на замену jpg, png, gif (причём их всех одновременно). То есть, в любом случае, делает win над другими конкурентами по overall (даже если по каким-то отдельным категориям что-то из современных-окункурентов его слегка и обгоняет). А, собственно, этого многие и хотят.
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	136. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 15-Июн-23, 21:08
	Мне кажется, что JXL силён в том, что в интернете особо и не нужно. Для векторной графики, где важно отсутствие артефактов сжатия (лосслесс), имеет смысл использовать SVG (принципиально другой формат), а для фото в онлайне нет какого-то особого спроса от разработчиков сервисов на лосслесс форматы из-за того, что они в любом случае будут требовать слишком большой пропускной способности от сервиса (а это лишние расходы) — соответственно, в онлайне нужно лосси сжатие, где кодеки на основе видеосжатия очень удобны, так как уменьшают количество нового кода и позволяют задействовать аппаратное ускорение. Более того, разработчики видеокодеков не делают вид, что вот этот-то формат будет последним словом в технологии сжатия — они постоянно выкатывают что-то новое, соответственно, от форматов изображения на их основе и не будет требоваться многого, потому что «пока и так сойдёт, а в будущей версии, которая выйдет скоро, возможно, улучшим». Лосси JXL уже 100% устареет для интернета как только выйдут эти самые новые будущие кодеки. Для использования вне интернета JXL даёт лишь большую степень сжатия по сравнению с предыдущими форматами, что, конечно, хорошо, но не так что бы уж очень актуально в мире постоянно дешевеющего стораджа. Зато отсутствие поддержки множеством программ и устройств по сравнению с теми же TIFF или PNG (или JP2 в специализированных областях) пользователями будет ощущаться весьма остро. Излишние амбиции, выражающиеся в попытках сделать всё и сразу, нередко убивают перспективные проекты. Однако понятно, почему Cloudinary на это пошли — им не интересен оффлайн, они хотят заполучить онлайн, где их формат не так уж и силён, потому что его сильные стороны в онлайне не будут особо востребованы.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 15-Июн-23, 21:15
	Я хочу добавить, что экономия места, которую даёт пережатие JPG в JXL, тоже актуальна, по большому счёту, только в оффлайне — для хранения. Онлайн сервисы уже очень давно транскодят JPG в новые лосси форматы для отдачи клиентам и клиенты не жалуются на следующую из этого потерю качества, потому что большинство пользователей не занимается разглядыванием пикселей. Соответственно, передача лишних байт, которые будет иметь JPG картинка, пережатая в лосслесс JXL по сравнению с нею же пережатой в другой лосси формат, пользователем оценена в должной степени не будет. Для тех редких случаев, когда фото надо передать клиенту без изменений, поддержка браузером конечного формата, по большому счёту, не требуется.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (134), 16-Июн-23, 15:56
	> Онлайн сервисы уже очень давно транскодят JPG в новые лосси форматы для отдачи клиентам А тут прикиньте - транскодить не надо будет каждому клиенту (умножайте на количество клиентов например у гугла). Один раз перегнать надо только. Экономия места, экономия ширины канала, экономия процессорного времени. Берёте гугл как пример и представляете экономию ресурсов (и денег). > Для тех редких случаев, когда фото надо передать клиенту без изменений, поддержка браузером конечного формата, по большому счёту, не требуется. Про редкие случаи - это вы щас , например, про любое изображение в инете, например, с мелким текстом? Громкое заявление. Просто для примера: логотип опеннета из шапки сконверченный в jxl на 25% меньше становится. Без потери качества. Отмасштабируйте эффект какую-нибудь соцсеточку или фотохостинг.
	Ответить | Правка | Наверх | Cообщить модератору

	147. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 16-Июн-23, 17:34
	>А тут прикиньте - транскодить не надо будет каждому клиенту (умножайте на количество клиентов например у гугла). Один раз перегнать надо только. Экономия места, экономия ширины канала, экономия процессорного времени. Берёте гугл как пример и представляете экономию ресурсов (и денег). Оно и сейчас так происходит — перекодированные изображения кэшируются, конечно; их не перекодируют при каждом запросе. Проблема в том, что пока таких лосси форматов нужно больше одного, но если победит условный AVIF или JXL, то он и будет один, пока не появится следующее поколение форматов (а оно неизбежно появится) — не важно кто, среднестатистического пользователя устроит любой, потому что он не разглядывает пиксели. >Про редкие случаи - это вы щас , например, про любое изображение в инете, например, с мелким текстом? Громкое заявление. >Просто для примера: логотип опеннета из шапки сконверченный в jxl на 25% меньше становится. Без потери качества. Отмасштабируйте эффект какую-нибудь соцсеточку или фотохостинг. SVG. Для текста правильно использовать SVG. Не PNG, не GIF, не JXL, не AVIF — SVG. Есть, конечно, скриншоты, но тут справится даже JPG с менее агрессивными настройками. Думаю, AVIF тоже вполне может справится. Я имел в виду условные фотобанки, где клиент заходит на сайт, видит понравившуюся картинку (в лосси формате) и скачивает её уже в оригинальном лосслесс формате себе на компьютер для дальнейшего использования. Здесь поддержка лосслесс формата браузером не нужна — картинка просто скачивается на компьютер в оригинальном формате, а чем её откроет сам пользователь — это его дело.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (134), 16-Июн-23, 15:39
	> Мне кажется, что JXL силён в том, что в интернете особо и не нужно. Вы пытаетесь сказать, что в интернете не особо-то и нужен формат изображений, который лучше JPG, PNG, GIF и по сжатию и по совокупности? Давайте остановимся на том, что из моей аргументации в ответ будет только : ха-ха-ха. На такое даже отвечать серьезно нет смысла. Гугль вот считает иначе - там вон собственный WebP изобретали только ради этого, а вы тут вердикт вынесли: "нинужон". На этом лучше остановиться.
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

	146. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 16-Июн-23, 17:21
	>Вы пытаетесь сказать, что в интернете не особо-то и нужен формат изображений, который лучше JPG, PNG, GIF и по сжатию и по совокупности? Давайте остановимся на том, что из моей аргументации в ответ будет только : ха-ха-ха. На такое даже отвечать серьезно нет смысла. Гугль вот считает иначе - там вон собственный WebP изобретали только ради этого, а вы тут вердикт вынесли: "нинужон". На этом лучше остановиться. Вы передёргиваете моё высказывание. Я говорил лишь про лосслесс форматы — они действительно не очень нужны в вебе, где есть векторная графика и <video>. Расцвет GIF и PNG пришёлся на те времена, когда ничего этого в вебе не было. Сейчас это есть повсеместно. Насчёт JPG — да, ему нужна замена, но для этого не нужен уберформат, который умеет всё, включая то, что не нужно, а нужен только дешёвый в реализации формат, которого будет достаточно. Гугл так решил.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (112), 14-Июн-23, 22:27
	> Всё-таки есть что-то подозрительное в том, что JPEG XL использует в качестве > целевой метрики Butteraugli производства тех же самых разработчиков Да просто капец как подозрительно: те разработчики заметили (чуть быстрее чем Зоркий Глаз) что PSNR меряет погоду на марсе и попытались надизайнить метрику лучше. Это ессно получилось - PSNR это вообще нечто совершенно левое, и он коррелирует с визуальным качеством слабее чем того хотелось бы при использовании его как критерия оптимизации, так что уделать его не вопрос. Если что - тот же нетфликс по тем же причинам VMAF сделал допустим (больше для видео). А если ну совсем никак, SSIM есть но он тоже не очень хорошо работает для некоторых вариантов картинок. > и большую часть своего преимущества в качестве обосновывает именно на превосходстве > в этой метрике, а при сравнении с помощью простого и понятного PSNR, PSNR довольно хреново коррелирует с тем как качество картинки воспримут двуногие и поэтому он простой, понятный, но на этом его достоинства и заканчиваются. Как метрика он достаточно паршивый. > которому сто лет в обед, сливает конкурентам, в том числе очень старым типа JP2. А зачем надо оптимизироваться на архаичную метрику? Надо оптимизироваться на то чтобы двуногим нравилось, мы для них жмем а не для метрик. Butteraugli известен в тематичной среде тем что моделирует восприятие двуногих не в пример лучше - так что куда более реалистичный показометр. Потому и катит как оптимизационный критерий. Да, вы правильно поняли - энкодер перебирает много варантов кодирования, пытаясь найти тот который с минимальным размером и при том наилучшим "видом" (критерием визуальным оптимизации). Все и сразу конечно не получится но оптимальное соотношение размера данных к качеству при даденых constraints более-менее поймать можно. Кстати если кто удивлялся почему AV1/H265/266/etc медленно жмут: вариантов брутфорса оптимального кодирования стало сильно больше. Ну они и брутфорсят теперь кучу вариантов как лучше кодировать.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	140. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 16-Июн-23, 00:05
	>Как метрика он достаточно паршивый. Вопрос немного не об этом. Непонятно почему я должен принимать то, что Butteraugli непаршивый. Этих метрик полным полно было, что мешало взять какую-то готовую от сторонних авторов, а не придумывать свою? Откуда я могу быть уверен, что оптимизация на эту метрику, чьи свойства (в отличие от имеющегося PSNR, по которому куча peer-reviewed статей написано) не особенно хорошо изучены и описаны — это правильно? Почему в Гугле посмотрели на этот Butteraugli и решили, что на выбор того, какие кодеки оставить, а какие выкинуть, он влиять не должен, а должен влиять PSNR, который использовался в том самом отчёте, на основании которого было принято решение выкинуть JXL из хрома?
	Ответить | Правка | Наверх | Cообщить модератору

	141. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 16-Июн-23, 00:28
	Пардон, нашёл это сравнение и там речь про MS-SSIM, а не PSNR. Это не так уж и важно, так как MS-SSIM — тоже старая метрика, хорошо исследованная в академических источниках.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от uis (??), 15-Июн-23, 11:41
	> а при сравнении с помощью простого и понятного PSNR Лол, PSNR самая худшая метрика. Настолько плохая, что даже простой SSIM лучше.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

17. Скрыто модератором	+/–
Сообщение от Chromium (ok), 10-Июн-23, 14:51
Привет. Я знаю о JPEG XL. Это новый формат изображений, который поддерживает сжатие как с потерями, так и без потерь. Он разработан для улучшения качества и эффективности сжатия изображений в интернете и профессиональной фотографии. Он также поддерживает широкий цветовой диапазон, высокий динамический диапазон и высокую битовую глубину изображений²¹. Я думаю, что JPEG XL имеет много преимуществ перед старым форматом JPEG и другими современными форматами, такими как HEIC, AVIF и WebP. Он может существенно уменьшить размер изображений без потери качества, а также обеспечить обратную совместимость с существующими приложениями на основе JPEG². Он также может поддерживать анимацию, прозрачность, слои, миниатюры, постепенное кодирование и другие функции для разных сценариев использования¹. Он специально разработан для работы с широким цветовым диапазоном и высоким динамическим диапазоном, такими как Rec. 2100 с функцией передачи PQ или HLG². Так что я думаю, что внедрение JPEG XL может быть полезным для улучшения пользовательского опыта при просмотре и обработке изображений в интернете и за его пределами. Как ты думаешь? 😊 Источники: (1) JPEG XL - Wikipedia. https://en.wikipedia.org/wiki/JPEG_XL. (2) JPEG - JPEG XL. https://jpeg.org/jpegxl/. (3) JPEG XL — Википедия. https://ru.wikipedia.org/wiki/JPEG_XL.
Ответить | Правка | Наверх | Cообщить модератору

	18. Скрыто модератором	+/–
	Сообщение от Аноним (25), 10-Июн-23, 14:55
	Привет, Бинг 👋
	Ответить | Правка | Наверх | Cообщить модератору

	22. Скрыто модератором	+1 +/–
	Сообщение от Аноним (22), 10-Июн-23, 15:03
	Привет, ChatGPT.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	35. Скрыто модератором	+/–
	Сообщение от Аноним (35), 10-Июн-23, 17:00
	Аж затошнило пока читал... Слишком слащаво и оптимистично, на языке румяных и эффективных.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

23. Скрыто модератором	–3 +/–
Сообщение от ИмяХ (?), 10-Июн-23, 15:06
Гугл уже выкинул это устаревшее гвнo из своего браузера, а эти только начинают его поддержку. Вот сразу видно, кто реальный технологический гигант и шагает впереди планеты всей, а кто вечно догоняющий со своими депрекейтнутыми, никому не нужными технологиями.
Ответить | Правка | Наверх | Cообщить модератору

	29. Скрыто модератором	+2 +/–
	Сообщение от Анонус (?), 10-Июн-23, 15:20
	Но почему-то большая часть поделок технологического гиганта попадает сюда https://killedbygoogle.com/
	Ответить | Правка | Наверх | Cообщить модератору

	30. Скрыто модератором	+2 +/–
	Сообщение от birdie (ok), 10-Июн-23, 15:26
	Где вы достаёте такую жёсткую траву?
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

31. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
Сообщение от grayich (ok), 10-Июн-23, 15:26
почему бы подобное не выносить в модули, зачем тащить в базовый код
Ответить | Правка | Наверх | Cообщить модератору

	98. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Разработчики браузеров (?), 12-Июн-23, 00:48
	А что, так можно было???
	Ответить | Правка | Наверх | Cообщить модератору

36. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
Сообщение от Всем Анонимам Аноним (?), 10-Июн-23, 17:09
Прикольно, в гугловском багрепорте (который начал один из команды Chromium, кстати), вместо объективный доводов куча просто срача, типа какой гугл плохой, а аппл хороший. Могу поспорить, только 1% идет от людей, которые занимаются web разработкой, если они там вообще есть. Иначе бы обосновали почему вдруг в задницу клюнуло в 2023 году и им всем срочно понадобился именно этот формат только из-за того, что в его названии слово JPEG присутствует.
Ответить | Правка | Наверх | Cообщить модератору

	37. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
	Сообщение от Аноним (37), 10-Июн-23, 17:22
	> вместо объективный доводов куча просто срача Врать-то зачем?
	Ответить | Правка | Наверх | Cообщить модератору

	41. "В Safari 17 и WebKit включена поддержка формата изображений ..."	–2 +/–
	Сообщение от Аноним (69), 10-Июн-23, 19:38
	Вообще, я согласен, какой-то просто неприличный хайп трейн везёт этот JPEG XL — как будто это лучшее, что изобрело человечество со времён чесночного хлеба. В том же JPEG 2000, в общем-то, почти все эти фичи есть уже давным давно. Мегакорпорациям нужен формат для экономии трафика на изображениях, вот и всё, для этого webp/avif/heif за глаза хватает, а когда упрутся в их ограничения, их просто депрекейтнут, заменив новыми на основе новых будущих видеокодеков, которые и так чуть ли не каждый год выходят. Уберформаты, которыми  можно и гвозди забивать, и шурупы вкручивать (то есть хранить в высоком качестве с HDR, колор менеджментом и прочим блэкджеком) уже давно есть — TIF для лосслесс, JP2/JPX для лосси/лосси. Мне кажется если бы не этот уберпиар на каждом IT-углу, то никому особо этот JXL и не нужен был бы. Сообщения людей в багтрекере хромиума наводят на мысли о том, что туда просто нагоняют хомячков, которые просто не знают, что есть что-то ещё кроме JPEG, видеоформатов и их прелести.
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	43. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+2 +/–
	Сообщение от Аноним (5), 10-Июн-23, 19:39
	Уже есть нейросети кому интересный эти форматы?
	Ответить | Правка | Наверх | Cообщить модератору

	47. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+2 +/–
	Сообщение от Аноним (2), 10-Июн-23, 20:08
	Я перепаковал 300гб png в 120гб jxl без потерь. TIFF так может? Может быть TGA может? Что, нет?
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	49. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 10-Июн-23, 20:16
	Там ещё кучка лосси жпг файлов, в среднем экономия 20% при лосслесс перекодировании (заодно почистил мусор в тегах). Это 200гб просто так. Но это просто маленький набор данных, до которого я добрался и на котором мог проверить. А что касается лосси кодирования, то там то же самое -- настолько эффективного и качественного лосси кодирования до сих пор ещё не показывал ни один кодек. Теперь не надо кодировать в убитый jpeg-60 чтобы иметь адекватный размер файла.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (69), 10-Июн-23, 20:18
	>Там ещё кучка лосси жпг файлов, в среднем экономия 20% при лосслесс перекодировании (заодно почистил мусор в тегах). Это 200гб просто так. Но это просто маленький набор данных, до которого я добрался и на котором мог проверить. Есть арифметик JPEG, man jpegtran
	Ответить | Правка | Наверх | Cообщить модератору

	54. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 10-Июн-23, 20:41
	Уменьшает малоцветный файл на 3%. JPEG reconstruction на 13%. 2 рисованный файл на 9% и jpegxl на 23%. Это jpeg q100 и q99, файлы огромные. Если бы кодировали в полноценный jpegxl, они были бы куда лучше и без артефактов. Это кажется ерундой, но когда у тебя каждый жпег под сотни мегабайт это имеет значение.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (69), 10-Июн-23, 21:08
	>когда у тебя каждый жпег под сотни мегабайт Серьёзно, что это за джипеги, в которых сотни мегабайт? Если это карты, спутниковые снимки или ещё что-то, что выводится тайлами, то это идеальный кандидат для J2K. Если это фотки какие-то, то возникает закономерный вопрос — какие фотки требуют так много, да ещё и со смехотворной джипеговой 24-битовой цветностью?
	Ответить | Правка | Наверх | Cообщить модератору

	61. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 10-Июн-23, 21:19
	Обычные жпеги, каждый второй такой сегодня. CGI в основном. 16к разрешение. PSD для сравнения часто на много гигабайт, но под гигабайт это всегда. Проблема J2K в том, что сколько я ни пытался его использовать, ни разу он не показал достойные результаты, ощутимо уступая всем конкурентам по всем параметрам, так что я не понимаю, как за него можно топить -- это полный абсурд.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (69), 10-Июн-23, 21:26
	> CGI в основном. 16к разрешение. Да там поди постеризация дичайшая с 24 битами-то при таком разрешении. >Проблема J2K в том, что сколько я ни пытался его использовать, ни разу он не показал достойные результаты, ощутимо уступая всем конкурентам по всем параметрам А вы как его пользовали? Кодек какой? Какие параметры сжатия?
	Ответить | Правка | Наверх | Cообщить модератору

	74. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 10-Июн-23, 22:57
	А там много вариантов? Не так много софта на линуксе поддерживает экспорт. Ну вот беру рандомный пнг файл 9,810,593 байт (2к разрешение), кодирую IM в jp2 с -q0 получается 9,445,597 байт (все программы с поддержкой jp2 говорят, что это битый файл, и некоторые сообщают ошибку "sRGB: number of numComponents 4 does not equal 3"). Гимп единственный вроде открывает, хоть и медленно. В просмотрщиках поддержки нет. Для сравнения pngcrush 9,484,308 и лайтовый дефотный zopflipng (не перебирал все варианты тоже) 9,295,750, т.е. даже png не обходит. А раньше в каком-то фотошопе экспортировал, то же самое. Для сравнения WEBP 6,802,638 и JPEGXL 5,860,156. А вот jxl q95 (VarDCT, d0.550, effort: 9) всего 2,099,687 и я реально не вижу разницы, она есть только на 800x зуме, и то высматривать пиксели придётся.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 10-Июн-23, 23:09
	>все программы с поддержкой jp2 говорят, что это битый файл, и некоторые сообщают ошибку "sRGB: number of numComponents 4 does not equal 3" Файл не битый, в исходнике просто есть альфа канал и он был сохранён в JP2. Другие кодировщики его сохранили? Вообще, попробуйте opj_compress -i file.png -o file.file.jp2  (в некоторых дистрибутивах opj2_compress). Потом попробуйте opj_compress -I -i file.png -o file.file.jp2 (разница в -I, да) и отпишитесь какие результаты. Интересно, что получится. С просмотрщиками не очень хорошо, да. Есть запускаемый из командной строки jiv из jasper-tools и vipsdisp (рекомендую последний). Есть довольно неплохой geeqie, но он фейлится на альфа-каналах и неправильно отображает изображения с глубиной канала больше 8 бит.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 10-Июн-23, 23:36
	Ещё такой эксперимент (вероятно, более интересный) могу предложить. cjxl -d 1 file.png file.jxl djxl file.jxl jxled.ppm compare -metric PSNR file.png jxled.ppm /dev/null (тут он выдаст вам число) opj_compress -I -q (подставляете сюда это число — можно c дробной частью) -i file.png -o file.jp2 Сравниваете размеры file.jxl и file.jp2. compare -metric PSNR file.png file.jp2 /dev/null (тут он выдаст вам второе число) Сравниваете два числа.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 10-Июн-23, 23:48
	Если второе число покажется вам слишком маленьким, попробуйте немного увеличить число, передаваемое с -q так, чтобы второе число немного превысило первое (конечно, вряд ли получится полное совпадение) и после этого сравните размеры файлов. Ну и, конечно, сравните сами файлы :)
	Ответить | Правка | Наверх | Cообщить модератору

	91. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 11-Июн-23, 19:31
	Файл битый, даже точнее сказать безвозвратно запоротый (без вариантов, потому что восстановить изображение, хотя бы наполовину напоминающее исходное, невозможно). Не работает с прозрачностями, короче (и не предупреждает). Но так это и не лосслесс, о чём тут говорить вообще? Что-то типа jpeg100, такая же помойка. Если у файла результирующий размер лосслесс (ну, немного меньше jxl), но это не лосслесс, то такой формат абсолютно никчёмен и бесполезен. Нельзя предсказать, какие артефакты и где вылезут, и какой размер получится. Смысл лосслесс сжатия в том, чтобы при меньшем размере, файл был равен исходному, без всяких округлений и артефактов. Файлы с прозрачностью не поддерживает, опять же (и все эти гимпы настойчиво пытаются запороть цвета при удалении прозрачности). Только они зачем-то называют это лосслесс, непонятно. Вот мой q0 -- это лосслесс. А к лосси применяются совсем другие требования. Если кодер jpeg2000 начинает сжимать, то качество сразу падает до негодного. Абсолютно негодного. Это выглядит ужасно даже без зума и узких мест. Пиксели похожи, да не те, что влияет на общую картину. Метрики вещь бесполезная, особенно PSNR. На глаз видно, что цвета плывут, пиксели плывут, лезут артефакты, содержимое лезет за край, а метрика хорошая будет. При этом, у jxl значения какие-то жуткие будут, но видимых отличий как-то и нет. Я больше переживаю из-за поплывших цветов. Webp (с твиками) в плане работы с 8-битным rgb примерно на одном уровне с jpeg. Vips выдаёт оооочень неприятный файл. Фоновая текстура сильно поплыла. При увеличении видно, все пиксели смазаны. Не нашёл, как настроить. В порядке уменьшения предпочтительности я бы перечислил jxl100/webp100,jxl97,webp98,webp97,opjjp2r1,avif100, avif99,vipsjp2,jpeg100,aviffakell,jp2q0. По размеру файла видно, что jp2 не конкурент. У лосси jxl и webp одинаковое искажение голубого цвета (на q99 и, вероятно, на q98, его нет), но в остальном сопоставимо. Это с sharp-yuv=1, без этой опции цвета у webp цвета плывут гораздо сильнее. Тут нужна опция для лучшего сохранения цветов в jxl, но, когда я в прошлый раз хотел её использовать, она не работала. Края у webp98 намного более зашумленные, по сравнению c jxl97, больше артефактов. У jpg100 такое же искажение и очень много артефактов, у jp2opj не видно таких проблем. Comparing distortion in relation to file:'1_noalpha.png' size:8756197b ./1_avif98.avif file:'conv/1_avif98.png' size:3086635b decoded:7966709b PAE=0.44705882 RMSE=0.0095472869 PSNR=40.402401 butteraugli=1.877860 --- ./1_avifheicll444rgb.avif file:'conv/1_avifheicll444rgb.png' size:5976328b decoded:8801570b PAE=0.0039215686 RMSE=0.0021962788 PSNR=53.166251 butteraugli=0.816788 --- ./1_avifheicll.avif file:'conv/1_avifheicll.png' size:3944476b decoded:8026140b PAE=0.44705882 RMSE=0.0092152831 PSNR=40.709826 butteraugli=1.877704 --- ./1_avifq100.avif file:'conv/1_avifq100.png' size:3944476b decoded:8026140b PAE=0.44705882 RMSE=0.0092152831 PSNR=40.709826 butteraugli=1.877704 --- ./1_jp2q0.jp2 file:'conv/1_jp2q0.png' size:7004217b decoded:8756157b PAE=0 RMSE=0 PSNR=0 butteraugli=0.000000 --- ./1_jpg100.jpg file:'conv/1_jpg100.png' size:2009346b decoded:7919700b PAE=0.18039216 RMSE=0.0090801592 PSNR=40.838131 butteraugli=2.352790 --- ./1_jxl99.jxl file:'conv/1_jxl99.png' size:3599739b decoded:8642618b PAE=0.22352941 RMSE=0.0038234994 PSNR=48.350779 butteraugli=0.408618 --- ./1_jxlll.jxl file:'conv/1_jxlll.png' size:5804929b decoded:8857242b PAE=0 RMSE=0 PSNR=0 butteraugli=0.000000 --- ./1_jxlq97.jxl file:'conv/1_jxlq97.png' size:2428116b decoded:8718645b PAE=0.30196078 RMSE=0.0056463669 PSNR=44.964618 butteraugli=0.720617 --- ./1_opjjp2.jp2 file:'conv/1_opjjp2.png' size:4163304b decoded:8612059b PAE=0.015686275 RMSE=0.0025997342 PSNR=51.701421 butteraugli=0.529211 --- ./1_vipsjp2.jp2 file:'conv/1_vipsjp2.png' size:2513912b decoded:13430237b PAE=0.050980392 RMSE=0.0046394369 PSNR=46.670695 butteraugli=1.237172 --- ./1_webpq100.webp file:'conv/1_webpq100.png' size:6609482b decoded:8756157b PAE=0 RMSE=0 PSNR=0 butteraugli=0.000000 --- ./1_webpq97.webp file:'conv/1_webpq97.png' size:2134404b decoded:8921901b PAE=0.40784314 RMSE=0.0084823874 PSNR=41.429638 butteraugli=1.348880 --- ./1_webpq98.webp file:'conv/1_webpq98.png' size:2429768b decoded:9009915b PAE=0.41176471 RMSE=0.008221429 PSNR=41.701054 butteraugli=1.305168 --- Это на пнг, у меня есть жпеги на которых можно оценить характер и амплификацию артефактов у разных кодеров, например, при ресайзе (отдельная тема) или обработке и тут jpegxl чётко победитель, у webp лестницы на градиентах, avif перманентно убог (хоть и без лестниц) и так далее. Я подбирал файлы, на которых можно найти артефакты при кодировании. Острые края, кромки, полупрозрачности, градиенты, и так далее. Не на каждом файле будут очень заметны дефекты, но тестовый набор гугла для webp2 вполне годится для демонстрации проблем. Хотел использовать webp для всего, но быстро обнаружилось, что он довольно плох. Из всех экспериментов с кодеками jxl дольше всего живёт. Лосси лучше webp, лосслесс намного лучше м универсальнее webp. Чуть дороже, это да, но качественнее и без ограничений webp. Чёткое разделение опять же. На лосслесс, лосслесс жпг, и лосси. Сразу можно сказать, что за файл. Профили и информация коррекции цвета не исчезает в процессе. И используется кодером. А это, между прочим, самое важное в кодере. По итогу, JP2 довольно хороший формат, но катастрофически устаревший и вне PDF ему делать вообще нечего. Лосслесс никуда не годится, фейклосслесс больше размером и не лучше качеством (видимые искажения даже больше) по сравнению с лосси jxl, поддержки в софте никакой, кодер кривой и багованный.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	93. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 11-Июн-23, 23:01
	Так, давайте по порядку. Для JP2 действительно есть хорошие имплементации и не очень. OpenJpeg (opj_compress и opj_decompress) - хорошая, так что будем отталкиваться от неё. Множество линукс-софта использует Jasper или что-то ещё которые работают, прямо скажем, не очень. У opj_compress, как и у большинства кодеков JP2, есть опция -r. С её помощью можно получить файл заданного размера. Посчитать можно так (это не совсем точный подсчёт, но для этих целей подойдёт): r = размер сжатого другим кодеком файла ÷ размер этого же файла в формате pnm (сойдёт и bmp для 8-битовых изображений). Поскольку лосси JP2 без -I большого смысла не имеет, то надо добавить эту опцию. После сжатия получится файл размера близкого к размерам сжатого другим кодеком файла. Уже с этим файлом стоит работать с метриками, сравнивая с другими кодеками. Кстати, какие ещё форматы умеют так вписываться в заданные ограничения? Я таких не знаю. Из вашего результата видно, что у 1_opjjp2.jp2 (OpenJpeg JP2) довольно интересные результаты: PSNR выше только у AVIF ( ./1_avifheicll444rgb.avif ), который почти на два мега тяжелее. Butteraugli лучше (меньше — лучше, согласно https://github.com/google/butteraugli/issues/22 ) только у JXL (./1_jxl99.jxl), который ещё и меньше на полмега, при этом отстаёт в PSNR. Тут мы приходим к вопросу — а чем, собственно, butteraugli лучше PSNR? Butteraugli — метрика за авторством авторов JPEG XL. Лично мне кажется, что обосновывать превосходство, используя самодельные метрики, да ещё и такой высокой вычислительной сложности — сомнительное дело, поскольку тут можно подогнать и метрику к кодеку, и кодек к метрике. PSNR при всех его недостатках изобрели не разработчики JP2 и не разработчики AVIF, что убирает этот конфликт интересов. Честно скажу, вот эти все ужасы с "не теми цветами" и "не теми пикселями" я не наблюдал ни c JP2, ни с JXL, ни c AVIF. У меня совершенно обычный IPS монитор с поддержкой sRGB, которых миллионы, если не миллиарды — без калибровки или ещё чего-то. Вообще, в линуксе пока есть проблемы с color management — не весь софт его поддерживает и, например, в моём случае автоматически сгенерированный colord профиль - полное дно, которое чистый синий RGB-цвет показывает как фиолетовый, так что советую при проведении визуальных сравнений переключить и монитор (если он wide-gamut), и color management линукса в sRGB, чтобы проблемы линукса не влияли на результат. В вашем случае мог быть такой случай, так как, скажем, просмотрщик eog (стандартный гномовский просмотрщик) поддерживает color managmeent, а vipsdisp  (просмотрщик JP2 и не только) — нет, и соответственно изображения будут визуально на экране отличаться (при условии того, что у вас включён какой-то цветовой профиль отличный от sRGB — а это очень даже возможно, так как могло быть сделано автоматически). Артефакты сжатия у JP2, в общем-то, при установке opj_compress -q 47 (то есть целевого PSNR) или выше лично я не замечал никаких и никогда. Уже ниже — такое бывало, но я не могу с уверенностью сказать, что артефакты начинаются ровно ниже -q 47 — скорее, просто кодек при таком значении точно не выдаст результат сильно ниже границы, где начинаются артефакты, так как соответствие целевой метрике всё же не 100%, насколько я могу судить. Плюс само изображение играет важную роль, конечно — на некоторых изображениях артефакты проявляются на более высоких PSNR, да, но думаю, в этом плане  JP2 ничем не отличается от других кодеков и других метрик.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 11-Июн-23, 23:12
	>r = размер сжатого другим кодеком файла ÷ размер этого же файла в формате pnm (сойдёт и bmp для 8-битовых изображений) Конечно, имелось в виду наоборот: r = размер файла в формате pnm (сойдёт и bmp для 8-битовых изображений — главное, чтобы он был без сжатия и сохранялась глубина каналов) ÷ размер файла сжатого другим кодеком Jasper понимает оба варианта, но с openjpeg я не проверял первый.
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	97. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 11-Июн-23, 23:34
	>да ещё и такой высокой вычислительной сложности Имелась в виду просто сложность, хотя вычислительная, конечно, тоже выше, чем таковая у PSNR.
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	135. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (134), 15-Июн-23, 15:52
	> Кстати, какие ещё форматы умеют так вписываться в заданные ограничения? Я таких не знаю. Потому, что это сейчас почти никому не надо. Времена "надо уложиться в 1,44 мегабайта" слегка прошли. А поскольку это изображение, то целевым является логичное качество изображения. Соответственно в случае lossy выбирается минимально устраивающее качество изображения, а размер получится тот, который получится. Делать целевым параметром именно размер файла, не обарщая внимания на каыесатво изображения можно только в одном случае: когда файл надо сохранить любой ценой в ограниченном объёме. Но такой сценарий сейчас "в дикой среде" крайне редкий. >Butteraugli — метрика за авторством авторов JPEG XL. Лично мне кажется, что обосновывать превосходство, используя самодельные метрики, да ещё и такой высокой вычислительной сложности — сомнительное дело, поскольку тут можно подогнать и метрику к кодеку, и кодек к метрике. Но ведь вы делаете ровно это: вы обосновывается превосходство (для использования как метрики) PSNR'а исходя исключительно из авторства. это ненаучно и как раз и является сомнительным делом. Да, при прочих равных, независимое авторство было бы плюсом и определяющим. Но вы-то его ставите как определяющий фактор. А такой подход ставит крест уже на ВАШЕЙ объективности. >PSNR при всех его недостатках изобрели не разработчики JP2 и не разработчики AVIF, что убирает этот конфликт интересов. Это предвзятый подход. Вы без пруфов просто заявляете, что PSNR лучше, просто потому, что вы "собака-подозревака" - подозреваете автора Butteraugli в предвзятости. Мало того, что без пруфов, так вы еще и не учитываете, между прочим, что Butteraugli может быть лучше, даже будучи предвзятым (я про). Ну и про крайнюю неудачность PSNR как метрики не сказал уже только ленивый. Ладно бы вы хоть с PSNR-HVS-M с Butteraugli сравнивали, а так это вообзще не серьезный разговор получается у вас.
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	138. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 15-Июн-23, 22:52
	> Но такой сценарий сейчас "в дикой среде" крайне редкий. Я не соглашусь, интернет всё ещё с нами — размеры изображений и других загружаемых ресурсов растут, а кое-где всё ещё ловится только EDGE. Иногда приходится впихивать в жёсткий лимит. >Но ведь вы делаете ровно это: вы обосновывается превосходство (для использования как метрики) PSNR'а исходя исключительно из авторства. это ненаучно и как раз и является сомнительным делом. Да, при прочих равных, независимое авторство было бы плюсом и определяющим. Но вы-то его ставите как определяющий фактор. А такой подход ставит крест уже на ВАШЕЙ объективности. Моя (не)объективность тут никакой роли не играет. Дело не в авторстве, просто есть метрика, которая  существует давно и с использованием которой написаны горы научных статей и есть Butteraugli, который «хороший, потому что… потому что сделали в Гугле» (хотя ирония судьбы сами знаете какая). >Вы без пруфов просто заявляете, что PSNR лучше, просто потому, что вы "собака-подозревака" - подозреваете автора Butteraugli в предвзятости. Мало того, что без пруфов, так вы еще и не учитываете, между прочим, что Butteraugli может быть лучше, даже будучи предвзятым (я про). Не заявляю, а констатирую, что демонстрация преимуществ JXL не обходится без упоминаний этой самопальной метрики, а не какой-то другой, хотя существующих метрик от независимых сторон вагон и маленькая тележка. Это-то и подозрительно.
	Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

	142. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (134), 16-Июн-23, 15:31
	> Я не соглашусь, интернет всё ещё с нами — размеры изображений и других загружаемых ресурсов растут, а кое-где всё ещё ловится только EDGE. Иногда приходится впихивать в жёсткий лимит. И много вы знаете рельаных сценариев в инете, где картинки жмут специально под "а вдруг там только EDGE"? Такое, конечно, бывает в редких случаях, типа полярники и т.п. но это не массовые сценарии. Повторюсь: такие сценарии в дикой среде редкий. > Моя (не)объективность тут никакой роли не играет. В рамках текущей дискуссии - вполне себе играет. Вы ведь на этом аргументе строите свою позицию. > Дело не в авторстве, просто есть метрика, которая  существует давно и с использованием которой написаны горы научных статей и есть Butteraugli, который «хороший, потому что… потому что сделали в Гугле» (хотя ирония судьбы сами знаете какая). Ага... Деды тыще лет без этих ваших инторнетов жили и ничаво... Второй раз вам говорю: тот факт, что PSNR долго использовался сам по себе не является аргументов в пользу его "лучшести". Просто говорит о том, что его придумали раньше и он за это время успел распостраниться больше. Копьё, как оружие, использовали тыщи лет, а пулемёт - всего сотню. Но что-то мне подсказывает, что в общем случае вы не станете утверждать, что в современном бою копьё лучше автомата, потому что "диды столетиями использовали". Чаще всег овсё ровно наоборот от вашей позиции: более новые форматы и стандарты более совершенны, чем более старые. > Не заявляю, а констатирую, что демонстрация преимуществ JXL не обходится без упоминаний этой самопальной метрики, а не какой-то другой, хотя существующих метрик от независимых сторон вагон и маленькая тележка. Это-то и подозрительно. Ну так сделайте на этих независимых метриках и выложите. Все посмотрят - обсудят. А пока ваши "констатации" голословны. Это не вызывает доверия еще больше: у Butteraugli можно хотя бы какие-то объективные аспекты (преимущества/недостатки) обсуждать, а у вас пока кроме необъективно предвзятого на основе авторства мнения вообще ничего из фактуры нет.
	Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

	145. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 16-Июн-23, 17:15
	>В рамках текущей дискуссии - вполне себе играет. Вы ведь на этом аргументе строите свою позицию. Нет, не играет — пожалуйста, не сводите разговор к обсуждении моей объективности, потому что если вы считаете, что объективность существует, то это свидетельство удивительной наивности. А если мы принимаем, что её не существует, то и обсуждать такие вопросы бессмысленно. Моя позиция — это предположение, которой пытается объяснить, почему Гугл отказался от JXL. В его пользу говорит то, что сравнительные тесты, которые они использовали основывались на MS-SSIM. SSIM — это тоже старая метрика, по которой написано много peer-reviewed статей, чего, повторюсь, по Butteraugli нет. Более ничего мне прошу не приписывать. > Дело не в авторстве, просто есть метрика, которая  существует давно и с использованием которой написаны горы научных статей и есть Butteraugli, который «хороший, потому что… потому что сделали в Гугле» (хотя ирония судьбы сами знаете какая). >Чаще всег овсё ровно наоборот от вашей позиции: более новые форматы и стандарты более совершенны, чем более старые. Для таких утверждений нужна статистика,которой, конечно, никто не ведёт. Если взять сайт JPEG, перечисляющий множество форматов, появившихся после JPEG 1 и, вероятно, более совершенных, чем JPEG 1 и сравнить их известность с JPEG 1, то получается, что совершенство формата и его распространённость — это вещи вообще не очень коррелирующие, см. эффект good enough (Betamax vs VHS и т.п.) >Ну так сделайте на этих независимых метриках и выложите. Все посмотрят - обсудят. А пока ваши "констатации" голословны. Это не вызывает доверия еще больше: у Butteraugli можно хотя бы какие-то объективные аспекты (преимущества/недостатки) обсуждать, а у вас пока кроме необъективно предвзятого на основе авторства мнения вообще ничего из фактуры нет. Я не считаю себя достаточно компетентным в вопросах сравнений качества кодеков и у меня нет заинтересованности в победе или поражении JXL, так что ничего этого делать я, конечно, не буду. Заинтересовать компетентных неаффилированных людей своей разработкой, чтобы они провели это тестирование и выложили его результаты в паблик — это задача разработчиков JXL или хотя бы тех, кто так рьяно защищает его честь. Раз таких исследований пока не наблюдается, то, видимо, ситуация неоднозначна. Констатация — это перечисление фактов. Факты таковы: «JPEG XL заточен на Butteraugli», «Авторы Butteraugli являются соавторами JPEG XL». Определение конфликтов интересов можно легко найти в интернете. Моё мнение таково, что замалчивать конфликты интересов — неправильно и если я считаю правильным его запостить здесь, то я буду это делать. Раз уж мы тут предлагаем друг другу «сделать» что-то, то я предложу вам вместо упражнений в красноречии найти самому исследования от третьих лиц (или сделать их самому). Это в ваших интересах же — просто будете кидать ссылку на них в ответ скептикам вместо тысячи слов.
	Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

	51. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (69), 10-Июн-23, 20:20
	>Я перепаковал 300гб png в 120гб jxl без потерь. TIFF так может? Может быть TGA может? Что, нет? J2K может лосслесс паковать и может это делать лучше TIF.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	52. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 10-Июн-23, 20:24
	В том и дело что ни один из лосслесс кодеров не может даже близко сравниться с jxl. Его может побить только png упакованный проприетарью на оффтопе, но это только когда мало цветов и менее универсально.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (69), 10-Июн-23, 20:33
	>В том и дело что ни один из лосслесс кодеров не может даже близко сравниться с jxl. Во-первых, тут нужны источники. Во-вторых, cjxl на стандартном эффорте 7 очень-очень медленно жмёт, а на более низких он ничем не лучше J2K, а то и хуже. Я бы сказал, что это как архиватор PAQ — да, жмёт сильнее всех, но скорость убивает любые преимущества. Из той же категории pigz -11, который жмёт лучше, чем -9, но до конца сжатия мало-мальски крупного файла можно и не дожить :)
	Ответить | Правка | Наверх | Cообщить модератору

	63. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 10-Июн-23, 21:24
	На 4 пне? И каким боком тут потоковые компрессоры deflate? Я кодирую 9 файлы с разрешением 4-16к и мне норм, фактически бесплатно по хранилищу выходит. Кодирует только в 1 поток (1 из этапов вроде 2 потока) поэтому можно спокойно загружать по числу ядер.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (69), 10-Июн-23, 21:34
	> На 4 пне? Да если бы. > Кодирует только в 1 поток (1 из этапов вроде 2 потока) поэтому можно спокойно загружать по числу ядер. Так можно любые форматы ускорить с помощью xargs, тут ничего нового. Вообще, https://jpegxl.io/articles/faq/#parallelizable говорит, что оно параллелизуется, так что вы тут что-то недопоняли.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 10-Июн-23, 21:41
	Ток независимо от числа тредов загружает 1 ядро, а так да. Других параметров кодера я не вижу.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (83), 11-Июн-23, 10:18
	>Из той же категории pigz -11, который жмёт лучше, чем -9, но до конца сжатия мало-мальски крупного файла можно и не дожить :) Для png есть zopflipng, для zip в zopfli умеет zipalign.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	89. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (25), 11-Июн-23, 17:58
	pigz -11 — это и есть zopfli, только для gzip. Он чудовищно медленный, но для выигрыша нескольких процентов путём сжатия, например, небольших файлов, передаваемых много раз по сети и обеспечения совместимости с Deflate, вполне подходит. Жать им что-то мало мальски большое очень и очень долго. Впрочем, эти два условия необходимы разве что для экономии трафика при передаче ресурсов старым браузерам.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (112), 14-Июн-23, 22:50
	А эта штука тоже пытается подобрать оптимальный вариант кодирования. Есть много способов как закодировать поток, дающий при декомпрессии одно и то же. У любителей сжатия на эту тему есть свой поиск святого грааля - optimal coding. В случае zlib эта задача несколько проблематична в решении поскольку за LZ еще хаффман и кодировать LZ так чтобы было максимально удобно хаффману вроде бы не решенная а может и нерешаемая полностью задача. Однако брутфорсом вариантов кодирования можно приблизиться к оптимуму. У zlib словарик куцый, 32 кило всего. Так что это ему не сильно поможет, он не может ссылаться более чем на 32 кило от сего места и не поймает совпадение. В этом смысле brotli и zstd куда интереснее.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (5), 10-Июн-23, 20:53
	Зачем хранить png где ты их взял, сканы? Качества обычного джипега тебе вы хватило за глаза.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	119. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (112), 13-Июн-23, 23:01
	>  TIFF так может? Который из? TIFF так то КОНТЕЙНЕР а не КОДЕК. А внутрях абсолютно разное барахло может быть. В принципе даже вот JXL тоже можно в TIFF врапнуть. Как отдельный, собссно, вариант "тега". Это тоже TIFF будет (не знаю есть ли уже стандартный тег для такого субформата). Извините, даже DNG (RAW фоты с некоторых камер) - формально как бы TIFF файл. А JXL может, извините, байеровский формат пикселей вообще? Ну вот такое с матрицы фотика на самом деле идет :)
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	122. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 14-Июн-23, 00:31
	Ни о чём.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (112), 14-Июн-23, 22:44
	> Ни о чём. Пойнт в том что в TIFF может быть что угодно, он лишь контейнер. Поэтому сравниваться с ним - полное ололо. С тем же успехом можно туда и сабжевое сжатие засунуть. И получится что сравнили JXL vs JXL тогда? :). Другое дело что такой диалект (пока еще?) может и не быть устаканившимся и стандартнам. А так поугарать, взятая наобум равка в DNG была TIFF содержащим в себе... 1) JPEG как превьюху. Жпег может быть встроен в формат контейнера TIFF. 2) Байеровсие данные в том чудесатом формате. После жпега уже. На то и теги что их может быть более 1. Что так уж запрещает в TIFF засунуть не просто JPEG а JPEG XL - кто б его знает. Ну а что конкретная программа работающая с TIFF умеет - другой вопрос уже.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (2), 15-Июн-23, 00:11
	Ну и чё, кто-нибудь уже засунул наверно, да? Неужели нет, а почему? У каждого вендора свой форк этой дряни, а сжатия не завезли. Ещё внезапно окажется, что это раздутый контейнер. А у jxl очень грамотный контейнер с прицелом на минимум оверхеда. И вообще ему контейнер не обязательно. Так вот и вопрос, получается, где же конкуренция?
	Ответить | Правка | Наверх | Cообщить модератору

	139. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (-), 15-Июн-23, 23:59
	> Ну и чё, кто-нибудь уже засунул наверно, да? Неужели нет, а почему? Может кто и засунули. Основная трабла с TIFF - это поддержка софтом ВСЕХ фич. Это как с AVI, можно скачать мувик, а там что угодно. Может xvid, а может и cinepak какой-нибудь. Потому что .avi мало что говорит что за кодек внутри. Да любой, даже h.264 в принципе можно. Аналогично - никогда не видали AV1 сунутый в BMFF? Это такое суперкомбо, когда AV1 затолкан в контейнер известный большинству как "mp4". Ну вот такой вот "mp4" - который внутрях AV1. Это кстати в ISO'шный стандарт на BMFF вроде бы даже уже и внесли. > У каждого вендора свой форк этой дряни, а сжатия не завезли. Там чертова куча сжатий как раз. Просто из-за форков не все программы умеют все фичи. Если JXL станет популярным, его туда > Ещё внезапно окажется, что это раздутый контейнер. Сам по себе ему не с чего быть раздутым. Хотя если напихать всяких EXIF и XMP расписывающих все вплоть до числа пятен на солнце в момент съемки, даже мелкая картинка может стать не очень мелкой. Но так даже в стандартном JPG можно было. > А у jxl очень грамотный контейнер с прицелом на минимум оверхеда. И вообще ему контейнер > не обязательно. Ну как бы без контейнера RAW bitstream кодека очень мало кто может сожрать. В случае VP8/9/AV1 так тоже можно, как впрочем и H.26x - но софта готовых именно RAW битстрим кодека схарчить немного. У них еще есть подобные по смыслу легкие "нативные" форматы. У AV1 это известно как "OBU". У h26x тоже нечто такое в спеках есть. Но юзают довольно редко. > Так вот и вопрос, получается, где же конкуренция? Кодек не может с контейнером конкурирвоать, они тупо разные уровни абстракции :)
	Ответить | Правка | Наверх | Cообщить модератору

	55. "В Safari 17 и WebKit включена поддержка формата изображений ..."	–1 +/–
	Сообщение от Kuromi (ok), 10-Июн-23, 20:42
	Абсолютно такие же срачи бывают и в Мозилловской Багзилле, правда с некоторых пор они оперативно лочат комменты в таком случае.
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	59. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (69), 10-Июн-23, 21:01
	О чём и речь, JPEG XL пушится толпой хомячков, которые ничего не понимают в области и по этой причине вынуждены обращаться к срачам чтобы хоть как-то обосновать своё мнение. При этом формат, вероятно, и вправду интересный, но методы его продвижения мне не очень нравятся. Похоже на астротурфинг, если честно.
	Ответить | Правка | Наверх | Cообщить модератору

39. "В Safari 17 и WebKit включена поддержка формата изображений ..."	–1 +/–
Сообщение от Аноним (39), 10-Июн-23, 19:18
Эппля как всегда ОПОМНИЛАСЬ! :)) Люди уже AVIF продвигают (т.е. даже WebP уже вчерашний день)
Ответить | Правка | Наверх | Cообщить модератору

	42. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
	Сообщение от Аноним (5), 10-Июн-23, 19:38
	Опять решили сделать не как все со своими клавиатурами бабочки и очередной раз облажались.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от 0_0 (?), 11-Июн-23, 16:59
	В Safari уже давно есть поддержка WebP и AVIF, а теперь добавили еще один. Опомнись.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	108. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Kuromi (ok), 13-Июн-23, 17:57
	> В Safari уже давно есть поддержка WebP и AVIF, а теперь добавили > еще один. Опомнись. Сафари начал пддерживать WebP когда они поняли что Мозилла с Гуглем пришли к соглашению - Хром включает APNG, Файрфокс включает WebP. В этот момент отказываться от WebP стало просто неактуально.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
	Сообщение от DEF (?), 12-Июн-23, 17:39
	JPEG XL более новый, чем AVIF.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

44. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
Сообщение от timur.davletshin (ok), 10-Июн-23, 19:55
https://addons.mozilla.org/en-US/firefox/addon/jxl/ - для нетерпеливых. https://jpegxl.info/art/2021-04_jon.html - для тестирования (да, оно тормозное).
Ответить | Правка | Наверх | Cообщить модератору

	56. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+2 +/–
	Сообщение от Kuromi (ok), 10-Июн-23, 20:44
	А не проще Nightly поставить тогда? Так хоть нативная поддержка, а не полифилы на JS.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
	Сообщение от Аноним (5), 10-Июн-23, 20:54
	Не надо ставить эту падучку.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "В Safari 17 и WebKit включена поддержка формата изображений ..."	–1 +/–
	Сообщение от Аноним (67), 10-Июн-23, 21:38
	а эти падения они сейчас с нами? в этой комнате?
	Ответить | Правка | Наверх | Cообщить модератору

	70. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (5), 10-Июн-23, 22:36
	У тебя глюки?
	Ответить | Правка | Наверх | Cообщить модератору

	110. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Kuromi (ok), 13-Июн-23, 18:01
	> Не надо ставить эту падучку. Да хосспади, ставите Nightly, проверяете что все работает, вырубаете обновление (известно как, политиками). Потом при релизе свежего стабильного релиза аккуратно создаете резервную копию и обновляетесь. Такая схема почти ничем от сидения на стабильно релизе не отличается. Это если вам Jpeg XL реально нужен.
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	81. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от AleksK (ok), 11-Июн-23, 08:30
	Поставил аддон и зашёл на тестовую страничку ноутбук кулерами завыл как будто на нём 4K без хардварного ускорения включил. Это как надо упоротся чтобы просто показать статичных картинок так ресурсы жрал?
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	109. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Kuromi (ok), 13-Июн-23, 17:59
	> Поставил аддон и зашёл на тестовую страничку ноутбук кулерами завыл как будто > на нём 4K без хардварного ускорения включил. Это как надо упоротся > чтобы просто показать статичных картинок так ресурсы жрал? А там в аддоне WASM потому что, целая библиотека в него перегнана. Поэтому Nightly - вот путь.
	Ответить | Правка | Наверх | Cообщить модератору

62. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+3 +/–
Сообщение от Аноним (62), 10-Июн-23, 21:23
Если хотите, чтобы ваш новый передовой формат изображений все ненавидели и никуда не принимали - назовите его JPEG [что-нибудь].
Ответить | Правка | Наверх | Cообщить модератору

	71. "В Safari 17 и WebKit включена поддержка формата изображений ..."	–1 +/–
	Сообщение от Аноним (5), 10-Июн-23, 22:37
	100% работает.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
	Сообщение от Аноним (99), 12-Июн-23, 01:00
	JPEG-RUST
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

78. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
Сообщение от penetrator (?), 11-Июн-23, 00:09
Реально отличный результат, ни WebP ни AVIF не нужно, они хуже даже, чем JPG, особенно там где много деталей
Ответить | Правка | Наверх | Cообщить модератору

80. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+2 +/–
Сообщение от Аноним (73), 11-Июн-23, 08:20
На самом деле истина проста: всем нужен быстрый, более-менее качественно жмущий, стандартизированный формат. Как он там называется, запамятовал?..
Ответить | Правка | Наверх | Cообщить модератору

	84. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (84), 11-Июн-23, 10:27
	Нет, всем нужен формат, устраивающий всех. Для вендоров бесплатного софта самое главное требование - отсутствие патентов, так как от уплаты отчислений с каждой загруженной копии только Гугл защищён - у него свои патенты, и если MPEG LA начнёт с ним судиться, то все члены патентного пула огребут.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+1 +/–
	Сообщение от Аноним (25), 11-Июн-23, 17:59
	JPEG XL, только без XL (шутка, состоящая лишь из доли шутки)
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

86. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+2 +/–
Сообщение от Аноним (86), 11-Июн-23, 10:57
Где-то плачет микрософт со своим jpeg xr.
Ответить | Правка | Наверх | Cообщить модератору

	128. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
	Сообщение от Аноним (112), 14-Июн-23, 22:52
	> Где-то плачет микрософт со своим jpeg xr. Учитывая что экс-ишак стал всего лишь проприетарной шкуркой для хрома у них есть и другие поводы поплакать.
	Ответить | Правка | Наверх | Cообщить модератору

130. "В Safari 17 и WebKit включена поддержка формата изображений ..."	+/–
Сообщение от uis (??), 15-Июн-23, 11:29
> Mozilla пока сохраняет нейтральную позицию в вопросе продвижения этого формата. > В Firefox поддержка формата JPEG XL доступна в ночных сборках Не такая уж и нейтральная, раз есть только в найтбилдах и только за флагом. Хром раньше прятал только за флагом.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема