Re: Color Reference of NTSC Formula?

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

"Mark McDougall" <markm@vl.com.au> wrote in message 
news:44cefa5c$0$1464$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
> Bryan Parkoff wrote:
>
>>     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.
>
> Ahhhhhhhhhhhhhhhhh - I think I *finally* understand what you're trying
> to do!?!? I've had it backwards all along...
>
> Right, so you want to 'emulate' NTSC output on RGB, using the *exact*
> same colours as you'd see on the NTSC monitor, including the
> artifacting... right....
>
> Now, 14MHz will allow you generate 4 distinct chrominance values, at
> phases 0, 90, 180 and 270 degrees. Presumably you can also generate 4
> different levels of luminance, which gives you 4*4=16 different colours.
>
> So I guess the key is to knowing, from the 4 bits that define each
> colour, which bits control the phase and which bits control the
> luminance, and how. This is something that will be unique to the Apple
> 2, and not something a generic formula can give you.
>
> Once you know that, you can at least choose the 16 'pure' values
> directly from the colour wheel, given your 16 pairs of phase,luminance
> values calculated theoretically.
>
> Now the hard part, artifacts. The originating input is generated by
> square waves, and low-pass filtered to be shaped more like sine waves.
> But they're not perfect, and the phase comparator in the NTSC monitor is
> going to 'see' the phase difference drift slightly across each pixel.
> The problem is more pronounced when you need to switch the phase 180
> from once pixel to the next (opposite sides of the colour wheel). This
> is why you get purple/violet fringing on the white for example - it
> takes a while for the "true" phase to be seen by the comparator.
>
> To calculate these artifacts I think you'd have to model the filtering
> of the square wave and the bandwidth limitation on the phase comparator.
> Trouble is, the 'fringing' is an analogue effect and to show this on an
> RGB monitor would require several pixels for each Apple 2 pixel. I guess
> it's fortunate that we have 1900x1600 monitors these days! ;)
>
> Am I on the right track now?

Mark,

    Correct.  It is what I mean.

Bryan Parkoff