Palettes

Arne's palette is so random. Even if your using a ROM palette, at least give all hues an equal amount of equally placed shades, and pick the colors from a low res RGB palette.

Well...Arne's palette might seem random, but from an artist's perspective it's actually a pretty great palette. It's an analog palette like the C64 palette, where everything was hand-picked to work best for low-resolution pixel art graphics. Giving all of your hues an equal number of shades is actually a really bad idea, because then you'll end up with lots of ugly, unusable magentas like in the EGA palette. Notice how the palette lacks any skin colors, so you have to make everyone look like a crab-faced mutant?

On the other hand, if you look at analog palettes like the famous Dawnbringer 16, you'll see that hand-picking your colors makes a huge difference. Both EGA and DB16 have 16 colors to work with, but the latter looks waaay better!

But with that being said, I do think arne could have organized his palette a lot better. I've attempted to organize it into a nice grid at least a million times and I've always failed.

Pedanticism: That's the CGA palette.

The EGA palette is much more diverse, basically the same as the SMS palette. Only 16 simultaneous colors instead of 32, though.

EtA: (moved this section to newest post)

Ohh! You're talking about that old 6-Bit palette, right? Remember how I said I wasn't able to organize Arne's palette? I was actually able to organize EGA into some nice ramps for my own purposes!



EGA (not CGA, sorry about that) is really cool because even though it's a machine-generated palette, it's actually really usable for pixel art. There's a nice mix of high-saturation and low-saturation colors and a neat pattern to how big each ramp is...Primary/secondary RGB colors have 6 colors in their ramps, tertiary colors have 2 colors and quaternary colors have 1 color each.

Also, keeping things on subject...would it be possible to make an NES ROM using EGA colors? I know NES hardware can't generate RGB colors, but in theory could one create an emulator palette file and get games to run in EGA? You'd have to completely redo a game's graphics from the ground-up and the game wouldn't work on actual hardware, but it would be an interesting experiment. Hmm...

Wouldn't you call that an SMS game? I mean, modulo the bits about how the NES has eight three-color palettes and the SMS has two fifteen-color palettes, and the SMS can't do split screen...


The Dawnbringer 16 palette is ... more-or-less completely divorced from the constraints of what made the market move in the way it did. It's made without an eye to the hardware constraints imposed by using RGB or YUV, and his stated intention to rely on halftoning makes it collide badly with PAL and NTSC. The specific colors he's chosen are randomly all over the place in terms of RGB and YUV values, so there's no hardware advantage to such a fixed palette, either (unlike the VIC20 and C64, where there were five fixed brightnesses, and seven (out of 16) predefined chroma angles chosen.)

So it's more or less only usable as a software palette. Which is fine! the Macintosh's and VGA's 16-color modes would have benefited. (In fact, a number of games released before Windows95 and the ubiquity of 256-or-more-color VESA modes look rather like this). But those are highish resolution modes, so the crunchy low-res aesthetic doesn't jibe with reality. And the VGA high-resolution mode doesn't leave enough memory to double buffer what's onscreen, in addition to making full-screen updates a pain because of the planar layout.

That depends on what kind of filtering your video encoder uses. Most TMS9918 descendants (NES PPU, SMS VDP, S-PPU, MD VDP) use a really shortcutty 1980s design, but something that outputs YUV and applies the correct low-pass filter to UV channels before combining them with Y will make the checkerboards blend properly.

Ha-ha! It was a monumental success! With the aid of YY-CHR, a custom .pal file and a hex editor, I was able to convert a Super Mario Bros ROM to EGA color.



The 3-color tile restrictions are still in place, this isn't compatible with other NES palettes and this wouldn't work on actual hardware, but there are 10 more usable colors and a much better coverage of the RGB spectrum. In the conversion to EGA color, some things improved (more browns and super-smooth ? block flashing) while some things came out worse (oversaturated greens). Overall, an interesting experiment.

Ah, what a shame...I've always wondered how gaming would have been different if we had gotten graphics like these on older systems. But it turns out, it would've only been possible on older PCs. Regardless, thanks for the insight. It makes a lot more sense to me now why older games had the palettes they did.

Very very nice. This is actual oldschool pixel work that any classic console enthusiast can appreciate.

Not true. Arne statistically sampled MANY images from random interenet sources, and used the results to calculate a 64-colour palette. http://androidarts.com/palette/PaletteUnwrap256rnd.png

