It is currently Tue Oct 17, 2017 6:32 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 31 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject:
PostPosted: Mon Jun 27, 2005 7:41 am 
Sorry, that last post was me.


Top
  
 
 Post subject:
PostPosted: Mon Jun 27, 2005 3:31 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
If you do not emulate "artifact colors", then the bricks in underground levels of Super Mario Bros. won't look like those on real NES hardware. Instead, they might look like the bricks on a VS Unisystem or a PlayChoice 10.

And they won't shimmer when you scroll the screen (bothersome or not, it was part of the NES experience). I take it Nintendo's arcade boxes used RGB (why use lossy modulation schemes when you can just send the color components directly to the CRT?).


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jun 27, 2005 8:18 pm 
blargg wrote:
I take it Nintendo's arcade boxes used RGB (why use lossy modulation schemes when you can just send the color components directly to the CRT?).


Yes, NES-based arcade hardware generated RGB from a palette stored in a PROM, like typical arcade video hardware of the time (more modern arcade hardware has fully software-defined palettes, like a SNES or a PC's VGA card). The only unusual thing about Nintendo's arcade hardware was that the color PROM was embedded right in the PPU rather than being on a separate chip; games with different palettes used different PPU models. This may have been intended as a form of copy protection.


Top
  
 
 Post subject:
PostPosted: Wed Jun 29, 2005 11:50 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 283
tepples wrote:
If you do not emulate "artifact colors", then the bricks in underground levels of Super Mario Bros. won't look like those on real NES hardware. Instead, they might look like the bricks on a VS Unisystem or a PlayChoice 10.


The NES does not use "artifact colors", period. Forget about them, they only apply to the Apple ][ and the CGA 160x200 composite color mode. It doesn't apply the NES simply because the NES generates colors differently. The word "artifact colors" has a specific meaning which does not apply to the NES PPU.

What you're describing is the result of the fact that the PPU generates the luminance and the chrominance portion of the video signal in the same process and that it generates square waves instead of sine waves --- it has nothing to do with "artifact colors". The "shimmering" by the way only occurs in the NTSC PPU, the PAL PPU has constant "jagginess".

I don't even know whether that's worth emulating --- after all, it doesn't affect the COLOR of a pixel, only the placement.

Quote:
NES-based arcade hardware generated RGB from a palette stored in a PROM,


Right, but keep in mind that the palette found in RGB PPUs is not accurate in that it would correctly represent what NES games should look like --- several PlayChoice 10 games (Volleyball, Punch-Out) actually had their color values changed in the game code from their regular cartridge versions to look better on the PC10 PPU.

Quote:
That would mean that the lightest row of non-gray colors is approximately half as saturated as the other three rows.


It is true that x1-xc colors oscillate between the x0 and xd values, HOWEVER that information is only relevant when you're dealing in voltage levels --- it's unusable if you're trying to deduce saturations from a "TV-captured" palette, because there is not a set of x0/xd values that is not clipped --- for 0x and 1x, the d color is clipped at zero; for 2x and 3x, the 0 color is clipped at 255 (or 1.0, whatever your notation is).
Chances are that the 3x colors are just as saturated as the rest (level-wise), but appear less saturated because most TVs "hard clip" the input signal at 120 IRE, thus reducing modulation and therefore, saturation.

Quote:
Can you provide more details as to how US and Japanese sets differ from each other and from the NTSC specification, or does it vary from manufacturer to manufacturer?


The coefficients indeed differ from manufacturer to manufacturer and from model to model, but the algorithms are more-or-less the same. For example, a given US TV set might use a color decoder with the following characteristics (taken from a Sony service manual):

R-Y: 112° ´ 0.83, G-Y: 252° ´ 0.3 (B-Y: 0° ´ 1)

This would translate into the following decoder matrix:
R = Y + 1.539*V - 0.622*U
G = Y - 0.571*V - 0.185*U
B = Y + 0.000*V + 2.000*U

This matrix represents a typical "red boost", supposedly making flesh tones more "natural" on 9300K phosphors (manufacturers use 9300K phosphors because they look "brighter" than the 6500K that the standard calls for). Looks a little like Chris Covell's old captured palette.

Again, other sets might use different coefficients, but the algorithm is basically the same, at least for US sets.

Japanese TV sets are a different story, because Asian fleshtones are different; instead of a "red boost", you have a "yellow boost". Basically, "Yellowness" is (I-Q), so, to boost yellows, you'd do something like this:
Yellowness = (I-Q);
if (Yellowness > 0) {
I = I + Yellowness*factor;
Q = Q - Yellowness*factor;
}
"factor" would of course be < 1. The decoding matrix would be more-or-less like the above with a little less gain in the red channel, I suppose.

Only as a general idea though, I don't know the exact coefficients for any given set because newer Japanese TVs (to whose service manuals I have access) don't use "yellow boost" anymore because everyone over there uses Digital TV now and thus these "picture improvement" features have become obsolete. Consequently, the matrices listed in today's Japanese TV's service manuals are basically like the same as the NTSC standard's.

Anyway, maybe you'd like to see my calculated "Japanese" palettes, which I like very much and match those old Japanese TVs I've seen:
http://www.lau-net.de/~nl2305/6500K.pal
http://www.lau-net.de/~nl2305/9300K.pal

Use the first one if your PC monitor is set to 6500K (it usually is if you've calibrated your monitor for photoshop) --- it will simulate the blueish picture of a 9300K monitor; if your PC monitor is set to 9300K (which most monitors are factory-setting-wise), use the second one, it's like the "raw output". Make sure you're getting the right one for accuracy --- if you use the 6500K.pal on a 9300K monitor, it'll look way too blue; if you use the 9300K.pal on a 6500K monitor, it'll look too yellowish. :)
Notice how the yellow boost that is applied in these palettes makes SMB3's color combinations of 0x27 and 0x36 actually look sensible, or likewise 0x29 and 0x38 in Ice Climber and others.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 29, 2005 1:43 pm 
NewRisingSun wrote:
It is true that x1-xc colors oscillate between the x0 and xd values, HOWEVER that information is only relevant when you're dealing in voltage levels --- it's unusable if you're trying to deduce saturations from a "TV-captured" palette, because there is not a set of x0/xd values that is not clipped --- for 0x and 1x, the d color is clipped at zero; for 2x and 3x, the 0 color is clipped at 255 (or 1.0, whatever your notation is).
Chances are that the 3x colors are just as saturated as the rest (level-wise), but appear less saturated because most TVs "hard clip" the input signal at 120 IRE, thus reducing modulation and therefore, saturation.


So, can someone use a scope and get the actual voltage levels for all the x0 and xD colors?

NewRisingSun wrote:
The coefficients indeed differ from manufacturer to manufacturer and from model to model, but the algorithms are more-or-less the same. For example, a given US TV set might use a color decoder with the following characteristics (taken from a Sony service manual):

R-Y: 112° x 0.83, G-Y: 252° x 0.3 (B-Y: 0° x 1)

This would translate into the following decoder matrix:
R = Y + 1.539*V - 0.622*U
G = Y - 0.571*V - 0.185*U
B = Y + 0.000*V + 2.000*U


Hmm, it looks like I misunderstood what those angles meant. I assumed that 112° and 252° were the angles of the hues that decoded to pure red (R > G = B) and pure green (G > R = B) relative to the hue that decoded to pure blue (B > R = G) For a standard NTSC decoder, the angles of the pure primary colors from the Q axis are:

R = tan-1[(-0.647 - 1.703)/(-1.106 + 0.272)] = 70.5°
G = tan-1[( 0.621 - 1.703)/(-1.106 - 0.956)] = 207.7°
B = tan-1[( 0.621 + 0.647)/(-0.272 - 0.956)] = -45.9°

The angle between red and blue is 116.4° and the angle between green and blue is 253.6°, which are very close to the angles given in the Sony datasheet, so you can see why I thought along these lines.

Previously you referred to I and Q being 105°-120° apart on Japanese decoders, but now you're talking in terms of U and V. Could you clarify what you meant earlier in reference to Japanese equipment?

NewRisingSun wrote:
Anyway, maybe you'd like to see my calculated "Japanese" palettes, which I like very much and match those old Japanese TVs I've seen:
http://www.lau-net.de/~nl2305/6500K.pal
http://www.lau-net.de/~nl2305/9300K.pal


I think I'd rather see the algorithm you used to create those palettes. What I'm really interested in is not creating a single "perfect" NES palette, but an algorithm with parameters which can be tweaked to simulate the colors produced on a variety of displays. This algorithm could be used in emulators of other

Before I forget, I had one question about the PAL version of the NES. Since PAL uses YUV instead of YIQ, are the hues on a PAL PPU "rotated" one step compared to a NTSC PPU? I've never seen a PAL NES in operation, but the "PAL palettes" for emulators I've seen (such as the one hardcoded into FCEUltra) all make hue x8 orange-yellow, not green-yellow.


Top
  
 
 Post subject:
PostPosted: Wed Jun 29, 2005 1:49 pm 
This time not only did I forget my name, I left a sentence unfinished. What I meant to say in the second-last paragraph was "This algorithm could be used for emulation of other composite video hardware similar to the NES PPU in the way they produced colors, such as the Atari TIA family and the Commodore VIC, VIC II and TED (used in the VIC20, C64/C128 and Plus4/C16 respectively)


Top
  
 
 Post subject:
PostPosted: Wed Jun 29, 2005 3:31 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 283
Quote:
For a standard NTSC decoder, the angles of the pure primary colors from the Q axis are:


Nonono, that's completely wrong. If you want to convert RGB values to NTSC and back, you need to use the proper matrices. Trigonometry alone won't get you anywhere until you're using the proper scale factors.
See http://wwwzenger.informatik.tu-muenchen ... COL_29.htm

Quote:
Previously you referred to I and Q being 105°-120° apart on Japanese decoders, but now you're talking in terms of U and V. Could you clarify what you meant earlier in reference to Japanese equipment?


It's just different ways of talking about the same thing:
V = 0.877*(R-Y)
U = 0.493*(B-Y)
I = V plus 33 degrees
Q = U plus 33 degrees.

R-Y is at 90 degrees, as is V.
B-Y is at 0 degrees, as is U.
I is at 123 degrees.
Q is at 33 degrees.

You can decode the same signal either using I and Q, or U and V; the result is the same except that the hue offset is different, which is okay since all NTSC decoders have a hue control anyway.
I and Q, as well as U and V, are 90° apart in standard; they are further apart (up to 120°) in common implementations.

Quote:
Since PAL uses YUV instead of YIQ, are the hues on a PAL PPU "rotated" one step compared to a NTSC PPU?


The PAL NES creates hues that are rotated half a step (15°) vs. the NTSC PPU, making color x8 look like SMPTE yellow (R=G). Forget about "hard-coded" palettes, they're based on what emulator authors think "looks good". Yes, the PAL NES actually creates different colors than the NTSC NES.

Quote:
I think I'd rather see the algorithm you used to create those palettes.


Well, what did I just post before, about "Yellowness" and such... :roll:

Quote:
This algorithm could be used for emulation of other composite video hardware similar to the NES PPU in the way they produced colors, such as the Atari TIA family and the Commodore VIC, VIC II and TED (used in the VIC20, C64/C128 and Plus4/C16 respectively


Well, these are American machines, so try the US decoder matrix I gave you. You can also convert SNES RGB values to YUV using the standard encoder matrix and back to RGB using the "Sony US TV" decoder matrix if you're in the mood. :)


Last edited by NewRisingSun on Wed Jun 29, 2005 10:53 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 29, 2005 9:23 pm 
NewRisingSun wrote:
Quote:
For a standard NTSC decoder, the angles of the pure primary colors from the Q axis are:


Nonono, that's completely wrong. If you want to convert RGB values to NTSC and back, you need to use the proper matrices. Trigonometry alone won't get you anywhere until you're using the proper scale factors.
See http://wwwzenger.informatik.tu-muenchen ... COL_29.htm


I think you misunderstood what I was doing. I was using the "proper" matrix:

Code:
[ R ]   [ 1  0.956  0.621 ][ Y ]
[ G ] = [ 1 -0.272 -0.647 ][ I ]
[ B ]   [ 1 -1.106  1.703 ][ Q ]


What I was doing was inverting this matrix to find the NTSC hues of SMPTE red, SMPTE green and SMPTE blue. An equivalent (and simpler) way of doing it would have been to start with the inverse matrix:

Code:
[ Y ]   [ 0.299  0.587  0.114 ][ R ]
[ I ] = [ 0.596 -0.274 -0.322 ][ G ]
[ Q ]   [ 0.211 -0.523  0.312 ][ B ]


and just plug in RGB triplets of (1, 0, 0), (0, 1, 0) and (0, 0, 1) (Yes, I know these are too saturated to be legal NTSC colors, but the math is simplest this way...)

Doing this I get:

RGB(1, 0, 0) = YIQ(0.299, 0.596, 0.211)
hue = tan-1(0.596 / 0.211) = 70.5°

RGB(0, 1, 0) = YIQ(0.587, -0.274, 0.523)
hue = tan-1(-0.274 / -0.523) = 207.7°

RGB(0, 0, 1) = YIQ(0.114, -0.322, 0.312)
hue = tan-1(-0.322 / 0.312) = -45.9°

...which are exactly the same hues as I got by inverting the YIQ-to-RGB matrix (as expected).

Since you've made it clear that this isn't what those numbers mean in the first place, this discussion is probably meaningless.

By the way, the RGB-to-YIQ matrix on that page you linked to has a couple of the signs backwards.

NewRisingSun wrote:
Quote:
Previously you referred to I and Q being 105°-120° apart on Japanese decoders, but now you're talking in terms of U and V. Could you clarify what you meant earlier in reference to Japanese equipment?


It's just different ways of talking about the same thing:


Yes, I already know what the relationship between I/Q and U/V is. Sorry, I understand what you meant now.

NewRisingSun wrote:
Quote:
Since PAL uses YUV instead of YIQ, are the hues on a PAL PPU "rotated" one step compared to a NTSC PPU?


The PAL NES creates hues that are rotated half a step (15°) vs. the NTSC PPU, making color x8 look like SMPTE yellow (R=G). Forget about "hard-coded" palettes, they're based on what emulator authors think "looks good". Yes, the PAL NES actually creates different colors than the NTSC NES.


I suspected such, but every NES dever I asked insisted that NTSC and PAL units produced the exact same colors. Thanks for the confirmation.


Top
  
 
 Post subject:
PostPosted: Wed Jun 29, 2005 10:44 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 283
Quote:
(Yes, I know these are too saturated to be legal NTSC colors, but the math is simplest this way...)


Both 100% red and 100% blue are completly legal NTSC colors, in fact, the 0.877 and 0.493 coeffecients were deliberately chosen so that 100% red and 100% blue, which do occur in nature, WOULD be legal. 100% yellow is "illegal" in NTSC because the upper peak of the modulation exceeds 120 IRE (reaches about 133 IRE).
By the way, there's one more systematic difference between Japanese and "real" (American) NTSC: the NTSC standard calls for a 7.5% setup, Japanese devices however use 0%. I think you can even select between these two on some camcorders...

Quote:
Since you've made it clear that this isn't what those numbers mean in the first place, this discussion is probably meaningless.


Your equations would be right if it was about the R axis, not the R-Y axis... :)

Quote:
By the way, the RGB-to-YIQ matrix on that page you linked to has a couple of the signs backwards.


Right, I've been meaning to email the author of those pages a couple of times, but always forgot... :)

Quote:
I suspected such, but every NES dever I asked insisted that NTSC and PAL units produced the exact same colors. Thanks for the confirmation.


I must say though that I have never seen an American NES unit in operation, I have only seen a PAL NES as well as Japanese Famicoms, Twin Famicoms and AV Famicoms; so MAYBE the American NES produces hues like the PAL NES, though I think that's extremely unlikely, as the PPU is the same.

By the way, you wrote that you'd like to emulate the output for a variety of displays; that would mean you'd also have to adjust to different phosphor types, effectively necessitating complete color management, Photoshop-like. Basically what you'd want is a general conversion algorithm for RGB values between sets of given phosphor chromaticities. I've written a couple of C code lines for this, tell me if you need anything. :)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 30, 2005 10:40 am 
NewRisingSun wrote:
Both 100% red and 100% blue are completly legal NTSC colors, in fact, the 0.877 and 0.493 coeffecients were deliberately chosen so that 100% red and 100% blue, which do occur in nature, WOULD be legal. 100% yellow is "illegal" in NTSC because the upper peak of the modulation exceeds 120 IRE (reaches about 133 IRE).
By the way, there's one more systematic difference between Japanese and "real" (American) NTSC: the NTSC standard calls for a 7.5% setup, Japanese devices however use 0%. I think you can even select between these two on some camcorders...


Yeah, I remember reading somewhere about the difference in black levels between standard NTSC and "NTSC-J".

I was wondering a while ago exactly where the 0.877 and 0.493 coefficients in the YUV matrix came from. I was able to work out that their ratio determined the angle of G-Y, and presumably was chosen so that G-Y would be more or less equidistant from R-Y and B-Y (it's actually just a bit closer to B-Y)

NewRisingSun wrote:
By the way, you wrote that you'd like to emulate the output for a variety of displays; that would mean you'd also have to adjust to different phosphor types, effectively necessitating complete color management, Photoshop-like. Basically what you'd want is a general conversion algorithm for RGB values between sets of given phosphor chromaticities. I've written a couple of C code lines for this, tell me if you need anything.


It would be great if you could point me to a general formula for converting between color temperatures. The page you linked to has the following matrices for converting between NTSC and EBU (=PAL?) colors:

Code:
[Rntsc]   [0.6984  0.2388  0.0319][Rebu]
[Gntsc] = [0.0193  1.0727 -0.0596][Gebu]
[Bntsc]   [0.0169  0.0525  0.8450][Bebu]


[Rebu]   [ 1.4425 -0.3173 -0.0769][Rntsc]
[Gebu] = [-0.0275  0.9350  0.0670][Gntsc]
[Bebu]   [-0.0272 -0.0518  1.1081][Bntsc]


Are these color temperature conversions, or something else? (And are they even correct, or are some of the signs reversed again?) The page mentions that NTSC and EBU have different "white points", which I understand is related to color temperature (but am likely completely wrong)

As you've probably guessed by now, my knowledge of this stuff is pretty fragmentary and mostly gleaned from a lot of Googling and doing math by hand. My background is in biology, not color science...


Top
  
 
 Post subject:
PostPosted: Thu Jun 30, 2005 11:40 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 283
AWJ wrote:
I was wondering a while ago exactly where the 0.877 and 0.493 coefficients in the YUV matrix came from.


Well, the low peak of the video signal must not go below a level of -0.33:
Luma - Chroma > -0.33

The nature of quadrature modulation means we can write it like this:
Y - sqrt (V² + U²) > -0.33

For R=1.0 or B=1.0, this would be violated if we just used V=R-Y and U=B-Y. Therefore, we need to scale them in such a way that R=1.0 and B=1.0 are just within range.
Let coR, coG, coB be given (they'd be 0.299, 0.587 and 0.114 in current implementations), and scR, scB the scale factors for R-Y,B-Y that we're looking for. The following must be fulfilled simultaneously (sorry, don't know how to do this in HTML):

Image

The first line is for R=1.0, which means Y=coR, R-Y=1-coR, B-Y=0-coR. The second line is for B=1.0, you get the idea.
Have a lot of fun working out the scale factors from that. :D

Quote:
It would be great if you could point me to a general formula for converting between color temperatures. The page you linked to has the following matrices for converting between NTSC and EBU (=PAL?) colors:


The general algorithm would be to convert from (linear!) RGB values for the source phosphor to CIE XYZ values, and then from those to linear RGB values for the target phosphor. Setting up RGB<->XYZ matrices from a given set of chromaticities is somewhat involved and best shown using C code, not a formula.

Quote:
Are these color temperature conversions, or something else? (And are they even correct, or are some of the signs reversed again?) The page mentions that NTSC and EBU have different "white points", which I understand is related to color temperature (but am likely completely wrong)


Color temperature means white point. These equations are basically right, however meaningless since those "NTSC primaries" this page and other people keep talking about are completely obsolete (no real non-ancient NTSC TV uses them); unless you're trying to emulate the look of a 1954 RCA CT-100 TV set, you'd use "real world" primaries from actual monitor profiles, not these theoretical NTSC/SMPTE-C/EBU values.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 30, 2005 6:13 pm 
I've been trying to come up with a NES palette of my own for the longest time. I tried using the vid capture method to grab colors (or more than one card) but the results of that are way off. I'd tried Kevin Horton's generator but could never get satisfactory results. I just found your (AWJ) method a few days ago, and it's better than Kevin's but still doesn't do it for me :P

What I ended up doing a while back is color calibrating my TV and monitor as best I could and just winging my own pallete by eyeballing it from the NES playing on the TV. I'm still not %100 pleased with it, but I think it's pretty good. Like NewRisingSun said, I don't think there is a perfect hard coded palette.

My results from my palette are interesting though, the hue shifts are quite uneven and so is the saturation, but to a lesser extent. I also noticed there is quite a difference between the color from RF output and composite output. The composite colors seem to be distributed better than RF (no surprise) but I actually found the RF colors to be more fitting and pleasing to the eye in most cases. BTW, I'm using an NTSC TV/NES.

I am very interested in what you guys come up with here :)


NewRisingSun, this is a somewhat strange question, but it seems you may know or be able to find this out. The TV I'm using for my NES and other older consoles is a 27" RCA model# 27F630T. I'm wondering if you know how to enter the service mode on this? I've looked elsewhere on the net but have never found a combo that works. My screen geometry is messed up, it's rotated I would guess about 5 - 10 degrees. Very apparent with computer generated images.


Top
  
 
 Post subject:
PostPosted: Fri Jul 01, 2005 1:00 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 283
I don't know anything about current RCA sets --- they're not even sold here in Europe.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 01, 2005 5:42 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19085
Location: NE Indiana, USA (NTSC)
NewRisingSun wrote:
I don't know anything about current RCA sets --- they're not even sold here in Europe.

Are there any sets sold under the name THOMSON? Those are made by the same company as current RCA or current GE sets.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 02, 2005 7:05 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
NewRisingSun wrote:
R-Y: 112° ´ 0.83, G-Y: 252° ´ 0.3 (B-Y: 0° ´ 1)

This would translate into the following decoder matrix:
R = Y + 1.539*V - 0.622*U
G = Y - 0.571*V - 0.185*U
B = Y + 0.000*V + 2.000*U


How did you get those values from those angles ? When I don't understand something, I just do trial-and-error, and the only one I could find was tan(252)/2=1.539


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 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