Освобождение, упомянутое въ послѣднемъ абзацѣ предшествующаго сообщенія, может быть достигнуто только одним способом: нужно составить ѿдѣльное собственное мнение о каждом из трёх вариантов формата WebP. Я своё мнение составил и сейчас подѣлюсь им, начиная с мнения о первом из этих вариантов.
Формат lossy WebP задумывался как замѣна для JPEG на случай необходимости сжать изображения цѣною внесения потерь. Существует исследование Google, показывающее превосходство качества сжатых изображений в формате lossy WebP над качеством сжатых изображений в формате JPEG равного им объёма, гдѣ качество измѣрялося по объективному показателю (SSIM), а затѣмъ ещё показывающее, что при равном качестве файл WebP получается иногда на четверть, а иногда и на треть меньше, чѣмъ файл JPEG. Существует также альтернативное исследование Фонда Мозиллы (сохранившееся в Архиве Интернета), которое показывает, что в зависимости от выбора оцѣнки: Y-SSIM, RGB-SSIM, IW-SSIM, PSNR-HVS-M — файлы WebP равного качества могут быть и больше, и меньше, и примѣрно равны файлам JPEG по объёму, так что итог этого исследования был назван в 2013 году и затѣмъ ещё в 2014 году не позволяющим прийти к убеждённости в превосходстве lossy WebP над JPEG, а вмѣсто того всѣмъ надо, дескать, стремиться к тому, чтобы получше сжимать файлы JPEG (и для такого сжатия этот фонд создал MozJPEG). Этим же исследованием было показано, что ключевые кадры видеоформата HEVC сжимают изображение (при равных показателях SSIM его качества) гораздо лучше, чѣмъ JPEG и чѣмъ lossy WebP.
Получается, что lossy WebP при примѣрно равной JPEG степени сжатия поддерживается менѣе широко, а выбранный подход (создание формата сжатия изображений на основе извѣстнаго формата ключевых кадров нѣкотораго видеопотока) получше работает на основе болѣе новыхъ, чѣмъ VP8, видеоформатов, так что на этом пути lossy WebP сперва оказывается обойдён форматом HEIF (на основе видеоформата HEVC), который (в отличие от WebP) поддерживается в продуктах Apple (начиная от iOS 11 и притом под названием HEIC вмѣсто HEIF), а в будущем — обойдён и форматом AVIF (на основе видеоформата AV1).
Кроме того, нетрудно чувствовать, что этот подход: создание формата сжатия изображений на основе извѣстнаго формата ключевых кадров нѣкоторого видеопотока — является в какой-то мѣрѣ извращённым. Тут не «просто чувство»: оно подкреплено фактами технических недостатков, являющихся послѣдствіемъ выбраннаго подхода, то есть послѣдствіемъ ѿличій, существующих между нуждами видеоформата и нуждами формата изображений.
Напримѣръ, так как производительность видеопроигрывателей еле-еле начала подбираться к кадрам размѣромъ 4K и 8K, то предѣльный размѣръ кадра VP8, хотя бы и запроектированный «на вырост», всего ≈вдвое больше них, так что и размѣръ изображения в WebP не может превосходить 16383×16383 пиксела.
Напримѣръ, так как видеокадр рассматривается как недѣлимый, то формат WebP не предусматривает постепенной (чересстрочной) развёртки файла (файл показывается по мѣрѣ загрузки всегда только сверху вниз).
Напримѣръ, так как быстрая смѣна кадров позволяет въ полной мѣрѣ полагаться на то, что цвѣтовая чувствительность зрѣнія человѣка отстаёт от яркостной, то и для lossy WebP обязательна цвѣтовая субдискретизация 4:2:0 (всегда один пиксел цвѣтности на 2×2 пиксела яркости), хотя иллюстрацию могут (и будут) рассматривать дольше кадра, что сдѣлает болѣе явною нечёткость цвѣтовых контуров.
Кроме того, WebP наслѣдуетъ от VP8 восьмибитность цвѣтовыхъ каналов, за предѣлы TrueColor ему не выйти.
Ото всѣхъ этих недостатков lossy WebP будет свободным будущий формат JPEG XL, о достоинствах которого я упоминал ужé на моём канале в Telegram 26 декабря прошлого (2019) года въ нѣскольких сообщениях, начиная вон с того. А ещё JPEG XL будет меньше сглаживать картинку, чѣмъ это дѣлается форматом HEIC (основанном на видеокадрах HEVC, одержавших побѣду над lossy WebP в исследовании Фонда Мозиллы). А ещё JPEG XL будет поддерживать обратимое переужатие информации из файлов JPEG.
Всё это — причины уходить с JPEG именно на JPEG XL, а lossy WebP для этой роли не сгодился.
Формат lossy WebP задумывался как замѣна для JPEG на случай необходимости сжать изображения цѣною внесения потерь. Существует исследование Google, показывающее превосходство качества сжатых изображений в формате lossy WebP над качеством сжатых изображений в формате JPEG равного им объёма, гдѣ качество измѣрялося по объективному показателю (SSIM), а затѣмъ ещё показывающее, что при равном качестве файл WebP получается иногда на четверть, а иногда и на треть меньше, чѣмъ файл JPEG. Существует также альтернативное исследование Фонда Мозиллы (сохранившееся в Архиве Интернета), которое показывает, что в зависимости от выбора оцѣнки: Y-SSIM, RGB-SSIM, IW-SSIM, PSNR-HVS-M — файлы WebP равного качества могут быть и больше, и меньше, и примѣрно равны файлам JPEG по объёму, так что итог этого исследования был назван в 2013 году и затѣмъ ещё в 2014 году не позволяющим прийти к убеждённости в превосходстве lossy WebP над JPEG, а вмѣсто того всѣмъ надо, дескать, стремиться к тому, чтобы получше сжимать файлы JPEG (и для такого сжатия этот фонд создал MozJPEG). Этим же исследованием было показано, что ключевые кадры видеоформата HEVC сжимают изображение (при равных показателях SSIM его качества) гораздо лучше, чѣмъ JPEG и чѣмъ lossy WebP.
Получается, что lossy WebP при примѣрно равной JPEG степени сжатия поддерживается менѣе широко, а выбранный подход (создание формата сжатия изображений на основе извѣстнаго формата ключевых кадров нѣкотораго видеопотока) получше работает на основе болѣе новыхъ, чѣмъ VP8, видеоформатов, так что на этом пути lossy WebP сперва оказывается обойдён форматом HEIF (на основе видеоформата HEVC), который (в отличие от WebP) поддерживается в продуктах Apple (начиная от iOS 11 и притом под названием HEIC вмѣсто HEIF), а в будущем — обойдён и форматом AVIF (на основе видеоформата AV1).
Кроме того, нетрудно чувствовать, что этот подход: создание формата сжатия изображений на основе извѣстнаго формата ключевых кадров нѣкоторого видеопотока — является в какой-то мѣрѣ извращённым. Тут не «просто чувство»: оно подкреплено фактами технических недостатков, являющихся послѣдствіемъ выбраннаго подхода, то есть послѣдствіемъ ѿличій, существующих между нуждами видеоформата и нуждами формата изображений.
Напримѣръ, так как производительность видеопроигрывателей еле-еле начала подбираться к кадрам размѣромъ 4K и 8K, то предѣльный размѣръ кадра VP8, хотя бы и запроектированный «на вырост», всего ≈вдвое больше них, так что и размѣръ изображения в WebP не может превосходить 16383×16383 пиксела.
Напримѣръ, так как видеокадр рассматривается как недѣлимый, то формат WebP не предусматривает постепенной (чересстрочной) развёртки файла (файл показывается по мѣрѣ загрузки всегда только сверху вниз).
Напримѣръ, так как быстрая смѣна кадров позволяет въ полной мѣрѣ полагаться на то, что цвѣтовая чувствительность зрѣнія человѣка отстаёт от яркостной, то и для lossy WebP обязательна цвѣтовая субдискретизация 4:2:0 (всегда один пиксел цвѣтности на 2×2 пиксела яркости), хотя иллюстрацию могут (и будут) рассматривать дольше кадра, что сдѣлает болѣе явною нечёткость цвѣтовых контуров.
Кроме того, WebP наслѣдуетъ от VP8 восьмибитность цвѣтовыхъ каналов, за предѣлы TrueColor ему не выйти.
Ото всѣхъ этих недостатков lossy WebP будет свободным будущий формат JPEG XL, о достоинствах которого я упоминал ужé на моём канале в Telegram 26 декабря прошлого (2019) года въ нѣскольких сообщениях, начиная вон с того. А ещё JPEG XL будет меньше сглаживать картинку, чѣмъ это дѣлается форматом HEIC (основанном на видеокадрах HEVC, одержавших побѣду над lossy WebP в исследовании Фонда Мозиллы). А ещё JPEG XL будет поддерживать обратимое переужатие информации из файлов JPEG.
Всё это — причины уходить с JPEG именно на JPEG XL, а lossy WebP для этой роли не сгодился.