[GEM-dev] Fwd: another videoDV4L bug

Mathieu Bouchard matju at artengine.ca
Tue Mar 20 20:02:29 CET 2007


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


More information about the GEM-dev mailing list