Re: NTSC's Three Dots Per One Pixel

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

Michael,

    I agree with you that one pixel is stretched to cover mask holes on
Apple NTSC Monitor.  I have no idea why stretching pixel is done that it
looks like 5 dots (mask hole) for violet and green color and 6 dots (mask
hole) for white color.
    I have put violet color and green color into YIQ.

    Look at my example.

Y = 0.299(221) + 0.587(0) + 0.114(221) --> 91
I = 0.596(221) - 0.274(0) - 0.322(221) --> 61
Q = 0.211(221) - 0.523(0) + 0.312(221) --> 116
Violet

Y = 0.299(0) + 0.587(221) + 0.114(0) --> 130
I = 0.596(0) - 0.274(221) - 0.322(0) --> 61
Q = 0.211(0) - 0.523(221) + 0.312(0) --> 116
Green

    The problem is that SVGA has RGB 24 Bits per pixel.  Red is 8 Bit, Green
is 8 Bit, and Blue is 8 Bit.  Each pixel contains four bytes into video
memory before it can display in SVGA screen.  I can't figure that Y should
be in Red byte, I should be in Green byte, and Q should be in Blue byte.  It
does not work that way.
    It is why I have to create color palette for YIQ so color palette for
YIQ is always in RGB 24 Bits.  Do you know what I mean?
-- 
Bryan Parkoff
"Michael J. Mahon" <mjmahon@aol.com> wrote in message
20040626202439.12238.00000767@mb-m01.aol.com">news:20040626202439.12238.00000767@mb-m01.aol.com...
> Bryan Parkoff replied:
>
> >"Michael J. Mahon" <mjmahon@aol.com> wrote in message
> >20040626040152.16528.00000476@mb-m22.aol.com">news:20040626040152.16528.00000476@mb-m22.aol.com...
> >> Bryan Parkoff wrote:
> >>
> >> >   Do you see that Apple IIgs' RGB monitor displays one dot per pixel?
> >If
> >> >you type in Applesoft BASIC like below.
> >> >
> >> >10 HGR
> >> >20 HCOLOR=2
> >> >30 HPLOT 0,0 TO 100,100
> >> >RUN
> >> >
> >> >    It displays a violet line from (0,0) to (100,100).  Do you notice
> >that a
> >> >pair of pixels do not get close together that it only displays one dot
> >per
> >> >pixel?  Now, compare to NTSC.  Do you notice that it displays three
dots
> >per
> >> >pixel?  It is because NTSC's beam to light three dots per pixel, but
it
> >> >looks like that it is really five dots or six dots per pixel.
> >>
> >> I believe that you are confusing the dots created by the CRT's shadow
> >> mask with pixels.
> >>
> >> Try plotting a single point and look at the screen.  Then plot two
> >adjacent
> >> points (which will appear to be white) and look at the screen.
> >>
> >> Apple pixels are, indeed, single pixels, but when sent to a monitor
> >> using NTSC encoding, the bandwidth is limited and the dots are
> >> smeared somewhat.  If you see multiple discrete dots in a single
> >> Apple pixel, this is not in the video signal, but in the shadow mask
> >> just behind the CRT's screen.
> >>
> >> If you want to see what is actually going on, you should look at
> >> the Apple video signal with an oscilloscope.  That will make it quite
> >> clear that an Apple pixel is a single pulse, regardless of "color".
> >>
> >> The color of a displayed pixel is an artifact of the phase (timing)
> >> of the pulse with respect to the color reference burst.  The video
> >> signal is simply a sequence of pulses, one per "on" pixel, each
> >> of the same amplitude (even the "runt pulse" that occurs when
> >> a pixel pulse is cut short by a change in "color set" between
> >> video bytes).  It is the location and duration of these pulses
> >> that produce the apparent color of the display.
> >
> >    Thank you for the information.  I do understand that Apple II's
picture
> >signal always outputs one dot per pixel, but video monitor displays three
> >dots per pixel that is called shadow mask CRT.  It does make sense that
it
> >is how NTSC is designed to use shadow mask CRT unlike Apple IIgs' RGB
> >monitor.
>
> The RGB monitor uses a shadow mask, too, but the bandwidth of the
> RGB signal is high enough that a pixel is not "stretched" to cover
> more mask holes.
>
> The finer the shadow mask, the more "dots" you will see for a single
> pixel, even if driven by an RGB signal.  These dots have to do with the
> construction of the CRT and the width of the video pulse, not the
> number of pixels displayed or their color (though different spots on
> the CRT will illuminate for different colors).
>
> >    I am trying to simulate RGB pixel into NTSC's shadow mask CRT.  I
would
> >not be able to find any information on the website using google search.
My
> >goal is to write C++ source code by translating RGB pixel into NTSC's
shadow
> >mask CRT.  NTSC screen will look real on SVGA monitor.
>
> Curious--you are trying to emulate the bandwidth limitations of NTSC
> on a high-resolution monitor!
>
> One approach is to take high-resolution digital photos of an NTSC
> monitor screen, then present them on a high resolution monitor.
>
> >    Can you please help me to find the information like source code,
graphic
> >/ video functions including shadow mask CRT formula and YIQ formula for
> >translating from RGB to NTSC while I am searching right now.
>
> I didn't bother to invert the RGB-to-YIQ matrix an earlier respondent
> supplied, but I did happen to come across an YCrCb-to-RGB matrix.
> There are various such matrices dependent on exact color models,
> but this is one typical of TV (with all components from 0..256):
>
> R = 1.164*(Y-16) + 1.596*(Cr-128)
> G = 1.164*(Y-16) - 0.813*(Cr-128)-0.392*(Cb-128)
> B = 1.164*(Y-16) +2.017*(Cb-128)
>
> Note that the Cr and Cb values are excess-128 signed, while the
> Y values are absolute.  Also note that in TV signals, there is a
> luminance "setup" of 16 units to provide margin for the blanking
> signals to be "blacker than black".
>
> -michael
>
> Check out amazing quality sound for 8-bit Apples on my
> Home page:  http://members.aol.com/MJMahon/