Palettes

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: Palettes

Post by Sik »

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).
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Palettes

Post by psycopathicteen »

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 )
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: Palettes

Post by Drag »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Palettes

Post by tepples »

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
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Palettes

Post by Dwedit »

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.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: Palettes

Post by Sik »

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.).
User avatar
DragonDePlatino
Posts: 94
Joined: Mon Oct 20, 2014 1:50 pm

Re: Palettes

Post by DragonDePlatino »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Palettes

Post by tepples »

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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Palettes

Post by lidnariq »

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.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Palettes

Post by psycopathicteen »

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
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: Palettes

Post by Sik »

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).
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Palettes

Post by psycopathicteen »

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
User avatar
yxkalle
Posts: 62
Joined: Sun Jan 27, 2013 7:30 pm

Re: Palettes

Post by yxkalle »

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.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Palettes

Post by psycopathicteen »

Y = sqrt( .299 + .587 + .114 ) = 1
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Palettes

Post by lidnariq »

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...
Post Reply