Joe Burks wrote:
At 09:35 PM 8/9/2002 -0700, you wrote:
It does not, indeed. It had been decided that a v4l driver should only
produce the stream in one format, preferrably closest to the native
device
format (palette). A driver must not convert palettes - this is difficult
to do in kernel space, awkward to do without FPU, makes the driver much
more complicated and crash-prone, and pollutes the kernel space with
similar-but-different pieces of conversion code (in each driver).
I'm not sure I agree that this is necessarily awkward without FPU.
Every webcam I've seen scans images through a Bayer (or similar)
pattern matrix of RGB filters sitting in front of a CMOS image
sensor. The hardware on the camera does the Bayer RGB->YUV/Planar/etc
conversion. Chances are the embedded microcontroller is using integer
arithmetic since the silicon cost of an integer unit is much less than
a floating point unit. Reversing the process with integer arithmetic
to get RGB back shouldn't be the impossible proposition many here seem
to think it is.
It isn't impossible, but it isn't very pretty either. For example, see
http://alpha.dyndns.org/ov511/download/ov511.c , in the function
move_420_block(). It does YUV->RGB with a 16.16 fixed-point algorithm.
It's not very complicated at all, and I wouldn't be surprised if it's
faster than doing it with the FPU (at least with the crappy x87).
However, you're much better off doing in user-space with MMX/SSE. Doing
it in the (non-preemptive) kernel has a noticable impact on system
responsiveness too. It's better to just get the data out of the kernel
as quickly as possible.
--
Mark McClelland
mark@xxxxxxxxxxxxxxxx
