Improper colors

[spenoza]

I dunno about over-saturation. Most modern iPhones follow the RGB gamut pretty closely and have excellent and near-perfect color response. But that’s off-topic, so...

I don’t have RGB anything, sadly. Do we know how the color output of the PC Engine Mini looks compared to original?

[gredler]

Fantastic discussion, thanks for this!

[turboxray]

Jun 22, 2020 17:20:39 GMT SignOfZeta said:

Bonk never looks right in RGB. That’s about all I can contribute to this conversation.

He looks good running in Mednafen on my iMac but not the same. On actual RGB modded systems he doesn’t look particularly good or correct.

The thing that has to be considered regarding composite is that isn’t not just an additive process of R, G, and B, it’s usually missing information in certain bands. VHS tapes murk it a lot more than chips do but even chips producing “super NTSC” grade composite will still have less chroma resolution in certain ranges than you’d get from RGB.

So therefore it’s never going to look identical. It’s going to have uneven color response. If the game was made around the specific trend of the Hu chip then RGB will possibly never produce it without a filter.

I swear some of the HDMI or whatever adapters for the PCE (or just RGB?) saturate even more than what RGB does over Composite. Bonk's Adventure looks horrible. To the point where I'm surprised no one has released a color hack so he's not so orange haha. 

 But even if you take Composite and crank up the saturation (which all my friends did with their Duos when playing on an SD TV bitd), it doesn't have that over saturated-warmth-look that RGB has with PCE games. Some games that try to over saturate on the PCE's composite, like Bomberman '93, are just blown out even more in RGB color space. I do think some people just associate over saturation with "higher quality". 

 Edit: You can't really rely on capture cards (at least for composite). The aren't made for any sort of accuracy.. they're made to capture you VCR footage in the best possible image quality. I've used 5 different cards over the years.. non of them are accurate. A lot of them have filter options that you can't actually turn off without modded drivers, and force settings like through Vdub.

[turboxray]

Jun 24, 2020 15:11:38 GMT turboxray said:

Figured I would share this from Artemio. If you know to read waveform and vector output of NTSC video, there are some interesting things about PCE composite video.




A few things definitely immediately standout

1) Cyan is not at the right brightness level (which the next group of colors follow behind it, have relatively correct stepping except blue, which means they're all less bright as well)
2) Blue is not at the right brightness level (more than just a shift down like the colors above it).
3) Not surprising that the video doesn't start at IRE 7.5 (seems no consoles of that era do), but the max luma never hits 100 IRE (it's 90 IRE).

On the vector side..


