Color difference between emulator and hardware?

[hechelion]

I have a theoretical question about the colors in the emulator vs hardware.

I know that the emulator repeats the nibble of each channel to generate a 24 bit color that is used on the desktop.
That is, the color 2F8, in the emulator it will be seen as the color 22FF88.

If we think that in 12 bits, the maximum value of a channel is F, it makes perfect sense that in 24 bits the max value of a channel is FF.

But the mean value, which is 8, should be 80 and not 88.

That small difference is what got me thinking.
I understand that the VERA chip, when generating the analog signal (VGA) of a color channel, used the 12-bit value, that is, a value of 8 should be 50% of the analog signal. or I'm wrong?
If I am correct, does it mean that the emulator has a little difference from the hardware?

To clarify, I know this difference is small and really doesn't matter when developing a game, but it got me thinking.

PS: Make it clear that I am aware that on a monitor we have external calibration and many other parameters that can influence how a color will actually look. Rather, it was a theoretical concern while studying how to convert a color palette to use in a game I'm starting to program.

[ahenry3068]

I'm kind of weak on the technical details. But the last several weeks I've
been working on learning Pallette manipulation in BASIC. I've tested
all my sample code in Emulator R43 and on Hardware. They seem
to render the same colors.

[hechelion]

Thanks for your answer.
I am sure that to the human eye it is almost impossible to find a difference and that is why I do not give practical importance to the subject.
(Assuming my reasoning is correct and there is a small difference)

As I was saying, it is more of a theoretical/technical question that arose when working with indexed images for the CX16.

[DragWx]

What you're noticing is, when there's an even number of something (like 16), the midpoint falls in between the middle two elements.

When you have 16 levels (0 to 15), the 50% point is actually level 7.5, and because of the "round to even" rule, it's usually rounded to 8. As weird as it seems, it is indeed impossible to achieve a perfect middle gray!

Consider a 1-bit display: black, white. Now a 2-bit display: black, dark gray, light gray, white. Notice how we can only add grays that are a half-step darker or lighter than the actual middle gray, with each bit that we add. Finally, with 8 bits, we still can't get a perfect middle gray (127.5 or $7F.8), but a step of 1/256 is so small that you can choose either $7F or $80 as your approximate middle-gray, and you'll be fine.

Here's the really crazy part though: the emulator is showing the exact right colors! (255 / 15 = 17), or ($FF / $F = $11). In other words, if you have a maximum value of 255, and you need to get from 0 to 255 in just 15 steps (which creates 16 levels since our starting value also counts), that step width is an integer, which means the 16 levels of a 4-bit display are also included in an 8-bit display; no rounding needed.

The same couldn't be said if the VERA used RGB555 or RGB565 instead (which are also popular "2-byte" color formats), but we wouldn't be able to see the rounding errors when scaled up to 24-bit color for an emulator. Also, let me say that RGB565 is especially evil for gray tones, and I'm incredibly glad it's not used here.

[hechelion]

Thanks for the answer, quite clear and makes all the sense.