RGB full vs RGB limited

https://github.com/MiSTer-devel/Main_MiSTer/wiki

Moderators: Mug UK, Zorro 2, Greenious, spiny, Sorgelig, Moderator Team

Locutus73
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 129
Joined: Wed Feb 07, 2018 6:13 pm

RGB full vs RGB limited

Postby Locutus73 » Fri Feb 23, 2018 12:33 pm

Hi!
Yesterday I was reading about next Analogue Super NT update that will include RGB gamma controls, so MiSTer immediately came to my mind. I verified the DE10-Nano HDMI output on my DVD iSCAN Mini and it reports a RGB888 signal, so, my first question: does MiSTer implement a full RGB gamma (0-255 values), commonly used on PC monitors, or a RGB limited gamma (16-235), commonly used on TV sets?
Now, full RGB has obvious advantages over limited, and emulating computers it should make more sense, but, on the other hand, not all TV sets let choose between full and limited, so it is useful to have sources that implement both options.
I don’t know how MiSTer works regarding video output. I mean I don’t know if each core implements HDMI output on its own, or if it relies on a framework offered by MiSTer (a la Libretro/RetroArch) or any in-between solution, but it is my understanding that Sorgelig is working on a new API with specific functions for video output.
So, here’s my point (probably I’m suggesting something obvious and granted for Sorgelig): can it make sense adding something in MiSTer (at API and/or user interface level) that lets the user choose between full RGB and limited RGB on a system wide and/or core scale?

Thank you in advance
Best regards

Locutus73

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2012
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: RGB full vs RGB limited

Postby Sorgelig » Fri Feb 23, 2018 8:52 pm

From all available for MiSTer cores, only one can be affected by this option - Minimig. All other cores have less than 8-bits per color component. It means both 235 and 255 usually represent the same brightness for most cores. Same for black level.

Even with Minimig i didn't get enough info how limited color range is affecting the picture.
Usually if source provides limited color range on full range monitor/TV you notice only grayish black. With opposite case you may notice some detail loss near white and black and usually it's hard to notice unless you compare it side by side.

Anyway, video generation is done on FPGA and is up to core implementation.
Currently cores output colors as-is, i.e. in full range.

Locutus73
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 129
Joined: Wed Feb 07, 2018 6:13 pm

Re: RGB full vs RGB limited

Postby Locutus73 » Sat Feb 24, 2018 3:37 pm

Usual disclaimer: I know the open source nature of MiSTer and that anyone can code the required features, but we are here in order to exchange ideas and to understand better.

Sorgelig wrote:From all available for MiSTer cores, only one can be affected by this option - Minimig. All other cores have less than 8-bits per color component. It means both 235 and 255 usually represent the same brightness for most cores. Same for black level.

I don't get how having less than 8 bits translates to correct full and/or limited RGB gamma. I mean I understand it means that the original platform can represent less color levels than limited RGB, but we should get no correct correspondence both with limited and full RGB (i.e. total black and total white don't match). Let me explain what I think (I might be wrong) should be a correct match: let's say we are emulating/simulating an old computer with RGB555 color space. Its DAC should output volt levels (computer monitors levels or TV/broadcasts levels) corresponding to total black for RGB 0-0-0 and to total white for RGB 31-31-31, and these should correspond to 0-0-0/255-255-255 for HDMI full RGB and 16-16-16 /235-235-235 for limited RGB. So if oR is original red, oRB is original red bitdepth and hR is HDMI red we should have hR=oR/(2^oRB-1)*255 for HDMI RGB full and hR=oR/(2^oRB-1)*(235-16)+16 for HDMI RGB limited. This may be an oversimplification, we could apply correction curves, I'm no video expert, but this is how it should work to the best of my understanding.

Sorgelig wrote:Even with Minimig i didn't get enough info how limited color range is affecting the picture.
Usually if source provides limited color range on full range monitor/TV you notice only grayish black.

Yep, we should get grayish (too bright) blacks and grayish (too dark) whites; generally, we should have compressed and shifted levels through the whole gamma (not only at the extremes).

Sorgelig wrote:With opposite case you may notice some detail loss near white and black

Again, we should have expanded and shifted levels through the whole gamma with clipping (detail loss) at the extremes.

Sorgelig wrote:and usually it's hard to notice unless you compare it side by side.

Perception is personal and depends on, among other things, sensibility, training and OCD levels :lol:

Sorgelig wrote:Anyway, video generation is done on FPGA and is up to core implementation.
Currently cores output colors as-is, i.e. in full range.

So, if I understand correctly, if HDMI output is 1:1 to emulated/simulated color buffer, we have full RGB HDMI only when the original color buffer is RGB888.

