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

В Safari 17 и WebKit включена поддержка формата изображений JPEG XL, opennews (??), 10-Июн-23, (0) [смотреть все] У Гулага просто есть своя карманная вебп Она получше авиф и прочей дряни, но то, Аноним (2), 13:47 , 10-Июн-23, (2) +13 // 1 По пункту webp vs jpegxl анон полностью прав JXL технологичней кодирования к, Аноним (11), 14:16 , 10-Июн-23, (11) +6 // И чо Вот жупег изначально тоже типа халявный, а потом выяснилось, что там запате, Гогольмоголь (?), 18:19 , 10-Июн-23, (38) –2 Во время JPEG были более технолоничные форматы сжатия с потерями Про убогий GIF , Аноним (73), 22:47 , 10-Июн-23, (73) Формат PNG не только имеет поддержку сжатия без потерь, но и неограниченноую пал, iZEN (ok), 12:22 , 11-Июн-23, (87) +4 Клёво, а в анимацию умеет Как промежуточный формат 8212 вы шутите Или его ре, Аноним (73), 12:07 , 12-Июн-23, (102) –3 Да, через формат на его основе известный как APNG Интересно тем что даже декоде, Аноним (112), 18:45 , 13-Июн-23, (112) Большинство разработчиков формата JXL из Google , Аноним (40), 19:34 , 10-Июн-23, (40) // Не знаю как там насчёт формата, но как минимум половина и вроде даже лучшая лос, Аноним (2), 20:02 , 10-Июн-23, (46) –1 скоро выходит Jpeg ai, опять все переписывать, совсем не аноним (?), 20:13 , 10-Июн-23, (48) +2 посмотрел несколько тестов кодирования интересовали результаты jpeg xl и wepb , Аноним (85), 10:38 , 11-Июн-23, (85) +2 // Вебп очень плох в плане сохранения качества в пересчёте на размер И вебп2 не на, Аноним (2), 19:47 , 11-Июн-23, (92) В некоторых случая да Но браузер предназначен для отображения, т е для декодир, VladSh (?), 13:33 , 12-Июн-23, (103) Yolo WebP это по сути I-фреймы из кодека VP8 в упрощенном формате файла На п, Аноним (112), 18:41 , 13-Июн-23, (111) Вдруг webp станет никому не нужен Подскажите, а webp придумали не потому, что е, Аноним (3), 13:50 , 10-Июн-23, (3) +1 // webp - это контейнер RIFF некоторая обвязка над алго сжатия, которые применяют, Аноним (11), 14:07 , 10-Июн-23, (8) // Так это выдернутый ключевой кадр из VP8, засунутый в webp контейнер, или нет Я , Аноним (12), 14:24 , 10-Июн-23, (12) +1 // Я не специалист, но судя по тому, что я видел, что говорят про WebP HEIF AVIF - , Аноним (25), 15:12 , 10-Июн-23, (25) Ну да И к тому же AV1 AVIF ключевой кадр AV1 сильно эффективнее чем VP8 WebP, Аноним (112), 18:49 , 13-Июн-23, (113) Непонятно только теоретикам Он дефективный и артефачит на пустом месте, больше , Аноним (2), 19:24 , 13-Июн-23, (114) Больше чем YUV с субсэмплингом то С RGB-скрина десктопа какого Ну да, кон, Аноним (112), 22:32 , 13-Июн-23, (115) +1 Именно так, обычный cwebp sharp_yuv на пару порядков лучше обычного libaom в пла, Аноним (2), 23:34 , 13-Июн-23, (121) Кривая цветопередача в основном заслуга subsampling самого по себе И в этом пла, Аноним (112), 22:10 , 14-Июн-23, (124) Если совсем точно, то в AVI-контейнер хотя RIFF применяется в довольно многих ф, Анонус (?), 15:16 , 10-Июн-23, (27) Вообще-то этот контейнер называется как раз RIFF AVI файлы является частным слу, Аноним (112), 22:44 , 13-Июн-23, (116) Так точно , Аноним (45), 19:56 , 10-Июн-23, (45) +1 Лучше бы они вместо того чтобы высказываться высылали бабулесы в Гугл Вот это б, Аноним (5), 13:58 , 10-Июн-23, (5) +1 // Лучше бы ты вместо своего высказывания денег перевёл нуждающимся , Тот_Самый_Анонимус__ (?), 14:14 , 10-Июн-23, (10) –1 // Перевёл твоя очередь , Аноним (5), 14:59 , 10-Июн-23, (19) +1 // Пфф, без пруфов не катит , Тот_Самый_Анонимус__ (?), 22:46 , 10-Июн-23, (72) Отправил бабулю в гугл, с ней все будет в порядке , Аноним (95), 23:14 , 11-Июн-23, (95) // Хапроий бабушка, научим golang, обучим играть go, наймем разрабатывать alphago, Абрахимн Ибо Гуглин (?), 09:13 , 13-Июн-23, (106) Еще бы, иначе сможешь неплохо поднять баб осов за эйджизм и сикхизм, Аноним (107), 15:20 , 13-Июн-23, (107) И вообще анимированный jpeg сразу в гарбедж без раздумий , Аноним (5), 13:59 , 10-Июн-23, (6) // Там с анимациями не очень пока емнип Но вот типичная гифка 100 кадров 5-10 гига, Аноним (2), 14:07 , 10-Июн-23, (7) +1 // Но кстати повторное лосси кодирование не уменьшает размер некуда уменьшать , но, Аноним (2), 14:10 , 10-Июн-23, (9) Абсолютно Есть же видеокодеки для такого , Аноним (12), 14:25 , 10-Июн-23, (13) +1 // MJPEG хороший кодек, но всё же подустарел , Аноним (2), 14:31 , 10-Июн-23, (14) –1 // Он хорош двумя вещами 1 низкая вычислительная сложность2 отсутствие межкадрово, Аноним (25), 15:02 , 10-Июн-23, (21) –1 Попробуй-ка на мелком маломощном устройстве с мизером памяти организовать видеот, Бывалый смузихлёб (?), 09:46 , 11-Июн-23, (82) Проблема Mjpeg в том что аппаратного ускорения нет, хотя раньше софт умел, не зн, Аноним (95), 23:19 , 11-Июн-23, (96) Там в чём-то другом может быть проблемаПо крайней мере, уж если какой-нибудь есп, Бывалый смузихлёб (?), 05:07 , 12-Июн-23, (100) Нет, проблема именно в том что теперь аппаратного ускорения видео mjpeg нет, ни , Аноним (95), 15:32 , 12-Июн-23, (104) Частота кадров получается неплохой только если битрейта завались Поскольку inte, Аноним (112), 22:47 , 13-Июн-23, (117) Даже сам эпл у себя на сайте делает анимации плавных переходов или разворотов пр, Аноним (5), 15:01 , 10-Июн-23, (20) // https stackoverflow com questions 60114243 using-videos-in-img-html, Аноним (34), 16:35 , 10-Июн-23, (34) Кроме того момента что реклама делающая это же самое но нагло и бесяще всех дост, Аноним (112), 22:51 , 13-Июн-23, (118) Всё-таки есть что-то подозрительное в том, что JPEG XL использует в качестве цел, Аноним (25), 14:47 , 10-Июн-23, (16) // Что подозрительного Имеет значение только визуальное качество и PSNR это очень , Аноним (2), 15:09 , 10-Июн-23, (24) // Подозрительное оно тем, что Butteraugli сложный и их собственный 8212 конфли, Аноним (25), 15:18 , 10-Июн-23, (28)   // Можно просто своими глазами сравнить, jpegxl явно лучше гугловского webp, соревн, Cucumber (?), 21:37 , 10-Июн-23, (66)   Быть лучше webp не так уж и трудно, так как это довольно старый формат с огранич, Аноним (69), 21:53 , 10-Июн-23, (69)   Jpeg XL однозначно лучше Jpeg 2000 в любых пресетах https twitter com jonsney, Аноним (123), 20:27 , 14-Июн-23, (123)   Снейерс и Клаудинари, проводившие это исследование 8212 одни из разработчиков, Аноним (25), 14:27 , 15-Июн-23, (132)   частей стандарта, конечно, Аноним (25), 14:31 , 15-Июн-23, (133)   Даже если вот просто с этим согласиться закрыв глаза на всё, то всё равно пол, Аноним (134), 15:08 , 15-Июн-23, (134)   Мне кажется, что JXL силён в том, что в интернете особо и не нужно Для векторно, Аноним (25), 21:08 , 15-Июн-23, (136)   Я хочу добавить, что экономия места, которую даёт пережатие JPG в JXL, тоже акту, Аноним (25), 21:15 , 15-Июн-23, (137)   А тут прикиньте - транскодить не надо будет каждому клиенту умножайте на количе, Аноним (134), 15:56 , 16-Июн-23, (144)   Оно и сейчас так происходит 8212 перекодированные изображения кэшируются, кон, Аноним (25), 17:34 , 16-Июн-23, (147)   Вы пытаетесь сказать, что в интернете не особо-то и нужен формат изображений, ко, Аноним (134), 15:39 , 16-Июн-23, (143)   Давайте остановимся на том, что из моей аргументации в ответ будет только ха-х, Аноним (25), 17:21 , 16-Июн-23, (146)   Да просто капец как подозрительно те разработчики заметили чуть быстрее чем Зо, Аноним (112), 22:27 , 14-Июн-23, (125) // Вопрос немного не об этом Непонятно почему я должен принимать то, что Butteraug, Аноним (25), 00:05 , 16-Июн-23, (140) // Пардон, нашёл это сравнение и там речь про MS-SSIM, а не PSNR Это не так уж и в, Аноним (25), 00:28 , 16-Июн-23, (141) Лол, PSNR самая худшая метрика Настолько плохая, что даже простой SSIM лучше , uis (??), 11:41 , 15-Июн-23, (131) Скрыто модератором, Chromium (ok), 14:51 , 10-Июн-23, (17) // Скрыто модератором, Аноним (25), 14:55 , 10-Июн-23, (18) Скрыто модератором, Аноним (22), 15:03 , 10-Июн-23, (22) +1 Скрыто модератором, Аноним (35), 17:00 , 10-Июн-23, (35) Скрыто модератором, ИмяХ (?), 15:06 , 10-Июн-23, (23) –3 // Скрыто модератором, Анонус (?), 15:20 , 10-Июн-23, (29) +2 Скрыто модератором, birdie (ok), 15:26 , 10-Июн-23, (30) +2 почему бы подобное не выносить в модули, зачем тащить в базовый код, grayich (ok), 15:26 , 10-Июн-23, (31) +1 // А что, так можно было , Разработчики браузеров (?), 00:48 , 12-Июн-23, (98) Прикольно, в гугловском багрепорте который начал один из команды Chromium, кста, Всем Анонимам Аноним (?), 17:09 , 10-Июн-23, (36) // Врать-то зачем , Аноним (37), 17:22 , 10-Июн-23, (37) +1 Вообще, я согласен, какой-то просто неприличный хайп трейн везёт этот JPEG XL , Аноним (69), 19:38 , 10-Июн-23, (41) –2 // Уже есть нейросети кому интересный эти форматы , Аноним (5), 19:39 , 10-Июн-23, (43) +2 Я перепаковал 300гб png в 120гб jxl без потерь TIFF так может Может быть TGA м, Аноним (2), 20:08 , 10-Июн-23, (47) +2 // Там ещё кучка лосси жпг файлов, в среднем экономия 20 при лосслесс перекодирова, Аноним (2), 20:16 , 10-Июн-23, (49) Есть арифметик JPEG, man jpegtran, Аноним (69), 20:18 , 10-Июн-23, (50) Уменьшает малоцветный файл на 3 JPEG reconstruction на 13 2 рисованный файл , Аноним (2), 20:41 , 10-Июн-23, (54) Серьёзно, что это за джипеги, в которых сотни мегабайт Если это карты, спутников, Аноним (69), 21:08 , 10-Июн-23, (60) Обычные жпеги, каждый второй такой сегодня CGI в основном 16к разрешение PSD , Аноним (2), 21:19 , 10-Июн-23, (61) Да там поди постеризация дичайшая с 24 битами-то при таком разрешении А вы как е, Аноним (69), 21:26 , 10-Июн-23, (64) А там много вариантов Не так много софта на линуксе поддерживает экспорт Ну во, Аноним (2), 22:57 , 10-Июн-23, (74) Файл не битый, в исходнике просто есть альфа канал и он был сохранён в JP2 Друг, Аноним (25), 23:09 , 10-Июн-23, (75) Ещё такой эксперимент вероятно, более интересный могу предложить cjxl -d 1 fil, Аноним (25), 23:36 , 10-Июн-23, (76) Если второе число покажется вам слишком маленьким, попробуйте немного увеличить , Аноним (25), 23:48 , 10-Июн-23, (77) Файл битый, даже точнее сказать безвозвратно запоротый без вариантов, потому чт, Аноним (2), 19:31 , 11-Июн-23, (91) Так, давайте по порядку Для JP2 действительно есть хорошие имплементации и не оч, Аноним (25), 23:01 , 11-Июн-23, (93) Конечно, имелось в виду наоборот r размер файла в формате pnm сойдёт и bmp дл, Аноним (25), 23:12 , 11-Июн-23, (94) Имелась в виду просто сложность, хотя вычислительная, конечно, тоже выше, чем та, Аноним (25), 23:34 , 11-Июн-23, (97) Потому, что это сейчас почти никому не надо Времена надо уложиться в 1,44 мега, Аноним (134), 15:52 , 15-Июн-23, (135) Я не соглашусь, интернет всё ещё с нами 8212 размеры изображений и других заг, Аноним (25), 22:52 , 15-Июн-23, (138) И много вы знаете рельаных сценариев в инете, где картинки жмут специально под , Аноним (134), 15:31 , 16-Июн-23, (142) Нет, не играет 8212 пожалуйста, не сводите разговор к обсуждении моей объекти, Аноним (25), 17:15 , 16-Июн-23, (145) J2K может лосслесс паковать и может это делать лучше TIF , Аноним (69), 20:20 , 10-Июн-23, (51) В том и дело что ни один из лосслесс кодеров не может даже близко сравниться с j, Аноним (2), 20:24 , 10-Июн-23, (52) Во-первых, тут нужны источники Во-вторых, cjxl на стандартном эффорте 7 очень-оч, Аноним (69), 20:33 , 10-Июн-23, (53) На 4 пне И каким боком тут потоковые компрессоры deflate Я кодирую 9 файлы с р, Аноним (2), 21:24 , 10-Июн-23, (63) Да если бы Так можно любые форматы ускорить с помощью xargs, тут ничего нового , Аноним (69), 21:34 , 10-Июн-23, (65) Ток независимо от числа тредов загружает 1 ядро, а так да Других параметров код, Аноним (2), 21:41 , 10-Июн-23, (68) Для png есть zopflipng, для zip в zopfli умеет zipalign , Аноним (83), 10:18 , 11-Июн-23, (83) pigz -11 8212 это и есть zopfli, только для gzip Он чудовищно медленный, но , Аноним (25), 17:58 , 11-Июн-23, (89) А эта штука тоже пытается подобрать оптимальный вариант кодирования Есть много , Аноним (112), 22:50 , 14-Июн-23, (127) Зачем хранить png где ты их взял, сканы Качества обычного джипега тебе вы хвати, Аноним (5), 20:53 , 10-Июн-23, (57) Который из TIFF так то КОНТЕЙНЕР а не КОДЕК А внутрях абсолютно разное барахло, Аноним (112), 23:01 , 13-Июн-23, (119) Ни о чём , Аноним (2), 00:31 , 14-Июн-23, (122) Пойнт в том что в TIFF может быть что угодно, он лишь контейнер Поэтому сравнив, Аноним (112), 22:44 , 14-Июн-23, (126) Ну и чё, кто-нибудь уже засунул наверно, да Неужели нет, а почему У каждого ве, Аноним (2), 00:11 , 15-Июн-23, (129) Может кто и засунули Основная трабла с TIFF - это поддержка софтом ВСЕХ фич Эт, Аноним (-), 23:59 , 15-Июн-23, (139) Абсолютно такие же срачи бывают и в Мозилловской Багзилле, правда с некоторых по, Kuromi (ok), 20:42 , 10-Июн-23, (55) –1 // О чём и речь, JPEG XL пушится толпой хомячков, которые ничего не понимают в обла, Аноним (69), 21:01 , 10-Июн-23, (59) Эппля как всегда ОПОМНИЛАСЬ Люди уже AVIF продвигают т е даже WebP уже вч, Аноним (39), 19:18 , 10-Июн-23, (39) –1 // Опять решили сделать не как все со своими клавиатурами бабочки и очередной раз о, Аноним (5), 19:38 , 10-Июн-23, (42) +1 В Safari уже давно есть поддержка WebP и AVIF, а теперь добавили еще один Опомн, 0_0 (?), 16:59 , 11-Июн-23, (88) // Сафари начал пддерживать WebP когда они поняли что Мозилла с Гуглем пришли к сог, Kuromi (ok), 17:57 , 13-Июн-23, (108) JPEG XL более новый, чем AVIF , DEF (?), 17:39 , 12-Июн-23, (105) +1 https addons mozilla org en-US firefox addon jxl - для нетерпеливых https j, timur.davletshin (ok), 19:55 , 10-Июн-23, (44) +1 // А не проще Nightly поставить тогда Так хоть нативная поддержка, а не полифилы н, Kuromi (ok), 20:44 , 10-Июн-23, (56) +2 // Не надо ставить эту падучку , Аноним (5), 20:54 , 10-Июн-23, (58) +1 // а эти падения они сейчас с нами в этой комнате , Аноним (67), 21:38 , 10-Июн-23, (67) –1 У тебя глюки , Аноним (5), 22:36 , 10-Июн-23, (70) Да хосспади, ставите Nightly, проверяете что все работает, вырубаете обновление , Kuromi (ok), 18:01 , 13-Июн-23, (110) Поставил аддон и зашёл на тестовую страничку ноутбук кулерами завыл как будто на, AleksK (ok), 08:30 , 11-Июн-23, (81) // А там в аддоне WASM потому что, целая библиотека в него перегнана Поэтому Night, Kuromi (ok), 17:59 , 13-Июн-23, (109) Если хотите, чтобы ваш новый передовой формат изображений все ненавидели и никуд, Аноним (62), 21:23 , 10-Июн-23, (62) +3 // 100 работает , Аноним (5), 22:37 , 10-Июн-23, (71) –1 JPEG-RUST, Аноним (99), 01:00 , 12-Июн-23, (99) +1 Реально отличный результат, ни WebP ни AVIF не нужно, они хуже даже, чем JPG, ос, penetrator (?), 00:09 , 11-Июн-23, (78) На самом деле истина проста всем нужен быстрый, более-менее качественно жмущий,, Аноним (73), 08:20 , 11-Июн-23, (80) +2 // Нет, всем нужен формат, устраивающий всех Для вендоров бесплатного софта самое , Аноним (84), 10:27 , 11-Июн-23, (84) JPEG XL, только без XL шутка, состоящая лишь из доли шутки , Аноним (25), 17:59 , 11-Июн-23, (90) +1 Где-то плачет микрософт со своим jpeg xr , Аноним (86), 10:57 , 11-Июн-23, (86) +2 // Учитывая что экс-ишак стал всего лишь проприетарной шкуркой для хрома у них есть, Аноним (112), 22:52 , 14-Июн-23, (128) Не такая уж и нейтральная, раз есть только в найтбилдах и только за флагом Хром, uis (??), 11:29 , 15-Июн-23, (130) 2,3,5,6,16,31,36,39,44,62,78,80,86,130

Сообщения

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

	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ообщить модератору

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

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