nesdev.com
http://forums.nesdev.com/

Palettes
http://forums.nesdev.com/viewtopic.php?f=21&t=12143
Page 4 of 5

Author:  Sik [ Sat Dec 20, 2014 1:03 pm ]
Post subject:  Re: Palettes

Regarding colors being off: welcome to the main reason why so many people hate NTSC. This is why NTSC TVs have a hue setting, which can change the colors completely. The saturation setting tends to be just as bad about this as well. For example, another color that tends to be dangerous is magenta, since it has a tendency to turn red.

Trying to account for different TVs is futile, they're all just way too different (especially for NTSC).

Author:  psycopathicteen [ Sat Dec 20, 2014 1:06 pm ]
Post subject:  Re: Palettes

Maybe luminance should be calculated based on the 3D distance from black on the RGB color cube, instead of a linear matrix.

Y = sqrt( .299*R^2 + .587*G^2 + .114B^2 )

Author:  Drag [ Sat Dec 20, 2014 2:02 pm ]
Post subject:  Re: Palettes

I actually really like the NES's palette because it's YIQ/YUV based. Trying to pick colors using raw RGB is harder because the luminance varies greatly depending on the hue, which is a problem if, for example, you're trying to make differently colored blocks all have the same relative lightness/brightness, especially if you're working with a very low resolution RGB, like RGB222.

Also, on a CRT, SMB's sky color looks like an extremely vibrant blue, not like the washed-out purplish blue a lot of emulators seem to give it. I like using hue C for stylistic purposes, but I go with other shades of blue if it clashes too much with the rest of the objects in the scene.

Author:  tepples [ Sat Dec 20, 2014 2:20 pm ]
Post subject:  Re: Palettes

DragonDePlatino wrote:
Oh, but I will have to disagree with you on one thing...$22 may have been the iconic sky blue of SMB, but any other colors could have been used. I usually find myself using $21 or $2C for my sky colors. $21 has more of a morning/afternoon color while $2C gives me the impression of noon.

That'd be an interesting hack for ShaneM to attempt. Super Mario Bros. appears to take place over the course of three days and two nights, the nights being worlds 3 and 6. So I wonder how hard it'd be to make SMB1's sky vary among $22, $21, and $2C based on "time of day":

World 1-1: $22; 1-2: $21; 1-3: $2C
World 2-1: $2C; 2-2: $21; 2-3: $22
Worlds 4 and 7: As World 1
Worlds 5 and 8: As World 2

Author:  Dwedit [ Sat Dec 20, 2014 2:23 pm ]
Post subject:  Re: Palettes

DragonDePlatino wrote:
Image

That's not a very good palette to begin with, looks like the old Nesticle palette. (Dead giveaway is the really bright blue in the top row)
Here's the palette that Nintendulator uses:
Image
You'll notice that the colors of each row look much closer to the same luminance level.

Author:  Sik [ Sat Dec 20, 2014 3:15 pm ]
Post subject:  Re: Palettes

Question: has anybody tried to get the YUV colors straight from a PPU already? (before it gets encoded into the RF unit) Then we could just recreate the intended colors from those values.

psycopathicteen wrote:
Maybe luminance should be calculated based on the 3D distance from black on the RGB color cube, instead of a linear matrix.

Y = sqrt( .299*R^2 + .587*G^2 + .114B^2 )

