It is currently Wed Oct 18, 2017 5:22 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 71 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Mon Dec 17, 2012 1:15 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Quote:
the NTSC NES runs on the YIQ color space, and most computers I know of use RGB. YIQ is capable of generating colors that cannot be reproduced with RGB, and indeed, the blues and purples of the NES are out of gamut.

...but TVs convert everything to RGB for the electron guns, so a computer can reproduce that aspect.

Reasons for inability to reproduce that come to mind:
  • People remember the colors different than they were
  • Different TVs produced different colors
  • The colors depend on horizontally-adjacent colors, not just the pixel's palette index.


Top
 Profile  
 
PostPosted: Mon Dec 17, 2012 1:29 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
TVs do convert to RGB, but given the analog nature of the electronics used, the values don't need to be clamped to 100%. You can't output a blue that's less than 0, but you can output a blue that's greater than 255, and that's what happens on my TV, at least.

When I plug my NES into my LCD TV (where the RGB channels do need to be finite), the palette gets really ugly clamping, especially on the out-of-gamut colors, such as $22, $13, and $23. (if I recall correctly)


Top
 Profile  
 
PostPosted: Mon Dec 17, 2012 1:42 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19097
Location: NE Indiana, USA (NTSC)
Then it should be possible to make a palette where white is something less than 255, to give a bit of headroom for out-of-gamut blues.


Top
 Profile  
 
PostPosted: Mon Dec 17, 2012 3:03 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
I'm pretty sure that I have the NES NTSC filter do this, so that white isn't 1.0, since some of the blues go beyond that. In other words, if an RGB TV can do it, so can an emulator.


Top
 Profile  
 
PostPosted: Mon Dec 17, 2012 10:25 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
tepples wrote:
Then it should be possible to make a palette where white is something less than 255, to give a bit of headroom for out-of-gamut blues.

I tried it, the palette comes out uncomfortably dark (or uncomfortably desaturated). I tried a couple of methods to clip the OOG colors. One was a hue-preserving clip (if B is clipped but R and G are left alone, then the hue shifts), but the color lost its brilliance. I'd have to set this simulation back up to remember exactly what happened, but it definitely looked a lot better than just a simple RGB clip, even if the saturation was wrong. I tried a hue and saturation preserving clip, and the color kept its brilliance, but the luminance was obviously wrong compared to the rest of the colors.

No matter what I did, I couldn't get the palette to look "right" unless I cranked the generator's brightness way down, which would require me cranking my display's brightness up to cancel it out. This is basically the same as displaying a color that is brighter than 1.0, which gave me the idea that I'd never be able to attain the exact palette I want, unless LCD technology changed somehow.

Then again, maybe I think it's impossible because I was completely alone when trying to solve this.


Top
 Profile  
 
PostPosted: Sun Dec 23, 2012 8:14 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 919
Drag wrote:
On the subject of emulator palettes vs real palettes:
Forget it. A 100% accurate reproduction of the NTSC NES's palette is impossible because the NTSC NES runs on the YIQ color space, and most computers I know of use RGB. YIQ is capable of generating colors that cannot be reproduced with RGB, and indeed, the blues and purples of the NES are out of gamut.
I intend one day when I build some computer, its NES/Famicom emulator will have a mode to output the NTSC signal directly, to result in a 100% accurate colors (and to emulate RGB Famicom when making RGB output signal). I don't know when. But, you can do the same thing in any emulators you make, if you are able to make it to output NTSC signals! But the other idea is to make the emulator to have a RGB emulation mode, using RGB palette and timing and so on (I think there is one extra dot, or one dot missing or something like that?), which could be written the game to detect NTSC/PAL/RGB/Dendy mode.

_________________
.


Top
 Profile  
 
PostPosted: Sat Dec 29, 2012 12:18 am 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
I took another stab at a palette generator.

