Real GBA and DS-Phat colors

The github one is correct as the most recent update. So to answer your questions.

  1. If you want to manually set it up, load shader 0 with gamma control for desired handheld (gbc, gba, or others) and set to nearest 1x. shader 1 would be the LCD shader, correct. Must match to whichever integer scaling retroarch sets to, along with using nearest filter. After that, shader 2 will use the color correction shader at nearest 1x. So yeah, that order is correct.

  2. Accurate ones would be ones that uses subpixels. LCD-Grid-V2 would fit the usage, as long as you leave the lcd gamma at 2.2 as the gamma correction shader does its job. The V2 supports BGR subpixels that GBA uses. Although on Android with Vulkan, the subpixels are misaligned only on LCD-Grid-V2 for whatever reason, but not sure about on ios. May behave better under metal. More accurate ones would be either Authentic-GBC shader due to its more accurate subpixel rendering (minus the lack of BGR layout), or load the first two shaders from LCD-Shaders. For best results, Authentic-GBC (fast or single pass) works best when image is scaled by 3x due to three subpixels clearly emulating the look from GBC that looks the best at 3x, 6x, 9x, and so on. For sharp results, I leave bloating at 0 and brightness at 0.08 as there is no blend between subpixels that way. As for the LCD-Shader method, I used it in my way, but yeah it requires integer scaling by 3x as there is no scaling on its shaders. Just load the first two pass, its first one set to 3x or 6x. Second pass is left at 1x. Cell should be at 2 if scaled by 6x, and make R, G, and B’s subpixels to only use respective colors. BGR’s layout is done the same, but swap Red and Blue’s subpixels settings. Then load up the color correction shader on top of it. The last two lcd-shader passes aren’t needed as it makes parts of the subpixels a bit fuzzy or something, lack of better words lol.

Yeah sounds a bit complicated, but if you want a bit more easy way for accurate representation of LCD look, the Authentic-GBC is the best way to go with a bit less work. LCD-Grid-V2, while less sharp than the other two shaders, works good enough without worrying about integer scaling by 3x as subpixels are always blended together. The LCD-Shader method seems to produce it slightly more sharp than Authentic-GBC, performs faster on a phone, and was easy for me to set RGB or BGR subpixel layouts as Authentic-GBC doesn’t have BGR yet. How it works as BGR is it’s complete 180 rotation from RGB as I can see the tail be on the top for BGR layout instead of the bottom that RGB layout shows.

  1. Yeah, quite often the shader repository constantly changes the location on where the shaders are stored in which folder. Whenever I come back into doing GBA or GBC shaders here, I always see either the shaders or the presets move to a different location, including my presets. But for your situation, it should work fine if you put everything inside from “Handheld-Colorspace-Shaders-main” to “shaders_slang” folder where the folders are identical that you would accept “write into” when pasting folders.

  2. I don’t know how it works on IOS, but I assume it has an option that changes colorspaces from its option. On both my LG-V60 and Samsung S23 Ultra android phones, all I had to do is use the “Vivid” colorspace mode to use the screen’s full gamma for Retroarch to take advantage of wider colors for the blue color to look more accurate. At least Retroarch on Android isn’t color-managed that happens on other apps on my V60, so I was able to use full gamut on it. As for IOS, I don’t know if the IOS version is color-managed to where it automatically applies as sRGB app, or if it’s allowed if the phone supports a type of vivid mode that forces wide colors on all apps. The whole thing can be tedious for me if I’m not familiar with how it works on IOS or other phones with different ways of representing color management.

iOS is color managed. There isn’t a way to force a colorspace. If the RA app supports HDR then you could use one of the HDR shaders to output HDR10 and set up the shader to output BT.2020 color space.

I see. I’ll eventually get to the HDR side of things later on. I also got plans to redo the GLSL shaders since I know a lot of linux ARM based handhelds may only use OpenGL.

This would be fantastic! :slight_smile:

1 Like

It’s easy if the data is already in BT.2020: you just use #pragma format to set a 10-bit output texture, apply a linearization function (if needed), multiply the value by a target brightness (can be 100, 203, or a user brightness setting), and encode with the PQ function which compresses the range from 0 to 10 000 to 0 to 1.

You can append one of the HDR presets which does this. They include an inverse tonemapper, but that step is entirely optional. But I encourage you to do it yourself.

