Автор сообщений >>5329 и >>5330 (я так понимаю, что это два сообщения от одного автора) в феврале получил от меня один только отклик >>5331 и только лишь насчёт текстовой части своих сообщений, но в этом он сам и виноват, раз уж пренебрёг тѣмъ, что всѣ мы находимся въ Сѣти, и полѣнился указать URL того первоисточника, в котором взял разглядываемые картинки, а именно https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs
Только теперь, нѣкоторое время назад натолкнувшись волею случая на тот же первоисточник, я получил возможность пристального вглядывания въ тѣ же картинки и возможность откликнуться по существу их.
Итак, автор сообщения >>5329 не видит разницы между четырьмя картинками, скриншот которых прилагает? — а ничего удивительного, потому что Jon Sneyers (автор расположенной по адресу https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs блогозаписи) приложил к этому сразу нѣсколько усилий:
① Использованы иллюстрации 1080×1080 пикселов, но уменьшены (некратно) до 400×400, чѣмъ уменьшены различия в их качестве.
② Притом же онѣ не сдѣланы гиперссылками, так что просто жмякнуть мышóю (или ткнуть пальцем), чтоб добраться до полноразмѣрной версии (и затѣмъ сопоставлять таковые версии разных форматов), не получится, а надо вмѣсто того лезть в контекстное меню.
③ Если всё же найдётся читатель, преисполнившийся настойчивости, и откроет первую из этих картинок через контекстное меню, то даже тогда он обнаружит не «Original PNG image (2.6 MB)», как сказано в подписи, а расположенную по адресу https://res.cloudinary.com/cloudinary-marketing/image/upload/f_jpg,q_97/Web_Assets/blog/high_fidelity.png картинку, переужатую в JPEG (на 97 баллов качества) и объёмом всего-навсего 298 840 байтов. Разумѣется, если он примется ея качество сопоставлять с другими картинками, то найдёт много менѣе разницы, чѣмъ если б сопоставлял с неужатым PNG. (Это не моё открытие, конечно же; в комментариях по адресу https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs#comment-4929536866 это было обнаружено читателем ещё 27 мая 2020 года.)
④ Только если догадаться (или прочитать в справке по Cloudinary) о том, как исправить адрес картинки, только тогда по адресу https://res.cloudinary.com/cloudinary-marketing/image/upload/f_png/Web_Assets/blog/high_fidelity.png можно будет скачать файл объёмом 2 603 132 байта и в формате PNG.
Впечатление >>5330 о том, кто у кого и сколько раз отсосал, также продиктовано (судя по приложенному скриншоту) вглядыванием в картинку https://res.cloudinary.com/cloudinary-marketing/image/upload/v1589998060/Web_Assets/blog/high_fidelity.q95.png (демонстрирующую качество JPEG) и ей подобные (демонстрирующие качество других форматов), но я бы не торопился со слѣпымъ довѣріемъ и к этим картинкам также. Если разсмотрѣть болѣе пристально эти картинки (и предшествующие, по отношению к которым эти являются увеличенными фрагментами), то тогда видно вот что:
① Jon Sneyers пишет, что кодировщик JPEG XL, работая с настройками по умолчанию, изготавливает из рассматриваемого PNG (то есть, надо думать, из того, который по адресу https://res.cloudinary.com/cloudinary-marketing/image/upload/f_png/Web_Assets/blog/high_fidelity.png располагается и нами был только что съ нѣкоторымъ трудом обнаружен) пятидесятитрёхкилобайтовый JPEG XL. Однако даже болѣе новый кодировщик JPEG XL версии 0.6.0 (если на форуме https://forum.doom9.org/showthread.php?p=1949910#post1949910 его сборку разыскать и в архиве https://www.sendspace.com/file/ee80f2 скачать) не окажется способным на такой подвиг (несмотря на то, что между той блогозаписью, которую Jon Sneyers опубликовал, и нынешнею версиею кодировщика лежит почти 1¼ года непрерывного улучшения кодирования), сгенерированный командной строкою «cjxl high_fidelity.png high_fidelity.jxl» файл JPEG XL по объёму будет равен 66707 байтам. Даже если сознательно отойти от использования настроек по умолчанию и вмѣсто них потребовать от кодировщика максимальных усилий, то и тогда сгенерированный командной строкою «cjxl --effort=9 high_fidelity.png high_fidelity.jxl» файл JPEG XL по объёму будет равен 65600 байтам. Почему же? — да потому, что кодировщик создаёт контейнер и запихивает в него, окромя изображения, ещё 15765 байтов метаданных XMP, бережно сохранённых из того же файла PNG. Вот если подать команду «cjxl --strip high_fidelity.png high_fidelity.jxl», то тогда кодировщик наплюёт на XMP и создаст файл JPEG XL объёмом 50894 байта (это меньше, чѣмъ 53 килобайта, так что очень видно, что разработчики кодировщика всё это время не стояли на мѣстѣ), а команда «cjxl --effort=9 --strip high_fidelity.png high_fidelity.jxl» — даже 49787 байтов. Но вот про «--strip» вам Jon Sneyers не расскажет. И команда «cjxl --help» не расскажет. И команда «cjxl --help --verbose» не расскажет. Как минимум «cjxl --help --verbose --verbose» нужно для того, чтоб достигнуть упоминания этого параметра справкою.
② Далѣе Jon Sneyers пишет, что файл WebP равного объёма выглядит не так хорошо, как JPEG XL, потому что плавные переходы между цвѣтами получаются слегка (но замѣтно) полосчатыми, а текст получается размытым. Он прилагает файл https://res.cloudinary.com/cloudinary-marketing/image/upload/Web_Assets/blog/high_fidelity_webp.png (по-видимому, результат обратного преобразования из WebP в PNG), который вроде как соѿвѣтствуетъ такой оцѣнкѣ; проблема тут в том только, что нетрудно взять по адресу https://storage.googleapis.com/downloads.webmproject.org/releases/webp/libwebp-1.2.1-windows-x64.zip свѣжую сборку libwebp и создать ею такой файл WebP (командою «cwebp -m 6 -pre 5 -mt -v -progress high_fidelity.png -o high_fidelity.webp -q 88.5» напримѣръ), который по объёму будет ещё меньше (а именно 49906 байтов, что ужé ближе к современному JPEG XL), а всё же лучше (замѣтно менѣе размытым) показывать текст, чѣмъ въ томъ примѣрѣ WebP, который Jon Sneyers привёл. Напрашивается вопрос о том, чѣмъ же сжимал в WebP сам Jon Sneyers, не прибѣгал ли опять же к настройкам по умолчанию, знал ли он о том, что у кодировщика WebP хѣровые настройки по умолчанию (как дань обратной совмѣстимости), etc.
③ Далѣе Jon Sneyers пишет, что файл JPEG равного объёма выглядит ещё хуже: плавные переходы между цвѣтами получаются очень замѣтно полосчатыми, вокруг текста — обрамление из артефактов, малый текст трудно прочесть. При этом он прилагает расположенный по адресу https://res.cloudinary.com/cloudinary-marketing/image/upload/Web_Assets/blog/jpeg_high_fidelity.jpg файл, который вроде как соѿвѣтствуетъ такой оцѣнкѣ; проблема тут в том только, что нетрудно взять по адресу https://github.com/mozilla/mozjpeg/releases/download/v4.0.3/mozjpeg-v4.0.3-win-x64.zip свѣжую сборку MozJPEG и создать ею такой файл JPEG (командою «magick convert high_fidelity.png ppm:- | cjpeg -quality 75.5 -outfile high_fidelity.jpg» напримѣръ; результат её прилагаю, чтобы можно было в двух вкладках открыть его и https://res.cloudinary.com/cloudinary-marketing/image/upload/Web_Assets/blog/jpeg_high_fidelity.jpg и посравнивать), который по объёму будет ещё меньше (а именно 49672 байта, что даже чуть меньше современного JPEG XL), а всё же лучше (замѣтно менѣе размытым) показывать текст, чѣмъ въ томъ примѣрѣ JPEG, который Jon Sneyers привёл. И плавные цвѣтовые переходы будут ну очень менѣе ступенчатыми, чѣмъ въ томъ примѣрѣ, который Jon Sneyers привёл. Напрашивается вопрос о том, чѣмъ же сжимал в JPEG сам Jon Sneyers, знает ли он вообще о том, что на свѣтѣ есть такой хороший кодировщик JPEG, каким является MozJPEG.
Мораль сей басни такова, что если довѣряете одному из создателей JPEG XL сравнивать его дѣтище с WebP и с JPEG, то одному діаволу извѣстно (потому что сам Jon Sneyers не расскажет), какой гадкий подход к кодированию WebP и JPEG он использует для того, чтобы JPEG XL выглядѣлъ лучше на их фоне, и как преувеличит возможности настроек JPEG XL по умолчанию.