RE: Definitive apple ][ lo res (and hi res) mode colors (RGB values)
Bryan Parkoff
Back to the date: September 20, 2005. My comments is below.
>Inspired by this thread I did the math to find out what the NTSC Apple
>II/II+/IIe/IIc colors actually are. (The IIgs produces noticeably
>different colors because of its RGB operation). Unfortunately, most
>emulators don't get the colors right. Maybe somebody feels like patching
>the correct color values as given here into some emulator(s)?
>
>The PAL Apples produce almost identical colors to their NTSC cousins,
>but unfortunately unlike for NTSC there's no pretty mathematical way to
>calculate their theoretical values, since the PAL Apples use some
>not-so-well-defined analog circuitry to add together luminance and
>chrominance signals, while the NTSC Apples produce both luma and chroma
>in a single digital process.
>
>I'm assuming that the A2 logic circuits produce a perfectly rectangular
>output on the video out, alternating between 0 (black) and 1 (white),
>not counting the sync (which is added afterwards). This is pretty close
>to what they actually do. The only possible error is a very slight one
>in color saturation, hue and brightness should not be affected by this
>assumption.
>
>I'm also assuming that the NTSC decoder at the receiving end is
>completely to (modern) spec. The original "NTSC 1953" norm called for
>YIQ decoding and had different color primaries than modern sets, but
>almost all TV sets actually produced use YUV decoding and the modern
>primaries, which were then made the standard in "SMPTE 1979", the modern
>NTSC norm. I follow the 1979 norm since the old norm is mostly of
>theoretical value only, and when the Apple was released in 1977 the
>modern norm was de facto already in place.
>
>Then it is easy to mathematically derive the correct color values. All
>it takes is a fourier transform of the waveform. The zeroeth coefficient
> (which is 0.0 for black, 0.25 for the 4 "dark" colors, 0.5 for grey
>and the four "mid" colors (which are also the hires colors), 0.75 for
>the four "bright" colors, and 1.0 for white) of said transform gives the
>luminance, the first coefficient (0 for black, grey, white, 1/(2*pi) for
>the "mid" colors, and 1/(2*sqrt(2)*pi) for the "dark" and "bright"
>colors) gives the color saturation. Phase angels (hues) are multiples of
>90° for the 4 "dark" and the 4 "bright" colors, and multiples of 90°
>plus 45° for the 4 "mid" colors.
>
>The lores colors 4, 7, 8 and 11 are affected by clipping, i.e. when
>these colors are used the Apple is telling the TV to produce a color it
>can't actually produce since it's somewhat outside the gamut - none of
>the three electron guns in the picture tube can be turned down below
>zero power, or above maximum power. This clipping is taken into
>consideration in the tables.
>
>The resulting RGB values (in hex) in the SMPTE color space for the 16
>lores colors are as follows:
>
>NTSC Apple II Colors RGB Values in SMPTE 1979 color space
>---------------------------------------------------------
>R, G, B [ 0] = 0x000000 * Hires 0 & 3
>R, G, B [ 1] = 0x901740
>R, G, B [ 2] = 0x402ca5
>R, G, B [ 3] = 0xd043e5 * Hires 2
>R, G, B [ 4] = 0x006940
>R, G, B [ 5] = 0x808080
>R, G, B [ 6] = 0x2f95e5 * Hires 6
>R, G, B [ 7] = 0xbfabff
>R, G, B [ 8] = 0x405400
>R, G, B [ 9] = 0xd06a1a * Hires 5
>R, G, B [10] = 0x808080
>R, G, B [11] = 0xff96bf
>R, G, B [12] = 0x2fbc1a * Hires 1
>R, G, B [13] = 0xbfd35a
>R, G, B [14] = 0x6fe8bf
>R, G, B [15] = 0xffffff * Hires 4 & 7
>
>The numbers in square brackets are the lores color numbers (COLOR= in
>Applesoft). The hires colors (HCOLOR= in Applesoft) are marked with an
>asterisk.
>
>Note that these RGB values are valid only for the SMPTE 1979 color
>space. Converting them to sRGB color space (which is what modern PC
>monitors *should* use when set to 6500K color temperature, most are at
>least close; this is also the color standard for HDTV sets and for Web
>pages) and linearily scaling their brightness so that the maximum
>coefficient is 0xff, gives these slightly different values:
>
>NTSC Apple II Colors RGB Values in sRGB color space
>---------------------------------------------------
>R, G, B [ 0] = 0x000000 * Hires 0, 3
>R, G, B [ 1] = 0x8a2140
>R, G, B [ 2] = 0x3c22a5
>R, G, B [ 3] = 0xc847e4 * Hires 2
>R, G, B [ 4] = 0x07653e
>R, G, B [ 5] = 0x7b7e80
>R, G, B [ 6] = 0x308fe3 * Hires 6
>R, G, B [ 7] = 0xb9a9fd
>R, G, B [ 8] = 0x3b5107
>R, G, B [ 9] = 0xc77028 * Hires 5
>R, G, B [10] = 0x7b7e80
>R, G, B [11] = 0xf39ac2
>R, G, B [12] = 0x2fb81f * Hires 1
>R, G, B [13] = 0xb9d060
>R, G, B [14] = 0x6ee1c0
>R, G, B [15] = 0xf5faff * Hires 4 & 7
>
>Hope this helps,
>--
>Linards Ticmanis
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.
Bryan Parkoff
Linards Ticmanis
> 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.
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.
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.
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.
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.
It's really impossible to understand this whole junk without doing a bit
of the math yourself, so I'll refrain from giving canned formulas of the
"Just Believe!" type.
--
Linards Ticmanis
Michael J. Mahon
> 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."