On Wed, 2007-05-09 at 14:55 -0400, Mathieu Bouchard wrote:
On Wed, 9 May 2007, IOhannes m zmoelnig wrote:
another way (less efficient, and wrong if matju is right): videoV4L.cpp:173: add "m_image.image.swapRedBlue();"
In my last mail, I didn't claim that the problem was surely (U,V) swapping, I said that it was a possibility, but now I think I should have said that it's almost certainly that.
It's because, in the encoder of the camera, U and V are necessarily encoded as properly scaled B-Y and R-Y anyway, because else it would be a blatant bug, and I can't imagine a camera setting that would allow for violating the definitions of U and V to make them confuse R and B. (although... now that I think of it, I'd really enjoy a camera that allows me to set the contrast separately on Y, U and V.)
Therefore, U and V come as correct through the cable and the driver and/or the GEM object confuses them.
makes sense?
hm... if U=B-Y and V=R-Y, and if U and V are swapped by gem, does that mean, i can correct it by swapping B and R afterwards? i tried to fix the wrong colors by swapping R and B using [pix_colormatrix] and a list [0 0 1 0 1 0 1 0 0( and the result looked very similar to the picture i get now with the 'fixed' videoV4L.cpp. or in other words: does swapping U and V in YUV-colorspace and swapping B and R in RGB-colorspace have the same effect?
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de