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 [EMAIL PROTECTED] _______________________________________________ Video4linux-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/video4linux-list
