|
|
Post by elmer on Apr 10, 2022 17:42:56 GMT
When talking about “artistic intent”, I’m convinced that the early developers used the tools naively and didn’t think much about it Honestly, when the console's manufacturer provides you with a program for editing your graphics, and then doesn't mention anywhere in the documentation that the colors that it displays on your PC's monitor *may* not be 100% accurate ... you can't be surprised that the developers "used the tools naively"!  … whereas the later developers who targetted PCE directly for their work looked closely at how it appeared on the actual PCE output on a TV, as the user would. I'm sure that some did, but from the amount of PCE games that are using brightest-white (7,7,7) as the color for large chunks of human skin in games, then I'm pretty sure that developers were not seeing a modern-PC 100%-white (255,255,255) when they were drawing. IMHO *no* European Atari ST or Amiga artist BITD would have used that color for skin (if they wanted to keep their job). I can only conclude that the Japanese artists were not seeing that bright a white on their screens, either their PC or their PCE, when they were developing their artwork. That is clearly the case if they were using Hudson's art tool, where brightest-white is 80%-white, and I feel that the same applies to the PC Engine's output when looking at my CRT TV screen. The brightest-white skin tone used in the intro animations for "Gate of Thunder" and "Madou Monogatari" looks good at 80%-white in Mednafen when using Hudson's palette, but it looks unreal and overly-contrasted when using the 100%-white that is in both Mednafen's default linear-step-by-36 palette and Kitrinx's current-best-approximation to the PCE's palette.
FWIW, "Gate of Thunder" also looks good (and not overly-contrasted) on my CRT TV screen.
And a third group - those who ported from, say, Amiga (Loriciel for example), just took existing RGB assets as-is, as much as possible. Which makes absolute sense given the size of the PCE market in Europe, and the lack of an documentation to tell them that they shouldn't! |
|
|
|
Post by dshadoff on Apr 10, 2022 18:21:59 GMT
… whereas the later developers who targetted PCE directly for their work looked closely at how it appeared on the actual PCE output on a TV, as the user would. I'm sure that some did, but from the amount of PCE games that are using brightest-white (7,7,7) as the color for large chunks of human skin in games, then I'm pretty sure that developers were not seeing a modern-PC 100%-white (255,255,255) when they were drawing. IMHO *no* European Atari ST or Amiga artist BITD would have used that color for skin (if they wanted to keep their job). I can only conclude that the Japanese artists were not seeing that bright a white on their screens, either their PC or their PCE, when they were developing their artwork. That is clearly the case if they were using Hudson's art tool, where brightest-white is 80%-white, and I feel that the same applies to the PC Engine's output when looking at my CRT TV screen. The brightest-white skin tone used in the intro animations for "Gate of Thunder" and "Madou Monogatari" looks good at 80%-white in Mednafen when using Hudson's palette, but it looks unreal and overly-contrasted when using the 100%-white that is in both Mednafen's default linear-step-by-36 palette and Kitrinx's current-best-approximation to the PCE's palette. FWIW, "Gate of Thunder" also looks good (and not overly-contrasted) on my CRT TV screen.
I'm not aware of any games using 7/7/7 for skin tone. Can you name one or two ? I'm not saying that you're wrong, but it just wouldn't make sense to do so under any conditions unless that was the artistic intent. I do know that in Japan, there is a preference/desire for fairer skin, especially starting around 1990; also many artists may have chosen to represent a "white" person without seeing one up close. Enough of the games get it right (or close enough) that I'm shocked to hear of any using 7/7/7 though. (Except maybe when representing kabuki and geisha/maiko who wear white makeup...) ...and as I had mentioned elsewhere, I'm not seeing improved contrast on the Startling Odyssey II screenshots here (across multiple monitors/machines now) - although I'm glad that you are. |
|
|
|
Post by turboxray on Apr 10, 2022 19:16:21 GMT
For folk to compare on their own PC's screens, here is the Startling Odyssey 2 background in both Hudson's, and the linear-step-by-36 palettes. Linear Palette ... <button disabled="" class="c-attachment-insert--linked o-btn--sm">Attachment Deleted</button> Hudson's Palette ... <button disabled="" class="c-attachment-insert--linked o-btn--sm">Attachment Deleted</button> Just an FYI- if you see a noticeable difference there between those two screen shots - you have a crappy LCD display and/or uncalibrated display. (I even had a 65" 4k display in the past with that problem) This is one of the issues with trying to post screen shots for people to look at. Even high-end devices like iphone 13 or whatever expense android.. have ramp profiles that can and will affect how this looks (they auto-correct color). Near-invisible colors are just one aspect of the difference between RGB output and VCE's comp output. But if you understand how color and brightness works, you'll understand that these are fringe colors - right on the edge. It doesn't take much to change (percentage-wise). As in crappy displays with gaps and uneven ramps can make these fringe colors appear distinct instead of hard of their true visibility. So.. one of the main reasons why the sky blue example is what it is, is that the YUV has a non-uniform luma stepping in the table (I've posted this many times); in RGB the difference between the two is 0/108/252 and 36/108/252. That difference between R of 0 and 36 contributes almost nothing for brightness, and almost nothing for hue (because of how strong the other values are - you can directly see this). But those values in the RGB to YUV table have a lot more going on; you have different step for red, green, and blue (relative to YUV) as well as luma itself. Your palette is just a monitor compensation for white crush. I'm it's pretty apparent; you have lower steps of 34 (and linear too) so that you don't hit the white crush point of the monitor, and even at that - you still have a non-linear compensate at the top. All that tells you, is that the monitors they were working with had a poor range/ramp. This doesn't mean anything about anything. That has nothing to do with this discussion about improper colors, and how the comp output is more than just less vibration translation of RGB. Your extract palette doesn't fix the sky blue issue. And it does nothing to address the oversaturated oranges, yellows, and browns. In your own screen shots, that dirt is 'orange-brown' (not brown-orange), some garish orange pixels mixed in; it's not in VCE comp output. I mean, yeah, it's an interesting find - but it doesn't have anything to do with this discussion (and the PCE's RGB or Comp out doesn't fit that white-crush correct ramp, so it's not even a match up there). I'm not aware of any games using 7/7/7 for skin tone. Same. The only thing I can see, is for 'phong' or shine on skin. And it still serves the same purpose if you're compensating for white-crush or not. Just a word of caution about the CRT thing; a CRT has soo much more going on than an LCD or whatever (a display that produces 'solid' pixels). 15khz signal is going to have non-linear scanline ramp influences based directly on the brightness of the color/pixel. It's simply because of beam 'bloom'. So dark colors will appear darker, relative to brighter colors - than they would with a solid pixel display (LCD, double-line CRT, etc). This is a 240p thing for 15khz displays. It's gives a completely different ramp. While that does affect the image, that's different subject and belongs with monitor simulation (scanline gaps, masks, bloom, etc). We're trying to distill the composite palette as its self, then at some other point you can apply CRT artifacts (which retrotink-5k can do). Building those kinds of things into palettes leads to issues. It's best done as a second image process. Besides the issues I already listed, this is even more true if you haven't calibrated and 'mapped' the whole range of your CRT. European artists did a lot of questionable things IMO haha. The whole muted color look of a lot of early Amiga games, so that color re-use through out the screen didn't look so jarring - just comes off as faded, no contrast, and dull. And those games did use muted greys and such for skin tone 'phongs'. |
|
|
|
Post by spenoza on Apr 10, 2022 19:57:19 GMT
My iPhone XR has a lovely screen and I definitely see a contrast difference. It isn’t massive. It’s rather subtle, actually, but I do notice it. I was expecting something a little more eye popping at first and glossed over it but came back and gave it a longer look. I should note, however, that I have True Tone turned off, so my screen isn’t auto-adjusting the color balance.
|
|
|
|
Post by turboxray on Apr 11, 2022 1:11:57 GMT
My iPhone XR has a lovely screen and I definitely see a contrast difference. It isn’t massive. It’s rather subtle, actually, but I do notice it. I was expecting something a little more eye popping at first and glossed over it but came back and gave it a longer look. I should note, however, that I have True Tone turned off, so my screen isn’t auto-adjusting the color balance. Contrast difference between the pics??? That should be noticeable. I'm talking about the sky band itself, relative to the color band above it, in either pic. On my iphone 12 both pics have the same stepping result; the delta isn't more pronounced between the two colors in one pic over the other. I mean, the iphone 12 makes the color delta a tiny bit easier to spot because it tints the lower band more towards purple than it should be (this is due to Apple's HDR remapping plus whatever vibrancy they're boosting) - but that's the whole point; the iphone screen isn't prioritizing accuracy. It's not crappy. It's just not accurate. |
|
|
|
Post by spenoza on Apr 11, 2022 1:33:01 GMT
If you have True Tone turned off your iPhone screen should be more color accurate than probably any other screen you’ll encounter outside of a professional design-oriented monitor.
|
|
|
|
Post by gredler on Apr 11, 2022 2:06:10 GMT
This discussion makes me curious the variations available that I should be testing on.
Right now I test across these platforms:
Stock core 2 with Composite on a crt
Stock core 2 with genesis 2 hd reteovision cables and a random breakout board I got in ebay
Rgb modded duo r with composite output (silly, I know)
Screen replaced express by Keith Courage
Stock defaults of bizhawk
Pce.emu android app on Samsung galaxy note 10+
I frequently jump between all of these across a few different tvs to try and make sure I am happy with it on aggregate between them.
|
|
|
|
Post by elmer on Apr 11, 2022 22:52:37 GMT
I frequently jump between all of these across a few different tvs to try and make sure I am happy with it on aggregate between them. That's pretty-much all I've ever seen done in professional dev, so from my POV (for whatever that's worth), I'd say that you're doing as much as you need to do!  For a short while, after colorimeters started to become reasonably-available, there was a developer-fad to calibrate TVs so that they were all "standards-compliant" for testing. The fad didn't last long at the time, because ... 1) It was a huge PITA. 2) That's not what 95%+ of the customers actually do to their TVs, so it was *far* more important to get a variety of TVs, and to see whether the games still looked reasonably decent on the widely-varying default settings that different manufacturers used to market their particular brands. |
|
|
|
Post by elmer on Apr 12, 2022 13:44:40 GMT
I'm not aware of any games using 7/7/7 for skin tone. Can you name one or two ? I'm not saying that you're wrong, but it just wouldn't make sense to do so under any conditions unless that was the artistic intent. Same. The only thing I can see, is for 'phong' or shine on skin. And it still serves the same purpose if you're compensating for white-crush or not. OK, here are a couple of examples for you, from Gate of Thunder and Madou Monogatari, snapshotted from Mednafen with no custom palette so that they using the default linear step-by-36 palette, and brightest-white (7,7,7) is 252,252,252. Yes, to both of you, a lot of these examples are absolutely "artistic intent" to show "phong", and yes, it still serves the same purpose if you're compensating for white-crush or not. We agree. What I'm saying is that all of these examples make a heck of a lot more artistic sense to me, as an ignorant-programmer, on the (probably crappy) LCD screen that I'm using, if I'm looking at them in the 80%-white that the Hudson's palette uses, rather than the 100%-white that either the linear-step-by-36 palette uses, or the 100%-white that Kitrinx's palette uses.    |
|
|
|
Post by elmer on Apr 12, 2022 13:46:09 GMT
|
|
|
|
Post by elmer on Apr 12, 2022 14:17:44 GMT
My iPhone XR has a lovely screen and I definitely see a contrast difference. It isn’t massive. It’s rather subtle, actually, but I do notice it. I was expecting something a little more eye popping at first and glossed over it but came back and gave it a longer look. As turboxray pointed out, I hope that you're seeing the difference in the middle sky tone, and not just noticing the overall drop in brightness between the 2 images!  Yes, the difference is subtle, and if I remember my biology classes it would be because the human eye is more sensitive to small color changes in darker colors, but if it lets an artist see something on-screen while editing that would otherwise be hidden, then it is a *useful* difference (IMHO). If artists do not see any *useful* difference on their (better-than-mine) LCD screens in comparison to the step-by-36 range, then they can just use the step-by-36 range and the world moves on.  |
|
|
|
Post by elmer on Apr 12, 2022 16:38:23 GMT
But if you understand how color and brightness works, you'll understand that these are fringe colors - right on the edge. It doesn't take much to change (percentage-wise). As in crappy displays with gaps and uneven ramps can make these fringe colors appear distinct instead of hard of their true visibility. So.. one of the main reasons why the sky blue example is what it is, is that the YUV has a non-uniform luma stepping in the table (I've posted this many times); in RGB the difference between the two is 0/108/252 and 36/108/252. That difference between R of 0 and 36 contributes almost nothing for brightness, and almost nothing for hue (because of how strong the other values are - you can directly see this). But those values in the RGB to YUV table have a lot more going on; you have different step for red, green, and blue (relative to YUV) as well as luma itself. Absolutely! We agree on all the points, but we don't seem to be finding a meeting-of-minds on the conclusion. Yes, as you say, the middle sky color's step of 36 in the red is difficult to see precisely "because of how strong the other values are". That's just how the human eye works. What I'm saying is that to *me*, on *my* crappy LCD monitor, using Hudson's palette, the difference between 0/102/204 and 34/102/204 is *more* visible, and therefore more usable for art-production, precisely because the 20% reduction in the top-of-the-range is doing less to drown-out the small change in the red. Until all art-production is done with tools that come closer to matching the PCE's composite output, I see some value in supporting the use of Hudson's palette as an optional-alternative to the linear step-by-36 palette. Neither of the two is a perfect solution for representing the PCE's actual composite output, but for art tools that only support limiting their color picker ranges to linear 3bit-RGB or 4bit-RGB, then artists are left with choosing which approximation they wish to use. A far-far-better solution is to do like 0x8bitdev has just done, and to add the ability for the color-picker to use a custom-palette, but that is the only tool that I know which allows that. The PCE development community *may* eventually get the open-source Grafx2 developers to support that too, and Jan *may* be willing at some point to add it to ProMotion ... but I can tell you right now that Adobe won't be supporting it in Photoshop for PCE artists at any point in the near-future! |
|
|
|
Post by elmer on Apr 12, 2022 17:23:41 GMT
European artists did a lot of questionable things IMO haha. The whole muted color look of a lot of early Amiga games, so that color re-use through out the screen didn't look so jarring - just comes off as faded, no contrast, and dull. And those games did use muted greys and such for skin tone 'phongs'. Hahaha ... touché!  But let me pick one thing out of the dig at us "bloody foreigners" ... "And those games did use muted greys and such for skin tone 'phongs'." Absolutely, a bright grey, say 6,6,6 in the Atari ST's linear 3bit-RGB palette (85%-white), is a good fit and contrast for that purpose, kinda like the way that the Gate of Thunder phongs look in 80%-white if you use Hudson's palette. Total coincidence? Hmmmmm, maybe!  |
|
|
|
Post by elmer on Apr 12, 2022 19:01:35 GMT
Just a word of caution about the CRT thing; a CRT has soo much more going on than an LCD or whatever (a display that produces 'solid' pixels). 15khz signal is going to have non-linear scanline ramp influences based directly on the brightness of the color/pixel. It's simply because of beam 'bloom'. So dark colors will appear darker, relative to brighter colors - than they would with a solid pixel display (LCD, double-line CRT, etc). This is a 240p thing for 15khz displays. It's gives a completely different ramp. While that does affect the image, that's different subject and belongs with monitor simulation (scanline gaps, masks, bloom, etc). We're trying to distill the composite palette as its self, then at some other point you can apply CRT artifacts (which retrotink-5k can do). Building those kinds of things into palettes leads to issues. It's best done as a second image process. Besides the issues I already listed, this is even more true if you haven't calibrated and 'mapped' the whole range of your CRT. I totally agree, and understand the importance of the work that's being done to try to get a more-accurate reference palette for people to use in their emulators, especially when the output is followed by that "second image process" that you mention. This is great work, and highly appreciated. And it is work that is still on-going, judging by Kitrinx's latest check-ins that I grabbed today. I know that there's also an effort to improve Mednafen so that its "second image process" stage (when enabled) will look better. But what this thread, and the associated screen captures show me, is that I've never really been that happy with the output of raw-Mednafen in comparison to a CRT TV, and that one of the things that has bothered me in particular is that the brightness and contrast displayed on my LCD screen seems "off", using either the default or the current-Kitrinx palette. So, since Mednafen doesn't actually seem to offer "Brigntness", "Contrast" and "Tint" knobs for me to mess with (does MiSTer?), then I have taken Kitrinx's latest code and just dialed down the "Brightness" knob a bit mathematically to produce a palette for Mednafen that is more pleasing to my eyes on my (probably crappy) LCD monitor. Thanks to y'all for doing this wonderful work, and super-thanks to Kitrinx for releasing the code publicly so that people like me can tweak it for our own displays.  |
|
|
|
Post by theoldgodfx on Oct 25, 2024 19:45:00 GMT
Was curious about this old thread, so joined this forum to revive this from the dead, even if only for a moment or two. The issues with Startling Odyssey 2 and others where some specific tones are missing or matching, is this tied mostly to use with LCD displays/emulation, or people using CRT's also? Personally, I've been treating PCE RGB to Component output like any other random Jamma pcb that produces too hot/bright colors. As in, in a cab, adjust the color pots, or on a supergun, after RGB being fed into a Jrok or Neobitz, just lowering the color setting on my crt display slightly. That seems to correct most of the issue on the display for me. I don't have an issue on my display, Samsung TX-P2034, seeing the lighter blue transition in the sky on Startling Odyssey 2, or the change in red tones on Ken's Karate gi in SF II', etc.
What I do notice is that in RGB, ghosting in relation to some objects with specific shades of white is still slightly present, as it was in composite (and very present in s-video). Examples of this would be like the clouds in Override generating some ghosting in the display, or the ghosting that happens on the Shinobi title screen. It reminds me of the ghosting that can occur on certain VHS players composite signal with certain tapes, like the Anchor Bay release of Evil Dead 2. Is this something that is just not possible to fix, in composite, s-video, or RGB?
|
|