Of course, I don’t know if HDR is supported on iOS. I would confirm that. And the HDR system is being worked on, there are some backwards incompatible changes, so best to wait until the next stable release.

2 Likes

Thank you! this was really helpful! I also had a question about GB micro. You said this in your original post:

Does this mean that the GBMicro shader would be preferred to use compared to the GBA shader? With my own testing it seems that the micro shader gives slightly more saturation but otherwise is very similar to GBA-color

1 Like

Comparing GBA and Micro, Micro has red a bit warmer and slightly more saturated, and the green is even more saturated. I know a couple have problems with GBA’s red color being a bit colder, and had suggestions to use Micro before. Tho, when I scanned the GBA one a couple months ago, the red color doesn’t look as cold as I thought it would, but still a bit, and the SP-001 one is a bit more colder. So yeah, now it’s moreso your preference. Somehow GBA’s screen has a bit more saturation than both GBC and SP-001 screens. The hue of the red color from GBC is almost similar to Micro but different saturation level

Updated the shader once again. This time finally ported the shaders to GLSL for devices that can only use the GL driver where Slang support isn’t currently possible with those devices.

Summary: Reworked the shaders and scanned the LCDs much better with better averaging and formulas used. CAT16 is used to shift the scanned colors to D65. RGB Scaling and especially XYZ scaling was inaccurate. GBA and GBA SP-001 are more similar on the colorspace, with red colors not being as cold much like the previous update, and all of them including the GBC got its fullest colorspace shown on the data. Gamma Ramps are added for GBA SP-001 and NSO-GBA, along with the update for GBA and GBC. Removed the colortemp preset as it’s currently under WIP. The middle gamma is also WIP, but really really close to how the middle light angle hits the reflective screens. Rename files much better, such as nds-color and nds-lite-color, rather than just ds-lite-color.

I removed the preset folder, one that loads in LCD presets along with the shaders. For reasons, it’s because how often the main repository changes the directory that doesn’t reflect the desired directory to my shaders, as well as needing organization. I plan to later use a colorimetry shader to combine multiple console colorspace onto one, such as GBA, NDS, and PSP, just to have less amount of shader files or presets. Tho that would come later once everything is figured out behind the scenes, especially the HDR support where I am waiting for much stable HDR shader code to come out.

Also fun fact. GBA SP-001, one that’s manufactured by Panasonic with the later GBA screens since late 2001, while looking similar with the GBA’s launch models with Sharp’s display, have similar colorspace with minor to bigger difference. The green is a tad warm, red is very slightly warmer, and the blue is wider, almost reaching the BT.2020 wall much like the PSP-1000. Also, the middle gamma has more difference with the overall gamma being darker than the Sharp display. Sharp one is almost as bright as 2.2 with slight darker gamma with dark shaders appearing a bit darker.

The hard part was scanning the gamma for the displays. I have to scan the reflective screens twice, one being scanned with Colormunki Photo’s head facing north or south for each turn since the light inside for spectral scanning hits near 90’ degrees, direction to the head. So yeah it would have different light angle that would hit the screen differently that would make the gamma look really bright or dark. The direction with the brightest gamma would scan the colors with much widest colors it can get once you subtract the black color in XYZ with all the colors scanned for full gamut from the LCD display. Although, finding the middle light angle’s gamma was tricky as the instrument hides the test suite’s UI so I couldn’t see it at all. So I had to use the brightest gamma angle to find some results on that. I used bt.1886 input method inside HCFR, and it would give off the closest middle gamma I can see from the LCD. Tho, I got reports on a group that bt.1886 can give weird results, but I did find it the closest I can get for now. Still under investigation to see if there was any better option to find out the best gamma, so since the latest results came really identical, I’d release it in the current state and seem to match quite often on the gamma. GBC is really bright and GBA, especially the SP, have a bit darker gamma. Although with scanning the top and bottom with different gamma results, still showed me the brightest and darkest gamma the LCDs can show based on the light angle source, so I tuned in to tweak the gamma settings to go from -1.0 to 1.25 currently.

Here are the details on the matter from Brankale’s contribution page:

5 Likes

I really like the how the BGB color correction looks with Gen2 Pokemon. It makes the skin tones look a lot more natural compared to the sunburned-look raw.

The Gearboy core color correction appears to use the same filter.

1 Like