On Thursday 21 March 2002 10:48 pm, Dmitri wrote: > > 2. The conversion code is much more complex if you care about quality > > Generally, it should not be done in integers. Woo... the argument I could spew about the value of floating point in all modern processors! > > 3. There are about a million variants of YUV colorspaces and the V4L > > API isn't sufficient to correctly describe them :) > > The worst variants come from OEMs who say "No, our firmware for the DSP > is not broken, it's just we invented Yet Another YUV colorspace" :-) Yes! Another reason why there will always be drivers with colorspace conversions in the kernel unless we have some user space component. The number of #define'd color spaces we have now is too many, and it will never be enough. (I could extend this argument to "standard controls". V4L2 has a rich set of standard controls, but it will never have enough.) > I have a camera for which I still can't figure out what it sends. I even > have the decoder, but the colors are not quite right... and I fear that > without the OEM's help (the exact transformation matrix) it is not even > theoretically possible to fix it. I feel your pain. The 3Com Homeconnect that I wrote the driver for, the original manufacturer absolutely will not release ANY technical documents on the internals of the camera. We had to reverse engineer everything on the camera from USB captures of the windows driver in action. Including its unique color space encoding. > Not that many USB 1.1 cameras come even *close* to 30 fps :-) You just have to do it at 80x40 in a compressed quality mode. :) > Actually, few best apps will survive. The rest will die because, without > a 3rd party library, nobody will be able to cope with so many different > formats coming from so many different drivers... I'm of the (probably unpopular) belief that the easier you make a new API, the more people will write apps for it and the number of good apps is generally a constant percentage of the total apps made. Ballpark around 10%. As the API becomes more mature the bad apps will whither away, and the good apps will remain. If your new API is hard (and v4l is hard, it just doesn't look it at first blush), you will have fewer apps that reach maturity. All apps not being the same, I think this is a bad thing. > v4l was bttv-centric, and it still is. Amen! I hope everyone realizes this. V4L is fairly good at everything BTTV needed. (I've recently started to look at the rivatv project, and not coincidentally the V4L controls map to their needs reasonably well also) > I can remove YUV->RGB conversion from ibmcam driver in less than 10 > minutes (plus some time to figure out what output format shall I use). > However there are some questions: You could, I think the users of your driver won't be happy about it though. You'll stop working with some v4l apps already out there. > - how will I paint into the output buffer? I want to draw numbers, > lines and colored pixels there. I'd assume, I have only Y channel > to easily play with? I'm betting the answer would be "drawing onto the output buffer is something the application should do". Debug or not. For the record, I think your hex character overlay code in usbvideo.c is pretty neat. > - how do I implement the software controls (contrast, hue, saturation) > for cameras that don't have them in hardware? In RGB, I can do 2 out > of those 3 more or less reasonably. The answer is probably "only implement the controls that your camera supports". I think if I searched the archives I'd see that being said to me. It all comes down to the intention that V4L drivers do not process data, they just retrieve it from the camera. And I agree. In a perfect system, kernel drivers should be completely flyweight. Their only function should be set/retrieve the device parameters and send/receive data. No driver running in kernel space should ever have to convert its raw data to the nearest supported standard format.