Ew! Not THIS mess again! Why is this palette so over-used?! The colour selection is just nasty. :X I don't think I've seen too much art from it, that isn't horrible muddied.

Did you even LOOK?! http://androidarts.com/palette/64PalV8Ordered.gif

Thank you so much! Even if I didn't get the aspect ratio right, I'm still proud of how much detail I was able to cram into the 12x21 resolution.

Well, if he statistically sampled a ton of images and was able to generate a nice series of 4-color ramps, it isn't so random, is it?

Weeell...it all depends on how you use the palette. Most people over on PixelJoint like to push palettes to the extreme, and while their work is amazing it can lack clarity sometimes. Here is a good example of something a little more clean. Unlike most 16-color palettes, you can plop down huge flat areas of green and it'll be pretty easy on the eyes.

No waaay! I didn't realize he had that tucked away somewhere on his site! I can't believe I wasted a whole afternoon trying to make that myself. D: Thanks for sharing this shiny new toy with me!

The PPUs are not TMS9918 descendants o.O (you could argue about tilemaps and sprites, but that stuff was inherited from arcades in general really) Also the TMS9918-based chips were RGB-based internally (which means its ugly palette makes even less sense since there wasn't any real restriction it seems).

Also while we're talking about random palettes, one thing that annoyed me was when trying to cram non-paletted RGB into 8-bit, it was usually 3 bits for red and green and only 2 for blue... which leaves blue with very few shades in comparison (the steps are still too big to not matter), not to mention making it impossible to make a convincing gray. I was messing around and making red and blue share the LSB would have been a much better idea (I should make an image of that palette again, the one I have is in the old Win98 machine). I wonder why nobody came up with it back then.

And yeah, CGA palette =P Which everybody calls EGA because nearly nobody bothered to change it from the default (although apparently there were some cheap clones that had it fixed to that, which may explain the issue...).

This page shows a couple of interesting 8-bit palettes (RRGGBBSS and RRGGBBII).


I remember reading that the EGA palette couldn't be changed in the 320x200-pixel mode (EDIT: The wikipedia page says this), which was the most common for games.

True in that they were implementations from scratch of the same concept. But see 6502freak's post about the ColecoVision port of Donkey Kong being the Famicom's inspiration.


I think the 200-line EGA modes were in some sense fixed to the CGA palette because they were intended for compatibility with CGA monitors. Wikipedia states without citation: "The extended [64] color palette cannot be used in 200-line modes." Apparently game graphics weren't quite as high a high priority for International Business Machines as high-resolution business graphics.

Ugh at the palette thing =/ Though looked it up, apparently the problem was not the card itself but the monitors:
http://www.reenigne.org/blog/why-the-eg ... ine-modes/

And here I had just assumed that it wouldn't display fully correct colors when using a CGA monitor.


That seems to talk about the idea of a console in general though, not the hardware design in itself. Remember that the Donkey Kong arcade itself was based on tilemaps and sprites (it just lacked scrolling), and it certainly wasn't the first arcade to have that either, so it's not like Nintendo took the idea from the Colecovision.

May as well say that every system using tilemaps and sprites is a TMS9918 derivative.

But was there a tilemaps and sprites picture generator on a single chip with greater than 160 pixels across before the TMS9918? The TMS9918 proved that full LDTV-resolution tilemaps and sprites, as opposed to a dumb frame buffer like an Apple II or CGA or a chunky 160x96 tile plane like Odyssey 2 or INTV, could be done in a console. Notice how chunky Mario is in every pre-NES home Mario game other than Donkey Kong for ColecoVision:


Mario sprites on pre-NES consoles
Atari 800 Donkey Kong, Atari 800 Mario Bros, ColecoVision, Intellivision, Commodore 64, Atari 2600

What no one realized at the time was that it's possible to make colorful sprites on a C64 without making it look too chunky, by using two sprites: one full-res for the outline and one half-res for the innards.

So wait, it's a TMS9918 derivative just because it can display that stuff with more pixels, which is something that would have happened anyway just by technology getting better over time? =|

Also I imagine that with the C64 sprite there was 1) the fact it eats into the sprite limit (not sure how bad it is in this case, although I'm not sure if the resolution could be set per sprite, and even then how it'd affect the programming) and 2) back then porting a game wasn't exactly easy either due to the massive amounts of mismanagement so developers usually would not get time to get anything fancy either (not like today is much better, but at least it's not anywhere as horrible as at that time).