Yes, I know, there's a dozen of these already. However, I'm taking a different approach, and I'm converting YIQ to various CIE color spaces (using the physical red, green, and blue as defined by the NTSC specification), and coverting from CIE to RGB. When I say I want a palette that looks like my TV, I'm being absolutely serious, and I'm doing all I can to figure out how to correctly simulate a CRT's colors. The only issue is that sRGB's gamut is absolutely piss-poor by comparison, since a lot of colors wind up out of range unless you drop the saturation or contrast down.

Also, if you view source, please excuse how sloppy my coding was. :S


Top
 Profile  
 
PostPosted: Sat Dec 29, 2012 12:33 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
You're saying that the gamut of a device that merely has a brighter picture is wider? I think you might be saying that if you treat 1.0,1.0,1.0 as white in sRGB, you get a poorer gamut than if you treat say 0.5,0.5,0.5 as white. A TV basically does the latter it seems you're saying, so that it can do super-saturated colors, but also compensates by making the screen really bright so that 0.5 white appears bright. But everything in the sRGB world treats 1,1,1 as white, so you can't just crank up your monitor's brightness and use 0.5,0.5,0.5 as white, since nothing else will and thus the screen will blind you, save for your emulator. Throw in scanline emulation and you darken the picture more, prompting even more need to crank up the monitor's brightness.


Top
 Profile  
 
PostPosted: Sat Dec 29, 2012 6:15 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19097
Location: NE Indiana, USA (NTSC)
There is a scanline emulation algorithm that doesn't darken as much, which involves a form of bloom. I can explain more later. But I do remember the Dreamcast's license screen using 0.75,0.75,0.75 for white.


Top
 Profile  
 
PostPosted: Sun Jan 06, 2013 4:37 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
So my current project is to try to simulate the three colored phosphors in CIELuv. The FCC specification specifies three coordinates on the CIE color space. Red, green, and blue are defined as (.67, .33), (.21, .71), and (.14, .08).

I chose CIELuv because I read somewhere that CIELab is geared more towards colored surfaces and dyes, and CIELuv is a better approximation of colored lights specifically (i.e., CRT displays).

I've converted the R, G, and B points (called "primaries") to their CIELuv equivalents. What I do is I convert YIQ to RGB, and then starting at the white point (FCC defines it as C, (.3101, .3161), but SMPTE defines it as D65 (.3127, .3290)), I treat the primaries as vectors that radiate from the white point, and I use R, G, and B from YIQ->RGB as magnitudes for the vectors. The resulting point is the color I need, but this is where I get stuck.

I was translating the result point back into CIEXYZ, and then converting XYZ -> outputRGB (where outputRGB is the color being sent to the screen), and this gave me some pretty nifty results (you can see it in the HTML5 app I made), but this creates some problems.

The main one: I need to be able to apply gamma curves to R, G, and B. If I apply it to outputRGB's R, G, and B, I get an approximation, but it isn't exactly "correct", because what I should be doing is applying the gamma curve to the "simulated" R, G, and B before converting it to outputRGB. I can't apply the curves to YIQ->RGB's R, G, and B, because those represent the difference between white and color, so instead of the individual channels getting darker, they just become unsaturated, and that's not correct.

Another observation I've made; it seems that the NES's palette is hue-shifted. If I just use a raw YIQ->RGB conversion, the hues are off by a little bit. Color x8 indeed has the colorburst hue, but on my television, it's yellow-orange instead. Indeed, other colors end up wrong too, but by shifting the hues over just a fraction, everything looks correct again. Why? I don't know. Maybe televisions shift the hues themselves, maybe the NES somehow shifts the colorburst phase by a fraction of a clock (unlikely).

Finally, most of the NES's colors are out of the sRGB gamut used by computers. I'm unsure of a good method to perform gamut-mapping; what I do right now is I desaturate the color until its R, G, and B components are all in range, and although the luminance is correct, the color itself ends up washed out.

