Техническое примечание TN2307

QuickTime - Рендеринг в Y'CbCr

Первоначально опубликованный 20-го августа 2000 как Ледяная Отгрузка Плавучей льдины 27, часть «Букв от Ледяной группы» Плавучей льдины документов разработки QuickTime.

Это примечание адресует улучшения производительности и качества при рендеринге видео (т.е. применении эффектов или обработке видео) при помощи цветовых пространств Y'CbCr в противоположность традиционному использованию RGB.

RGB является собственным цветовым пространством QuickTime, так исторически большинство видео компрессоров и декомпрессоров преобразовывают от их сжатого формата до и от RGB. Однако много алгоритмов сжатия для видео используют внутренний формат данных, где интенсивность (luma) и цвет (цветность) значения сохранены отдельно. Преобразование от этих цветовых пространств YUV до RGB на распаковке и назад на сжатии влияет на производительность и точность, и также, может отсечь значения, которые могут быть представлены только в одном из этих двух цветовых пространств.

Один из наиболее распространенных форматов цветового пространства YUV, использованного в видео домене, указан Rec. ITU-R BT.601-4, часто называемый «Rec. 601». который определяет цветовое пространство Y'CbCr. Это - формат, используемый стандартными телевизионными сигналами, и сжало материал, такой как DV, MPEG или JPEG движения.

Диапазон значений в канале для изображения Y'CbCr обычно следующие:

Y': 16 to 235 recommended range.
        (Values 0 and 255 are reserved by Rec. 601 for synchronization
        purposes.)
Cb: -112 to +112, offset by 128, for a recommended range of 16 to 240
Cr: -112 to +112, offset by 128, for a recommended range of 16 to 240

Однако обратите внимание на то, что экстремальные значения диапазона кодирования обеспечивают сигнальную высоту (Poynton, p. 174). Также обратите внимание на то, что в некоторых случаях, камеры генерируют значения за пределами рекомендуемого диапазона (Цифровые видеокамеры генерируют из значений диапазона особенно часто). - больше на этом позже.

Y'CbCr обычно упоминается как наличие 4:2:2 подвыборка - это обозначение относится к частотам дискретизации luma и цветности в сигнале. Это может также относиться к способу, которым пиксели упаковываются в данном формате пикселя. Обратите внимание на то, что подвыбранный сигнал может быть упакован в пиксельной карте, чем может сохранить больше разрешения. Сигнал, подвыбранный в 4:1:1 (такой как NTSC DV), мог быть сохранен в 4:2:2 упакованная пиксельная карта. Точно так же это могло бы быть сохранено в 4:4:4 пиксельная карта также.

Ошибки преобразования между Y'CbCr и RGB
Известные проблемы реализации
Ссылки
История версии документа

Ошибки преобразования между Y'CbCr и RGB

Искажение

При преобразовании между двумя различными цветовыми пространствами, даже при том, что процесс преобразования разработан, чтобы быть симметричным (повторенные преобразования не вызывают смещения), происходит искажение, потому что цветовые пространства не выравниваются для каждого пиксельного значения. Поэтому существует свойственное преобразование потерь от Y'CbCr до RGB и назад.

Фиксация Luma

Компьютеры определяют RGB, черный как 0 (на компонент) и белый как 255. Для поддержания полный черный к белому диапазону в пространстве RGB, уравнения преобразования цветового пространства отображают значения luma, колеблющиеся от 16 до 235 до значений RGB от 0 до 255 (C. Poynton, Eq. 9.11, pg. 177 или Цвет Poynton FAQ).

Обычно это является надлежащим, но существуют времена, когда значение luma в исходном изображении может быть выше, чем 'рекомендуемое' максимальное значение 235. Это особенно верно для многих цифровых видеокамер, обычно генерирующих значения luma в диапазоне 236-254. В этих случаях всех значениях более чем 235 будут отображены на 255 в RGB, вызывающем изменение в фактическом значении интенсивности. Это обычно известно как 'luma фиксация'.

Примером этого был бы белый стул в солнечном свете, где значения Y'CbCr цифровой видеокамеры могли бы быть (Y' =250, Cb=128, Cr=128). Используя уравнения цветового пространства для движения в RGB мы получаем значения RGB, фиксирующиеся к 255,255,255 (272,272,272 прежде, чем зафиксировать). При возвращении к Y'CbCr результат был бы (Y' =235, Cb=128, Cr=128), который будет заметно более темным, чем оригинал.

Фиксация цветности

Существует много значений цвета Y'CbCr, отображающихся на значения RGB, больше, чем 255 или меньше, чем 0. Это означает, что существует, раскрашивает YCbCr, который не может быть представлен в RGB GWorld. Эти цвета будут зафиксированы к значениям RGB, которые находятся в диапазоне 0-255, вызывая 'фиксацию цветности'.

