Subject: Re: [stella] tia hue luminance From: "Eric Ball" <ericball@xxxxxxxxxxxx> Date: Thu, 11 Dec 2003 23:14:30 -0500 |
Wow, lots of interesting questions. Let me see if I can come up with some answers & clarification. This will probably be long and I may ramble a bit, sorry. 1. Ranges In the calculations I've given the range of RGB & Y are 0.0 - 1.0, which are then multiplied by 255 to yeild an 8 bit value (so black = #00000 and white = #FFFFFF). In other situations different ranges are used (eg Yblack = 16 and Ywhite = 235) to allow for some underflow/overflow due to signal processing. When talking about NTSC video IRE units are used, where sync = -40 IRE, blank = 0 IRE, black =7.5 IRE & 100% white = 100 IRE. There is some video equipment which uses black=0 IRE. Color saturation is also expressed in IRE with colorburst being 20 IRE. 2. the TIA The TIA generates the video signal via 6 output pins: phase shifted colorburst COL, and digital luma SYNC, BLK, LM2, LM1, and LM0. The phase shift for the COL pin is generated internal to the TIA via some delay gates selected via a multiplexer (with an output disable for COL=0). SYNC and BLK are driven automatically by the TIA horizontal counters, with LM2-0 being tied directly to the object color selector. The digital luma pins drive a simple resistor D to A converter. (Note: the pins sink current, so a lower resistance means a higher output voltage.) Based on the knowledge that SYNC is 40 IRE, we can derive values for LUM. (Note: the BLK pin isn't connected on the 2600A, so the dark colors will tend to be darker.) Note: the same values of LUM are used for COL=0 and the other colors. Therefore, any attempts to make COLUM #F bright white will wash out the other colors. Because the TIA generates a Y/C signal directly, the "colors" it can generate sometimes fall outside the normal 0.0 - 1.0 range for RGB (typically those with low LUM values). These values are clipped, which changes the resulting hue, saturation & brightness. (One of the reasons to keep COLUM lower is to reduce clipping at the top end.) 3. Output Confusion Coming up with the R'G'B' values is easy. Getting those values to display consistently is hard. There are a bunch of variables which are beyond my knowledge and control. First, the color of RGB is unknown. The color & brightness of TV/monitor phosphors has changed over the years. LCD display color is a combination of a "white" cold cathode florescent light and color filters. This can be further complicated by manual adjustments to color "temperature", tint, or the internal 2600 color delay pot. Next, the "gamma" of the output is unknown. In order to compensate for the non-linear light response of the TV's CRT to input voltage, the video input is pre-compensated at the broadcast end so the TV output is linear. (I'm not sure whether this was done to make the TV electronics simpler or for broadcast power reasons.) Because the TIA generates a Y/C signal, the brightness of LUM 0-7 is not linear. On the emulator side this gets even more complicated because I don't know whether RGB is considered linear or non-linear, i.e. is it passed straight through to the CRT guns, or is it compensated. The answer to this question may vary from platform to platform (including such details as graphics card and API). Finally, brightness can be changed by black level & contrast settings etc. 4. Formula Tweaks There are a few tweaks which can be made to the formulas I've given: - LUM could be scaled by more than 0.045 to get Y, although not much since it will wash out the high LUM colors. An offset could be added, though that will change black and the low LUM colors. - COL could be scaled by a different value than 24 degrees to get hue. This may be what is needed to make the higher colors match. An offset here is probably wrong because the colorburst is likely just a gated COL=1. I think that the external pot is just to get the burst in the correct phase relative to SYNC. - Changing to linear RGB? I've gone through the sRGB spec three times and I still can't figure out which is right. - Transforming the output to Rec 709 RGB (which is used by HDTV and is a better representation of current CRT colors) would be interesting, but probably have little impact. Gamma is also an unknown here. 5. Next steps Given infinite time, there are some things I would like to try. - Actually fire up the colorbar demo I've done (all 128 colors onscreen at once using PF/BK), and do some comparisons myself. - Try to persuade my video capture card to capture my colorbar demo without super-saturating all over the place. (Probably missing AGC somewhere.) - Take the palettes used by the emulators and figure out what the equivalent Y/hue/sat values are to get some hints. - Start to think about considering the possibility of looking into how PAL color works. ---------------------------------------------------------------------------------------------- Archives (includes files) at http://www.biglist.com/lists/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] tia hue luminance, Adam Wozniak | Thread | Re: [stella] tia hue luminance, Adam Wozniak |
Re: [stella] tia hue luminance, Adam Wozniak | Date | Re: [stella] tia hue luminance, Adam Wozniak |
Month |