Anyway, I'm no FPGA expert, but it's my understanding that you can program groups of internal elements of the FPGA chip to act as specific configuration of logic gates and connections. Each specific group can act as an emulated/simulated original chip, with peripheral connections of this group acting as pins of the chip. So, we can interconnect different groups as the interconnections of the chips on the original hardware. Then, again, the peripheral connections of this set of groups (the whole original emulated/simulated hardware) go to the pins of the FPGA chip in order to talk to other components of the FPGA board (HDMI chip, SDRAM, GPIO, etc.). Now, if I'm not wrong, does it make any sense to imagine part of a FPGA chip configured as a "virtual universal DAC" for MiSTer cores? I mean something with standardized peripheral connections for cores to be used as a modular audio and video DAC, as some sort of FPGA utility/API that would take care of all conversions from old audio/video formats to correct modern HDMI levels and timings. I'm trying to imagine MiSTer as a sort of Libretro/RetroArch of the FPGA world, where it could offer standard input/output interfaces for cores that should "only" re-implement original hardware without bothering about user interface and real-world input/output. In emulation world this approach has great success. Take as an example Higan SNES; the native Higan offers two synchronization methods (excluding variable refresh rate monitors) of the emulated SNES (60.1Hz video) to the computer output (60Hz): sync to video, with audio crackling, and sync to audio, with video stuttering; then we have Libretro Higan SNES that automatically inherits Libretro Dynamic Audio Rate Control where video is synchronized to monitor vsync and audio is dynamically stretched to match video rate without crackling; to me, the best possible Higan SNES came when it was ported to a platform like Libretro. Again I'm imagining MiSTer as FPGA's Libretro (I know, I know… good idea, I'm free to implement it).

Locutus73

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2012
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: RGB full vs RGB limited

Postby Sorgelig » Sat Feb 24, 2018 4:38 pm

You need to read more about FPGA to understand how it gets programmed. In short: every core reloads the whole FPGA. It means every core includes everything and you cannot use libraries. The only way is to have library at source level which is what i do. There is a framework of MiSTer included in every core i wrote or ported.

Actually there is such thing as partial FPGA reconfiguration, but that's another story and another level. It's even unclear if this technology available for current FPGA.

Since MiSTer is open source project, you can start to learn FPGA programming on one of the core and then start to improve it to suit your OCD :) Many cores are far from perfect so you will have a lot thing to do there :)

As for Limited/full range - you're exaggerating the problem as it's applicable only for sources providing true color (or at least high color) range where color shift could be noticed. How to notice the color shift on ZX core providing only 8(!) colors?

Locutus73
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 129
Joined: Wed Feb 07, 2018 6:13 pm

Re: RGB full vs RGB limited

Postby Locutus73 » Sat Feb 24, 2018 5:25 pm

Sorgelig wrote:You need to read more about FPGA to understand how it gets programmed. In short: every core reloads the whole FPGA. It means every core includes everything and you cannot use libraries. The only way is to have library at source level which is what i do. There is a framework of MiSTer included in every core i wrote or ported.

I suspected this, but, nonetheless, it's perfect! "Library at source level" is still a framework to me and doesn't lessen the importance or the weight of something like MiSTer. Somehow, we could compare it to statically linked libraries… ok, they're precompiled, not source included, but you get a monolithic executable just like a monolithic core. All this seems to confirm my idea of MiSTer as some sort of FPGA's Libretro... eventually this framework could provide a "virtual DAC" facility.

Sorgelig wrote:Actually there is such thing as partial FPGA reconfiguration, but that's another story and another level. It's even unclear if this technology available for current FPGA.

Again, partial FPGA reconfiguration is not required to me in order to consider MiSTer a full framework platform.

Sorgelig wrote:Since MiSTer is open source project, you can start to learn FPGA programming on one of the core and then start to improve it to suit your OCD :) Many cores are far from perfect so you will have a lot thing to do there :)

I know, I have no doubts about it… what I doubt is my free time an my will force to learn a new programming paradigm.
But I can assure you my mental mumblings, some help in testing/scripting/programming and me bothering you with ideas and questions until this hobby keeps my interest alive :lol:

Sorgelig wrote:As for Limited/full range - you're exaggerating the problem as it's applicable only for sources providing true color (or at least high color) range where color shift could be noticed. How to notice the color shift on ZX core providing only 8(!) colors?

Yep, but you're reducing MiSTer scope and potential restricting it to ZX core

Thank you for your work
Locutus73

User avatar
Foxie
Captain Atari
Captain Atari
Posts: 354
Joined: Wed Feb 03, 2016 7:12 pm

Re: RGB full vs RGB limited

Postby Foxie » Sat Feb 24, 2018 6:42 pm

Personally, I'd be very surprised if you could notice the difference. Lack of true white isn't a problem, it just results in an imperceptibly dimmer screen. If you've used Hatari before, then you would have been using something with much less than true white - Hatari does a fast conversion from ST colour space to IBM PC colour space. As a result, whites are not 255.

As far as the black level goes, that depends on the TV's brightness control and the ambient lighting. With every change in ambient light levels, you need to re-adjust the brightness control so that the blacks are right on the threshold of black to the eye. When you switch between a source that uses 16 as black and 0 as black, you need to readjust the brightness control.

In reality, I doubt you need to bother with such an adjustment. The ambient light levels in a domestic setting vary considerably and nobody ever bothers recalibrating each time the light level changes. As a result, the error from ambient light is much much higher than the error due to the 16/0 thing.

Furthermore, if you're using an analogue input on your TV I'm not even sure if the 16/0 thing applies at all. The convention of using 16 for the black level came about from digitising video - and the need to represent negative values for undershoot etc. Black level in analogue video is very well-defined and I think it's the same between PAL and VGA. The black level is set by the blanking period after the sync pulse, and 0.7V above that is considered true white.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2012
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: RGB full vs RGB limited

Postby Sorgelig » Sat Feb 24, 2018 7:00 pm

Locutus73 wrote:Yep, but you're reducing MiSTer scope and potential restricting it to ZX core

it's just an example. Substract Minimig and ao486 from the whole set of MiSTer cores, then what you will get? Cores with up to 64 different colors. Will you see the difference between full and limited range on 64 colors? I doubt.

Foxie wrote:The convention of using 16 for the black level came about from digitising video - and the need to represent negative values for undershoot etc.

if i remember correct 16-235 range comes from conversion YUV color space used in old color television (PAL/NTSC/SECAM) to RGB.


Return to “MiSTer”

Who is online

Users browsing this forum: No registered users and 3 guests