Примером этого был бы очень насыщенный цвет, такой как (Y' =155, Cb=174, Cr=220). Если бы это было отображено в RGB (255 [309 прежде, чем зафиксировать], 69,255), и затем назад в Y'CbCr (Y' =141, Cb=182, Cr=196), то значимый colorshift и затемнение были бы видимы.

И фиксация luma и фиксация цветности состоят в том вследствие того, что цветовое пространство RGB меньше, чем цветовое пространство Y'CbCr при использовании формул для преобразования между Y'CbCr и компьютером RGB.

Гамма-коррекция

GWorlds на Macintosh традиционно представлены как гамма 1,8 буфера RGB. Стандартные видеосистемы представлены как наличие эффективной гаммы 2,2. Преобразование кодеков в и от RGB обычно гамма исправляет для учета различных эффективных гамм. Это преобразование является процессом с потерями, однако, таким образом сохранение представленных буферов в гамме 2.2 желаемо.

Предпочтенные форматы пикселя Y'CbCr

Путем обработки буферов рендеринга в Y'CbCr вышеупомянутого искажения и зажимных проблем избегают, и дополнительно, так как сжатым форматом является исходно Y'CbCr, дорогих преобразований в и от RGB можно избежать.

2vuy

Формат пикселя '2vuy' (k2vuyPixelFormat) является стандартом, рекомендуемым формат для обмена в домене Y'CbCr. '2vuy' следует за Rec. 601 диапазон компонента. Это действительно имеет определенные ограничения: '2vuy' 4:2:2 формат, что означает, что пара значений luma совместно использует те же значения цветности. Это имеет преимущество, что хранение меньше, но это трудно для обработки видеоданных, так как пиксельные пары совместно используют те же значения цветности, таким образом, обработка каждого отдельного пикселя больше не независима. Кроме того, формат пикселя хранит два luma для каждой пары цветности, таким образом, это не хороший формат, если бы данные также не подвыбираются (например, 4:2:2 или 4:1:1 было бы хорошо, 4:4:4 было бы плохо). Это рекомендуется как формат хранения.

'v308' и 'v408'

Эти форматы пикселя (k444YpCbCr8CodecType и k4444YpCbCrA8CodecType) используют то же цветовое пространство как '2vuy', таким образом, у них также есть те же преимущества Y'CbCr. Однако они оба 4:4:4 выборка, таким образом, они являются более подходящими для обработки видеоданных. 'v408' подобен 'v308' за исключением того, что это имеет дополнительный Альфа-канал с тем же диапазоном как Y' компонент: «максимальная альфа» соответствует «белый» в канале Y и поэтому в значении 235; «минимальная альфа» соответствует «черный» в канале Y и поэтому в значении 16. Они рекомендуются как форматы хранения также.

'r408'

Apple определил новый формат пикселя, 'r408' (k4444YpCbCrA8RCodecType), который является дружественным по отношению к приложениям, представляющим в форматах ARGB, но хотящим использовать в своих интересах цветовое пространство Y'CbCr. Его преимущества перед другими цветовыми пространствами Y'CbCr следующие:

  • Это 4:4:4:4, что означает, что компоненты НЕ совместно используются через пиксели.

  • Альфа колеблется от 0-255, тот же диапазон как в ARGB.

  • Это упаковывается AY'CbCr. Это позволяет многим подпрограммам обработки изображений быть выполненными неизменные на данных Y'CbCr. Это включает любую обработку изображений, делающую пиксельную выборку и большинство алгоритмов, не выполняющих цветную определенную обработку.

  • Значение luma (Y') смещается так, чтобы черный был 0, а не 16. Рекомендуемые диапазоны для luma поэтому от 0 до 219, а не 16-235. Высота выше 235 сохраняется, но потерян footroom. Этот компромисс стоит того, потому что теперь операции на luma только могут быть сделаны легко, не имея необходимость смещать черную точку для каждого пикселя. Это снова для производительности и для более простого портирования существующего ARGB, представляющего код.

'r408' предназначается как формат рендеринга, не формат хранения. Некоторые дополнительные примечания: если никакое определенное значение не доступно, 1) При распаковке материала к формату 'r408', кодеки требуются, чтобы заполнять альфа-канал во время распаковки, заполняющейся 255 (непрозрачный). 2) Компрессоры должны зафиксировать входные значения 'r408' luma, так как сохраненные диапазоны могут превысить допустимый диапазон Y'CbCr luma (1-254). После отображающихся уравнений 'r408' Y' оценивает, более чем 238 должны быть зафиксированы. 3) гамма буфера 'r408' обычно 2.2. Рекомендации рекомендуется, что все кодеки, воздействующие на данные Y'CbCr быть обновленными для поддержки 'r408', чтобы позволить приложениям выполнять самую точную обработку изображений.

Некоторые кодеки могут также хотеть поддерживать 'v408' цветовое пространство, потому что 'v408' позволяет надлежащее кодировать изображений с 'суперчерными' значениями (т.е. цветные полосы). Кодеки, поддерживающие 'v408', позволят приложениям генерировать истину pluge для их цветных полос.

Писатели кодека захотят добавить новые форматы пикселя к своему 'требуемому списку формата пикселя', обнаруживают их в BeginBand и реализуют надлежащее хранение в DrawBand. Кодеки должны также распространить поддерживаемые форматы в 'cpix' ресурсе.

Приложения, вероятно, захотят представить пользовательские интерфейсы, позволяющие выбор желаемого 'уровня белого' для графики. «Белый» приравнял бы к Y' значение 235, и «Супер Белый» приравняет к Y' значение 254. Приложение использовало бы эту информацию, чтобы определить, отобразить ли импортированную диаграмму RGB RGB (255,255,255) в «белый» Y'CbCr (235 [или 219 в 'r408']) или «супер белый» (254 [или 238 в 'r408']).

Приложения могут определить возможности сжатия до и от Y'CbCr путем запросов компонента для его 'cpix' ресурса и исследования содержания на желаемый fourCC.

Известные проблемы реализации

Ссылки



История версии документа


ДатаПримечания
04.02.2013

Новый документ, первоначально опубликованный как Ледяная Отгрузка Плавучей льдины 27, «Буквы от Ледяной Плавучей льдины» технические документы.