58 replies to this topic

[_33]

I created a thread about this subject on where I usually post but now I'm stuck, and no one has a smart answer for me.  So I decided to contact the real pros.  What I'm trying to find is the real colors of the ATARI 8-bit.  I've made my own, and I'm trying to compare.  I need someone with the brains to dump the colors, take a snapshot with a cam, and post it here.  I've checked the colors in G2F, but they seem off.  Someone might confirm with me.

My palette is off, but I don't know how off thoe!



G2F's color chooser:

Edited by _33, Sun Jun 24, 2007 1:57 PM.

[Shannon]

I'm pretty sure there are only 128 "displayable" colors, even though the register is one byte.

[_33]

On the GTIA in 16 color modes, there is one mode with 16 shades (mode 9), and they are very distinct shades of one hue.  Since there are 16 hues (mode 11), there are 256 colors to choose from.  On the older CTIA, there are 128 colors to choose from, with several graphics modes less.

http://www.sonic.net...ew_and_emu.html

Edited by _33, Tue May 29, 2007 6:40 PM.

[Rybags]

The best method might be to reproduce that display on a real Atari then feed it to a video capture card.

But, the inherent problem with reproducing colours on a PC monitor is that typically a monitor will display any given RGB value at a lower brightness than a TV.

Then you have the additional problem that colour trimmers on different Ataris can fall out of adjustment and cause slight colour variations.

Not to mention the fact that PAL Ataris don't produce the same as NTSC.  Colour 1 is the same as 15, and Colour 4 I believe is reddish on NTSC but more purple/violet on PAL.

[_33]

Rybags, on Tue May 29, 2007 8:01 PM, said:

The best method might be to reproduce that display on a real Atari then feed it to a video capture card.

But, the inherent problem with reproducing colours on a PC monitor is that typically a monitor will display any given RGB value at a lower brightness than a TV.

Then you have the additional problem that colour trimmers on different Ataris can fall out of adjustment and cause slight colour variations.

Not to mention the fact that PAL Ataris don't produce the same as NTSC.  Colour 1 is the same as 15, and Colour 4 I believe is reddish on NTSC but more purple/violet on PAL.

Thanks for this very nice tip Rybags!

I've got the MESS emulator colors now.  They seem to give somewhat bright full colors in the lower ranges, but close to what I got in the high ranges.  There seems to be some staircase variants (notably in the blues and reds and some yellows...  Well a lot of staircase color changes).  Your toughts?

Edited by _33, Tue May 29, 2007 11:38 PM.

[Rybags]

If I have time later on, I'll get my real machines out and generate some captures.  They're all PAL though - most emulations look best with NTSC colour representations.

[_33]

Rybags, on Tue May 29, 2007 8:29 PM, said:

If I have time later on, I'll get my real machines out and generate some captures.  They're all PAL though - most emulations look best with NTSC colour representations.

I'm sure if I scan through the source code of any other Atari 8-bit emulator (Atari 800Plus, done that one also), that it wouldn't match any of the color charts that I posted already, which add to the confusion.  Now, with the mention of the PAL colors, it's getting even worse!

Edited by _33, Tue May 29, 2007 8:45 PM.

[SeaGtGruff]

Aside from possible differences in the way the color output is "tuned" on different Ataris, another issue when using a TV is the way the brightness, contrast, and tint are set-- especially with NTSC Ataris and TVs. Anyway, following is a video capture I made several years ago of a 256-color display. I believe I posted a short Atari BASIC program here a year or two back, to display the 256 colors as in this video capture, and there were a couple of people who posted their own video captures from it on their NTSC or PAL Ataris, so you might want to search this forum for it.

By the way, I've always thought that luminances 7 and 8 look virtually identical to each other, whereas the other luminances have a more noticeable "step" between them-- but when you display luminances 7 and 8 side-by-side (as in this video capture), you get a "dark line" where they meet.

Michael

[Rybags]

That's another problem.

Due to interference you tend to get inconsistencies depending on where a pixel is within a character cell.

[Shannon]

_33, on Tue May 29, 2007 8:33 PM, said:

On the GTIA in 16 color modes, there is one mode with 16 shades (mode 9), and they are very distinct shades of one hue.  Since there are 16 hues (mode 11), there are 256 colors to choose from.  On the older CTIA, there are 128 colors to choose from, with several graphics modes less.

http://www.sonic.net...ew_and_emu.html

Correct.  I was thinking CTIA when I posted that.  But even in a GTIA machine, CTIA modes can still only display 128 diff colors.

