Разработчики кодека x264 резко критикуют формат WebP, предложенный Google
Основной разработчик проекта x264, в рамках которого ведется разработка высокопроизводительного H.264-кодировщика, представил в своем блоге технический анализ открытого сегодня компанией Google формата для хранения изображений WebP. Перевод данной заметки:JPEG является очень старым форматом сжатия изображения с потерями качества. По сегодняшним меркам он ужасен с точки зрения силы сжатия: практически любой формат, предложенный с момента появления кодека MPEG-2, идёт на равных, а то и выигрывает у JPEG в его собственной игре. Причина, по которой люди не перешли на что-то более современное, обычно сводится к одному простому факту — переход не стоит затраченных усилий. Даже если бы появился формат, который сжимает изображение лучше JPEG в два раза, убедить весь мир перейти на него после 20 лет использования последнего практически невозможно. Более того, сжатие по алгоритму JPEG быстрое, простое и практически гарантированно не содержит никаких патентов, о которых можно было бы беспокоится. Свергнуть JPEG уже пытались неоднократно: сначала это был JPEG-2000, потом Microsoft JPEG XR. Ни один из них далеко не продвинулся.
Сейчас Google пытается заставить нас пользоваться ещё одним новым форматом - WebP. Но на самом деле WebP является частью межкадрового сжатия видеокодека VP8. С практической точки зрения у "нового" формата существуют несколько проблем, в сравнении со старым добрым JPEG: он не поддерживает все возможности JPEG, также не содержит тех возможностей, которых от JPEG все хотели, например, сжатия без потерь (сохранение неизменного качества). WebP поддерживает только выборку насыщенности цвета 4:2:0, тогда как JPEG поддерживает 4:2:2 и 4:4:4. Google, похоже, не заинтересована в этих возможностях.
Но давайте вернёмся к вопросу о том, насколько хорошо известные кодеки сжимают неподвижное изображение. В моём первом анализе VP8 я показал, что он поддерживает межкадровое предсказание, как и H.264, что является одной из причин эффективности сжатия. VP8 поддерживает матрицы только i4x4 и i16x16, что является недостатком по сравнению с H.264, который также поддерживает матрицы i8x8, однако VP8 близок по этому параметру.
Все результирующие файлы в нашем тестировании имеют размер приблизительно 155 Кб. Для всех трёх файлов я выполнил бинарный поиск уровней качества, чтобы сжать изображения до примерно одинакового размера. Например, для 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.
Эти результаты поднимают законный вопрос – сошли ли с ума представители Google? Я бы мог понять продвижение WebP, если бы он был лучше JPEG. И, конечно, учитывая достоинства оригинального кодека VP8, он мог бы быть лучше JPEG. Но заметьте, что я использую выражение "мог бы". Зачем анонсировать его сейчас, когда libvpx является таким отвратительным упаковщиком? Надо быть сумасшедшим, чтобы заменять JPEG на этот размытый шум. Я не говорю о том, чтобы libvpx пытался на равных конкурировать с x264, лучшим кодеком формата H.264 в мире, но, несомненно, он должен был бы победить кодек почти двадцатилетней давности, коим является JPEG, появившийся в 1992 году.
Мир компании Google: сначала сделайте хороший кодировщик, затем пытайтесь его пропагандировать как замену существующим форматам. Обратное не работает так же хорошо.
Полный текст статьи читайте на OpenNet
