screenshot.png
screenshot.10bit16qm11-15.avif
screenshot-d5.60001.jxl
screenshot.jxl
Мысли о сильном сжатии, изложенныя в моём предыдущем сообщении, можно иллюстрировать на примѣрѣ скриншота, там приложенного. Этот скриншот содержит 1280×1152 = 1474560 пикселов. Значит, рассуждая об использовании не болѣе ½ битов на пиксел в среднем, мы говорим о таком объёме файла, который не превосходил бы 1474560 / 16 = 92160 байтов для этого скриншота. В качестве наглядной иллюстрации я предлагаю четыре файла:
① Файл PNG объёмом 218 883 байта. Это исходный скриншот, сжатый (без внесения потерь) посредством Efficient Compression Tool. Тот JPEG, который приложен к предшествующему сообщению, всего-навсего на 8% меньше этого PNG — на мой взгляд, достигнутая экономия не стóит потерь, внесённых JPEGованием, так что по уму Телеграму (да и Твиттеру) слѣдовало бы принимать файлы PNG такого удѣльнаго объёма (1,19 bpp) без принудительного перекодирования в JPEG.
② Файл AVIF объёмом 91833 байта. Его качество изображения куда лучше, чѣмъ у того файла JPEG, который был приложен к моему предшествующему сообщению — а вѣдь разница по объёму болѣе чѣмъ двукратна! На этом примѣрѣ видно, что возможности нового формата (AVIF) позволяют неслабо экономить как объём, так и качество изображения (причём одновременно) при таком малом удѣльном объёме (≈½ bpp), который в рамках старого формата (JPEG) достигался бы только при досадных потерях качества.
③ Файл JPEG XL объёмом 91791 байт. Видно, что его алгоритм сжатия, совершаемого с внесением потерь, скверно работает при настолько малом количестве битов — чрезмѣрно размазывает отдѣльные пикселы. Появление JPEG XL не потеснит AVIF в этой области сильного сжатия: достоинства JPEG XL требуют большего удѣльнаго объёма.
④ Файл JPEG XL объёмом 152 445 байтов. Этот файл большего удѣльнаго объёма (0,827 bpp) — примѣръ возможностей сжатия без потерь, в JPEG XL заложенных (как нетрудно сосчитать, по силе сжатия он опережает PNG болѣе чѣмъ на 30%).
Сравнивать изображения, хранимые в этих новых форматах, приходится в просмотрщике, понимающем как AVIF, так и JPEG XL. (Ну, напримѣръ, в XnView MP.)
① Файл PNG объёмом 218 883 байта. Это исходный скриншот, сжатый (без внесения потерь) посредством Efficient Compression Tool. Тот JPEG, который приложен к предшествующему сообщению, всего-навсего на 8% меньше этого PNG — на мой взгляд, достигнутая экономия не стóит потерь, внесённых JPEGованием, так что по уму Телеграму (да и Твиттеру) слѣдовало бы принимать файлы PNG такого удѣльнаго объёма (1,19 bpp) без принудительного перекодирования в JPEG.
② Файл AVIF объёмом 91833 байта. Его качество изображения куда лучше, чѣмъ у того файла JPEG, который был приложен к моему предшествующему сообщению — а вѣдь разница по объёму болѣе чѣмъ двукратна! На этом примѣрѣ видно, что возможности нового формата (AVIF) позволяют неслабо экономить как объём, так и качество изображения (причём одновременно) при таком малом удѣльном объёме (≈½ bpp), который в рамках старого формата (JPEG) достигался бы только при досадных потерях качества.
③ Файл JPEG XL объёмом 91791 байт. Видно, что его алгоритм сжатия, совершаемого с внесением потерь, скверно работает при настолько малом количестве битов — чрезмѣрно размазывает отдѣльные пикселы. Появление JPEG XL не потеснит AVIF в этой области сильного сжатия: достоинства JPEG XL требуют большего удѣльнаго объёма.
④ Файл JPEG XL объёмом 152 445 байтов. Этот файл большего удѣльнаго объёма (0,827 bpp) — примѣръ возможностей сжатия без потерь, в JPEG XL заложенных (как нетрудно сосчитать, по силе сжатия он опережает PNG болѣе чѣмъ на 30%).
Сравнивать изображения, хранимые в этих новых форматах, приходится в просмотрщике, понимающем как AVIF, так и JPEG XL. (Ну, напримѣръ, в XnView MP.)