I doubt anyone here knows about anything I've just said, but if anyone else is more familiar with gamuts, and color spaces, and all sorts of this stuff, I would really appreciate your input.


Top
 Profile  
 
PostPosted: Sun Jan 06, 2013 6:27 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
blargg wrote:
Reasons for inability to reproduce that come to mind:
  • People remember the colors different than they were
  • Different TVs produced different colors
  • The colors depend on horizontally-adjacent colors, not just the pixel's palette index.

Also different board revisions potentially generate different amounts of noise in the output signal?

tepples wrote:
Then it should be possible to make a palette where white is something less than 255, to give a bit of headroom for out-of-gamut blues.

Supposedly in NTSC black should be 16 and white should be 235. No idea from where the hell this comes (blacker than black and whiter than white are used for blanking signals but no sane video encoder should allow those for normal colors for starters), but that's the gist of it.


Top
 Profile  
 
PostPosted: Sun Jan 06, 2013 6:36 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6277
Location: Seattle
Sik wrote:
Supposedly in NTSC black should be 16 and white should be 235. No idea from where the hell this comes (blacker than black and whiter than white are used for blanking signals but no sane video encoder should allow those for normal colors for starters), but that's the gist of it.

Well, http://en.wikipedia.org/wiki/YCbCr, for starters; neither values of 16 nor 235 are far enough away from 0 and 255 to be able to also encode sync nor Y+C (140IRE) in band.


Top
 Profile  
 
PostPosted: Sun Jan 06, 2013 6:39 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
Different TVs produce different colors, yes. However, they all seem to consistently render color x8 as yellow-orange, and not as a sickly green-yellow. HDTVs are the only TVs I've seen that render color x8 as something other than yellow.

The out-of-gamut blues are extremely out of gamut. As in, white needs to almost be 150 before the blues are completely in-gamut. I mean, if you don't mind having a palette that dark, go ahead and knock yourself out.


Top
 Profile  
 
PostPosted: Mon Jan 07, 2013 9:10 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Drag wrote:
Different TVs produce different colors, yes. However, they all seem to consistently render color x8 as yellow-orange, and not as a sickly green-yellow. HDTVs are the only TVs I've seen that render color x8 as something other than yellow.

I had a TV that could render yellow as green. You had to mess with the hue setting, though. I wouldn't be surprised if HDTVs screw up at the hue values...

Drag wrote:
The out-of-gamut blues are extremely out of gamut. As in, white needs to almost be 150 before the blues are completely in-gamut. I mean, if you don't mind having a palette that dark, go ahead and knock yourself out.

How the hell did that even work? o_O


Top
 Profile  
 
PostPosted: Mon Jan 07, 2013 4:30 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
Sik wrote:
Drag wrote:
The out-of-gamut blues are extremely out of gamut. As in, white needs to almost be 150 before the blues are completely in-gamut. I mean, if you don't mind having a palette that dark, go ahead and knock yourself out.

How the hell did that even work? o_O

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)

So far, I've been treating YIQ like a color wheel, because that's basically what it is. I = sin(hue), Q = cos(hue). So, I figured out which "angle" is supposed to be colorburst, and lo and behold, if you do a simple YIQ->RGB conversion, you get that pale green color I keep talking about. However, if you do YIQ->CIELuv->RGB, you get yellow. So I'm not crazy, maybe the NES actually does output a pale green color for color 8, and it's just the physics of colored lights mixing together (or the definition of the NTSC color primaries) that turns it into yellow.

So I set color x8 as colorburst, and computed the rest of the hues from there. I haven't uploaded my latest version of the app yet, but I believe the hue setting should be spot on now.

--------------------------------------------------

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?

---------------------------------------------------

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?

What happens if the colorburst has a DC offset? Does that have any effect on the colors? I hypothesized that a positive DC offset on the colorburst would lighten the colors near the colorburst hue, and darken the colors near its complement, however I don't know if this actually happens.

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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 71 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group