① Этот добрый совѣтъ в сообщении >>4958 ужé давали два года назад (в начале августа 2019 г.) и затѣмъ в сообщении >>5069 больше года назад (в начале апрѣля 2020 г.), а воз и ныне там.

② Этот PNG-файл можно, не прибѣгая к другим форматам, ужать на 12,96% (примѣръ прилагаю) посредством oxipng в режиме Zopfli. После этого кодировщик WebP, работающий в режиме сжатия без потерь (с параметрами «-z 9 -mt»), может доужать это изображение на 9,63%. Для сравнения: кодировщик JPEG XL, также работающий в режиме сжатия без потерь (с параметрами «--effort=9 -d 0 -I 1 -E 3 -g 2»), может доужать это PNG-изображение на 18,19%.

③ Режим сжатия WebP, совершаемого с внесением потерь, не так выразительно опережает JPEG, но зато остающиеся от внесения потерь артефакты JPEG (и «расходящиеся волны» вокруг линий, и «вьющаяся мошкара» вокруг мелких деталей, и «размытие по квадратику» у острых углов и у диагоналей) гораздо болѣе отвратительны, чѣмъ артефакты WebP (мягкое «умное размытие», сперва подавляющее наиболѣе слабоконтрастныя детали и текстуры, от которого деревянныя и кожаныя и каменныя и металлическія поверхности постепенно начинают выглядеть всё болѣе похожими на гладкий пластик, а лица людей «прихорашиваются» устранением морщин и пор кожи, напоминающим эффект от наложения пудры или тонального крема) при равном объёме файла.

④ По адресу https://caniuse.com/webp ясно видно, что даже тѣ современные браузеры, которые когда-то прежде долгие годы считались не поддерживающими формат WebP, всё же к концу прошлого (2020) года подошли со многомѣсячною поддержкою этого формата.

⑤ Даже если ну очень хочется позаботиться о браузерах ещё болѣе старых и оттого не умеющих WebP (а не просто-напросто полагаться на то одно, что публикатор файла WebP — это чаще всего достаточно взрослый человѣкъ, который может самостоятельно оценивать и сознавать нѣкоторую ограниченность круга посетителей сайта, способных открыть его файл, но несмотря на неё самостоятельно же сдѣлать свой выбор в пользу нового формата, руководясь пониманием его достоинств), то даже тогда можно же пособлять тѣмъ браузерам при посредстве особых джаваскриптовых костылей, один из которых по адресу https://github.com/chase-moskal/webp-hero опубликован, а другой по адресу https://webpjs.appspot.com/ опубликован (причём опубликован с рецептом, позволяющим грузить его только в старых браузерах, ещё не поддерживающих формат WebP, а новые браузеры не утруждать), так что осталось лишь выбрать желаемое по своему вкусу, а от поддержки WebP не воздерживаться.

Продолжая хвалить эффективность того режима сжатия без внесения потерь, который является одним из вариантов формата WebP (и хвалить который я ужé начал в сообщениях >>5069 и >>5101 и >>5262 и >>5331 в том обсуждении, которое бамплимитнулося), нельзя обойти вниманием то обстоятельство, что эффективен он до такой степени, что иногда приходится встречать такое изображение, сохранённое в формате JPEG с внесением потерь, которое при пересохранении в lossless WebP, которое совершается без внесения каких-либо дополнительных потерь, всё же уменьшается в объёме, и даже довольно значительно (болѣе чѣмъ на десяток процентов).

Для примѣра рассмотрим изображение Кобаящи, по адресу https://www.deviantart.com/dave-shino/art/Life-With-Dragons-700267501 переосмысленной в качестве героини извѣстнаго мема «This is fine».

Объём этого изображения на DeviantArt равен 717 987 байтам, однако примѣненіе сборки https://github.com/XhmikosR/jpegoptim-windows утилиты https://github.com/tjko/jpegoptim/ с параметрами «--preserve --preserve-perms --all-progressive --strip-none» позволяет уменьшить этот объём до 669 287 байтов (на 6,78%) без потерь, не выходя за рамки формата JPEG (результат прилагаю).

Однако же дополнительное примѣненіе libwebp версии 1.2.0 (командною строкою, на «cwebp -z 9 -mt -v -progress» начинающеюся) позволяет доужать этот файл в WebP без потерь до объёма 585 302 байтов (то есть ещё на 12,53%) несмотря на то, что сохраняется растр пикселов, декодированных из JPEG.

Для сравнения можно указать, что использование кодировщика JPEG XL (той сборки версии 0.5.0 на основе коммита 4122f3e, которая в архиве https://www.sendspace.com/file/ntup98 обнаруживается) в специальном режиме обратимого кодирования JPEG (сохраняющего не растр пикселов, а коэффициенты дискретного косинусного преобразования, свойственного нутру JPEG) командною строкою, на «cjxl --effort=9» начинающеюся, позволяет доужать этот файл в JPEG XL без потерь до объёма 578 464 байтов (на 13,57%).

Автор сообщений >>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 по умолчанию.

>>5453
Может вынести загрузку картинок на 2ch.sh или 0x0.st ?
Или на fastpic, как на рутрекере было раньше^W.

>>5489
С местом сейчас проблем нет.

Тѣмъ временем упомянутый FastPic ужé поддерживает публикацию WebP, причём не одних только статических, но и (с нынешнего декабря) анимированных также.

Хорошо бы было, кабы и на Nowere так.

>>5484

>① Использованы иллюстрации 1080×1080 пикселов, но уменьшены (некратно) до 400×400, чѣмъ уменьшены различия в их качестве.

Уже на этом пункте можно было остановиться.

Никоим образом нельзя было остановиться на одном этом пункте: это значило бы приоткрыть только краешек краешка.

>запилите webp
>ну запилите webp

пожалуй, я приложу картинку [x]

>>5484
Tl;dr: web2.0 облачные корпорасты обделались даже делая свою любимую маркетоидную политкорректную сеошную пропаганду