The C64 limit is eight 24-pixel sprites, but apparently those can be repositioned mid-screen, so it's in effect eight sprites per scanline at the cost of some slowdown due to raster interrupt processing.


Multicolor can be turned on per sprite.


The later C64 game Mayhem in Monsterland appears to have pulled it off, but only for the Bub/Sonic-looking main character, not the Yoshi-looking enemies.

Mayhem in Monsterland (C64) screenshot

I had completely forgotten about Monsterland when trying to remember if it was possible to mix sprite types x_X

And huh, until now I had assumed it was just three sprites (since after all you can have eight on a line and there aren't many overlaps in that game), but that makes sense I guess. And yeah only the player gets this treatment, every other sprite that's multicolor is lo-res.

I don't think I ever encountered that until the mid/late 90s with "web safe" palettes for GIFs and other images that might need to be displayed in a low-colour mode.

With the exception of VGA Mode 13h all of the old video systems I can think of used planar memory organization rather than byte-packing, so number of bits per pixel could easily match the hardware needs (at the price of making single pixel writes much more expensive). The Amiga even had a configurable number of bitplanes, depending on how much memory you wanted to dedicate to it. Of course, these were usually palette indices, and the palette itself was usually written separately, but I don't remember any that tried to pack an RGB palette entry into a single byte.

I first saw the web-safe palette in the shareware paint program GraphicConverter for Mac OS (classic). The default 8-bit palette on Mac OS was a 6x6x6 RGB cube followed by 16-step red, green, blue, and gray ramps. Also:



Sources: EGA, SMS

Oh, yeah obviously 222 or 111 is fine to be packed into a byte.

Did the Macintosh LC II have an 8-bit chunky format?

Yes.

All Macs with color screens have had chunky pixels. This includes every Mac II, every LC, the Color Classic, every Quadra, and every Power Mac.

(The list of 68000 machines with chunky pixels also includes the Sega Genesis, which has been made to run System 7, but I don't think it's in color because Color QuickDraw was never backported to the 68000.)

The other place I've run into an uneven RGB bandwidth was in DXT compression, which uses 5:6:5. Not a big deal most of the time, but as Sik mentioned earlier, it's problematic for greys, especially if there is a gamma curve in effect or anything else that can magnify the colour disparity. This is a very commonly used format in games today, but it didn't really see widespread use until it became a standard graphics card feature sometime in the 2000s.

It's also a little bit weird, because the 5:6:5 isn't the resolution of the output colour; DXT compression represents a 4x4 block as two 5:6:5 colours and a 2-bit interpolation between them, so there are 2 interpolated colours that aren't strictly bound to 5:6:5 (usually it's expanded to 8:8:8 before interpolation), so a clever DXT compressor can take advantage of this for slightly improved colour quantization.

Yeah, but 5.6.5 is not as problematic since it's 64 vs 32 shades. At that point the eye starts having difficulty telling apart the levels (it still can, especially in non-dithered gradients, but the difference is small enough to not make it so obvious). With 3.3.2 it's much worse since it's 8 vs 4. To put into context: with 5.6.5 it may be at worst ~1.56% off from the intended color, with 3.3.2 it would be 12.5%. (btw, 5.6.5 was the most common format for 16bpp on PC)

