Re: V4L2 Output Format
It sounds like the video buffer is not being rendered into or filled in.
A zeroed buffer in YUV format will appear green in RGB space, since U
and V = 0 indicate no red or blue color difference values.
This wikipedia article describes the relationship between YUV and RGB
graphically and algebraically.
On Aug 6, 2010, at 3:49 PM, Vikram Ivatury wrote:
Thanks for the quick reply. I will go ahead and use the YUYV packed
format. When I used the VYUY format, my output image was all green -
any reasons you think this might happen?
I am assuming that nothing is bring written to the image (all 0's in
YUV format) and then when it is converted to RGB that 0 is converted
to a green color value in RGB?
On Fri, Aug 6, 2010 at 11:17 AM, Dave Milici
On Aug 5, 2010, at 3:46 PM, Vikram Ivatury wrote:
I am using the .pixfmt = ATMEL_ISI_PIXFMT_CrYCbY and I am wondering
.capture_v4l2_fmt should be. Right now I have my .capture_v4l2_fmt =
V4L2_PIX_FMT_VYUY but I think it should be V4L2_PIX_FMT_YUYV? Is
The difference is in the physical ordering of the Y vs U and V data
as to which byte comes first (lowest in memory). Some graphics
devices are able to offer the YUV packed formats with either
ordering which is why this would be exposed. YUYV ordering is the
most commonly used packed format.
I am looking at Table 3-4 in the Atmel ISI datasheet and there is
listed under the V4L format for my specific ISI input of CrYCbY. I
want a wrong .capture_v4l2_fmt to lead to a color corruption in the
path. I am using a YUV to RGB conversion in my capture.c program.
It will be obvious if you chose the wrong pixel format order. The
colors will be all wrong and super-saturated intensity (like really
University of Michigan, Aerospace Engineering
Multi-Disciplinary Design - Space Systems Engineering
M-Cubed Payload Team Lead
Student Space Systems Fabrication Laboratory
video4linux-list mailing list