Re: color bandwidth

Richard Cogger (R.Cogger@cornell.edu)
Mon, 10 Oct 1994 12:01:24 -0400


At 5:57 AM 10/10/94, M. Carleer wrote:
>Hi all :-)
>
>Shame, shame, shame on me! I am the one who claimed a 6% increase on video
>bandwidth to convey color info in addition to grayscale. I forgot that
>CUSeeMe is digitizing grayscale on 4 bits, and not 8: So the amount of
>overhead for color transmission would be 12, and not 6%. Sorry!
>
>Cheers,
>
>Michel

Yes, I was going to comment: The usual way to minimize the
information needed to add color is to send the info for fewer of the
pixels. (The human visual system is good at dealing with this sort of
reduction) Michel is proposing that every 4th pixel on every 4th row be
sent, giving 1/16 as many pixels worth of data. Using the common Y-U-V
system, where the Y value for a pixel is the "luminence" and the U and V
values give "chrominence" you would have two values for 1/16 of the pixels
or 1/8 increase in the data. Tim pointed out however that the Y values
(monochrome) as currently sent in CU-SeeMe are compressed spatially by
about 50%, relying on the fact that pixels close to each other often have
similar values. With the color values so spread out, it's unlikely you
could get as much spatial compression for them, possibly not much at all.
If you assume no further spatial compression of the color info, then the
1/8 increase becomes more like 1/4 or 25%.
We also have in mind a means of saving about 10-15% by adjustment
to the current coding scheme, but these adjustments would not reduce the
needed color info. So the end result might be that color would take 30-35%
more than monochrome, but that it might be only 10-20% more than is now
used.

The real reason we may not get to color too soon for the Mac is
that the standard vdig driver does not provide access to the YUV coding
that digitizers (often) produce, but gives you a choice only of grayscale
(the Y values) or a translation to RGB. We would either have to translate
it back, potentially slowing things down, or write specific code to each
card, if we even could get the info to do so. Perhaps Apple can be
pursuaded to add a YUV access to the standard vdig spec. Also, the display
of received color info would be more complex, needing to allow for the
various possible color-depths and coding schemes. On the PC, it's easier,
given the current way CU-SeeMe for Windows is coded, since more general
routines are used for displaying received images, but also, that's probably
a big part of why the Windows version doesn't run as fast as the Mac, given
similar hardware power.

Bottom line, there are several things ahead of color support in the
queue; probably shouldn't expect it real soon.

Cheers, -Dick