And yeah, on PC you're unlikely to find 3.3.2 RGB, since programs were either fullscreen programs that were already designed around the concept of a palette (thereby not using any scheme like that) or Windows programs that couldn't use the full 256 palette in the first place. The most notorious offender that comes to my mind right now is the late MSX models, which had a mode where each pixel was one byte and the format was 3.3.2 RGB. Also the SNES in direct color mode (or whatever it's called) is like this, if you ignore the extra LSB (since that one can only be set per tile and not per pixel, making it not that useful). Also on the newer end there's one of those new consoles made for retro-looking games that uses 8-bit pixels, and the format is 3.3.2 RGB x_x (nope, not paletted, WTF?)

If you're referring to Uzebox and friends, that's because a 3-bit resistor ladder DAC is easy to build.

The Allegro library has a built-in 332 palette, which I assume is for use with dithering unknown photographs to 256 colors.

One workaround for proper gray temperature is to make full scale blue slightly weaker, such that 2 red or green steps equal one blue step. White would be (6, 6, 3).

And ironically white would not be white =P So you replaced one issue with another.

And yeah, was talking about Uzebox, I just forgot the name XD I'm aware of the DAC thing, although the idea of sharing the LSB of red and blue would still have worked just fine in that case (I'm not even sure if it'd have needed another resistor or if the same could be reused).

Yeah, for the UzeBox one would need to convert the blue DAC to a 3-bit DAC also. Not hard ...

RRGGGBBV does seem like one of the less awkward compromises.

The other way you can "fix" RRRGGGBB is to duplicate the blue MSB to make a 3-bit DAC again, expanding {0,1,2,3} to {0,2,5,7}.

Would it be worthwhile to explore a system of variable 2-bit -> 3-bit mapping? For instance:
RrGgBbyy

R, G, and B are all 2-bit (C, c), but y determines how they map to a 3-bit dac:

y = 0: {C, c, C} ; Normal
y = 1: {1, C, c} ; Light color
y = 2: {0, C, c} ; Dark color
y = 3: ?

That would basically work out to the three color cubes of {0,2,4,7; 0,1,2,3; 4,5,6,7}.
Of those nominal 192, there are several duplicates, with only 176 unique shades.

EtA: Braino. That should be {0,2,5,7}; the image is still of {0,2,4,7}

Not as colorful as RGB332, but has RGB222's advantage of R, G, and B all being mapped the same way, plus extra colors. A disadvantage is that it's no longer a continuous color space, so color fades would take a bit more logic to perform, but you'd also get that with shared-bit schemes (to a lesser extent though).

It seems like this could be useful though, and it'd be simple to implement in hardware. I was thinking {2, 3, 4, 5} would be useful to add as the unused y setting. The mapping for that would be {C, !C, c}. This way, you have one cube for saturated colors, and three cubes for less-saturated colors in the dark, medium, and light range. Unfortunately, this doesn't create any unique colors; it just provides a way to access colors you wouldn't be able to otherwise. My mistake, this would add a few extra hues to the palette.

I noticed that this is similar to ADPCM, where you have a fixed precision, but you can specify the range the precision covers, giving you more flexibility.

If I take that whole cube, it works out to something like a weird variant of the websafe 216-color palette:
For any given value of any two components, the third has 0, 4, 6, or 7 represented values.

I wonder if this thread should get split? All this discussion definitely has nothing to do with NES-like artwork =P

Anyway, here's how the scheme I proposed looks like:


(the format there is RRGGGBBZ, where I had absolutely no idea what letter to use to represent the LSB of red and blue)


Er, how does that help matters? Now not only you still have too few shades, but you also completely screwed over the linearity. I guess the only advantage is that you get both grays and white, but otherwise colors still take a severe hit.

Tentatively, "V" for violet?

It's still lousy in comparison to a full 9-bit palette. But it's easier to use than nonorthogonal mixing. It gets you all four shades with zero saturation (black, white, two greys), and since the output goes through a layer of gamma correction anyway I'm skeptical that this nonlinearity is particularly problematic? {0,1,2,3,4,5,6,7} becomes {0,3,16,39,74,121,182,255}.

Also, note the "scare quotes".

Just for fun, I came up with a palette generator for the thing I came up with. As a bonus, you can come up with different ways to expand the 2 bits into 3 bits. Here it is

It's not often a problem, but there are still situations where it comes up. When rendering a texture, we're not just putting the colour directly on the screen; there's all sorts of transformations that can magnify the error (harsh lighting, gamma correction, tone mapping, post processing, etc.). Also, because it happens on 4x4 texel boundaries, the problem looks a little like a patchwork quilt made of grey, green, and magenta squares. It would be less noticeable if it was just a per-texel error (especially with linear filtering).

It's way better than 3:3:2, yes. That's a given.

All this talk about palettes make me impressed how Nintendo were able to find such a nice looking palette with such simple technology they had. Several other systems used YC palettes, but NES did the best job balancing saturation with luminance. I can't think of any way to improve upon it without adding a lot of colors that are too far out of bounds.

Not only a nice palette, but one generated entirely by square waves for composite output.

I do like the 2600/7800's palette a little better. I don't know how many of its shades are technically out of gamut, though.

To be fair, the NES is using 6-bit for defining colors while most other systems at the time used 4-bit (and systems that had more usually would opt for going with RGB instead).


Don't they have different palettes for NTSC and PAL? (at least the 2600, no idea if the 7800 messed with the palette)

Well...the NES DID have a rather nice palette, but from an artist's perspective I think it could have been a lot better. I'm not sure how much of this was the result of technical limitations or the fact that I've changed a YPbPr colorspace into an RGB one, but...



A. Why does the NES that these two pairs of grayscale? They're essentially right next to each other, and isn't enough contrast between them to make a ramp of four grays.

B. Two whites and two blacks? I know there's a veeery dark gray tucked next to the black, but it's practically useless.

C. I very, very rarely ever find myself using these blues. The ones to the left are much more vibrant and have much better contrast. The space used up by these could have been used to add more...

D. Reds! The most frustrating part of the NES palette. Depending on what palette you're using, these 8 colors might not look red at all. With certain settings, sometimes you won't be able to ever use reds.

E. I always found this column of color very...undependable. On most screens it takes on a yellowish hue, but sometimes it'll be pushed so far towards green you won't ever be able to use yellow. That's two colors (red and yellow) you could potentially loose with the wrong settings.

F. Like the grays and blue-violets, there's no contrast between these two columns. I often find myself constantly switching them in projects and only seeing a slight difference in color temperature. Like C, I think the colors here could have been used elsewhere (like the yellows).

G. Wait! Before you say anything...I actually LOVE these two colors! They're my favorite colors in the entire palette! If you don't want to use black for your outlines, these two colors are dark enough to give your sprites some much-needed contrast. The only problem is...they're the only two colors in the entire palette that work this well. Every time I try using another color for outlines or shading, it turns out too bright or too saturated, like the darkest blue above the C.

H. Last but not least, these colors. Why?

Sorry if this sounds like a big whiny list of complaints, but this seemed like the best place to vent my years of frustration I've had with this palette. I'm also curious to see why these colors are this way.

The reason is video signal generation. As you may know, the NES' PPU generates video directly in composite and does not, ever, use RGB internally.

I am not very knowledgeable about video signals myself, but the colour information is added onto luminosity information in order to be retrocompatible with old monochrome displays. The colour information is a high-frequency sine wave. The amplitude of the wave is the colour's saturation, and the phase of the wave is the colour's hue. Thanks to this it was possible to broadcast TV on channels that were supposed to be black and white without changing any hardware. Whoever came with this idea is pure genius by the way, but that's another topic. (With todays' policy I'm sure they'd ask everyone to trash their old TVs and force everyone to update to colour, and change all their cables, etc...)