I never dabbled much in the new GTIA modes to realize that.  Other than the 16 hues and shades.

[_33]

SeaGtGruff, on Tue May 29, 2007 10:25 PM, said:

Aside from possible differences in the way the color output is "tuned" on different Ataris, another issue when using a TV is the way the brightness, contrast, and tint are set-- especially with NTSC Ataris and TVs. Anyway, following is a video capture I made several years ago of a 256-color display. I believe I posted a short Atari BASIC program here a year or two back, to display the 256 colors as in this video capture, and there were a couple of people who posted their own video captures from it on their NTSC or PAL Ataris, so you might want to search this forum for it.

By the way, I've always thought that luminances 7 and 8 look virtually identical to each other, whereas the other luminances have a more noticeable "step" between them-- but when you display luminances 7 and 8 side-by-side (as in this video capture), you get a "dark line" where they meet.

Michael

256color.PNG

See, this is what I came up with.  And now it's more obvious that the real bugger is nailing down the reds and blues properly in the lower range, since the saturation is high but also the luminence is fairly high.  So as the luminence increases, saturation decreases.  But it's special in the reds and blues.

[SeaGtGruff]

_33, on Wed May 30, 2007 1:33 AM, said:

SeaGtGruff, on Tue May 29, 2007 10:25 PM, said:

256color.PNG

See, this is what I came up with.  And now it's more obvious that the real bugger is nailing down the reds and blues properly in the lower range, since the saturation is high but also the luminence is fairly high.  So as the luminence increases, saturation decreases.  But it's special in the reds and blues.

I think your hue 2 is off; it looks yellow, but it should be yellow-orange. Aside from that, it looks like your other hues are pretty close to my video capture, other than the saturations and luminances. And your hue 1 may be a tad too greenish. The literature says that hue 1 is the same as colorburst, and NTSC colorburst is mostly yellow with a definite hint of green.

Here's a color wheel I made using a formula I found somewhere, based on hue 1 = colorburst, and the other hues being shifted around the NTSC color wheel by a certain number of degrees. The hues are numbered around the outside of the wheel, and the colors are oriented as close as I could get them to the NTSC color wheel, where colorburst is "due west," red is somewhere around "NNW," etc. I got the colors by using a free program called Colorspace, and rotating the NTSC color space by a certain number of degrees to get a specific value. I don't know how close the hues are to an actual NTSC Atari, but for the most part they look pretty good. I didn't try to get the saturations and luminances, just the hues, to see if the formula I'd found was accurate.

Michael

[SeaGtGruff]

By the way, the formula I found is more or less as follows:

Phase angle = 185.938636363636 + 27.0613636363636 * hue
where hue = 1 through 15.

The document I found gave slightly different values, but I tried to calculate more exact values based on the NTSC color clock timings. To use the resulting phase angles with the Colorspace program, I had to convert them to +/- values, e.g., 213 degrees (colorburst) is equal to -147 degrees. This is what I came up with:

hue 1 = -147
hue 2 = -119.938636363636
hue 3 = -92.8772727272728
hue 4 = -65.8159090909092
hue 5 = -38.7545454545455
hue 6 = -11.6931818181819
hue 7 = 15.3681818181818
hue 8 = 42.4295454545454
hue 9 = 69.4909090909091
hue 10 = 96.5522727272727
hue 11 = 123.613636363636
hue 12 = 150.675
hue 13 = 177.736363636364
hue 14 = -155.202272727273
hue 15 = -128.140909090909

As you can see, the hues span slightly more than 360 degrees, with hue 15 being between hue 1 and hue 2.

