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

Color emphasis - comparison
http://forums.nesdev.com/viewtopic.php?f=3&t=15483
Page 1 of 2

Author:  Zepper [ Thu Feb 02, 2017 7:23 pm ]
Post subject:  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.
Attachment:
wall_cmc.png
wall_cmc.png [ 63.4 KiB | Viewed 1719 times ]

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?
Code:
$2001:$E0      %Red   %Green  %Blue
000 Black       1.00   1.00    1.00
001 Red         1.00   0.85    0.85
010 Green       0.85   1.00    0.85
011 Yellow      0.85   0.85    0.70
100 Blue        0.85   0.85    1.00
101 Magenta     0.85   0.70    0.85
110 Cyan        0.70   0.85    0.85
111 White       0.70   0.70    0.70

Author:  lidnariq [ Thu Feb 02, 2017 8:44 pm ]
Post subject:  Re: Color emphasis - comparison

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.

Author:  zeroone [ Tue Feb 07, 2017 7:17 pm ]
Post subject:  Re: Color emphasis - comparison

lidnariq wrote:
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?

Author:  Zepper [ Tue Feb 07, 2017 7:40 pm ]
Post subject:  Re: Color emphasis - comparison

zeroone wrote:
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

Author:  zeroone [ Tue Feb 07, 2017 7:52 pm ]
Post subject:  Re: Color emphasis - comparison

Zepper wrote:
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.

Author:  lidnariq [ Tue Feb 07, 2017 7:57 pm ]
Post subject:  Re: Color emphasis - comparison

Zepper wrote:
TOO BAD #NESDEV
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.

Author:  tepples [ Tue Feb 07, 2017 8:23 pm ]
Post subject:  Re: Color emphasis - comparison

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

Author:  lidnariq [ Tue Feb 07, 2017 8:36 pm ]
Post subject:  Re: Color emphasis - comparison

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.

Author:  tepples [ Wed Feb 08, 2017 8:32 am ]
Post subject:  Re: Color emphasis - comparison

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

Author:  tepples [ Wed Feb 08, 2017 11:19 am ]
Post subject:  Re: Color emphasis - comparison

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.

Author:  Dwedit [ Wed Feb 08, 2017 11:42 am ]
Post subject:  Re: Color emphasis - comparison

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.

Author:  zeroone [ Wed Feb 08, 2017 12:23 pm ]
Post subject:  Re: Color emphasis - comparison

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.

Image

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:

Code:
/* Apply color emphasis */


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:

Image

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:

Image

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.

Author:  Zepper [ Wed Feb 08, 2017 1:30 pm ]
Post subject:  Re: Color emphasis - comparison

Attachment:
ark01.png
ark01.png [ 44.02 KiB | Viewed 1452 times ]

Author:  zeroone [ Wed Feb 08, 2017 1:50 pm ]
Post subject:  Re: Color emphasis - comparison

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

Author:  Zepper [ Wed Feb 08, 2017 3:58 pm ]
Post subject:  Re: Color emphasis - comparison

3/4th of the value. See the table below.
Code:
    1.00,3*0.85/4,3*0.85/4, // red
    3*0.85/4,1.00,3*0.85/4, // green
    3*0.85/4,3*0.85/4,3*0.70/4, // yellow
    3*0.85/4,3*0.85/4,1.00, // blue
    3*0.85/4,3*0.70/4,3*0.85/4, // magenta
    3*0.70/4,3*0.85/4,3*0.85/4, // cyan
    3*0.70/4,3*0.70/4,3*0.70/4  // black

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