hello everyone
when using [pix_video] with my built-in tv/video-card, colors look ok, but when i use it with the usb_cam [1], R and B are swapped. this happens only in gem. with other softwares (mplayer, camorama) both devices appear to have correct colors.
is it possible to _slightly_ change the source code of [pix_video], so that R- and G-subpixels are swapped? if yes, would it be possible with reasonable little effort to copy the source of [pix_video] to a new object called e.g. [pix_videoBGR], so that i can decide at runtime, which version i want to use?
thanks for any hints
roman
[1] philips spc900nc with latest pwc-driver from: http://www.saillard.org:8080/linux/pwc/
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
are you sure R and B are swapped? or is it a YUV/RGB problem? because I found similar problems and thought is was a problem of colorspace. marius.
Roman Haefeli wrote:
hello everyone
when using [pix_video] with my built-in tv/video-card, colors look ok, but when i use it with the usb_cam [1], R and B are swapped. this happens only in gem. with other softwares (mplayer, camorama) both devices appear to have correct colors.
is it possible to _slightly_ change the source code of [pix_video], so that R- and G-subpixels are swapped? if yes, would it be possible with reasonable little effort to copy the source of [pix_video] to a new object called e.g. [pix_videoBGR], so that i can decide at runtime, which version i want to use?
thanks for any hints
roman
[1] philips spc900nc with latest pwc-driver from: http://www.saillard.org:8080/linux/pwc/
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
yeah, i am pretty sure. if i record it to a file.mov, i can swap R and B, when playing with mplayer and then it looks fine. a similar issue, but with wrong colorspace, i have in gridflow with the same usb-cam, therefor i know, how it looks, when rgb is displayed as yuv.
roman
On Tue, 2007-05-08 at 12:13 -0400, marius schebella wrote:
are you sure R and B are swapped? or is it a YUV/RGB problem? because I found similar problems and thought is was a problem of colorspace. marius.
Roman Haefeli wrote:
hello everyone
when using [pix_video] with my built-in tv/video-card, colors look ok, but when i use it with the usb_cam [1], R and B are swapped. this happens only in gem. with other softwares (mplayer, camorama) both devices appear to have correct colors.
is it possible to _slightly_ change the source code of [pix_video], so that R- and G-subpixels are swapped? if yes, would it be possible with reasonable little effort to copy the source of [pix_video] to a new object called e.g. [pix_videoBGR], so that i can decide at runtime, which version i want to use?
thanks for any hints
roman
[1] philips spc900nc with latest pwc-driver from: http://www.saillard.org:8080/linux/pwc/
___________________________________________________________ Der frÌhe Vogel fÀngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Tue, 8 May 2007, Roman Haefeli wrote:
yeah, i am pretty sure. if i record it to a file.mov, i can swap R and B, when playing with mplayer and then it looks fine. a similar issue, but with wrong colorspace, i have in gridflow with the same usb-cam, therefor i know, how it looks, when rgb is displayed as yuv.
If you try (R,B) swapping correction, but somehow tones of orange look too yellow and tones of cyan look too blue, the problem was actually a (U,V) swapping problem. (I mentioned this in gem-dev archives)
Besides, with recent versions of GridFlow, USB cams don't have to be handled as YUV and the default conversion is to RGB, and it's much faster than in version 0.8.4.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Tue, 2007-05-08 at 12:56 -0400, Mathieu Bouchard wrote:
On Tue, 8 May 2007, Roman Haefeli wrote:
yeah, i am pretty sure. if i record it to a file.mov, i can swap R and B, when playing with mplayer and then it looks fine. a similar issue, but with wrong colorspace, i have in gridflow with the same usb-cam, therefor i know, how it looks, when rgb is displayed as yuv.
If you try (R,B) swapping correction, but somehow tones of orange look too yellow and tones of cyan look too blue, the problem was actually a (U,V) swapping problem. (I mentioned this in gem-dev archives)
though i probably don't have a deep understanding of these things, i think you are right. i made some screenshots on: http://www.romanhaefeli.net/gem/
the original.jpg is a screenshot from a capture to mjpeg/mov from usbcam from gem, played by mplayer with no additional options. the swapped.jpg is a screenshot from the same videofile, but played with 'mplayer -flip -vf swapuv,scale'
Besides, with recent versions of GridFlow, USB cams don't have to be handled as YUV and the default conversion is to RGB, and it's much faster than in version 0.8.4.
good news, i'll try it soon..
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Thu, 10 May 2007, Roman Haefeli wrote:
though i probably don't have a deep understanding of these things, i think you are right. i made some screenshots on: http://www.romanhaefeli.net/gem/
from the screenshots, it's not obvious that the problem is like that, because the colours as they are don't look unlikely, they look like they are just lit with yellowish light (fluor or neon), or that the chroma balance is off. With histograms, evidence could be a lot more telling that my semi-trained eyes, but even that could depend on the quality of the camera sensors. So really, the only way to know is to either make the reasoning that I made and check that it makes sense, or experimentally verify by using the same camera in different circumstances (e.g. in MS-Windows).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Roman Haefeli wrote:
hello everyone
when using [pix_video] with my built-in tv/video-card, colors look ok, but when i use it with the usb_cam [1], R and B are swapped. this happens only in gem. with other softwares (mplayer, camorama) both devices appear to have correct colors.
i haven't found out yet how to reliably detect which colourspace a device can(not) serve. obviously it does work for some devices and not for others...
is it possible to _slightly_ change the source code of [pix_video], so that R- and G-subpixels are swapped?
the change is trivial and has been done a lot of times, until it was confirmed that it is just the detection of the device's colorspace that is wrong.
if yes, would it be possible with reasonable little effort to copy the source of [pix_video] to a new object called e.g. [pix_videoBGR], so that i can decide at runtime, which version i want to use?
no way! a request for 2 different objects so that you "can decide at runtime" is a contradiction, isn't it?
the best way would of course be to correctly detect the colospace of the device and do any conversions if necessary. the second best way would be to provide a switch.
the worst way would be [pix_video_pwc], [pix_video_hauppauge] and [pix_video_sony].
thanks for any hints
try to find out what the "vmmap[frame].format" gets for the 2 cards after the ioctl() (in videoV4L::startTransfer())
mfg.asdr. IOhannes
On Wed, 2007-05-09 at 09:01 +0200, IOhannes m zmoelnig wrote:
is it possible to _slightly_ change the source code of [pix_video], so that R- and G-subpixels are swapped?
the change is trivial and has been done a lot of times, until it was confirmed that it is just the detection of the device's colorspace that is wrong.
if it is only one line, can you tell me what i have to change? it was only meant to have it different locally, not to be changed in the gem source code.
if yes, would it be possible with reasonable little effort to copy the source of [pix_video] to a new object called e.g. [pix_videoBGR], so that i can decide at runtime, which version i want to use?
no way! a request for 2 different objects so that you "can decide at runtime" is a contradiction, isn't it?
sorry for the confusion, i didn't meant it as a feature request or as something you you ae asked to implement in gem. i am not a c coder nor did i write an external for pd yet, but i hoped, i could copy the file pix_video.c to pix_videoLOCAL.c, which is slightly modified, so that i have two [pix_video] objects on (only) my box. if it's only the work of changing some strings from pix_video to pix_videoLOCAL o similar, i'd like to do it, but i don't know, if adding a new object to gem is that simple.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
On Wed, 2007-05-09 at 09:01 +0200, IOhannes m zmoelnig wrote:
is it possible to _slightly_ change the source code of [pix_video], so that R- and G-subpixels are swapped?
the change is trivial and has been done a lot of times, until it was confirmed that it is just the detection of the device's colorspace that is wrong.
if it is only one line, can you tell me what i have to change? it was only meant to have it different locally, not to be changed in the gem source code.
several ways: the most efficient would be to decode the video correctly directly; i don't know exactly which colorspace gets detected by Gem for your device, but try changing one (or all) of the following: videoV4L.cpp:158 change to fromYUV420P() to fromYU12() videoV4L.cpp:160 change to fromBGR() to fromRGB() videoV4L.cpp:161 change to fromBGRA() to fromRGBA() videoV4L.cpp:162 change fromYVYU() to fromYUY2()
OR
another way (less efficient, and wrong if matju is right): videoV4L.cpp:173: add "m_image.image.swapRedBlue();"
sorry for the confusion, i didn't meant it as a feature request or as something you you ae asked to implement in gem. i am not a c coder nor did i write an external for pd yet, but i hoped, i could copy the file pix_video.c to pix_videoLOCAL.c, which is slightly modified, so that i have two [pix_video] objects on (only) my box. if it's only the work of changing some strings from pix_video to pix_videoLOCAL o similar, i'd like to do it, but i don't know, if adding a new object to gem is that simple.
adding a new object to gem is as simple as putting a .cpp file into one of the directories; configure/make will automatically add this to the build-system; voila
mfg.asdr IOhannes
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?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
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
On Thu, 10 May 2007, Roman Haefeli wrote:
On Wed, 2007-05-09 at 14:55 -0400, Mathieu Bouchard wrote:
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?
It would be the case if U,V was really exactly B-Y and R-Y respectively, but they also have special multipliers. Because, of this, the colormatrix you need would contain 9 non-zero values in it, which would be various fractions, not just ones. You could try a patch like:
[#color] | [#rgb_to_yuv] | [#inner (3 3 # 1 0 0 0 0 1 0 1 0)] | [#yuv_to_rgb] | [#reverse] | [#color]
This can show you the kind of correction that you'll need. Actually if you feed "3 3 # 1 0 0 0" instead of [#color] and replace the other [#color] by [#print] or [display], you'll get the matrix that you'll have to use the inverse of in [pix_colormatrix]. To find the inverse, you may use GF's [lti.MatrixInversion] or the equivalent from any other library (Johannes wrote at least one matrix invertor)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
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.
yes; the "if matju is right" was not meant as a criticism; i intended to say something like "if matju is right (which btw i do not really doubt)"
the solution why i proposed this is, that it is a simpler solution to get some "almost" correct results....
Therefore, U and V come as correct through the cable and the driver and/or the GEM object confuses them.
i do not doubt this; however it seems like i have some fundamental misunderstanding on the colorspace-definitions since i cannot get it right.
mfga.srd IOhannes
On Thu, 10 May 2007, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
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.
yes; the "if matju is right" was not meant as a criticism; i intended to say something like "if matju is right (which btw i do not really doubt)"
I didn't take it as criticism, I just thought it was better to explain it, and also when you said it I was still just thinking that both cases were likely, but then I changed my mind saying UV swapping is very likely and BR swapping is not.
(Well, it would be possible for someone to get the order of the RGB channels wrong in a GEM external, but I wouldn't expect that from you...)
i do not doubt this; however it seems like i have some fundamental misunderstanding on the colorspace-definitions since i cannot get it right.
Perhaps, but I don't have enough info to help further.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, 10 May 2007, Mathieu Bouchard wrote:
On Thu, 10 May 2007, IOhannes m zmoelnig wrote:
i do not doubt this; however it seems like i have some fundamental misunderstanding on the colorspace-definitions since i cannot get it right.
Perhaps, but I don't have enough info to help further.
Actually, the problem is that fromYUV420P() is defined to be an alias for fromYV12(), when it should have been fromYU12(), because YV12 is another way to say YVU420P... Y,V,U, in that order.
see also http://v4l2spec.bytesex.org/spec/r3453.htm
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Wed, 2007-05-09 at 19:58 +0200, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
On Wed, 2007-05-09 at 09:01 +0200, IOhannes m zmoelnig wrote:
is it possible to _slightly_ change the source code of [pix_video], so that R- and G-subpixels are swapped?
the change is trivial and has been done a lot of times, until it was confirmed that it is just the detection of the device's colorspace that is wrong.
if it is only one line, can you tell me what i have to change? it was only meant to have it different locally, not to be changed in the gem source code.
several ways: the most efficient would be to decode the video correctly directly; i don't know exactly which colorspace gets detected by Gem for your device, but try changing one (or all) of the following: videoV4L.cpp:158 change to fromYUV420P() to fromYU12() videoV4L.cpp:160 change to fromBGR() to fromRGB() videoV4L.cpp:161 change to fromBGRA() to fromRGBA() videoV4L.cpp:162 change fromYVYU() to fromYUY2()
i'll try these
OR
another way (less efficient, and wrong if matju is right): videoV4L.cpp:173: add "m_image.image.swapRedBlue();"
sorry for the confusion, i didn't meant it as a feature request or as something you you ae asked to implement in gem. i am not a c coder nor did i write an external for pd yet, but i hoped, i could copy the file pix_video.c to pix_videoLOCAL.c, which is slightly modified, so that i have two [pix_video] objects on (only) my box. if it's only the work of changing some strings from pix_video to pix_videoLOCAL o similar, i'd like to do it, but i don't know, if adding a new object to gem is that simple.
adding a new object to gem is as simple as putting a .cpp file into one of the directories; configure/make will automatically add this to the build-system; voila
good to know that. i thought first, i need to modify the file pix_videoLINUX.cpp, so that i could have both, the orignal and the modified [pix_video], but since videoV4L.cpp is modified, it wouldn't make sense to have two different [pix_video]s, right?
thank you very much for your help
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Wed, 2007-05-09 at 19:58 +0200, IOhannes m zmoelnig wrote:
videoV4L.cpp:158 change to fromYUV420P() to fromYU12()
this did the trick. it seems that my built-in card uses another colorspace than my usb cam. so, both look good now.
many thanks again
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
-
IOhannes m zmoelnig -
marius schebella -
Mathieu Bouchard -
Roman Haefeli