The NES generate colours with an ADC with really few possible output voltages : There is only like 5 possible voltages (not counting the synchronosation voltages).

The colours are generated with a johnson counter that will create a square wave, "high" for 6 cycles then "low" for 6 cycles and repeat, for a period of 12 cycles. The phase of the counter correspond to the hue, so those 12 cycles corresponds to the 12 hues available. Column "$x0" correspond to the "high" voltage level and column "$xd" to the low voltage level. All other colours are synthetized by switching between the "$x0" and the "$xd" voltage, at different phases.

This also explains why it's not possible to control saturation, and why colours $2d is identical to $00 and $3d identical to $10. $0d is "blacker than black" and should never, ever be used, if you use it the video signal is invalid and the results are unpredictable.

Sure the palette could have been better if there was 15 different hues (this would have implied either a higher frequency crystal), and if the "$xd" column wasn't accessible, with the same # of bits. Unfortunately, whoever at Nintendo designed the PPU didn't make this choice.

In theory, the brightness of all colours from $01 to $0c is absolutely the same, compensating for the traditional "blue is darker than yellow" feeling we have (due to our eyes containing less blue captors than green and red). The YIQ colourspace was designed especially to compensate this, again for backwards compatibility to B&W monitors. The same applies too to all the other 3 lines. If you have a feeling that $0c and $08 are darker it could be either :
1) The particular RBG palette you used is a little off
2) Your eyes have a relative quantity of light captors for R, G and B that is a little off compared to what the YIQ guys designed

The limitation is that the Pb and Pr components have to be sin(theta) and cos(theta) where theta is a multiple of 30 degrees offset from color burst. (Column 8 is the same hue as color burst.)


Colors on the NES were generated by alternating between a voltage in column 0 (dark gray, light gray, white, white) and a voltage in column D (blacker, black, dark gray, light gray).


The one directly behind the letter C is $22, the iconic sky blue of SMB1.


Canonical red is $16.


Every console has the same problem with yellow. Different people see skin tones different way, and some TVs have "hyperreal" settings to boost vibrance of Asian skin tones. That's why it's Never The Same Color. Though $38 is pale, it's probably the closest to a canonical yellow that you'll get.


After the "high signal level" column, twelve color columns spaced 30 degrees apart, and the "low signal level" column, the rest is just unassigned.


