Palettes
Moderator: Moderators
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).
Trying to account for different TVs is futile, they're all just way too different (especially for NTSC).
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
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 )
Y = sqrt( .299*R^2 + .587*G^2 + .114B^2 )
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.
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.
Re: Palettes
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":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.
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
Re: Palettes
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)DragonDePlatino wrote:
Here's the palette that Nintendulator uses:
You'll notice that the colors of each row look much closer to the same luminance level.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
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.
Tested that, it becomes too dark (and also gray shades should remain untouched, which doesn't happen here).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 )
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.).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.
- DragonDePlatino
- Posts: 94
- Joined: Mon Oct 20, 2014 1:50 pm
Re: Palettes
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...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"
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!
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.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)
...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.
Re: Palettes
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.Sik wrote:Question: has anybody tried to get the YUV colors straight from a PPU already?
Re: Palettes
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).Sik wrote:Question: has anybody tried to get the YUV colors straight from a PPU already?
I'd think something more nuanced than RGB would be better, perhaps one of the ones Bisqwit mentions on his documentation for animmerger.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 )
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
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.
Sik: It's supposed to be .299*(R^2), not (.299*R)^2.
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).
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).
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Palettes
Red should beSik 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).
Y = sqrt(.299) = .547
Green should be
Y = sqrt(.587) = .766
Blue should be
Y = sqrt(.114) = .338
Re: Palettes
But the sum of those is > 1.0.psycopathicteen wrote: Red should be
Y = sqrt(.299) = .547
Green should be
Y = sqrt(.587) = .766
Blue should be
Y = sqrt(.114) = .338
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Palettes
Y = sqrt( .299 + .587 + .114 ) = 1
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...
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...