Color emphasis - comparison

No NTSC filtering. For RockNES, I'm using 3/4th of the value from the table below (otherwise, the effect is minimal). There are different results.

Well, I'll ask you again. There's a race for the "perfect" NES palette, even if the NES NTSC output wouldn't mean a paletted-mode. You can generate a NES RGB palette, but not for a stupid $2001 color emphasis!? Out of NTSC, why is this restricted to YUV color space?

So, the native colors out of the NES are most accurately expressed in YUV. Those colors can be converted to RGB; I'm not talking about full artifact emulation.

However, on conversion, some of the colors are out of gamut. (So, as a precursor to accurately emulating the emphasis bits without just using a 512-entry table, you need to store unclipped values in the 64-entry table, and then clip them when it comes time to render)

The emphasis bits effectively
1- Multiply the luminance component
2- Add something to the luminance component
3- Multiply the chrominance phasor by some scalar
4- Add another phasor to the chrominance phasor.

And even more of these values are out of gamut once converted to RGB.

Anything that just multiplies the RGB components by a constant 3-tuple ignores #2 and #4 and simplifies #3 in an inaccurate way.

If you plot the 54-color no-emphasis and unclipped RGB palette in 3-space, and then draw line segments to the corresponding versions of all 54 colors with any number of emphasis bits set (again without clipping), you'll discover that all of these line segments, if extended, would converge at close to the same point.

So: I tentatively think you should be able to emulate the emphasis bits directly in RGB by adding a specific RGB tuple, and then multiplying that sum by another 3-tuple.

Is a better table of constants available? Is there any advantage to doing the scaling in YUV color space?

They refuse to give any information about it. Color emphasis is only possible under a vague and high-level NTSC emulation/programming/whatever thing.

TOO BAD #NESDEV

Blargg's NTSC filter contains emphasis logic that can be applied to RGB. But, the results may just be the same as multiplying by those constants. I'll have to analyze it.

Because what you want is math without understanding, and that is the very thing I have never been willing to give.

I told you how to derive the specific constants yourself. You've just been unwilling to do any legwork.

Is that like the "you're expected to solder together your own devcart" mentality before the PowerPak became available?

I would not consider "understands what algebra is or is willing to learn" to be even close to an equivalent level of a barrier to entry.

I'm putting this question on hold until RockNES gains NTSC and/or PAL-M filter support.

I have unlocked this topic by request of zeroone. Please refrain from using condescending language toward somebody whose apparent negative tone may be the result of a language barrier. I will lock it again should that happen again.

I'd say just use 8 palettes (one per emphasis bit combination), and steal them all from Nintendulator.
But if you want to find the elusive RGB emphasis formula, you can do statistics on the palettes to see what effect it had on the RGB values. You may need to change the color space to Linear RGB first.

I decided to give this a shot. In the comparison pic below, the left image uses a palette based off of the RGB scale constants and the right image is based off of a procedure similar to the one described by lidnariq above.



The colors do look more vibrant on the right.

I am not certain that I am generating the values correctly. I made an attempt to implement an NTSC filter a while ago based on the information on the wiki, but I ended up just porting Blargg's code. And, the palette used above was generated using his techniques.

NTSC uses YIQ color space. That wiki link explains the color space and it shows how to convert between RGB and YIQ. Remember to normalize color values to [0.0, 1.0] for conversion and to clamp out of gamut values before display.

Look for a comment in Blargg's code that says:



It reveals how the 3 emphasis bits manipulate Y, I and Q. It does indeed do as lidnariq described, but it uses LUTs, constants and constraints; I do not know the origin or the exact purpose of these magic numbers.

Blargg's code was designed for NTSC. PAL uses Y′UV color space and the lower 2 bits of the emphasis triplet are swapped (the R and G bits). Adjusting Blargg's code accordingly, my emulator generates the following for Noah's Ark:



The water looks like sepia tone instead of the bluish water produced by multiplying the RGB values.

Edit: Here's what happens for PAL if everything is maintained in YIQ color space, but the R and G emphasis bits are swapped:



That looks much better. Wikipedia mentions that YIQ and YUV are just 33 degree rotations about the Y axis of each other. Blargg's magic numbers might only be geared for YIQ.

@Zepper That looks too dark. Is that with the 75% multiplication values?

3/4th of the value. See the table below.

The wiki describes the emphasis bits as modulating the composite output directly. So even using YIQ is an approximation, albeit an accurate one. If you don't want to write a complete NTSC decoder, I'd say use a 512-color palette and be done with it. There are existing tools to generate such palettes.

Thank you, sir!