[PD] [pdp]/[gridflow] trying to use a webcam

[Mathieu Bouchard]

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