Joe Burks (joe-v4l@xxxxxxxxxxx):
> I don't think the majority of time would be spent writing the
> conversion function. I bet I could google for a RGB->YUV or YUV->RGB
> algorithm and have the result converted to code, tested and debugged
> within an hour.
The problem with this argument is that the resulting code will likely
be subtly wrong. Remember:
1. Conversion from Y'CbCr->R'G'B' is very lossy
2. The conversion code is much more complex if you care about quality
3. There are about a million variants of YUV colorspaces and the V4L
API isn't sufficient to correctly describe them :)
So one would imagine that all the webcam apps would do the long, slow,
but accurate conversion code, probably using some expensive processing
filters, and that the playback applications would, where necessary, do
the fast but very inaccurate mmx transforms you see in the DVD apps.
You'd also expect that eventually the webcam apps would be sharing so
much code with all these expensive filters that eventually they'd do a
library. Maybe they're all waiting for someone to write this code for
them? Is that what you're saying?
> That is why I'm lobbying for a user space (middle tier, if you will)
> driver component that will keep the kernel space portion of the driver
> simple and make the kernel hackers happy, make the application side
> simple so they're happy, and make the user experience good.
I intend to help erik and wim with libcolorspace (codecs.org), but I
worry apps will either care too much about fretting over dependencies
(nobody will run my app if they have to download a library) or over
style (eww, but that lib is in C!) or something else just as silly.
If you do something that's userspace but transparent to any user of
the driver API, you'll piss off anyone who cares about full framerate
video recording (which is pretty much everyone these days). 16ms per
field is not alot of time to be switching around doing conversions. Not
only that, you're likely to offend any quality watchers.
> Well, as you just said there are already a number of drivers that do
> colorspace conversion in the kernel (that's why there is a YUV->RGB
> macro in ibmcam.c). In fact cpia.c (my personal favorite sample v4l
> driver - it's the place I started when writing mine) does color space
> conversion to RGB555, RGB565, RGB24, RGB32, GREY, YUYV, UYUV, and
> YUV422 (I think it might be YUV420 natively).
Well that sucks. Why do these drivers have to totally screw those of
us who care about quality?
> Basically the email attached to that one says "Making a driver
> compatible with the existing v4l applications is forbidden".
> Forbidden because no app supports all the color space encodings.
> Basically v4l is broke, and nobody is allowed a work around to fix it
> (except those who already managed to get in).
Is it really that hard to see that putting a broken conversion in the
kernel (or transparently through the v4l api) doesn't help in the end?
Application writers need to either get over the fact that they should
be building a lib since none of the kernel folks have. libcolorspace is
a step in that direction.
--
Billy Biggs
vektor@xxxxxxxxxxxx
