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

В 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]

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

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

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