home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / multimed / 3834 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  2.6 KB
  1. Path: sparky!uunet!mcsun!ub4b!alcbel!se.alcbel!btma74.nohost.nodomain!cgra
  2. From: cgra@btma74.nohost.nodomain
  3. Newsgroups: comp.multimedia
  4. Subject: Re: TV Resolution
  5. Message-ID: <1370@se.alcbel.be>
  6. Date: 14 Dec 92 17:32:29 GMT
  7. References: <1350@se.alcbel.be> <1992Dec10.175620.12719@waikato.ac.nz> <8326@charon.cwi.nl> <1992Dec14.092349.11705@prl.philips.nl>
  8. Sender: guest@se.alcbel.be
  9. Reply-To: cgra@btma74.nohost.nodomain ()
  10. Lines: 55
  11. Nntp-Posting-Host: btmw52
  12.  
  13.  
  14. In article <1992Dec14.092349.11705@prl.philips.nl>, martens@prl.philips.nl (martens p) writes:
  15. |>
  16. |>In article <8326@charon.cwi.nl> guido@cwi.nl (Guido van Rossum) writes:
  17. |>>ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:
  18. |>>
  19. |>>>Software wise, I'm less certain what the situation is. I think a great mass
  20. |>>>of algorithms have been developed that work in RGB space, and a more compact,
  21. |>>>non-RGB encoding would require more complicated and lengthy computations in
  22. |>>>many cases, which wouldn't be worth the saving in memory.
  23. |>>
  24. |>>I presume one of the advantages of RGB for software is that it's
  25. |>>additive: if you have two images that you want to mix, and you have
  26. |>>the pixels as R,G,B color components, mixing becomes trivial (just
  27. |>>average the components).  Many shading algorithms also use this
  28. |>>additive property extensively.  I don't think this is as easy for YUV.
  29. |>
  30. |>
  31. |>As far as I know, you don't even need a math processor to convert YUV <-> RGB:
  32. |>
  33. |>Y = 0.3 R + 0.59 G + 0.11 B
  34. |>U = 0.49 (B - Y)
  35. |>V = 0.88 (R - Y)
  36. |>
  37. |>
  38. |>>
  39. |>>--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
  40. |>>"Appelmoes zoals appelmoes bedoeld is!"
  41. |>>
  42. |>Ontaarde amsterdammer :-)
  43. |>
  44. |>
  45. |>
  46. |>
  47. |>Peter Martens
  48. |>
  49. So YUV is also additive, like anything else which goes
  50.      [ a11  a12  a13 ]  [R]     [foo]
  51.      [ a21  a22  a23 ]  [G]  =  [bar]
  52.      [ a31  a32  a33 ]  [B]     [baz]
  53.                              - right?
  54. Then if we choose our matrix coefficients such that the inverse matrix is
  55. dead easy to compute (all 1s, .5s, .25s and 0s), and encode the data as
  56. foo bar foo baz foo bar foo baz ... where foo is the "luminance" component
  57. and is calculated for every pixel, and bar and baz are "chrominance" components
  58. calculated per 2 pixels (i.e. chrominance bandwidth half the luminance), all 8
  59. bits wide, then we save on memory-processor bandwidth (2 pixels per 32-bit 
  60. fetch, or 1 per 16-bit fetch), and size of course, for very little extra
  61. computation. I am thinking not so much of backing store here as of RAM - e.g.
  62. your DSP is unpacking video frames from disc into RAM and the CPU (or something
  63. else) is driving the screen.
  64.  
  65. Time to go home.
  66.  
  67. Chris              cgra@se.alcbel.be             ontaarede Yorkshireman :-/
  68.