Re: Color Reference of NTSC Formula?

["Bryan Parkoff" <nospam@nospam.com>]

"Mark McDougall" <markm@vl.com.au> wrote in message 
news:44ceae35$0$1466$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
> Bryan Parkoff wrote:
>
>> Think of color in a square.  It is truly RGB.  Darkness color is in
>> the bottom of this square and brightness color is in the top of this 
>> square.
>> You fill 0-255 value on R, G, and B signal.  It allows the line of RGB to 
>> be
>> moving from the bottom to the top of this square until you get the 
>> correct
>> color.
>
> An RGB colour space incorporates both chrominance and luminence which is
> why you have black and white included in the space. In, YIQ colour space
> (which is the same as CIE XYZ) the 'wheel' mapped out by I&Q describes
> only the chrominance - it does *not* include the luminance, Luminance
> (Y) represents the "power" or intensity of the light and is not encoded
> in the phase shift but rather the amplitude of the grey-scale signal.
> That's why there's no black or white on the "VECTOR SCOPE".
>
>>     Think of color in a circle what I am referring Deep Red, Dark Blue, 
>> Dark
>> Green, and Brown.  Apple IIgs attempts to emulate a color in the circle 
>> to
>> display HGR and DHGR using phase shift by the following 0 to 360 degree.
>> You place one bit on position 0 and three zero bits on position 1 through 
>> 3
>> of DHGR.  The phase shift is on 0 degree.  It displays Deep Red pixel. 
>> It
>> is where an arrow in the color circle is pointed to the 0 degree.
>
> I think you've sort of got the idea, but it's twisted a little. A group
> of 4 dots does not represent a "phase shift". Phase shift is relative to
> the colour burst, and is a property of a single pixel, not a group of
> pixels. I *think* what may be confusing is that the Apple can only
> adjust the phase of the signal by +/- 90 degrees for each bit, so it
> would take 4 shifts (4 pixels) to move all the way around the colour
> wheel. Of course, you can go backwards as well, so at most you need 2
> shifts to get to any desired pixel value.
>
>> It does the same process to clearing and setting bit.  It is like a bit 
>> is
>> moving from phase shift to phase shift.  1000, 0100, 0010, 0001, 1000.
>
> Look at the *shape* of the waveform produced a bitstream.
> eg. Say we have a colour burst encoded digitally at 4X the burst
> frequency. It may look like this...
> 0011001100110011
> So it takes 4 bits for once cycle, which looks more like a sine wave
> after it's passed through a low-pass filter.
>
> Now we choose a colour exactly *in phase* with the burst (which is a bit
> confusing, because the I axis is defined as being 57 deg from the burst,
> so our colour would be whatever is represented at -57 deg on the vector
> scope)... the encoding would be:
> burst: 00110011001100110011001100110011
> IQ: 00110011001100110011001100110011
> which is of course exactly the same as the burst.
>
> Now say we wish to move 90 degrees around the colour circle. So we need
> to shift the chrominance signal by 90 degrees. We then have...
> burst: 00110011001100110011001100110011
> IQ: 01100110011001100110011001100110
> The above signals show the encoding over *several* pixels.
>
> When you start changing the phase *every* pixel, it gets messy and
> difficult to actually show the phase shift.
>
>>     Do you agree what I provided 16 colors in a table with 4 bits and
>> degree?  Is it wrong?
>
> I haven't checked all your numbers but yes, I think some of them are 
> wrong.
>
>>     How do you get the value of Q and I with your knowledge?  Do you 
>> guess
>> the values by trying to pick up the correct degree for the color?
>
> No I didn't guess at all. It's all derived from the formula that
> converts RGB to YQI...
> Y = 0.3R + 0.59G + 0.11B
> which is the luminance or grey-scale component
> Q = 0.21R - 0.52G + 0.31B
> I = 0.6R - 0.28G - 0.32B
> which give the two quadrature components of chrominance.
>
> So for RGB red (255,0,0) which we scale to (1,0,0) for simplicity...
> Y = 0.3*1 + 0.59*0 + 0.11*0 = 0.3
> Q = 0.21*1 - 0.52*0 + 0.31*0 = 0.21
> I = 0.6*1 - 0.28*8 - 0.32*0 = 0.6
> I&Q are two vectors at right-angle (quadrature). The representative
> phase is the angle subtended when you join the vectors (this is the
> angle on the colour wheel, which gives the hue) and the magnitude is how
> far from the centre of the wheel the colour lies, which gives the
> saturation. The *angle* is given by the arctan of the length of Q
> divided by the length of I.
> So for our example of red, with Q=0.21 and I=0.6, the phase is
> arctan(0.21/0.6) = 19.3 deg.
> Since the I axis is defined as being 57deg from the burst, looking at
> the vector scope burst is at 180, so I is at 123deg. Subtracting 19.3
> from 123 gives 103.7 which corresponds with the Red square on the vector
> scope.
>
> For yellow, which is RED+GREEN in RGB space, I used (255,255,0) to get
> 167 deg.

Mark,

    OK.  You used RGB to YIQ formula.  The problem is that you already know 
Apple IIgs' 16 RGB colors so you put them into RGB to YIQ formula to get 
degree of color circle.  It is not a problem.  I do not intend to get RGB 
value for color because I don't want to use Apple IIgs' RGB 16 colors so I 
use NTSC color.  I decide to follow the bit stream of 14MHz while 3.58MHz 
color reference is activated.  It is up the color reference to decide and 
choose which color is to be used by the following bit stream of 14MHz.
    With the color information from bit stream of 14MHz, the degree of color 
should be obtained from it through 3.58MHz color reference.  Then, we say 
that YIQ is per four sub-pixels of whole pixel.  We may want to simulate 
NTSC screen on RGB monitor.  We need to use YIQ to RGB formula so it will 
show RGB pixels.  It is what we use NTSC color which it will never be 
identical to Apple IIgs' 16 RGB color.
    Do you know what I mean?  Do you know which is a good book so I can read 
and study?

Bryan Parkoff