?

Log in

No account? Create an account
nyaload

Журнал Пушыстого

Журнал Пушыстого

Previous Entry Share Flag Next Entry
JPEG Chroma subsampling
nyaload
_winnie
Часто слышу жалобы от художников и дизайнеров "JPEG портит красный цвет при любом качестве" или "JPEG блюрит картинку"



( http://i35.tinypic.com/n6z0qo.png , http://www.picamatic.com/show/2008/10/27/09/51/1254937_837x753.png , http://files.shapegame.ru/picture_paste/_w2008-10-27__09-54-35_9kb.png )


1) можно использовать Save For Web из фотошопа (качество >= 51).
2) можно в консольном стандартном из LibJPEG cjpeg.exe указать параметр chroma subsampling как -sample 1x1,1x1,1x1
3) Ищите же его в других программах!


Вот статья с няшными иллюстрациями и подробными объяснениями: http://www.impulseadventure.com/photo/chroma-subsampling.html

Вот не вырожденый пример, а реальная графика: http://stream.ifolder.ru/8764652 (перещёлкивать два jpg в какой нибудь графической смотрелке)


  • 1
Блин! Спасибо! Я знал, что jpeg хранит цвет с вдвое худшим разрешением, чем яркость, но почему-то наивно думал, что это намертво зашито в формат и не отрывается. Век живи, век учись.

... Форт - просто два дважды как ...


>"JPEG блюрит картинку"

JPEG блюрит картинку не только из-за субсэмплинга компонент цветности, но (в меньшей степени) ещё и из-за DCT и квантизации.

Неплохо также прикинуть размер. Если принять объём картинки при субсемплинге «1x1,1x1,1x1» за единицу, то объём той же картинки при субсэмплинге «1x1,2x2,2x2» будет 1/2, а при «1x1,2x1,2x1» — 2/3.

Можно также при кодировании учесть вид самой картинки. Например, если картинка состоит преимущественно из вертикальных полос (типа флаг Франции), то можно «1x1,2x1,2x1» заменить на аналогичный «1x1,1x2,1x2», падение качества будет меньше.

Ну и вообще, JPEG следует предпочитать для непрерывно тоновых изображений (фотографии), там субсэмплинг обычно малозаметен. В твоём конкретном сферическо-вакуумном примере с одноцветными областями без градиентов лучше применять какое-нибудь сжатие без потерь (например, PNG).

Просто это часто очень проявлялось на нашей игровой графике. Где в основном градиенты, но есть и тонкие элементы с контурами.

Кстати, вот невакуумный пример: http://stream.ifolder.ru/8764652

это смотря чего нужно добиться.
если так сохранять фотографии, то при фиксированном размере они потеряют в качестве. цвет для глаза не так важен как яркость, JPEG делает 4:1:1 неспроста.
если же нужно сохранять вещи вроде вашего примера (чёткие границы, маленький спектр цветов), то лучше сохранять в PNG.

> глаза не так важен как яркость
Ох, не надо на автомате говорить фразами из учебника по комрессии графики.

Я дал ссылку на реальную графику, http://stream.ifolder.ru/8764652 , как выключив сжатие цветового канала и при том же размере в 24 кб сделать так же без размытия, как в out.jpg ?

А в png она весит 80 килобайт, в три раза больше.

про PNG я имел ввиду ваш пример с квадратом.
для тестовой картинки PNG ясно дело не подходит. на ней, возможно, 1:1:1 и имеет смысл. специфика в том, что это не фотография, есть много резких переходов, поэтому JPEG и лажает. на другом примере 1:1:1 может навредить. важно понимать это.

Да, это действительно так...
Но, ИМХО, 2:1:1 по умолчанию - это нехорошая подлянка...

Там дальше ещё цветовые коэффициенты квантуются сильней чем яркость, вот это правильно, и действительно корректно используется факт меньшей чувсвительности к цвету.
Но вот такой вот блюр цвета по умолчанию - мне кажется это игра в рулетку, причем ненужная. Ведь всё равно, на этапе квантования высокочастотных элементов на автомате будет использован факт, что нет резких переходов цвета.

