🚀 go-pugleaf

In article <1992Dec14.092349.11705@prl.philips.nl>, martens@prl.philips.nl (martens p) writes:
|>
|>In article <8326@charon.cwi.nl> guido@cwi.nl (Guido van Rossum) writes:
|>>ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:
|>>
|>>>Software wise, I'm less certain what the situation is. I think a great mass
|>>>of algorithms have been developed that work in RGB space, and a more compact,
|>>>non-RGB encoding would require more complicated and lengthy computations in
|>>>many cases, which wouldn't be worth the saving in memory.
|>>
|>>I presume one of the advantages of RGB for software is that it's
|>>additive: if you have two images that you want to mix, and you have
|>>the pixels as R,G,B color components, mixing becomes trivial (just
|>>average the components).  Many shading algorithms also use this
|>>additive property extensively.  I don't think this is as easy for YUV.
|>
|>
|>As far as I know, you don't even need a math processor to convert YUV <-> RGB:
|>
|>Y = 0.3 R + 0.59 G + 0.11 B
|>U = 0.49 (B - Y)
|>V = 0.88 (R - Y)
|>
|>
|>>
|>>--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
|>>"Appelmoes zoals appelmoes bedoeld is!"
|>>
|>Ontaarde amsterdammer :-)
|>
|>
|>
|>
|>Peter Martens
|>
So YUV is also additive, like anything else which goes
     [ a11  a12  a13 ]  [R]     [foo]
     [ a21  a22  a23 ]  [G]  =  [bar]
     [ a31  a32  a33 ]  [B]     [baz]
                             - right?
Then if we choose our matrix coefficients such that the inverse matrix is
dead easy to compute (all 1s, .5s, .25s and 0s), and encode the data as
foo bar foo baz foo bar foo baz ... where foo is the "luminance" component
and is calculated for every pixel, and bar and baz are "chrominance" components
calculated per 2 pixels (i.e. chrominance bandwidth half the luminance), all 8
bits wide, then we save on memory-processor bandwidth (2 pixels per 32-bit 
fetch, or 1 per 16-bit fetch), and size of course, for very little extra
computation. I am thinking not so much of backing store here as of RAM - e.g.
your DSP is unpacking video frames from disc into RAM and the CPU (or something
else) is driving the screen.

Time to go home.

Chris              cgra@se.alcbel.be             ontaarede Yorkshireman :-/