It is 2, specifically the Helmholtz–Kohlrausch effect. More saturated colors are perceived to be brighter.


The $1x colors have the same luminance as the $00 gray behind them. Yet they look subjectively brighter due to the Helmholtz–Kohlrausch effect, except for the brown.
Illustration by Tyathalae

Thanks for clearing that up, tepples! So colors in the 0 and D columns aren't just colors, but are combined with different hues to generate the ramps? Now that I look at it, that makes a lot of logical sense. But...if one of those colors, (say $00) were a lot darker, wouldn't it be possible to combine more colors in the darker end of the spectrum? And what about the unassigned colors? What would the NES palette look like if those were used up and 64 colors were available? Is that even possible? Has someone ever done it before?

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.

Wikipedia screws up again with their claim that those colors have the same luminance. Since when does primary red have the same luminance as primary magenta?

While I was working with Dawnbringer on my 6-bit palette arrangement, I ran into the Helmholtz–Kohlrausch effect a lot. Don't underestimate the effect's potency!



There's the image desaturated in GIMP based on luminosity. The red and magenta look about the same to me.

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).

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

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

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:

You'll notice that the colors of each row look much closer to the same luminance level.

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).


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.).

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



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.

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

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.

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).

I'd think something more nuanced than RGB would be better, perhaps one of the ones Bisqwit mentions on his documentation for animmerger.

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.

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

But the sum of those is > 1.0.

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

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

I think I know what is going on: use squares to make the values non-linear, then use a square root to counter the bias towards black caused by that (to make it a bias towards white instead). Not sure how well that works though.

So basically the full calculation would be:
Y = sqrt(R * R * 0.299 + G * G * 0.587 + B * B * 0.114)

EDIT: did a quick check and it does seem that grays are preserved at least.

EDIT 2: OK, here we go again with the comparisons
Original image
Standard grayscale algorithm
Square-based grayscale algorithm

EDIT 3: and now I'm seeing shortcomings to both approaches =/ Lame (but of course it's possible that with this other algorithm different values are needed as well, remember the original algorithm was just a way to get reasonable results with the technology available at the time)

It is easy to prove: x=r=g=b implies y=sqrt(.299x^2+.587x^2+.114x^2)=sqrt((.299+.587+.114)x^2)=sqrt(x^2)=x. This is not a proof of how good it is; only that it has one good quality which is that it is idempotent so that grayscale pictures are preserved.

One slight problem is that the pictures do not all represent the same frame. It would be easy to fix by capturing one frame and then applying the algorithm and making outputs based on it (this should be easy to do using ImageMagick, for example).

In fact, it's really easy to do with ImageMagick:
convert YZG20dL.png -fx 'sqrt(0.299*R*R+0.587*G*G+0.114*B*B)' sqrt.png
convert YZG20dL.png -type Grayscale gray.png

I actually think the sqrt version seems to do a respectable job at compensating for the H-K effect... at least for pure reds, greens, and blues.

Yeah, but the only true difference is the clouds having moved a little and maybe Sol's position being slightly different so it's not hard to do (by the way, in case you wonder those images were made by applying a color filter in-game).

As I said the factors with the square-based algorithm could be wrong, I was messing with these ones to see how well it works, does anybody else want to give them a try? I didn't check yet but at least I got the impression that it wasn't anywhere as off (this was mostly noticeable with red):

R = 0.25
G = 0.60
B = 0.15

Wikipedia suggests removing the gamma, and then Y = 0.2126R + 0.7152G + 0.0722B, and then readding the gamma.

A simple approximation would be something like:
R = pow(R, 2.2);
G = pow(G, 2.2);
B = pow(B, 2.2);

Y = 0.2126R + 0.7152G + 0.0722B;

Y = pow(Y, 1/2.2);

Huh, I thought we were already dealing with linear RGB in the first place. Also that grass became way too bright.

Also this is what I got with the modified values I mentioned before. It still can be tweaked, but it certainly seems to look a lot closer than all the attempts I've seen so far (although my perception for the blue component may be off...).

The formulas with sqrt in them implicitly assume 2.0 gamma. I know that 2.0 of the 2.2 gamma comes from the fact that signal levels represent potential (in volts), and power is proportional to the square of potential if impedance is constant. But where's the other 10%?

Instead of a square root, take the 2.2-root? x^(1/2.2)

Doesn't the gamma depend entirely on the display? (which is why images for Macs always had to deal with a different gamma value)