смысл квантования 4:2:0 в том, что в фото и видео цвет для каждой точки не доступен изначально, он доступен только для квадрата 2x2 (байеровский фильтр).

>смысл квантования 4:2:0...

Это не квантование, это субсэмплинг. Квантование — совсем другая вещь.

>что в фото и видео цвет для каждой точки не доступен изначально

Поясните. Кодеру JPEG цвет каждой точки доступен изначально.

см. матрица байера или фильтр байера.

>см. матрица байера или фильтр байера.

Посмотрел. С вашим высказыванием «смысл квантования 4:2:0 в том, что...» по прежнему не согласен.

В посте речь идёт о кодировании существующей bmp-картинки, где вся информация доступна. В этом случае субсэмплинг — просто один из способов уменьшить объём картинки за счёт потенциального снижения качества. 4:2:0 даёт выигрыш в половину объёма, 4:2:2 — в одну треть. Иногда встречается субсэмплинг и вовсе 4x1. «Квадратность» MCU совсем не обязательна, алгоритмы в libjpeg никак не завязаны на конкретные значения частот дискретизации. Не вижу связи между размером элемента фильтра Байера и частотами в cjpeg по умолчанию. Из корреляции двух величин не следует их причинно-следственная зависимость.

Другое дело в jpg-файлах, закодированных цифровиком. Но и там встречаются фотографии с разнообразными частотами дискретизации цветовых компонент, а не только 2x2. (У меня как раз под рукой большая база фотографий, сделанных всеми современными моделями цифровиков.)

>как выключив сжатие цветового канала и при том же размере в 24 кб сделать так же без размытия, как в out.jpg ?

Вообще, в алгоритме сжатия JPEG есть много параметров доводки, но, повидимому, непосредственная отдача будет от оптимизации энтропийного кодирования.

Подробнее. Теоретически формат JPEG предусматривает возможность адаптивного энтропийного кодирования — арифметического. Но по ряду причин оно почти не используется, и стандартной реализацией (libjpeg), емнип, не поддерживается. Поэтому тюнить надо таблицы Хаффмана.

При генерации таблиц Хаффмана кодер из libjpeg не учитывает статистические свойства картинки, т. е. не делает дополнительного прохода для сбора статистики. Поведение по умолчанию — вставка рекомендованных стандартом ISO 10918-1 таблиц. Утилита cjpeg позволяет задать в качестве параметра свои таблицы. Так что можно попытаться «довести» конкретную картинку при фиксированном качестве (куда входит не только субсэмплинг, но и коэф-ты квантования) до минимального размера.

Детали реализации. Теоретически можно задавать несколько таблиц — разные для разных компонент, для коэф-тов AC/DC, плюс можно переопределять для разных кадров. На практике разумно сосредоточиться всего лишь на одной таблице — для AC коэф-тов, общая для цветовых компонент. Таблицы для коэф-тов DC chrominance-компонент и для AC и DC luminance-компоненты — хрен с ними, пусть будут стандартными.

Алгоритм построения таблицы Хаффмана будет отличаться от «школьного». Результатом будет не дерево, а другая струтура данных (список списков, подробности в литературе), которую легко запихнуть в целевой jpg-файл. Плюс есть ограничение на длину кода Хаффмана, поэтому оптимального кодирования не всегда можно достигнуть. Слишком длинные ветви «дерева Хаффмана» придётся отрезать и пришивать к другим веткам, что немного разбалансирует «дерево Хаффмана» и усложняет алгоритм.

Как-то так.

>При генерации таблиц Хаффмана кодер из libjpeg не учитывает
На всякий случай, -optimize

Еще интересно колупать матрицы квантования - это позволяет стандартными средствами выбирать, что "съест сжатие" в первую очередь. Нормальные цифровики и фотошоп обычно свои (отличные от libjpeg) и пользуют.

  • 1