Palette options

ash2fpga
Posts: 94
Joined: Tue May 26, 2020 6:20 pm
Has thanked: 8 times
Been thanked: 6 times

Palette options

Unread post by ash2fpga »

Came across an Atermio video showing MiSTer color options for the recent palette work. Looking forward to see this land. :)
User avatar
Phaedrus
Posts: 25
Joined: Mon May 25, 2020 12:57 am

Re: Palette options

Unread post by Phaedrus »

Interesting. My TG16 hardware is non-functional for a long time (one of the reasons I got a mister to begin with) so I've never done a direct compare.
Peredonov
Posts: 6
Joined: Wed May 27, 2020 4:04 pm

Re: Palette options

Unread post by Peredonov »

You may achieve something similar by using an RGB to composite converter, and just let the NTSC decoder on your monitor process the colors in the same way that it would have for the original composite output of the OCE. The VGA2NTSC could be used for this conversion.
dshadoff
Posts: 133
Joined: Sun May 24, 2020 9:30 pm
Been thanked: 5 times

Re: Palette options

Unread post by dshadoff »

Peredonov wrote: Tue Jul 21, 2020 4:28 am You may achieve something similar by using an RGB to composite converter, and just let the NTSC decoder on your monitor process the colors in the same way that it would have for the original composite output of the OCE. The VGA2NTSC could be used for this conversion.
No, that's not correct. The HuC6260 has a color lookup table for the conversion from RGB to Y/R-Y/B-Y which is not a direct translation.

The RGB had been considered as being a linear scale to apply each colour, but it turns out that there isn't enough space between some of the indexes to make a visible difference; this was the function of the Y/R-Y/B-Y conversion, which makes those less-visible transitions more visible.
LeftEmpty
Posts: 136
Joined: Sun May 24, 2020 6:47 pm
Has thanked: 2 times

Re: Palette options

Unread post by LeftEmpty »

This is a bit of an hardcore talk for me, but to contribute, on my first gen PCE RGB modded back in 1989, the colours were strikingly bright, even more than what the core displays currently (although different screen probably got a part in this too). This is why I enjoyed playing PCE games more in NTSC composite back then.
dshadoff
Posts: 133
Joined: Sun May 24, 2020 9:30 pm
Been thanked: 5 times

Re: Palette options

Unread post by dshadoff »

The issue is that RGB output - from emulators, FPGA systems, or modded hardware - are oversaturated for some colours. The index table used in the HuC6260 to transform into composite, makes for a more even spectrum of what the eye can discern.

Skin tones are too red on RGB, and there are also various other colour distortions, although to be fair, it's not an entirely different colour representation so many people have felt that the RGB output was basically the same colour set (although it's very different in some specific situations).
LeftEmpty
Posts: 136
Joined: Sun May 24, 2020 6:47 pm
Has thanked: 2 times

Re: Palette options

Unread post by LeftEmpty »

Ha ha, I totally remember the redskinned humans. I was striking as strange but whatever goes back then, and had totally forgotten about that.
I had no idea there were index tables and such. As a player, you take everything for granted, but it's funny to get glimpses of how the innards work.
Peredonov
Posts: 6
Joined: Wed May 27, 2020 4:04 pm

Re: Palette options

Unread post by Peredonov »

dshadoff wrote: Tue Jul 21, 2020 12:24 pm No, that's not correct. The HuC6260 has a color lookup table for the conversion from RGB to Y/R-Y/B-Y which is not a direct translation.
I didn't know this. In that case only the palette approach suggested by the original post would work. Fortunately this is not like the NES situation where no palette can accurately represent the NTSC colors fully, since the HuC6260's table values are known. So the PCE core would be able to give the best of both worlds, virtually the same colors as the original composite output but with the clarity of RGB (perhaps in combination with a gamma setting to further approximate the original picture via composite).
ash2fpga
Posts: 94
Joined: Tue May 26, 2020 6:20 pm
Has thanked: 8 times
Been thanked: 6 times

Re: Palette options

Unread post by ash2fpga »

I went back to take a look at the progress on this. I see Kitrinx had a commit 15 days ago. :D
User avatar
0x15e
Posts: 7
Joined: Sun Jul 26, 2020 8:10 pm

Re: Palette options

Unread post by 0x15e »

I did a build of that core and can definitely notice the difference. It's subtle but it definitely helps some details pop a little better.

What I'm curious about now is if / how the NTSC artifacting discussed here will be addressed.
dshadoff
Posts: 133
Joined: Sun May 24, 2020 9:30 pm
Been thanked: 5 times