Here's a screenshot of the Colorspace program, showing the NTSC (YIQ) "color cube" oriented at the angle usually shown on video equipment that's used to check the colors-- i.e., with colorburst at the far left ("due west"), or with the Q axis at 33 degrees, and the I axis at 123 degrees. Once I calculated the phase angles for the hues, using the formula shown above, I changed the "Phi" setting in Colorspace to rotate the YIQ color cube so that the Q axis had a particular phase angle, and then took the color that was "due east" (i.e., a Phi setting of -147 degrees rotates colorburst so it's "due east").

Michael

[Allas]

Is there is a formula to change a 24bit pixel BMP into 1byte APAC pixel color (1 nibble luminance+1 nibble hue)?

[SeaGtGruff]

Allas, on Wed May 30, 2007 1:30 PM, said:

Is there is a formula to change a 24bit pixel BMP into 1byte APAC pixel color (1 nibble luminance+1 nibble hue)?

I don't know, but if you're able to understand it (much of it is over my head), you could start with this page:

http://www.xmission....ideo_notes.html

I know there are conversion formulas for going from YIQ (NTSC) color values to RGB color values, and I know you also need to take into account the effects of different gamma values between TV sets and computer monitors. Furthermore, although APAC colors are created by effectively combining 16 hues with 16 luminances, the results are different than if you were to display the Atari's actual 256 colors.

I was trying to figure out where I'd found the hue phase-shift formula that I posted, and it looks like I'd extrapolated it from some information on this page:

http://homepage.ntlw...ari_hw/gtia.htm

Michael

[Rybags]

403- access denied on that first link.

[Nukey Shay]

Working fine here.  And this is IE6 on Windows '98 with most everything disabled.

[SeaGtGruff]

Here's another link with information and formulas related to converting from TV color space-- in this case, YUV (PAL) color space-- to RGB color space, with gamma correction taken into account. The discussion is oriented toward the VIC-II (C-64), but the formulas and general discussion ought to be applicable to converting from YIQ (NTSC) color space to RGB color space for the Atari's colors.

http://www.pepto.de/projects/colorvic/

Michael

[_33]

Here's a complete set of YIQ functions in C:

http://www.fools-err.../hc/lib/color.c

What is YIQ? Found info here: http://www.ardenwood...glossary_y.html

Quote

YIQ (YCbCr - Luminance/In phase/Quadrature phase)
A bandwidth optimized, matrixed, composite video signal format used by NTSC video systems employing separate luminance and two derived blue and red chroma components derived from the YUV format.
The modulated carriers (U) and (V) (phased 90 degrees apart) are what carry the color information in an NTSC-encoded composite color picture. This is called “quadrature”. We call the modulated carriers “I” and “Q” in NTSC ("In phase" and "Quadrature phase"). I and Q are bandwidth-limited differently so they’ll fit into the NTSC transmission spectrum.

The human visual system has less spatial acuity for magenta-green transitions than it does for red-cyan. Thus, if signals I and Q are formed from a 123 degree rotation of U and V respectively, the “Q” signal can be more severely filtered than “I” without being perceptible to a viewer at typical TV viewing distance. YIQ is equivalent to YUV with a 33 degree rotation and an axis flip in the UV plane. The first edition of W.K. Pratt “Digital Image Processing”, and presumably other authors that follow that bible, has a matrix that erroneously omits the axis flip; the second edition corrects the error.

Since an analog NTSC decoder has no way of knowing whether the encoder was encoding YUV or YIQ, it cannot detect whether the encoder was running at 0 degree or 33 degree phase. In analog usage the terms YUV and YIQ are often used somewhat interchangeably. YIQ was important in the early days of NTSC but most broadcasting equipment now encodes equiband U and V.

The D-2 composite digital DVTR (and the associated interface standard) conveys NTSC modulated on the YIQ axes in the 525-line version and PAL modulated on the YUV axes in the 625-line version. (See YUV)

I just made the YIQ2RGB in Blitz3D.  I don't think I'll have any use for this in particular.  I've tried it and found that it won't fix the reds and blues problem that I have...

Function yiq_rgb(y#,i#,q#, r%, g%, b%)
;Y = range [0.,1.]
;I = range [-.6,.6]
;Q = range [-.52,.52]
   red% = ((1.00309 * y) + (0.95485 * i) + (0.61786 * q)) * r
   green% = ((0.99678 * y) + (-0.27071 * i) + (-0.64479 * q)) * g
   blue% = ((1.00850 * y) + (-1.11049 * i) + (1.69957 * q)) * b
   If red < 0   Then red = 0 ElseIf red > 255 Then red = 255
   If green < 0   Then green = 0 ElseIf green > 255 Then green = 255
   If blue < 0   Then blue = 0 ElseIf blue > 255 Then blue = 255
   Return ((red And $FF) Shl 16) Or ((green And $FF) Shl 8) Or (blue And $FF)
End Function

Edited by _33, Thu May 31, 2007 12:41 PM.

[_33]

Best I could do so far!  Getting tired

But this is as close as I can imagine.  Ive compared colors in GIMP with the sample I got from this forum.  ANyhow thanks guys.  Any other real 8-bit sample of the 256 color palette would be appreciated.

[Rybags]

Here's a captured screen from my PAL 130XE via it's S-Video output.




I wrote my own program to generate it - it leaves space between the colours and also uses 3 black-coloured Players to help delineate the changes at the borders and between luminence levels 0 and 1.


Here is the program I used - Zipped ATR - mount it after loading DOS with BASIC, then ENTER "D:COLORBAR.BAS" and RUN it.

 Colorbar.zip   1.2K   169 downloads

Edited by Rybags, Fri Jun 1, 2007 4:01 AM.

[Rybags]

SeaGtGruff, on Wed May 30, 2007 2:25 PM, said:

256color.PNG

Interesting comparing that cap to mine.

I've got them both loaded up in Photoshop and checking the colours with the eyedropper and RGB and HSB sliders.

Despite being somewhat grainy, the cap from SeGtGruff seems to have perfectly consistent whites, ie - the R,G,B values for each sampled pixel are always the same.

Mine seems to have a misbalance - don't know if that's a PAL thing or just the settings on my capture card (I have them at default, other than adjusting interlace compensation and sharpness for a better looking display).

Edited by Rybags, Fri Jun 1, 2007 5:32 AM.

[SeaGtGruff]

Rybags, on Fri Jun 1, 2007 7:31 AM, said:

SeaGtGruff, on Wed May 30, 2007 2:25 PM, said:

256color.PNG

Interesting comparing that cap to mine.

I've got them both loaded up in Photoshop and checking the colours with the eyedropper and RGB and HSB sliders.

Despite being somewhat grainy, the cap from SeGtGruff seems to have perfectly consistent whites, ie - the R,G,B values for each sampled pixel are always the same.

Mine seems to have a misbalance - don't know if that's a PAL thing or just the settings on my capture card (I have them at default, other than adjusting interlace compensation and sharpness for a better looking display).

If I remember correctly, my capture was made a few years back by connecting my NTSC 8-bit to a VCR, and then connecting the VCR to my computer via a Snappy video capture device. (At the time, the only way I could connect my Atari to video was via the antenna connectors on the RF switch box!) Anyway, I played with the brightness and contrast settings in the Snappy software to get a good picture, from a nice dark black to a reasonably bright white. I kept the tint adjusted "in the middle" so it would be as "pure" as possible, rather than trying to adjust it more toward red or green to get a nice yellow for hue 1. (I'm not sure if I knew it at the time, but hue 1 on an NTSC Atari is said to be equal to "colorburst," which is sort of greenish yellow, but closer to yellow, so it's a good thing I didn't try to adjust the tint to make hue 1 equal a nice-looking yellow!)

I'm guessing that you need to adjust those capture card settings to bump up the brightness, and possibly adjust the contrast as well. Unless I'm getting it backward, TV has a higher gamma than computer monitors, so an image that looks good on a TV will look darkened on a computer monitor, hence you need to adjust the gamma, or brightness/contrast, to try to get a better match between the image as seen on a monitor and on a TV.

It doesn't help the situation that Ataris have a potentiometer which can be adjusted to modify the color output for the hues; that NTSC TVs have a tint adjustment; that computer monitors also have tint (RGB) adjustments; that all TVs and monitors have brightness/contrast adjustments; that TV sets and computer monitors use different gammas; that different TV sets or monitors may use different phosphors for red, green, and blue; etc. All of these factors tend to make the quest for perfect color emulation something of an "impossible dream." Of course, that shouldn't stop us from trying!

Michael

[SeaGtGruff]

By the way, I was thinking it would be cool to get a vectorscope, connect an Atari to it, have the Atari display each color one by one, and check the results on the vectorscope, to see where each hue is located around the NTSC (or PAL) color wheel. But then I saw how expensive vectorscopes are, which put a definite damper on *that* pipe dream!

Michael

[_33]

Rybags, on Fri Jun 1, 2007 3:57 AM, said:

Here's a captured screen from my PAL 130XE via it's S-Video output.

Atari_13..._Colours.jpg


I wrote my own program to generate it - it leaves space between the colours and also uses 3 black-coloured Players to help delineate the changes at the borders and between luminence levels 0 and 1.


Here is the program I used - Zipped ATR - mount it after loading DOS with BASIC, then ENTER "D:COLORBAR.BAS" and RUN it.

Colorbar.zip

Hi Rybags!  Could it be possible to print this screen without the black bars?  That should help do a 1 on 1 comparison with my palette and SeaGtGruff's.

BTW, SeaGtGruff, your Atari is an NTSC?

It seems in MESS, they tried to hack in a PAL palette and tried to increatse saturation to give them more lively colors.  It's a shame because MESS, like MAME, is supposed to emulate exactly the system, not have a ricer one

Cheers.

Edited by _33, Fri Jun 1, 2007 1:25 PM.