Hi Nemosoft,
Thanks for all your digging. I didn't realize
it was going to be such an endeavor.
I thought I was looking at a blue alien..
I think that Johannes will be reversing one of the
cpia return formats. But you're right, it is a mess.
~Randy
-----Original Message-----
From: Nemosoft Unv. [mailto:[EMAIL PROTECTED]]
Hi,
On 25-Mar-00 Dunlap, Randy wrote:
> Hi Nemosoft,
>
> I'm using the new cpia driver (works with parallel
> port or USB cpia cameras) with camstream.
> It's scary. I have blue skin again.
No, it's a sign you have just been smurfed :-)
> This is obviously the RGB vs. BGR problem.
> Where's the correct solution to this problem?
> (where should it be?)
Argh! This 'new' CPiA code tries to outsmart us... It's quite incompatible
with the other webcam drivers (ibmcam and ov511) at the moment!
What's the case? The new CPiA driver takes into account whether the image is
being requested through read() or mmap(). With read() it now returns a RGB
palette, and with mmap() BGR. However, the ibmcam, ov511 and my Philips
drivers always return BGR (my drivers don't have mmap() yet, but that shall
use BGR too).
I've been told this by Peter Pregler:
>> I discussed this on the v4l list. The 'correct' way is:
>> - for read: rgb is just rgb
>> - for mmap: rgb24/32 is actually bgr24/32, rgb15/16 is rgb
>> There is no reasoning for the above except history and misunderstanding
Now this of course just completely insane... More so since NONE OF THE
DRIVERS out there do this right.
After some 2 hours of reading code and downloading PDFs, here's a small
table
of all V4L devices in 2.3.51, and which format they use for which palette:
| read() | mmap() |
| RGB24 | RGB32 | RGB24 | RGB32 |
-------------------+---------+---------+---------+---------+
Zoran 36057/36060 | - | - | BGR | BGRa |
Zoran 36120/36125 | BGR | (1) | BGR | BGRa |
bttv (bt848 et all)| BGR (2)| BGRa | BGR | BGRa |
Stradis (3) | - | - | - | - |
bw-qcam | (4) | (4) | - | - |
c-qcam | RGB (5)| - | - | - |
usb/old-cpia | BGR | - | BGR | - |
usb/new-cpia | RGB | RGBa | BGR | BGRa |
usb/ibmcam | BGR | - | BGR | - |
usb/ov511 | BGR | - | BGR | - |
usb/philips (6) | BGR | RGBa | (BGR) | (RGBa) |
(1) The read() function always uses PALETTE_RGB24, thus BGR format.
(2) The code says this function is broken;
(3) This seems to be a write-only device (?)
(4) Only has GREY palette, so no colour problems
(5) Not sure if this is RGB, since code doesn't mention it
(6) RGBa is used to quickly fill imagebuffers in Qt (okay, this is a hack)
So you see... this is just a big mess. None of the devices adher to this
"standard", which is mainly "broken" because the grabber cards seem to
prefer
BGR format (fortunately, they all use the same format!). And some drivers
changed from RGB to BGR at some point in their development.
To make things worse, some of the V4L utilities don't pay attention to
VIDEO_PALETTE at all, and blindly assume one format or the other, let alone
set a palette...
My suggestion is to stick to BGR format, ditch RGB, and try to get "illegal"
formats out (like the Zoran 36120 which always returns BGR format with read,
even if you had set VIDEO_PALETTE_RGB32).
- Nemosoft
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
