Каскадный · [ Стандартный ] · Линейный+ Насчет цветового пространства в АВИ файлах..., давайте общаться

Смысл общения в следующем:
Я обнаружил в заголовке формата видео потока в ави файле следующее поле: BitDepth
Как показало дальнейшее изучение, оно принимает значения, которые легко ассоциировать с цветовым пространством, которое использовалось при кодировании ави, а именно 32, 24, 16, 12... (RGB32, RGB24, YUY2, YV12... соответственно).
Однако, проведенные мною тесты показали следующее:
1) Результат после кодирования DiVX 5.1.1 кодеком дает всегда на выходе 24 бита
2) XVID при кодировании в последней версии VirtualDub'a дал 24, 24, 16, 16
3) XVID при кодировании в последней версии VirtualDubmod'a дал 24, 24, 16, 12 (!)

Для теста я использовал следующий AviSynth 2.54 скрипт:
ImageReader("test.jpg", 0, 0)
FlipVertical()
Loop(200)
ConvertTo... (RGB32, RGB24, YUY2, YV12 соответственно)

Вопрос: в чем тут порылась собака?

В графической системе Windows для описания плоского изображения предусмотрена структура BITMAPINFOHEADER она используется для хранения файлов BMP, работе с графикой окон, работе с мультимедиа графикой (Video for Windows). Вот, и в ней описаны следующие поля
(я привожу только 6) //MSDN VC 6.0
biWidth - ширина изображения
biHeight - высота изображения
biPlanes - плоскости изображения (для 8 и более битных всегда 1)
осталось из прошлого
biBitCount - то что ты назвал BitDepth хранит число бит необходимое для представления одного пиксела в битах
biCompression - тип сжатия (для картинок без сжатия равно 0 для AVI без сжатия может быть равно ' BID' (что читается как DIB))
biSizeImage - размер изображения

Так вот исторически biBitCount можно было использовать для получения размера изображения:
biSizeImage = (biWidth * biHeight * biBitCount )/8;
Теперь поразмышляй и скажи имеет ли какое нибудь значение biBitCount если мы сжали в XVID кроме того, что предположительно оно будет распаковано в другой формат.

У Windows есть стандартные (поддреживаемые ей изнутри) форматы у них всегда biCompression =0 а biBitCount = 1,2,4,8,16,14,32 (я не тестил но вроде ещё 15)
У Windows вроде с 98SE есть поддержка biCompression = bi_JPG и bi_PNG или както так.
Для работы с отальными надо делать (или некоторые функции автоматически делают) преобразование (распаковку в формат вывода). Обычно формат вывода равен экранному.

Распаковку делают соответственно кодеки (CoDec)

Изображение в формате RGB32 в памяти выглядит так:
B G R A B G R A B G R A .... B G R A - последняя строка (нижняя)
B G R A B G R A B G R A .... B G R A
B G R A B G R A B G R A .... B G R A
B G R A B G R A B G R A .... B G R A - Первая строка (верхняя)
\ /
Первые пикселы
Первого столбца

Подобная картина и в форматах RGB24,16 и 15
В RGB8 я не буду расказывать (лень)

А вот в формате I420 или IYUV всё иначе:
для каждого из 4 соседних пикселов вычисляются 2 значения цветовых компонент и 4 яркостных

[rgb][rgb][rgb][rgb] [y][y][y][y]
[rgb][rgb][rgb][rgb] => [y][y][y][y] + [Cr Cb] [Cr Cb]
[rgb][rgb][rgb][rgb] [y][y][y][y]
[rgb][rgb][rgb][rgb] [y][y][y][y] [Cr Cb] [Cr Cb]
RGB24 I420 или IYUV

В RGB24
r занимал 8 бит
g занимал 8 бит
b занимал 8 бит
на один пиксел = 24

В I420 или IYUV (на 4 пиксела)
y занимал 8 бит * 4
Cr занимал 8 бит
Cb занимал 8 бит
сумма на 4 пиксела = 48 бит
На один пиксел = 12 бит

Любой разумный человек скажет - это потери качества!
- ясен пень.
Но в VHS видео там качества нет (оно было отфильтровано специальными фильтрами).
И поэтому многие устройства видео захвата предлагают такой формат как один из базовых.

YUY2, YV12 - взялись оттудаже не работал с ними но видел не редко

Также эти форматы любят оверлеи (в смысле они для них родные).
А для Windows их должен поддерживать либо специальный кодек (запаковщик распаковщик) либо кодек который распаковывает само видео (например XVID). Такое делает ffdshow.

Большинство кодеров при сжатии (JPEG и все MPEG'и) перед упаковкой переводят изображение в IYUV и для этого они должны делать вычисления следующего рода:
Найти яркость Y первого пиксела в квадрате 2x2 пиксела
... Y вторго
... Y третьего
... Y четвёртого
Потом найти среднее для всех пикселов Cr и Cb

Но на практике они определяют не среднее а значение Cr и Cb только значение для _первого_ пиксела а на остальные 3 плюют. Зато быстро работает.

Если сжимать картинку в которй будет чередование Красных/синих линий то она будет либо красная либо синяя.

Удивительно но перевод из RGB24 в I420 и наоборот Win98 и XP делают по разным алгоритмам.

мой емаил: casandr-dev@mail.ru и надо удалить из него '-dev'
'-dev' - диверсия для спамеров

Небольшое дополнение
Для теста
....сжимать картинку в которй будет чередование Красных/синих линий то она будет либо красная либо синяя.
Не подойдёт использование кадра из файла формта JPG:
ImageReader("test.jpg", 0, 0)