On Sat, 8 Mar 1997, Eckhard Stolberg wrote:
> NTSC PAL
>
> grey grey
It would be useful to establish actual RGB values for 2600 output instead
of just names. I realize that these are the 16 hue values available. You
won't be able to establish true RGB values just by grabbing screens
because the 2600 may be slightly off its center calibration and going from
RF or composite to RGB results in unpredictable results.
But it could be calculated mathematically. If you establish that there
are 16 hues, and 8 luminances per hue, then you should be able to convert
HSV to RGB to get at the internal values the 2600 is attempting to
generate. I could probably do it if noone else wanted to.
This is probably what emulator authors did, which also results in unique
problems when you run these RGB values on a computer monitor, which has
much different visual characteristics to NTSC monitors. RGB is almost
always darker with less color saturation. NTSC composite has "compressed"
bandwidth. The look of 2600 graphics is in part due to the
characteristics of NTSC (or PAL I guess) video. Authors should write with
this in mind.
So there is an "internal" RGB value, and then a conversion for the
apparent RGB when viewed on a TV. It differs from monitor to monitor,
which is why we have to start out at least by using the internal values,
and then average out some kind of conversion table for "apparent" RGB
values.
> orange gold
> orange green grey
> light orange grey
What seems odd about this is that the 16 hues on the left table do not
match up with the right table. There seem to be more hues available in
NTSC... For instance, there are no orangy hues in PAL, as these tend to
come out "grey".
Shouldn't the 2600 be able to generate all the same hues in PAL as it can
on NTSC?
--
To unsubscribe, send the word UNSUBSCRIBE in the body of a message to
stella-request@xxxxxxxxxxx
