I wonder whether that has anything to do with the tint bits, which attenuate the signal during those phases. Or it might have something to do with eight phase units (eight half cycles of the master clock) equaling one pixel, causing intermodulation between the pixel clock and chroma subcarrier.Drag wrote:I noticed a quirk. I went into my TV's settings and turned the saturation all the way down (my TV is capable of completely disregarding colorburst). Every 4th color (starting with color x4) has a slightly lighter luminance than the other colors. This is completely without chroma (as far as I know), so the luminance signals for those colors is slightly lighter? Does this happen for anyone else?
Emulator palettes vs real NTSC TVs
Moderator: Moderators
Re: Emulator palettes vs real NTSC TVs
Re: Emulator palettes vs real NTSC TVs
Yes.Drag wrote:NTSC buffs, please help me with this one. I know that the hue of the picture is relative to the hue of the colorburst. Is the saturation of the colors relative to the amplitude of the colorburst too?
Supposedly, nothing. Macrovision uses a DC offset during the back porch this to defeat VCRs' AGC. However, this does imply colors when routed through a VCR will be different. (Depending on the VCR, possibly only in recordings, or possibly all the time).What happens if the colorburst has a DC offset? Does that have any effect on the colors?
If anything were to happen, it would the AGC behavior I mentioned, with displacing black level up and so increasing contrast and darkening already dark colors. There should be no phase dependence.
The voltages on the wiki are colorburst low: 1V, colorburst high: 1.712V, black: 1.3V, and the average of the first two is 1.356V. So it sounds like yes, there's a slight DC offset.The reason I'm thinking about this is because the NES may have a DC bias on its colorburst signal. If it does, and it affects the output, then I need to take it into account.
Re: Emulator palettes vs real NTSC TVs
Well, it's 8-bit digitized RGB that uses 0-255 to represent some range brightness for each component. The brightness of 255 isn't absolute. TVs use RGB as well, converting RF/composite/component into RGB before the amplifiers. At that point, they are voltages from 0 to some maximum, which can be mapped to the 0-255 range. Analog electronics have limits as well, and so do phosphors, they're just working well within the limits. I believe that later CRTs did some digital processing on the signal, so they may very well have digitized each component (R, G, B) into some number of bits. It would be indistingishable if they used enough bits. Also remember that the gamma-to-linear conversion occurs mostly at the phosphors, so the digitized version would have favorable non-linearity that gave more precision in darker tones where the eye is more sensitive to smaller differences.Drag wrote:It's only RGB that's limited to 0-255. CRT televisions don't operate on RGB, they operate on YIQ, which can produce colors that are WAY out of RGB range, and because this is analog electronics we're talking about, there's no problem with it. (Phosphors don't have limits like that; they just shine brighter and brighter the more energy you give to them)
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Emulator palettes vs real NTSC TVs
I always wondered the same thing too. Does a smaller colorburst make colors more saturated or less saturated?lidnariq wrote:Yes.Drag wrote:NTSC buffs, please help me with this one. I know that the hue of the picture is relative to the hue of the colorburst. Is the saturation of the colors relative to the amplitude of the colorburst too?
Re: Emulator palettes vs real NTSC TVs
A smaller colorburst would likely make the picture more saturated, because the saturation levels in the picture will look bigger when you compare them to the smaller colorburst amplitude.psycopathicteen wrote:Does a smaller colorburst make colors more saturated or less saturated?
So my next challenge is that I don't know what exact saturation the colorburst is supposed to represent. In my app, a "sat" of 1.0 is basically a color explosion at the moment, so I know that's not correct.
For now, I've updated the palette generator. Some of the new tweak settings are from suggestions. The hue was me, because even though a hue tweak of 0.0 should represent the exact hues being sent, it still doesn't look right unless I shift them by -0.15. Your mileage may vary.
A CRT TV technically has a "gam" of 2.2, and it does help a little bit for some of the darker colors, but it seems to mess everything else up right now. Meh.
Also, if anyone has a better suggestion for gamut mapping (converting the out-of-gamut colors to in-gamut colors), I'm open to suggestions.
Edit: If anyone's interested, this is what I've been using on my NES for comparison. It's based on the older PALTEST.NES demo floating around here, but I needed to have the colors all touching each other. I tried to minimize the flickering glitches as much as I could. No emphasis toggling support though, sorry.
Last edited by Drag on Mon Jan 07, 2013 10:12 pm, edited 1 time in total.
Re: Emulator palettes vs real NTSC TVs
Depends on the television.
The last DSP-based ones scaled luma by the size of the sync pulse (scaling the entire input such that sync-to-blank was 40IRE), separate out chroma, and scale that such that the colorburst is also 40IRE peak-to-peak.
I believe the older analog sets only scaled everything according to the sync pulse. (Since NTSC was amplitude modulated, some kind of compensation for the distance to the transmitter is needed).
Many sets don't do this scaling for composite input, however.
OTOH, the 2600 has two variants, one which transmits its colorburst at the same amplitude as the rest of the color, and the other which attenuates the amplitude for the colorburst (ties /BLANK to CHROMA through a 680Ω resistor); I don't recall people have mentioned variation of saturation between the CX2600 and the CX2600A or the various mods (which largely seem to ignore /BLANK).
The last DSP-based ones scaled luma by the size of the sync pulse (scaling the entire input such that sync-to-blank was 40IRE), separate out chroma, and scale that such that the colorburst is also 40IRE peak-to-peak.
I believe the older analog sets only scaled everything according to the sync pulse. (Since NTSC was amplitude modulated, some kind of compensation for the distance to the transmitter is needed).
Many sets don't do this scaling for composite input, however.
OTOH, the 2600 has two variants, one which transmits its colorburst at the same amplitude as the rest of the color, and the other which attenuates the amplitude for the colorburst (ties /BLANK to CHROMA through a 680Ω resistor); I don't recall people have mentioned variation of saturation between the CX2600 and the CX2600A or the various mods (which largely seem to ignore /BLANK).
Re: Emulator palettes vs real NTSC TVs
That could easily be because nobody noticed or cared about it. However, I haven't thrown out the possibility that the colorburst is mainly used for its phase and nothing else. If a picture is too saturated, you can just twist the saturation knob, so it's plausible.lidnariq wrote:OTOH, the 2600 has two variants, one which transmits its colorburst at the same amplitude as the rest of the color, and the other which attenuates the amplitude for the colorburst (ties /BLANK to CHROMA through a 680Ω resistor); I don't recall people have mentioned variation of saturation between the CX2600 and the CX2600A or the various mods (which largely seem to ignore /BLANK).
Re: Emulator palettes vs real NTSC TVs
Scaling the entire signal level by the sync pulse works well for RF because RF uses negative modulation, where sync is the highest signal level. Composite uses positive modulation, so it's less helpful there.
I too have been assuming that color burst is for phase.
I too have been assuming that color burst is for phase.
Re: Emulator palettes vs real NTSC TVs
I was using the R, G, and B primaries as defined by the FCC, but the FCC defines those primaries with a white point of C. I've been using a slightly different white point so that the gray colors looked correct, and not bluish.
If anyone is versed in the CIE color space: In order to use a different white point, can I move the R, G, and B primaries the same amount as I've moved the white point?
In other words: R' = (.67, .33), G' = (.21, .71), B' = (.14, .08), and the C white point is (.310, .316). If I use a white point of (.314, .330), and the difference between the two white points is (.004, .014), can I add (.004, .014) to my primaries to make: R' = (.674, .344), G' = (.214, .724), B' = (.144, .094)? Or is that an incorrect way to shift the white point?
If anyone is versed in the CIE color space: In order to use a different white point, can I move the R, G, and B primaries the same amount as I've moved the white point?
In other words: R' = (.67, .33), G' = (.21, .71), B' = (.14, .08), and the C white point is (.310, .316). If I use a white point of (.314, .330), and the difference between the two white points is (.004, .014), can I add (.004, .014) to my primaries to make: R' = (.674, .344), G' = (.214, .724), B' = (.144, .094)? Or is that an incorrect way to shift the white point?
Re: Emulator palettes vs real NTSC TVs
I can suggest for the emulator to have two modes:
- NTSC mode: Set up the conversion matrix and attenuation amount.
- RGB mode: Set up the 64-entry palette, tint mode, and extra dot mode.
(Free Hero Mesh - FOSS puzzle game engine)
Re: Emulator palettes vs real NTSC TVs
Nestopia still can make a more accurate palette than anything my own palette generator can produce.
I don't understand it; I have the three coordinates that represent the exact color a TV's red, green, and blue are. I just want to mix various combinations of various intensities of red, green, and blue. So, I'm mixing the colors in CIELuv space, which is supposed to represent the behavior of mixing differently-colored lights together (like on a CRT for example). I even tracked down the exact hue colorburst is supposed to be.
Why can't I make my palette generator produce the correct colors? Do I need better way to remap the out-of-range colors? What's so hard about this? This should be absolutely everything needed to make perfect NES palettes. :\
I don't understand it; I have the three coordinates that represent the exact color a TV's red, green, and blue are. I just want to mix various combinations of various intensities of red, green, and blue. So, I'm mixing the colors in CIELuv space, which is supposed to represent the behavior of mixing differently-colored lights together (like on a CRT for example). I even tracked down the exact hue colorburst is supposed to be.
Why can't I make my palette generator produce the correct colors? Do I need better way to remap the out-of-range colors? What's so hard about this? This should be absolutely everything needed to make perfect NES palettes. :\
Re: Emulator palettes vs real NTSC TVs
To address the out-of-gamut colors, I'm trying out using some rendering intents, and the first one I'm trying is absolute colorimetric.
So basically, the color's RGB is converted to CIEXYZ coordinates (X, Y, Z), and then converted to CIELuv coordinates (L, u, v).
I also have the CIExyY coordinates for the R, G, B primitives (the points on the XYZ graph which give you #FF0000, #00FF00, and #0000FF), which I've converted from xyY to XYZ and then to Luv.
That's as far as I've gotten. I don't know what I'm doing, and I can't find anything helpful from a google search. I don't know what kind of 3D shape the sRGB primaries make; in 2D, they make a triangle, but in 3D, do they linearly connect to the white and black points to make a diamond shape, or is it supposed to be rounder?
Ugh, I'm so confused. Whatever shape it makes, if the color is outside of that shape, then it's out of the sRGB range (meaning R, G, or B is <00 or >FF), and the color needs to be remapped so the point is inside of the shape. If I've interpreted correctly, absolute colorimetry means the out-of-range colors are just brought closer to the white point until they're on the edge of the sRGB's "shape", which means one or more channel is FF.
So basically, the color's RGB is converted to CIEXYZ coordinates (X, Y, Z), and then converted to CIELuv coordinates (L, u, v).
I also have the CIExyY coordinates for the R, G, B primitives (the points on the XYZ graph which give you #FF0000, #00FF00, and #0000FF), which I've converted from xyY to XYZ and then to Luv.
That's as far as I've gotten. I don't know what I'm doing, and I can't find anything helpful from a google search. I don't know what kind of 3D shape the sRGB primaries make; in 2D, they make a triangle, but in 3D, do they linearly connect to the white and black points to make a diamond shape, or is it supposed to be rounder?
Ugh, I'm so confused. Whatever shape it makes, if the color is outside of that shape, then it's out of the sRGB range (meaning R, G, or B is <00 or >FF), and the color needs to be remapped so the point is inside of the shape. If I've interpreted correctly, absolute colorimetry means the out-of-range colors are just brought closer to the white point until they're on the edge of the sRGB's "shape", which means one or more channel is FF.
Re: Emulator palettes vs real NTSC TVs
Not sure if I can help you with the color science stuff yet, but I did have a question. How did you determine that NES uses Y'IQ colorspace instead of Y'UV? To the best of my knowledge, Y'IQ hasn't been used since the 1970s due to decoder cost. And I think you had the in-phase and quadrature-phase components backwards on page 2. Composite color for Y'IQ should be:
C = Q∙sin(ωt + 33°) + I∙cos(ωt + 33°)
For Y'UV:
C = U∙sin(ωt) + V∙cos(ωt)
For Both:
ω = 2π∙fsc
fsc = 315/88 MHz
Colorburst = A∙sin(ωt ± 180°) = -A∙sin(ωt)
A = 20 IRE = 142.8mV
C = Q∙sin(ωt + 33°) + I∙cos(ωt + 33°)
For Y'UV:
C = U∙sin(ωt) + V∙cos(ωt)
For Both:
ω = 2π∙fsc
fsc = 315/88 MHz
Colorburst = A∙sin(ωt ± 180°) = -A∙sin(ωt)
A = 20 IRE = 142.8mV
Re: Emulator palettes vs real NTSC TVs
What does it mean to say that something "uses" a particular color space? The NES merely has particular waveforms that it outputs in response to palette indicies. These consist of either constant amplitude or a square wave of a particular phase between two amplitudes. Game programmers choose indicies based on what colors appear on a TV. They don't choose based on describing the NES circuitry as "thinking" of a particular color in a particular encoding space, outputting the proper phase of wave for it, then the TV decoding the phase and interpreting that as "asking" for a particular color, then converting that to RGB and displaying it.
Re: Emulator palettes vs real NTSC TVs
In that case, the NES "uses" the color space of the TVs with which the artists tested their palette choices. So if we're emulating a TV, we have to know the color space of that TV.