[PD] [pdp]/[gridflow] trying to use a webcam
Mathieu Bouchard
matju at artengine.ca
Thu Nov 9 04:44:14 CET 2006
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
More information about the Pd-list
mailing list