Re: Palette options

Unread post by dshadoff »

0x15e wrote: Mon Sep 07, 2020 6:45 pm I did a build of that core and can definitely notice the difference. It's subtle but it definitely helps some details pop a little better.

What I'm curious about now is if / how the NTSC artifacting discussed here will be addressed.
Never say never.
But there's a lot to research before any effort is made toward such a thing.
ash2fpga
Posts: 94
Joined: Tue May 26, 2020 6:20 pm
Has thanked: 8 times
Been thanked: 6 times

Re: Palette options

Unread post by ash2fpga »

0x15e wrote: Mon Sep 07, 2020 6:45 pm What I'm curious about now is if / how the NTSC artifacting discussed here will be addressed.
Would you end up emulating the end result, or would you try to reproduce the composite signal being generated by the console (for analog output), and then try to reproduce decoding performed by televisions of the time (for HDMI output)?

I wish I had kept track of where, I think I had read about the NES outputting "tweaked" composite to take advantage of composite artifacting, too.
dshadoff
Posts: 133
Joined: Sun May 24, 2020 9:30 pm
Been thanked: 5 times

Re: Palette options

Unread post by dshadoff »

Whoa whoa whoa... first, I would need to understand exactly when the artifacts occur and specifically what causes them. Nothing will take place (at least from me) until I have that information, and the underlying root cause will almost certainly help define the appropriate response to be taken.

Right now, it's not even being looked at.

Instead, on Artemio's discord we are starting to look at how the digital values in the YPbPr lookup table affect the actual output signal, colour by colour. It's not so easy, since Pb/Pr are already modulated when they come out of the HuC6260 chip; also, they may have a non-linearity applied to them at various points along the way to the display, so there is a lot still to be understood.
ash2fpga
Posts: 94
Joined: Tue May 26, 2020 6:20 pm
Has thanked: 8 times
Been thanked: 6 times

Re: Palette options

Unread post by ash2fpga »

dshadoff wrote: Mon Sep 07, 2020 10:15 pm Whoa whoa whoa... first, I would need to understand exactly when the artifacts occur and specifically what causes them. Nothing will take place (at least from me) until I have that information, and the underlying root cause will almost certainly help define the appropriate response to be taken.

Right now, it's not even being looked at.
My reply was merely an "intellectual curiosity" response. I find what various hardware and software makers did fascinating. :)

dshadoff wrote: Mon Sep 07, 2020 10:15 pm Instead, on Artemio's discord we are starting to look at how the digital values in the YPbPr lookup table affect the actual output signal, colour by colour. It's not so easy, since Pb/Pr are already modulated when they come out of the HuC6260 chip; also, they may have a non-linearity applied to them at various points along the way to the display, so there is a lot still to be understood.
Thank you for sharing. Very cool to see the work being done.
User avatar
0x15e
Posts: 7
Joined: Sun Jul 26, 2020 8:10 pm

Re: Palette options

Unread post by 0x15e »

dshadoff wrote: Mon Sep 07, 2020 10:15 pm Whoa whoa whoa... first, I would need to understand exactly when the artifacts occur and specifically what causes them. Nothing will take place (at least from me) until I have that information, and the underlying root cause will almost certainly help define the appropriate response to be taken.

Right now, it's not even being looked at.
Oh absolutely. Like ash2fpga, I'm just curious right now. I understand there's already been a tremendous amount of time invested in this and there's still a lot going on. I'm definitely not trying to be a choosing beggar over here. :)

If nothing else, it should at least already be close enough that if people wanted to use one of the composite NTSC addons and connect it to a CRT, they would probably get something similar to the original intended effect.
dshadoff
Posts: 133
Joined: Sun May 24, 2020 9:30 pm
Been thanked: 5 times

Re: Palette options

Unread post by dshadoff »

0x15e wrote: Tue Sep 08, 2020 4:59 pm If nothing else, it should at least already be close enough that if people wanted to use one of the composite NTSC addons and connect it to a CRT, they would probably get something similar to the original intended effect.
The current expectation is that the artifacts somehow result from the modulation/demodulation approach on the signal. So the expectation is that simply using a composite modulator into a composite set (which then demodulates internally) would create those artifacts.

The questions are then whether there is any purpose for creating them artificially on non-modulated outputs, how they occur in the first place, and how to infer them. Of course, users would want them to be put "in desirable places but not in undesirable places", but that's a relative impossibility.
Post Reply