Re: Definitive apple ][ lo res (and hi res) mode colors (RGB values)

["Michael J. Mahon" <mjmahon@aol.com>]

Linards Ticmanis wrote:
> Bryan Parkoff wrote:
>
>
> >    I am curious.  How did you get NTSC colors to be translated into RGB 
> > values?  Do you have formula?  I like Apple IIgs' 16 colors better than NTSC 
> > colors according to my preference, but some people prefer NTSC colors. 
> > Emulator authors allows people to choose primary Apple IIgs' 16 colors or 
> > secondary NTSC colors.
>
>
> Hell Bryan,
>
> sorry about the belated answer, I failed to recognize the title of this.
> So much has happened in my life since back then that it feels like a
> writing of another person...
>
> I have to start with this hint: I'm no longer convinced of my formulas.
> The Apple video output is apparently further away from a perfect,
> symmetrical square wave than I believed back when I wrote this. Also, I
> have two NTSC Apples by now to see for myself, and there's a certain
> difference between theory and praxis, or at least between my TV screen
> and my PC monitor. Probably the latter is badly deadjusted.

Though symmetry would be an issue, any real NTSC monitor will strongly
band-limit the video signal, so the edges should not matter much.

The actual appearance on a particular NTSC monitor will, of course,
depend on its adjustment as well as its non-ideal chroma and luminance
processing.  The computational approach you describe will work for
"ideal" monitors if you also band-limit the U and V signals to the
appropriate NTSC values (around 1MHz).

> The formulas I used are three-step: Firstly, use Fourier analysis to
> convert the square waves into sums of sine functions. Brightness is the
> constant coefficient, and saturation is the first ("base tone") sine
> with a frequency of 3.58...MHz; phase (hue) is obvious anyway, though
> this is not completely exact since it is adjustable with a pot in real
> Apples. Such a hue adjustment would be easy enough to integrate in an
> emulator as well.

(Just for the record, it's adjusted by a variable capacitor, not a
potentiometer.  ;-)

> The second step is producing YUV values from that. Y (brightness) is
> already there from the first step. To get U and V, you have to transfer
> the polar coordinates of saturation (r) and hue (phi) to plain old
> rectangular x/y coordinates.

If the quadrature components U and V are aligned with the sine and
cosine, then they come out directly as the real and imaginary parts
of the Fourier transform.

> The last step is using the official formula for converting RGB into YUV,
> only applying it backwards. This is the formula:
>
> Y = 0.299 * R + 0.587 * G + 0.114 * B
> U = ( B - Y ) * 0.493
> V = ( R - Y ) * 0.877
>
> You can solve set of linear equations for R, G, B; then simply insert
> the YUV values and get out the RGB values.

   R = Y + 1.140V
   G = Y - 0.395U - 0.581V
   B = Y + 2.032U

> Lastly, you have to convert the values from a 0..1 range to a 0..255
> range and round them. Values above 1 or below 0 get clipped.
>
> The sRGB values in the second table are produced by a rather laborious
> process of un-applying NTSC Gamma, then a matrix multiplication, and
> re-applying the slightly different sRGB Gamma function. You'll have to
> take a hard look at the very ugly details of color management to
> understand this. As in practice its mostly the relationship of the
> colors that matters, this step is not really all that necessary.

IIRC, Microsoft actually published the YUV to sRGB conversion algorithm,
for 8-bit RGB components--somewhere in the Knowledge Base.

-michael

NadaNet networking for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."