Лишние байты в конце буфера YUV — RaspberryPi

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

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

Строка, которую это заменяет:

bytes_written = fwrite(buffer->data, 1, buffer->length, pData->file_handle);

Теперь размеры должны быть 2592 x 1944 (Ш x В), как указано в коде. Отрабатывая Википедию (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). Хотя я хотел бы понять эту загадку, я согласен с объяснением куска фиксированного размера.

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


camera raspberry-pi yuv
person douggard    schedule 19.12.2013    source источник
comment
Довольно часто буферы yuv имеют неиспользуемые конечные байты, но я не знаю деталей, специфичных для малины.   -  person Alex Cohn    schedule 19.12.2013
comment
Для других людей, которые видят это. Я перешел на SimpleCV и Python. Мой (не слишком сильно) модифицированный код RaspiStillYUV делал около 10 изображений за 8 секунд. SimpleCV делает ~ 7 в секунду. Оба образца взяты без дополнительной обработки. Вы можете использовать драйвер uv4l, чтобы получить камеру в качестве видеоустройства, чтобы использовать ее с SimpleCV.   -  person douggard    schedule 12.01.2014

Ответы (2)


arrow_upward
2
arrow_downward

Документация по этому адресу поддерживает вашу теорию заполнения: 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. Я просматриваю это описание, чтобы понять, дает ли оно подсказку для начала: "nofollow">http://en.wikipedia.org/wiki/YUV#Y.27UV420p_.28and_Y.27V12_or_YV12.29_to_RGB888_conversion

Отсюда я считаю, что это следующее:

Y-канал:

2592 * (1944+8) = 5059584

Ю-канал:

1296 * (972+4) = 1264896

V канал:

1296 * (972+4) = 1264896

Давая сумму:

5059584 + 2*1264896 = 7589376

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

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

person Ben    schedule 11.01.2014
comment
Я проверю это сегодня вечером, когда загружу свой pi и получу подтверждение. Хотя в этом есть смысл. Большое спасибо! - person douggard; 12.01.2014

arrow_upward
0
arrow_downward

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

person J Greb    schedule 14.01.2014