Tested that, it becomes too dark (and also gray shades should remain untouched, which doesn't happen here).

Drag wrote:
I actually really like the NES's palette because it's YIQ/YUV based. Trying to pick colors using raw RGB is harder because the luminance varies greatly depending on the hue, which is a problem if, for example, you're trying to make differently colored blocks all have the same relative lightness/brightness, especially if you're working with a very low resolution RGB, like RGB222.

Curiously, if you show me a color I can make a reasonable guess of its RGB value, but I'm utterly screwed when it comes to any other color system. This really seems to depend on which system one learned first, doesn't seem like any of them is particularly more intuitive in the long term (they still have their own advantages with other operations though, e.g. hue-based systems have it easy if you just want to change the hue, but simulating light addition/substraction is much easier with RGB, etc.).

Author:  DragonDePlatino [ Sat Dec 20, 2014 3:38 pm ]
Post subject:  Re: Palettes

tepples wrote:
...I wonder how hard it'd be to make SMB1's sky vary among $22, $21, and $2C based on "time of day"


Screw the sky, if someone did a hack like that you could change the entire level's palette! I played around a bit and was able to pull off 11 transitions, with two of them being repeated before/after noon...

Image

But actually, I'm pretty sure something like this exists. Mario Adventure had different times of day and even weather effects. All it was missing were some morning and evening palettes!

Dwedit wrote:
That's not a very good palette to begin with, looks like the old Nesticle palette. (Dead giveaway is the really bright blue in the top row)


Oh yeah, definitely. I actually just ripped that palette from Wikipedia's article on console palettes to use as an example. But even though it's not that great of a palette, many of the problems I described plague a lot of palettes.

...Except for Joel Yliluoma's NTSC palette generator. That thing produces freakin' gorgeous palettes! The reds and yellows are really strong and the contrast is great. That mockup I made up there? I got the palette for it from Joel's generator with the saturation set to 2.0.

Author:  tepples [ Sat Dec 20, 2014 4:02 pm ]
Post subject:  Re: Palettes

Sik wrote:
Question: has anybody tried to get the YUV colors straight from a PPU already?

That's what palette generators by Bisqwit and Drag attempt to do, and what NTSC filters in emulators attempt to do. In essence, they take the measured $x0 and $xD voltages, generate the composite output waveforms, and apply NTSC decoding functions to them.

Author:  lidnariq [ Sat Dec 20, 2014 5:26 pm ]
Post subject:  Re: Palettes

Sik wrote:
Question: has anybody tried to get the YUV colors straight from a PPU already?
The PPU directly emits NTSC (or PAL), not YUV component... we know the 12 angles that its square wave generator runs at (see my composite image).

psycopathicteen wrote:
Maybe luminance should be calculated based on the 3D distance from black on the RGB color cube, instead of a linear matrix.
Y = sqrt( .299*R^2 + .587*G^2 + .114B^2 )
I'd think something more nuanced than RGB would be better, perhaps one of the ones Bisqwit mentions on his documentation for animmerger.

Author:  psycopathicteen [ Sun Dec 21, 2014 7:05 pm ]
Post subject:  Re: Palettes

I don't know what that has to do with my post. I was coming up with a way of measuring lightness/darkness of a color.

Sik: It's supposed to be .299*(R^2), not (.299*R)^2.

Author:  Sik [ Sun Dec 21, 2014 7:25 pm ]
Post subject:  Re: Palettes

I implemented it as .299 * R * R (which should be identical), that still didn't work.

Original image
Standard grayscale algorithm
Your grayscale algorithm

Although of course this also assumes no gamma correction (e.g. modern standards use a different grayscale calculation that has been designed taking gamma correction into account).

Author:  psycopathicteen [ Thu Dec 25, 2014 10:49 am ]
Post subject:  Re: Palettes

Sik wrote:
I implemented it as .299 * R * R (which should be identical), that still didn't work.

Original image
Standard grayscale algorithm
Your grayscale algorithm

Although of course this also assumes no gamma correction (e.g. modern standards use a different grayscale calculation that has been designed taking gamma correction into account).


Red should be
Y = sqrt(.299) = .547

Green should be
Y = sqrt(.587) = .766

Blue should be
Y = sqrt(.114) = .338

Author:  yxkalle [ Thu Dec 25, 2014 4:45 pm ]
Post subject:  Re: Palettes

psycopathicteen wrote:
Red should be
Y = sqrt(.299) = .547

Green should be
Y = sqrt(.587) = .766

Blue should be
Y = sqrt(.114) = .338


But the sum of those is > 1.0.

Author:  psycopathicteen [ Thu Dec 25, 2014 8:46 pm ]
Post subject:  Re: Palettes

Y = sqrt( .299 + .587 + .114 ) = 1

Author:  lidnariq [ Thu Dec 25, 2014 9:27 pm ]
Post subject:  Re: Palettes

sqrt isn't associative. (you can't say sqrt(a)+sqrt(b) = sqrt(a+b).)

Anyway, normally we think of brightness as one of the dimensions of a matrix transformation of the input RGB tuple. At least, given linear brightness. Doesn't DTRT with gamma-corrected input. I don't know whether these sqrts are supposed to be on linear brightness...

Page 4 of 5 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/