VBA Accurate is still my favourite, just because it's the one that resembles more to an actual GBC. And it was you who convinced me of that: Post #455976
However, I can't ignore this argument in favor of Vivid:
Blazephlozard wrote:
if you hooked up a capture device to a Game Boy Color, it would output the same colors.
This basically means that all other palettes are just an hacked version of Vivid. And hacky solutions are bad.
Still, the Encoder Guidelines say that encodes should "appear, as closely as possible, as though the run was played on the original hardware", and the originally supposed hardware in this case was GBC. GBI is actually a later console that featured retrocompatibility for GBC games.
I also agree that we shouldn't crank down the brightness for GBA games, but that's because Nintendo specifically made an improved console, GBA SP, for fixing the brightness issue.
Reassuming:
VBA Accurate is a reasonably successful hacky attempt to visually imitate GBC colours.
Vivid is a faithful representation of the raw graphic data produced by the GBC internal video hardware, which also happens to match the visual output of a later retrocompatible official console, GBI.
Both options have their pros and cons, and I'm personally not sure which would be a better choice. Not that it matters much, as the final word on this matter it's not up to me.
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Just like NTSC means Never The Same Color, there's no "absolutely objectively perfectly accurate" palette for GBC, because the system had variations. What we can do tho is determining which palette corresponds to what device and encourage people to use them accordingly, instead of "I happen to like when it's all green, let's enforce it".
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
What we can do tho is determining which palette corresponds to what device
Define "corresponds".
Out of the two options I analyzed, the first subjectively corresponds to what appears to be displayed outside of the device screen, while the second objectively corresponds to the internal raw graphic data. Which one does "correspond to the device"?
Since you mentioned that NTSC means Never The Same Color and that the system had variations, I think you're saying to ignore the image physically observed on the device screen, and instead base the palette on the raw graphic data alone. But that's the opposite of what you decided to do last time, since you choose VBA Accurate.
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Raw data won't help because we're not watching those on the devices they were developed for, so it has to be some approximation of how they looked to a human in the end. With TVs it's completely impossible, but with handhelds it is maybe a bit more standard?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Yes, it makes sense. In a worst case scenario, we could make some live tests for improving the Gambatte or VBA Accurate palette, and I could contribute to that myself, since I own a functioning Game Boy Color.
Blazephlozard, in the post in which you compared the various palettes to a live photo, you said that "Under ideal lighting conditions, I do think a GBC screen's color shades look closest to Vivid's", but that's not what it looks to me from watching your comparison image, sorry. Also, I doubt that putting your Game Boy closely under a lamp could be considered as an ideal lighting condition, as that would be too blindly for being able to play comfortably.
I suppose I don't quite understand, because raw data seems to be what gets used for colors in GB and GBA encodes. So there's not much consistency here, even among handhelds.
In GB's case, well, it's really just white, black, and two grays, huh? So not much of a 'palette'. But still, there is no effort at all to emulate how a Game Boy game "looked to a human" on its original device. (Thank god.)
In GBA's case it seems their "Vivid" palette is the default, and I've never had an issue with it. I can try to compare that to console. I'm using Sabre Wulf as an example since I have it readily available and it does have lovely colors.
Game Boy Player output:
Encode:
Overall, I only see a shift in brightness/contrast between these two, with GBP being darker. But I'd say that's mostly a case of my capture setup / GBP compared to GBI being worse. Here's a good example of that, my capture compared to my example from Tikevin's output!
Here's the same comparison, but I applied Contrast +30 (Use Legacy) in Photoshop. Gets it pretty close.
So, I would say that my Sabre Wulf capture would look near identical to the encode, if my capture was at Tikevin's level. Close enough to not have a problem with it and say "this looks ugly", at least.
So, that means the palette used in GBA encodes, makes no effort to emulate the 'get the angle of your light source just right but everything's still dark and washed out' look. We all had to deal with that as a kid, and VBA Accurate (mostly successfully) does try to emulate that look for GBC. But there doesn't seem to be a precedent for handheld encodes to try to emulate that look. And emulating that look causes an arbitrary difference in colors that goes beyond a simple brightness/contrast adjustment.
If the argument is that GBA games are encoded as if they were on the best model of GBA SP, then I'd say there's a strong case that GBC games could also be encoded as if they were on a GBA SP, which I believe would be Vivid. (I don't own one to know for sure but from what I've seen and heard, their output should be the same as pixel-perfect GBI)
And likewise one could say GB encodes are done as if they're on a good GBA SP using the built-in Grayscale palette.
So it would create a coherence to Game Boy family encoding standards, using the greatest, officially made, handheld screen as the standard.
Moderator edit: Resized the images as they were breaking the page layout for some reason. Click on them to see the originals. — moozooh
I'm afraid you're forgetting a crucial fact about GBI: its supposed output interface is a home television, not an RGB signal capture device.
There are endless different television models, each with their own standards and quirks, which means we can't really have any consistent reference. In fact, these discrepancies between different TV models were taken in account for the making of some games, for example Crash Bandicoot, for which the main character was decided to be colored as orange and blue in order to be more likely to appear more vibrant on most TV models used at the time.
We could argue that OLED and AMOLED monitors could be used for having arguably more accurate, repeatable results, except that these were invented about 1 year after that Game Cube was released. Oops.
And even if we decided that using an external capture device is a valid way of defining a standard, how would we decide which capture devices or settings are more accurate? Look at the two GBI screens you provided in the last post. How can you be so sure that the latter GBI screenshot is more accurate? Couldn't be that the former one is actually closer to what the original game developers intended? For example, the "Z Button : Options", in the upper right, looks way too much bright to me, after applying the Photoshop filter you used.
Blazephlozard wrote:
In GB's case, well, it's really just white, black, and two grays, huh? So not much of a 'palette'. But still, there is no effort at all to emulate how a Game Boy game "looked to a human" on its original device. (Thank god.)
I agree that it may apparently seem inconsistent to use a grayscale palette for GB encodes, but guess what? GB is just like a TV, it doesn't give consistent results, so it's fine to enforce our own standard for it. Guess why? Well, take a look at this:
Since the user is able to regulate the contrast level at any time during play, it effectively means that it's impossible to define an objective standard palette.
Blazephlozard wrote:
If the argument is that GBA games are encoded as if they were on the best model of GBA SP, then I'd say there's a strong case that GBC games could also be encoded as if they were on a GBA SP, which I believe would be Vivid. (I don't own one to know for sure but from what I've seen and heard, their output should be the same as pixel-perfect GBI)
Again, just like GBI, the fact that GBA features retrocompatibility for GBC games doesn't mean that GBC games were developed for GBA. They were still developed for GBC, and the GBA retrocompatibility was just a little extra for making the game generation jump slower. It's true that some later GBC games occasionally featured GBA-only contents, but these were just basic routines checking if the console model is a GBA, and thus awarding the player with game contents that could still have been accessed via the GBC hardware just fine (in fact, you can still access them on GBC by using Game Shark codes).
Possible slight confusion in abbreviations, my captures (any with Z Button: Options) are the stock Game Boy Player software, so not "GBI". The GBP software does apply some blur/resizing to it, and possibly a contrast reduction it seems. Game Boy Interface is homebrew that still uses the GBP hardware (which is really just a GBA that plugs into a Gamecube) and provides a more raw output. (The contrast difference could also be just a matter of composite/s-video or my capture setup, compared to tikevin's)
But, it would be fine if there was a palette aiming to match the darker colors of that GBP capture for one key reason: It's only a difference in contrast. The VBA Accurate palette (and even more so of course, the Gambatte palette) changes the game's colors in a way that a contrast adjustment can not fix. That's what makes VBA Accurate look wrong, and makes me hate seeing this game using it.
I think the "GBA SP" approach is better than a "GBP/GBI" approach though, as it removes TVs from the equation. Either way, it is all GBA hardware, so it doesn't help with the "match GBC hardware" argument... If GBC had an official backlit release, would Vivid be the standard already?
Considering TASvideos ends up making RGB888 encodes, I don't see why there'd be an issue with using the game's RGB output as the basis for the colors in the most direct way possible... GBC is RGB555, so 5 bits for each color instead of 8, which should mean there can't be a 'perfect conversion', as some have to be slightly rounded up or down. But it's the closest, most logical approximation.
I'd be very very curious if anyone knows the origins of VBA Accurate's palette, and really all the palettes in general. Because all of them are just taking the color data the ROM code is outputting, and assigning a color to that in a presumably logical way, yes?
I would guess the Vivid palette is basically, "0b11111 = 0b11111111, 0b0 = 0b0, scale the rest the best you can", a typical RGB5->RGB8 conversion. What's done to the GBC's 5-bit color data to output VBA Accurate or Gambatte?
Looking into this more, I'm surprised by how well done this Wikipedia article is done: https://en.wikipedia.org/wiki/List_of_video_game_console_palettes#Game_Boy_Color
Most interestingly, GBA is also 15-bit color, further reducing any reason for GBC and GBA to have different encoding standards of how their color output is treated (since GBA's encodes seem to be accurate to the raw data in the same way GBC Vivid is).
Is GBC really only treated this way because it never got a backlit rerelease, and doesn't have a contrast option? Is there any other system encodes whose color data gets danced around?
Ambassador, Moderator, Site Developer, Player
(155)
Joined: 3/17/2018
Posts: 358
Location: Holland, MI
GBI's LUTs were based on shaders designed to match an array of original consoles and generally behave better than the Gambatte default palette.
GBI LUT examples
https://www.gc-forever.com/wiki/index.php?title=Game_Boy_Interface/Standard_Edition#Color_matrix
The shaders
https://forums.libretro.com/t/real-gba-and-ds-phat-colors/1540
I'm more than happy to do a 1:1 console capture with a preferred LUT, but I think there's a fair argument to using the identity RGB555 colors (BizHawk Vivid) as I do in my 4k captures since any LUT correction assumes that the developer themselves corrected the game in exactly that same way to account for the console's LCD.
Ambassador, Moderator, Site Developer, Player
(155)
Joined: 3/17/2018
Posts: 358
Location: Holland, MI
I made a PR to address Gambatte's default palette being nonsensical. It uses the behavior documented in the libretro GBC shader linked above to more closely mimick the GBC LCD.
https://github.com/TASVideos/BizHawk/pull/1917
Far left is Vivid (no color mixing), middle is Gambatte, right is the shader from libretro forums.
Is that really what it looks like? That looks really washed out to me. Do you have a real screen pic for comparison?
EDIT: I looked at some youtube videos and I guess it's pretty close, would still be good to see a high res pic though to compare.
Ambassador, Moderator, Site Developer, Player
(155)
Joined: 3/17/2018
Posts: 358
Location: Holland, MI
It certainly looks closer to me based on this extremely unscientific picture from Blazephlozard. It matches the cheeks and the blue in the logo more closely, and the general shade of pikachu isn't such a deep orange.
I hoped discussion could continue and perhaps the new shader split into a different option if preferred, but the PR was merged immediately.
*I'm making a new PR to change it to a separate option instead of rewriting the Gambatte palette code
Yeah actually Vivid is terrible, I change my mind oopsies. Well, I think it looks really nice for Pokemon TCG in general, but, using that game's tans and oranges to compare the palettes was evidently too narrow-minded. The Pokemon Yellow title screen examples have really opened my mind.
Pikachu is definitely not 'supposed' to be highlighter yellow, regardless of what the raw color data says.Vivid palette's RGB for the yellow there is 255/255/0, so it's a good benchmark for "this is the brightest yellow possible". (In addition, his cheeks are 255/8/8, and the Pika! blue is 0/0/140, providing benchmarks for red and dark blue)
But right now I would say none of the GBC palettes available look accurate to the screen then. If my big hub-bub might get a better palette made and accepted, hooray!
And yeah, I broke out the ol' GBC again, I have a better phone camera than I used a few years ago at least. But it is absolute hell to try to take a truly good picture, because your shadow gets in the way. That picture actually turned out pretty well, because it's a gradient from low, to mid, to high light. I would say approaching the high light area of the picture is what it actually looks like playing normally at a good angle. (around 2/3rds of the image from the left)
(click for large)
Right now I would say that yes it is a little too washed out. For example his cheeks are too close to pink instead of red. I applied +15 contrast in Photoshop and compared my screen directly to that result as much as I could, and found the Pika! blue, and red cheeks to be basically spot on; the yellow could maybe stand to be slightly less white (slightly closer to VBA Accurate).
The blue shadow of the Pokemon logo is particularly interesting to look at on Vivid and VBA Accurate, where both have it much more of a purple, but it's not purple whatsoever on a GBC. And overall Accurate is just too dark, in a way that makes it look off to me. I'm excited for this middle ground between highlighter yellow and mac and cheese!
Is GBC really only treated this way because it never got a backlit rerelease, and doesn't have a contrast option? Is there any other system encodes whose color data gets danced around?
Neo-Geo Pocket is a console very similar to Game Boy Color, under many aspects. However, that's much less widespread, so I guess it has been analyzed much less than any Nintendo hardware. It was never released in America. As for me, I didn't even once see a real NGP in my whole life, even though I live in an European country, Italy.
Blazephlozard wrote:
Yeah actually Vivid is terrible, I change my mind oopsies. Well, I think it looks really nice for Pokemon TCG in general, but, using that game's tans and oranges to compare the palettes was evidently too narrow-minded. The Pokemon Yellow title screen examples have really opened my mind.
I don't feel that Vivid is good for Pokémon TCG, maybe it doesn't appear so to you because it's a game that features small colored images only.
Let's take a look to a particularly colorful game instead. I happen to own a copy of Pokémon Puzzle Challenge (USA version) and I was able to take a couple of photos. The photo quality was the best I could get by shooting them at 8:30 AM, with indirect sunlight. Note that even if you shoot your photo by having your Game Boy Color screen under direct sunlight, the colors won't get more vivid. Anyway, not that it could be considered as an ideal lighting condition, since that would burn the LCD screen.
In the following comparison: a live photo (unedited), Gambatte palette, VBA Accurate palette, Vivid palette. Click for larger image.
I don't know about you guys, but to me the Vivid palette does look not only far from reality, but also ugly to look at. The colours are so strong that it almost hurts my eyesight, so I really doubt that it's in any way remotely supposed to be like that.
For the rest, VBA Accurate still looks the best to me.
Ah, welcome to the horrible world of taking pictures of GBCs. Puzzle Challenge's intro is a great choice.
Well, I tried to take a few if that helps. I tried having more light and making the shadow balance it out in the second one. (My Chikorita scene ones sucked)
Personally, it still looks like a middle ground between VBA Accurate's dark tones and the current new shader's overly light tones might be just right
I do like the look of the +15 contrast example, though I have to admit the libretro shader does look closer to correct for the red and yellow, blue looks more accuracte in the +15 contrast though.
But that's just me and I don't know how well the picture represents reality, nor do I own a GBC to check.
I think libretro and +15 contrast are way too bright compared to live photos.
From watching Blazephlozard's comparison, I must admit that Gambatte is closer than VBA Accurate. Gambatte's colors are slightly dull, but that's just how actual GBC screen appears in real life.
I think libretro and +15 contrast are way too bright compared to live photos.
From watching Blazephlozard's comparison, I must admit that Gambatte is closer than VBA Accurate. Gambatte's colors are slightly dull, but that's just how actual GBC screen appears in real life.
Well, the objective isn't to match live photos, it's to match live eyesight, right?
I think libretro and +15 contrast are way too bright compared to live photos.
From watching Blazephlozard's comparison, I must admit that Gambatte is closer than VBA Accurate. Gambatte's colors are slightly dull, but that's just how actual GBC screen appears in real life.
Well, the objective isn't to match live photos, it's to match live eyesight, right?
Eyesight is subjective, misleading. I myself did mistakenly prefer VBA Accurate over Gambatte because it looked prettier, instead of trying to see which one was closer to reality. Confirmation bias at its finest.
I'm really curious to know how the Gambatte developers did come up with their current palette. I wonder if they did practical tests on real hardware, and how.
Ambassador, Moderator, Site Developer, Player
(155)
Joined: 3/17/2018
Posts: 358
Location: Holland, MI
We do not know how Sinamas calculated the components for color mixing in Gambatte's palette. The libretro shader applies the same mixing as Gambatte, but accounting for the complexities of color theory like non-linear color spaces and gamma correction. The problem is that as alyosha observed while the reds and yellows (and in my opinion the greens) look pretty close, the blue doesn't match. The GBC LCD can do shades of blue that are outside the range to be encoded for and represented on typical monitors.
More research could be done to document precise color mixing components with the proper equipment, but in the meantime I'm happy to work on adding options given the available documentation from different emu developers
I think libretro and +15 contrast are way too bright compared to live photos.
From watching Blazephlozard's comparison, I must admit that Gambatte is closer than VBA Accurate. Gambatte's colors are slightly dull, but that's just how actual GBC screen appears in real life.
Well, the objective isn't to match live photos, it's to match live eyesight, right?
Eyesight is subjective, misleading. I myself did mistakenly prefer VBA Accurate over Gambatte because it looked prettier, instead of trying to see which one was closer to reality. Confirmation bias at its finest.
I'm really curious to know how the Gambatte developers did come up with their current palette. I wonder if they did practical tests on real hardware, and how.
You're using your subjective eyesight to compare low-quality pictures of a screen to emulator screenshots... So why not cut out the middleman and just compare the actual screen to emulator?
And if you're really saying Gambatte is more accurate than VBA Accurate now over one shade of yellow being better despite its proven inaccuracies in other areas, THAT'S confirmation bias. Also you haven't mentioned the new shader...
It is definitely subjective, and only accounts for a few possible colors, but for the Pokemon Yellow title screen, libretro shader has clearly more accurate yellows, reds and ESPECIALLY blues than VBAA or Gambatte palette, even comparing to the photos and especially when comparing to the GBC itself.
Like, "Gambatte vs. VBA Accurate" shouldn't even be a topic of discussion, it should be "what adjustments should libretro get"
We need more eyes on this...
Hmm, here's a quandary when it comes to attempting to match the screen's colors. Should a pure white not exist?
One thing that's interesting in TCG is that instead of white, the game uses a tan color in the background.
On a GBC screen, which is basically tan when off, this tan is nearly identical to white, with all current palette options having far too much of a difference between the two colors. It's easiest to see during the intro scene, which is white, then switches to tan for the Base Set pack and for the title screen. It also makes screen transitions less seizurey (not that white->tan->white->tan should trigger epilepsy, but there is a jarring change in color to be sure, that isn't visible on GBC).
One way to have constant transitions between tan and white is just to hold soft reset. I've filmed that here as best I can (there is a very very slight shift in colors, about matching what I see IRL), and this is what emulator palettes output:
https://youtu.be/6WRM-6hRrwYhttps://youtu.be/IR132o4bJQA
So, there's definitely a huge discrepancy between a GBC screen's "white" and emulator's white... But should that mean we display white as tan?
Surely developers intended their whites to be white; and our brain looking at a GBC screen can assume things matching the natural screen color are white, just like on a GB screen you know nothing is meant to be green. So perhaps tan should be changed to be closer to white, rather than the other way around?
But at the same time the reds/blues/yellows in libretro could stand to be slightly darker, so I don't think the RGB conversion formula could handle both...
What do the colors on a physical GBC look like with the screen cover off? (I'm assuming that the lcd display is kept protected from The Rest Of The World with a layer of plastic)
Uhm, now that I think about it... Everything we said here doesn't apply if we're playing a game in GBCinGBA mode, since that literally means that GBA (or GBI) is the hardware that it's being emulated, and the palette used should reflect that... Right? And the objectively correct palette for GBCinGBA mode is Vivid, as it reflects to what we already use for GBA movies.
Since the Vivid palette can potentially make some GBC movies less appealing (see Pokémon Puzzle Challenge), I think that we should allow GBCinGBA only for Moons and Stars movies, unless that mode is being used for accessing GBA-only content (see Wendy: Every Witch Way) or if the game has a built-in color adjustment logic (see Harry Potter). EDIT: Actually, that makes things worse, as the GBC games that adjust colors for GBA are actually taking as refer the original GBA only, as opposed to the later commercialized GBA SP that featured a backlight that improved brightness. So, I my opinion, GBCinGBA should still not be allowed for Vault if it accesses purely aesthetic routines only.
Pokota wrote:
What do the colors on a physical GBC look like with the screen cover off? (I'm assuming that the lcd display is kept protected from The Rest Of The World with a layer of plastic)
Encode:
Overall, I only see a shift in brightness/contrast between these two, with GBP being darker. But I'd say that's mostly a case of my capture setup / GBP compared to GBI being worse. Here's a good example of that, my capture compared to my example from Tikevin's output!
Here's the same comparison, but I applied Contrast +30 (Use Legacy) in Photoshop. Gets it pretty close.
So, I would say that my Sabre Wulf capture would look near identical to the encode, if my capture was at Tikevin's level. Close enough to not have a problem with it and say "this looks ugly", at least.
So, that means the palette used in GBA encodes, makes no effort to emulate the 'get the angle of your light source just right but everything's still dark and washed out' look. We all had to deal with that as a kid, and VBA Accurate (mostly successfully) does try to emulate that look for GBC. But there doesn't seem to be a precedent for handheld encodes to try to emulate that look. And emulating that look causes an arbitrary difference in colors that goes beyond a simple brightness/contrast adjustment.
If the argument is that GBA games are encoded as if they were on the best model of GBA SP, then I'd say there's a strong case that GBC games could also be encoded as if they were on a GBA SP, which I believe would be Vivid. (I don't own one to know for sure but from what I've seen and heard, their output should be the same as pixel-perfect GBI)
And likewise one could say GB encodes are done as if they're on a good GBA SP using the built-in Grayscale palette.
So it would create a coherence to Game Boy family encoding standards, using the greatest, officially made, handheld screen as the standard.
Moderator edit: Resized the images as they were breaking the page layout for some reason. Click on them to see the originals. — moozooh
Since the user is able to regulate the contrast level at any time during play, it effectively means that it's impossible to define an objective standard palette.
Far left is Vivid (no color mixing), middle is Gambatte, right is the shader from libretro forums.
I hoped discussion could continue and perhaps the new shader split into a different option if preferred, but the PR was merged immediately.
*I'm making a new PR to change it to a separate option instead of rewriting the Gambatte palette code
(click for large)
Right now I would say that yes it is a little too washed out. For example his cheeks are too close to pink instead of red. I applied +15 contrast in Photoshop and compared my screen directly to that result as much as I could, and found the Pika! blue, and red cheeks to be basically spot on; the yellow could maybe stand to be slightly less white (slightly closer to VBA Accurate).
The blue shadow of the Pokemon logo is particularly interesting to look at on Vivid and VBA Accurate, where both have it much more of a purple, but it's not purple whatsoever on a GBC. And overall Accurate is just too dark, in a way that makes it look off to me. I'm excited for this middle ground between highlighter yellow and mac and cheese!
I don't know about you guys, but to me the Vivid palette does look not only far from reality, but also ugly to look at. The colours are so strong that it almost hurts my eyesight, so I really doubt that it's in any way remotely supposed to be like that.
For the rest, VBA Accurate still looks the best to me.
Personally, it still looks like a middle ground between VBA Accurate's dark tones and the current new shader's overly light tones might be just right