None of the colors reach their target (that's very weird). And I don't mean just max saturation, but far from its mark. Also, Red and Cyan are noticeably off and not in the color space they're supposed to be in. Yellow and Blue are only slightly off.


Besides the custom YUV table in the VCE, these characteristics for the composite signal (also generated by the VCE internal) are also what gives the PCE its unique palette.

From the other S-video and component mod thread.
For reference: 

[apolloboy]

It looks like Voultar has been doing some research into this issue:

[dshadoff]

So, as I explained in the Repairs and Mods subforum, the Y/B-Y/R-Y table was extracted from the Hu6260, and a mapping matrix from these values to RGB values was derived, by taking some samples from a snapshot from a composite video capture device.  A full transformation formula was derived (but I won't share that, as there is still a lot of fine-tuning going on).

What I can share is a Mednafen palette file (NOT FINAL !) and a couple of snapshots.

In order to use the palette file in Mednafen, just drop the file in the relevant "palette" directory (which is next to the "sav" and "snaps" directories where the save files and screenshots go), which is normally beneath the Mendanfen base directory.


This isn't the final version of the palette, but I think it's the best one yet.


pce.pal (1.5 KB)

[Black_Tiger]

Jun 30, 2020 14:45:40 GMT dshadoff said:

So, as I explained in the Repairs and Mods subforum, the Y/B-Y/R-Y table was extracted from the Hu6260, and a mapping matrix from these values to RGB values was derived, by taking some samples from a snapshot from a composite video capture device.  A full transformation formula was derived (but I won't share that, as there is still a lot of fine-tuning going on).

What I can share is a Mednafen palette file (NOT FINAL !) and a couple of snapshots.

In order to use the palette file in Mednafen, just drop the file in the relevant "palette" directory (which is next to the "sav" and "snaps" directories where the save files and screenshots go), which is normally beneath the Mendanfen base directory.


This isn't the final version of the palette, but I think it's the best one yet.

Both look good. I don't have a shot of that SAII scene to compare, but Bonk now has flesh tones instead of looking orange.

[samiam]

Jun 30, 2020 14:45:40 GMT dshadoff said:

So, as I explained in the Repairs and Mods subforum, the Y/B-Y/R-Y table was extracted from the Hu6260, and a mapping matrix from these values to RGB values was derived, by taking some samples from a snapshot from a composite video capture device.  A full transformation formula was derived (but I won't share that, as there is still a lot of fine-tuning going on).

What I can share is a Mednafen palette file (NOT FINAL !) and a couple of snapshots.

In order to use the palette file in Mednafen, just drop the file in the relevant "palette" directory (which is next to the "sav" and "snaps" directories where the save files and screenshots go), which is normally beneath the Mendanfen base directory.


This isn't the final version of the palette, but I think it's the best one yet.

Wow, it's that simple to change Mednafen's palette?

Right now, all my equipment is taken apart to be moved from one room to another. When I get things back up, I really want to try this with the emu4crt Mednafen fork. 

[dshadoff]

Well, certainly there is some work in building the palette itself, but Mednafen has apparently had this facility for quite a long time.
Not only are palettes a hot topic in the NES world, but it seems that PC Engine people spoke about palettes way back when emulators first came into being. However, since the base RGB colors are quite close, and there was no way of determining a more appropriate set of colors at that time, I don't think anybody came up with a replacement palette until now.

[Black_Tiger]

Jun 30, 2020 14:45:40 GMT dshadoff said:

So, as I explained in the Repairs and Mods subforum, the Y/B-Y/R-Y table was extracted from the Hu6260, and a mapping matrix from these values to RGB values was derived, by taking some samples from a snapshot from a composite video capture device.  A full transformation formula was derived (but I won't share that, as there is still a lot of fine-tuning going on).

What I can share is a Mednafen palette file (NOT FINAL !) and a couple of snapshots.

In order to use the palette file in Mednafen, just drop the file in the relevant "palette" directory (which is next to the "sav" and "snaps" directories where the save files and screenshots go), which is normally beneath the Mendanfen base directory.


This isn't the final version of the palette, but I think it's the best one yet.

Is this palette based on a set of specific RGB values, like how Mega Drive uses 0, 52, 87, 116, 144, 172, 206, 255... or does each individual color have unique values?

[dshadoff]

Jul 7, 2020 16:07:12 GMT Black_Tiger said:

Is this palette based on a set of specific RGB values, like how Mega Drive uses 0, 52, 87, 116, 144, 172, 206, 255... or does each individual color have unique values?

Inside of the Hu6260, there is a LUT which decodes each of the 512 colors into Y, B-Y, and R-Y values (similar to YUV).  This mapping is not the same mapping as you might use for translating straight from RGB to YUV; it accentuated certain brightness variations, and is designed to make the most of what your eye can perceive (unlike RGB).  This was what started the thread... the fact that this 512-entry LUT exists and now has been decoded.

The next stage is to modulate into composite, which has another layer of math, and then to demodulate back into RGB values.

This particular palette made the assumption that modulation did not alter the signal, and that demodulation was just a few math transformation similar to "601" format, (but with a few added tweaks).

Since then, we have moved forward and found a few more pieces of information to refine it a bit more... but perhaps turboxray is better-equipped than I am to describe what math is now being used, and how close to "final" we are.

[turboxray]

Jul 7, 2020 16:07:12 GMT Black_Tiger said:

Jun 30, 2020 14:45:40 GMT dshadoff said:

So, as I explained in the Repairs and Mods subforum, the Y/B-Y/R-Y table was extracted from the Hu6260, and a mapping matrix from these values to RGB values was derived, by taking some samples from a snapshot from a composite video capture device.  A full transformation formula was derived (but I won't share that, as there is still a lot of fine-tuning going on).

What I can share is a Mednafen palette file (NOT FINAL !) and a couple of snapshots.

In order to use the palette file in Mednafen, just drop the file in the relevant "palette" directory (which is next to the "sav" and "snaps" directories where the save files and screenshots go), which is normally beneath the Mendanfen base directory.


This isn't the final version of the palette, but I think it's the best one yet.

Is this palette based on a set of specific RGB values, like how Mega Drive uses 0, 52, 87, 116, 144, 172, 206, 255... or does each individual color have unique values?

I mean, you can think of them as specific RGB values. Like Dave has said, there isn't any RGB in the VCE per se. The 9bits total of RGB values you write into CRAM for the PCE, are just used as an index into a table. If you're not familiar to what that means, a table works like this: table = [0,2,4,9,11,15]. If you gave a value of blue 0/0/1 which is 001, you would use the direct value to "index" the table. So table[001] = 2.
There are two color spaces in the PCE: RGB and raw YUV. So the RGB value is used for two things.. it's sent directly to the RGB output pins. The second part is that RGB value is used as an index into a 512 YUV table.

The YUV space, part of this whole issue, comes in multiple layers. For one, 99% of RGB to YUV is done via an external chip because you do this conversion in the analog domain. The PCE is unique in that it does the conversion inside the chip, in the digit domain. I.e. the RGB to YUV conversion table (there's a YUV ROM in the VCE, and this was dumped recently).

A bit about math and color space conversions. RGB does not map to YUV with the same precision. So the YUV table is made up of three entries.. obviously being Y, U, and V. The Y/U/V elements are 5bits each, so 15bit color total or 32k colors. That sounds like a lot, and you would think 512 RGB colors would easily map closely in 15bit YUV.. and you would be very wrong. For one, 512 RGB actually has over 500 brightness levels to all the colors. 15bit YUV only has 32 levels of brightness.

Here's the normal 9bit RGB with all the color stripped out and just brightness (luma).

And here's the same captured from the composite video without color (just luma).

That course brightness stepping (can you clearly see where two and even three entries share the same brightness) is a result of the 15bit YUV table, or rather the 5bit Y range. It doesn't have anything to do with "composite". The Genesis and Snes does not have this artifact. If we stopped right here, that would literally be enough of a difference between straight RGB and VCE's Y/B-Y/R-Y output. But there's still more..

A second thing to note is color:

This is a little more difficult you read. This is a vector scope image of IQ, or just the color information. This is from my 512 color demo (made a new demo for better reading and sampling). YUV is converted to YIQ (composite) as both color spaces are very similar. Brightness, or Y, doesn't affect the colors (dot) on this scope. If you look closely on the mask, you'll see boxes with R(ed), G(reen), B(lue), C(yan), Y(ellow), M(agenta). The rotation/angle on the image is the color, and how far it is out from the center is the saturation. The PCE VCE actually has less saturated color, as everyone with a real systems knows, so this is scaled up - but it's a linear scale so everything is in proportion.

Okay, so the color.. Y is not on its mark.. but leans towards green (but it's not over saturated). Red is on mark and not over saturated. Magenta is over saturated but on mark. Cyan is on mark but a little under saturated. Blue leans towards magenta. It doesn't matter if you rotate the whole set (hue) - their relationship is fixed. Why is this? Remember the components of U and V are only 5bits each as well. They are also translated it IQ of YIQ (composite and svideo color space, which is YUV color space rotated some 33 degrees). There's some attempt by the VCE to keep the color accurate such as the real 8 grey scale values have a special I/Q bumps on the signal to keep them pure (no color info) for those specific levels. The I and Q channels (labeled R-Y and B-Y on the chip pins) are non linear - but not exactly polynomial in ramping. Ehh this is getting too technical.

So the last part in that color chart.. there aren't "512" dots, one for each color, because there are colors that are repeated.. with just brightness as the difference. There about 169 color dots there. But if you look the pattern, not are angles approaching Blue and Yellow are off mark, but there's a slight "wave" to them as well from the Blue to Yellow axis (inside curvature), and the line from Red to Yellow, and Cyan to Blue (outside curvature). This isn't some analogue domain variances for or such. Remember, this is all generated digitally and inside the VCE - and this exists before it's all combined into CVBS in the external circuit. This is also consitant across all PCE systems tested so far.

The last things, is the waveform monitor. I can't include a pic here because I can only include 3 attachments per post, but the brightness of some colors are not linear either. Cyan, which looks slightly under saturated in the above vector image, is actually not as bright as it's supposed to be (the vector scope can't show this). So it's not just that Y (luma) is course 5bits but the of brightness for those colors are also very unique and easy to see they are not uniform (relative to each other).

What does this all mean? It means you get a more unique set of RGB values. And values that are otherwise useless in straight RGB space, but have a use in the PCE's unique YUV (external) space.

In relation to Startling Odyssey 2, the blue sky band is just one example. The overworld has green colors in the grass that you can't see in RGB. Same in the bushes/trees. The reason why it doesn't show out in RGB, is that the difference of Blue from 0 to 36 (one step) or just Red from 0 to 36 (one step), does not provide enough "brightness". The colors don't contribute to enough brightness in the low end as compared to the high end (say a single step from 182 to 222, which does show a perceptual difference).

One could simply use a professional grade capture card and decode the RGB table that way, and I've already captures all 512 colors on each Y, B-Y, R-Y pins with my oscilloscope 100mhz, but we wan't to be able to provide the math for the most accurate translation.

Also keep in mind, none of this takes into account that NTSC-J vs NTSC IRE 7.5 Luma discrepancy or the whole 6500k US/NA sets vs 9000K Japanese TV sets. It appears none of the other consoles at the time took this into account either (when they made US/NA regions of those systems). But the IRE thing can be applied afterwards if you that authentic experience of the whole US/NA black level clipping thing.

So yeah, it's definitely a unique set of "RGB". It's not the more apparent "can see invisible colors now", but saturation and brightness relative to color across ranges and across axis (not just 4 axis).

(Forgive any typos.. I typed this pretty quickly).

[turboxray]

Can you spot the extra color in her hair? Left is straight RGB, right is one of the work-in-progress palettes we're trying to RE from the table.

[Black_Tiger]

Thanks for breaking everything down. Since that custom palette file was for Mednafen which outputs RGB colors, I was curious how it manifested.

I took a screenshot of Chris' 512 color demo and saw that each color is indeed unique and that colors are not currently in a consistent transition. So straight red and blue favor the dark end and never reach full RGB red or blue value. The brightest straight red also has a big chunk of blue in it.

It will be interesting to see what the RGB equivalent of the final palette will look like, since we can only work in RGB color for pixelart.

If you mean the girl's green hair in that DH screen cap, I can see a shade between the dark and light green on my phone in both.

[nicole]

I'm curious how this interacts with the TurboExpress; does that use the raw RGB or does it also go through this lookup table?