Another forwarded message:
Hmm, I think I figured it out.
After
m_image.image.fromYVYU(decodedbuf);
I added
m_image.image.swapRedBlue();
and now it works. Strange... I guess this should be added as a patch (at least on Linux DV).
BTW, this is somewhat OT but is there a way to limit how many frames are captured from the camera per second in order to limit its CPU usage?
Best wishes,
Ico
Ivica Ico Bukvic wrote:
Another forwarded message:
Hmm, I think I figured it out.
After
m_image.image.fromYVYU(decodedbuf);
I added
m_image.image.swapRedBlue();
and now it works. Strange... I guess this should be added as a patch (at least on Linux DV).
i will have a look at this. the thing with the swapRedBlue() is, that it does not always have to be applied (that's why there is this function(); if it was clear how to decode the data correctly, then we i would do that before calling the swapRedBlue())
unfortunately it is mostly not that simple (e.g. my philips-toUcam (driver) somehow presents data with red and blue swapped when accessed via V4L; i cannot just add swapRedBlue() to the code, since then all other devices will have red and blue swapped (and they would even need cpu power for getting the wrong colors).
i am pretty sure that i got correct colors, last time i used DV4L....
mfg.asdr IOhannes
i am pretty sure that i got correct colors, last time i used DV4L....
The video was ok with me too, but since latest distro/iee1394 update, that is not the case any more.
How about we simply add it as a message then? For instance, swap_red_blue 0/1 that goes into video capture object? This would then be universal for all pix_video objects and available whenever such a problem is encountered...
BTW, this is somewhat OT but I am still trying to figure out why my ADVC-100 (external video input to fw box) eats so much cpu with a single feed from an NTSC camcorder (via S-video)? Someone suggested that it may be that decoding of frames happens in software but I thought that ADVC did that in hw?
Best wishes,
Ico
On Mon, 19 Mar 2007, IOhannes m zmoelnig wrote:
Ivica Ico Bukvic wrote:
After m_image.image.fromYVYU(decodedbuf); I added m_image.image.swapRedBlue();
unfortunately it is mostly not that simple (e.g. my philips-toUcam (driver) somehow presents data with red and blue swapped when accessed via V4L; i cannot just add swapRedBlue() to the code, since then all other devices will have red and blue swapped (and they would even need cpu power for getting the wrong colors).
IMHO, if you get swapped red and blue, then it's possible that it's actually U and V that are swapped, so you should replace this by a fromYUYV() or prepend fromYUYV() using a swapUV() and check whether the output looks better than swapRedBlue().
This is because 0.75*U = B-Y whereas 0.40*V = R-Y, and those two constants differ, so confusing U and V and then swapping reds and blues will cause reds to appear brighter and blues to appear dimmer, than if just U and V were swapped.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Mon, 19 Mar 2007, IOhannes m zmoelnig wrote:
Ivica Ico Bukvic wrote:
After m_image.image.fromYVYU(decodedbuf); I added m_image.image.swapRedBlue();
unfortunately it is mostly not that simple (e.g. my philips-toUcam (driver) somehow presents data with red and blue swapped when accessed via V4L; i cannot just add swapRedBlue() to the code, since then all other devices will have red and blue swapped (and they would even need cpu power for getting the wrong colors).
IMHO, if you get swapped red and blue, then it's possible that it's actually U and V that are swapped, so you should replace this by a fromYUYV() or prepend fromYUYV() using a swapUV() and check whether the output looks better than swapRedBlue().
This is because 0.75*U = B-Y whereas 0.40*V = R-Y, and those two constants differ, so confusing U and V and then swapping reds and blues will cause reds to appear brighter and blues to appear dimmer, than if just U and V were swapped.
yes, you are basically right. nevertheless, it is still unclear to me, how to detect correctly whether to use YUYV or YVYU
fmga.sdr IOhannes
IMHO, if you get swapped red and blue, then it's possible that it's actually U and V that are swapped, so you should replace this by a fromYUYV() or prepend fromYUYV() using a swapUV() and check whether the output looks better than swapRedBlue().
This is because 0.75*U = B-Y whereas 0.40*V = R-Y, and those two constants differ, so confusing U and V and then swapping reds and blues will cause reds to appear brighter and blues to appear dimmer, than if just U and V were swapped.
yes, you are basically right. nevertheless, it is still unclear to me, how to detect correctly whether to use YUYV or YVYU
Either way, it appears to me that a message should be added to address idiosyncrasies of various hardware solutions. This way a user should be able to address this within PD rather than tinkering with the source, especially given that PD is already a programming language in and of itself.
Best wishes,
Ico
On Mon, 19 Mar 2007, Ivica Ico Bukvic wrote:
Either way, it appears to me that a message should be added to address idiosyncrasies of various hardware solutions. This way a user should be able to address this within PD rather than tinkering with the source, especially given that PD is already a programming language in and of itself.
If you need to swap red and blue, you can do that using the GEM equivalent of GridFlow's
[#inner (3 3 # 0 0 1 0 1 0 1 0 0)]
which I think is [pix_colormatrix].
If you want to correct for mistaking U and V then you will have to replace the ones by other numbers, possibly 15/8 and 8/15.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-----Original Message----- From: Mathieu Bouchard [mailto:matju@artengine.ca] Sent: Monday, March 19, 2007 3:20 PM To: Ivica Ico Bukvic Cc: 'IOhannes m zmoelnig'; gem-dev@iem.at Subject: RE: [GEM-dev] Fwd: another videoDV4L bug
On Mon, 19 Mar 2007, Ivica Ico Bukvic wrote:
Either way, it appears to me that a message should be added to address idiosyncrasies of various hardware solutions. This way a user should be able to address this within PD rather than tinkering with the source, especially given that PD is already a programming language in and of itself.
If you need to swap red and blue, you can do that using the GEM equivalent of GridFlow's
[#inner (3 3 # 0 0 1 0 1 0 1 0 0)]
which I think is [pix_colormatrix].
If you want to correct for mistaking U and V then you will have to replace the ones by other numbers, possibly 15/8 and 8/15.
Is this as efficient as swapRedBlue()? Also, IMHO this should be probably better documented as the only way one would actually get to this conclusion is by understanding the innards of YUV etc. format which (again IMHO) by design Pd attempts to circumvent. In other words, rather than requiring low-level knowledge of formats (in which case one might as well build a C++ app from scratch for their live needs rather than use Pd/Gem), my thoughts are that Pd/Gem are designed to make this more transparent in order to improve creative productivity. Hence, (yet once again IMHO) I still believe that swapredblue or something similar as a message to pix_video would be the preferred way of dealing with this...
Best wishes,
Ico
Ivica Ico Bukvic wrote:
Is this as efficient as swapRedBlue()? Also, IMHO this should be probably
no.
better documented as the only way one would actually get to this conclusion is by understanding the innards of YUV etc. format which (again IMHO) by design Pd attempts to circumvent. In other words, rather than requiring low-level knowledge of formats (in which case one might as well build a C++ app from scratch for their live needs rather than use Pd/Gem), my thoughts are that Pd/Gem are designed to make this more transparent in order to improve creative productivity. Hence, (yet once again IMHO) I still believe that swapredblue or something similar as a message to pix_video would be the preferred way of dealing with this...
yes
mfg.asdr IOhannes
On Mon, 19 Mar 2007, Ivica Ico Bukvic wrote:
which I think is [pix_colormatrix].
Is this as efficient as swapRedBlue()?
No, it should be more than 3 times slower. (GridFlow has a [#reverse 2] which reverses the order of the channels and is faster than using a matrix, but I don't know any GEM equivalent for that).
If you want to correct for mistaking U and V then you will have to replace the ones by other numbers, possibly 15/8 and 8/15.
Also, IMHO this should be probably better documented as the only way one would actually get to this conclusion is by understanding the innards of YUV etc.
Well, actually, if trying to patch up for swapped UV after converting to RGB, it's more than what I said, one has to correct G as well, using R and B. Overall it's a lot easier to get UV swapped in the first place, and also much faster in any case.
format which (again IMHO) by design Pd attempts to circumvent.
Pd is not designed for video. GEM, PDP and GridFlow are all add-ons that are not considered a part of Pd, and each have their own principles. GEM may try to hide that it supports YUV, but that principle doesn't necessarily extend to other plugins and you shouldn't make it sound like it's something fundamental to Pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
IOhannes m zmoelnig -
Ivica Ico Bukvic -
Mathieu Bouchard