Joe Burks (joe-v4l@xxxxxxxxxxx): > > 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. Well waitasec. I think it's fine for the kernel to export more formats than the 'raw native hardware format' in the following cases: 1. The conversion is cheap 2. The conversion is _lossless_ For the case of 1, yes I'd love to see a userspace library for dealing with weird USB camera decompressions. That would be pretty cool. If the decompression is cheap, and there's only one way to do it, and you have the buffers setup in the kernel, well do it there. I just have problems with drivers that say 'this cam supports a 4:2:0 format, well I'll just double scanlines and now I support 4:2:2!'. This is bad! The conversion is incorrect. It is nontrivial to convert between the two! Even the bttv driver has this problem, the 4:2:0 it exports is kinda strange (doesn't interlace properly) and it was screwing up my capture app. I just want to make sure as an application writer that I know what formats are really available. I don't really care if the card exports a 4:2:0 where the Cb comes before the Cr, this is more about doing cheap versions of expensive conversions in the kernel behind the application's back. Just a note, I think it's pretty unlikely that many of these cams are coming up with completely new colorspaces. I'm sure the weirdness in color from the 3com hc and some of those others can be easily explained once we know more about the hardware. -- Billy Biggs vektor@xxxxxxxxxxxx
