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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
