Дополнительные байты на конце буфера YUV - RaspberryPi

Question

Я начал редактировать код RaspiStillYUV.c. В конечном итоге я хочу обработать изображение, которое я получаю, но сейчас я просто работаю, чтобы понять это. Почему я работаю с YUV вместо RGB? Поэтому я могу узнать что-то новое. Я внес незначительные изменения в функцию camera_buffer_callback. Все, что я делаю это следующее:

fprintf(stderr, "GREAT SUCCESS! %d\n", buffer->length); 

Линия это замена:

Теперь размеры должны быть 2592 x 1944 (Ш х В), как в коде. Отключение Википедии (YUV420) Я пришел к выводу, что размер файла должен быть w * h * 1.5. Поскольку компонент Y имеет 1 байт данных для каждого пикселя, а компоненты U и V имеют 1 байт данных для каждых 4 пикселей (1 + 1/4 + 1/4 = 1.5). Отлично. Выполнение математических операций в Python:

>>> 2592 * 1944 * 1.5 
7558272.0 

К сожалению, это не совпадает с выходом моей программы:

GREAT SUCCESS! 7589376 

Это оставляет разницу 31104 байтов.

Я полагаю, что буфер выделяется в куски фиксированного размера (размер вывода равномерно делится на 512). Хотя я хотел бы понять эту тайну, я в порядке с объяснением размера фиксированного размера.

Мой вопрос: если я что-то упустил. Являются ли дополнительные байты за ожидаемым размером значимыми в этом формате? Следует ли их игнорировать? Вычет моих расчетов?

Answer 1

документация по этому адресу поддерживает вашу теорию на дополнения: http://www.raspberrypi.org/wp-content/uploads/2013/07/RaspiCam-Documentation.pdf

В частности:

Обратите внимание, что буферы изображения, сохраненные в raspistillyuv обиты к горизонтального размера, кратного 16 (так что может должны быть неиспользуемыми байтами на конце конца каждой строки, чтобы ширина делилась на 16). Буферы также являются , заполненными вертикально, чтобы делиться на 16, а в режиме YUV каждая плоскость Y, U, V дополняется таким образом.

Так что моя интерпретация заключается в следующем. Ширина 2592 (делится на 16, так что это нормально). Высота 1944, что на 8 единиц меньше, чем на 16, поэтому добавляются дополнительные 8 * 2592 (также умножаются на 1,5), что дает вам дополнительные байты 31104.

Хотя этот вид помогает с размером файла, он не объясняет структуру выходного сигнала YUV должным образом.Я имею взгляд на это описание, чтобы увидеть, если это дает подсказку, чтобы начать с: http://en.wikipedia.org/wiki/YUV#Y.27UV420p_.28and_Y.27V12_or_YV12.29_to_RGB888_conversion

Из этого я считаю, что это выглядит следующим образом:

Y Канал:

2592 * (1944 +8) = 5059584

U канал:

1296 * (972 + 4) = 1264896

V Канал:

1296 * (972 + 4) = 1264896

Предоставление сумму:

5059584 + 2 * 1264896 = 7589376

Это приводит к тому, что цифры складываются, поэтому остается только подтвердить правильность этой интерпретации.

Я также пытаюсь сделать YUV-декодирование (для сравнения изображений), поэтому, если вы можете подтвердить, действительно ли это соответствует тому, что вы читаете в YUV-файле, это было бы высоко оценено.

Answer 2

Вы должны внимательно прочитать руководство. Буферы дополняются кратным 16, но данные о цвете полуразмерны, поэтому размер изображения должен быть кратным 32, чтобы избежать проблем с нарушением внешнего программного обеспечения.