Разработчики x264 критикуют формат WebP

🕛 02.10.2010, 13:05

Основной разработчик проекта x264, в рамках которого ведется разработка высокопроизводительного H.264-кодировщика, представил в собственном блоге технический разбор открытого сейчас фирмой Гугл формата для хранения изображений WEBP. Перевод данной заметки:
JPEG является весьма старым форматом сжатия изображения с потерями качества. По сегодняшним меркам он ужасен с позиции силы сжатия: почти любой формат, предложенный с момента возникновения кодека MPEG-2, идёт на равных, а то и выигрывает у JPEG в его своей игре. Причина, по которой люди не перешли на нечто более современное, как правило сводится к одному простому факту - переход не стоит затраченных усилий. Даже если бы возник формат, который сжимает изображение лучше JPEG вдвое, убедить весь мир перейти на него после 20 лет эксплуатации последнего почти нереально. К тому же, сжатие по алгоритму JPEG быстрое, простое и почти гарантированно не содержит никаких патентов, о которых возможно было бы волноваться. Свергнуть JPEG уже пробовали многократно: сперва это был JPEG-2000, позже Microsoft JPEG XR. Ни 1 из них отнюдь не продвинулся.
Теперь Гугл пробует заставить нас пользоваться ещё одним новым форматом - WEBP. Однако в действительности WEBP - часть межкадрового сжатия видеокодека VP8. С практической точки зрения у "нового" формата существуют несколько проблем, по сравнению со старым добрым JPEG: он не поддерживает все возможности JPEG, к тому же не содержит тех возможностей, которых от JPEG все хотели, к примеру, сжатия без потерь (сохранение неизменного качества). WEBP поддерживает лишь выборку насыщенности цвета 4:2:0, при том, что JPEG поддерживает 4:2:2 и 4:4:4. Гугл, похоже, не заинтересована в таких возможностях.
Однако давайте вернёмся к вопросу о том, насколько неплохо известные кодеки сжимают неподвижное изображение. В моём первом анализе VP8 я продемонстрировал, что он поддерживает межкадровое предсказание, как и H.264, что является одной из причин эффективности сжатия. VP8 поддерживает матрицы лишь i4x4 и i16x16, что - недостаток в сравнении с H.264, который тоже поддерживает матрицы i8x8, хотя VP8 близок по этому параметру.
Все результирующие файлы в нашем тестировании имеют размер около 155 Кб. Для всех 3-х файлов я выполнил бинарный поиск уровней качества, чтоб сжать изображения до приблизительно одинакового размера. К примеру, для x264 я выбрал следующие характеристики: "-tune stillimage -preset placebo". Для libvpx я использовал опцию "-best". JPEG изображение я заполучил при помощи ffmpeg, после изображение было обработано утилитой jpgcrush для уменьшения размера файла (эта программа перепаковывает JPEG для уменьшения размера без потерь в качестве). Я подозреваю, что в природе есть упаковщики лучше чем ffmpeg, тогда сами попробуйте провести этот тест и сообщите о ваших результатах. Исходное изображение (PNG) является двухсотым кадром видеоряда сцены Parkjoy, загрузить которое возможно тут.
Вот результаты сжатия x264, vp8 и jpg, сохранённые в PNG.
Требуется подчеркнуть, что результаты VP8 смущают - лично я думаю, что он продемонстрировал себя хуже всех, даже невзирая на блочность изображения JPEG. Что же тут случается в действительности? Кодирование энтропии у VP8 без сомнений серьезно лучше, чем у JPEG. VP8 содержит лучшее внутреннее предсказание (у JPEG есть лишь предсказание вида DC). Как так получилось, что VP выглядит хуже? Давайте это выясним.
VP8 использует трансформацию 4x4, которая приводит к замыливанию и потере в деталях в сравнении с преобразованием 8x8 у JPEG. Однако этого недостатка самого по себе недостаточно, чтоб разница в качестве была настолько значительной. Давайте проанализируем последующую гипотезу - что сложность кроется в том, что libvpx оптимизирует для PSNR и игнорирует психовизуальные критерии, когда кодирует изображение. Я закодирую изображение с параметром "-tune psnr -preset placebo" в x264, выключив все психовизуальные оптимизации.
Вот что получилось: x264, оптимизированный для PSNR, размер 154KB.
Какое размытие изображения! Немного лучше, чем VP8, однако всё равно хуже JPEG. И это используя тот же кодек и тот же уровень анализа, единственное что мы сделали иначе - отказались от использования психовизуальных оптимизаций. По этой причине мы пришли к выводу, который я вновь и вновь повторяю в собственном блоге - кодировщик значит более, чем формат сжатия, и что неплохие психовизуальные оптимизации важны более, чем нечто ещё. Libvpx, всерьез более сильный кодировщик, чем JPEG в составе ffmpeg, проигрывает, так как пробует чересчур весьма оптимизировать для PSNR.
Эти результаты поднимают законный вопрос - сошли ли с ума представители Гугл? Я бы мог понять продвижение WEBP, если бы он был лучше JPEG. И, естественно, принимая во внимание достоинства оригинального кодека VP8, он мог бы быть лучше JPEG. Однако заметьте, что я использую выражение "мог бы". Для чего анонсировать его теперь, когда libvpx является подобным отвратительным упаковщиком? Нужно быть сумасшедшим, чтоб заменять JPEG на этот размытый шум. Я не говорю о том, чтоб libvpx пытался на равных конкурировать с x264, лучшим кодеком формата H.264 в мире, без сомнений, однако, он должен был бы одержать победу кодек практически двадцатилетней давности, коим является JPEG, появившийся в 1992 г..
Мир компании Гугл: сперва сделайте хороший кодировщик, после пытайтесь его пропагандировать как замену существующим форматам. Обратное не работает так же неплохо.