[GEM-dev] Fwd: another videoDV4L bug

[Ivica Ico Bukvic]

> -----Original Message-----
> From: Mathieu Bouchard [mailto:matju at artengine.ca]
> Sent: Monday, March 19, 2007 3:20 PM
> To: Ivica Ico Bukvic
> Cc: 'IOhannes m zmoelnig'; gem-dev at iem.at
> Subject: RE: [GEM-dev] Fwd: another videoDV4L bug
> 
> On Mon, 19 Mar 2007, Ivica Ico Bukvic wrote:
> 
> > Either way, it appears to me that a message should be added to address
> > idiosyncrasies of various hardware solutions. This way a user should be
> > able to address this within PD rather than tinkering with the source,
> > especially given that PD is already a programming language in and of
> > itself.
> 
> If you need to swap red and blue, you can do that using the GEM equivalent
> of GridFlow's
> 
> [#inner (3 3 #
>    0 0 1
>    0 1 0
>    1 0 0)]
> 
> which I think is [pix_colormatrix].
> 
> 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.

Is this as efficient as swapRedBlue()? 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. format which (again IMHO) by
design Pd attempts to circumvent. In other words, rather than requiring
low-level knowledge of formats (in which case one might as well build a C++
app from scratch for their live needs rather than use Pd/Gem), my thoughts
are that Pd/Gem are designed to make this more transparent in order to
improve creative productivity. Hence, (yet once again IMHO) I still believe
that swapredblue or something similar as a message to pix_video would be the
preferred way of dealing with this...

Best wishes,

Ico