On Wed, 8 Nov 2006, Roman Haefeli wrote:
without knowing the principles behind the programming of gridflow, it is a pain, that the colorspace conversion ([#yuv_to_rgb]-[#clip]) eats quite a huge amount of cpu without any further processing. here on my pentium m 1.7GHz it is about 30% with 'dim 240 320' and a framerate of 30. again, i don't know the technical details behind the objects i work with, but it seems strange in my eyes, that having to do a conversion in gridflow is the only available option to get a 'normal' looking picture.
That's because I don't use webcams, and kernel developers don't want driver developers to include color conversions in drivers, and webcams don't transmit as RGB, and I prefer to use pd abstractions than code more C++, and [#inner] isn't as fast as it could be, and no-one really made me work on making it faster.
In my daily use of GridFlow there are only bt878 PCI cards, which all support RGB in hardware.
it is not always easy to work in the 'wrong' colorspace, depending on what one wants to do, since a change in the brightness results in a change of the color, is that right?
If you change the contrast or brightness of a picture as if were RGB, you'll get wrong results. [# + (42 42 42)] on RGB has to become [# + (42 0 0)] on YUV, and so on.
However if you mean sending YUV data directly to a [#out window]... well, GridFlow doesn't allow any object to know whether data passed along is in RGB or YUV.
if only YUV420P is a 'valid' colorspace, why are there others available?
The "colorspace" message's argument has two possible values, but some devices only allow one of them, and the error message doesn't say this.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada