Ah, those are easy edits (I forgot what the ‘white’ toggle was supposed be doing, exactly, hence the vague name lol), so I went ahead and made the changes there in my previous post.
I took out the saturation and contrast levels, but if you ever want/need them back, we can store them in any of the empty slots in the matrix.
I don’t need saturation or contrast setting, to which thanks. I’m only posting up slang shaders so if you can do the same with glsl and cg shaders once I upload the new slang handheld shaders.
All right, I have returned long since my last convo about the shaders. With more things in the way, I prepare an update on each shaders. Well, with LG V60 and Colorimeter to screen in, with matrix files for the Colormunki Display to use, I finally got the colors correct for NDS, and very close to GBA. So pretty much I’n finished with NDS. GBA, I probably would leave this new update as the last until if I can find a tool for color sampling without a light on a screen, once I get around it. But still, on lots of time testing over the months and taking a look at the colors on the GBA to match on my phone (with vivid color mode on RGB app) to get color matrix as best as possible. PSP, I only got it from Displaymate’s graph and mapped the graph with one from ColorHCFR and did a couple of changes to have it look closely to the console’s colorspace. So once I get a real PSP 1000, I would just render the actual graph to show like the NDS last year on my tumblr.
But yeah, all shaders are ready. I only included the slang shaders as I usually been working with them, and I’ll wait until the update on glsl and cg shaders would come that includes white balance and colorspace modes (sRGB, DCI-P3, and Rec.2020). Yep, GBA, GBC, NDS, PSP, and Nokio Palm shaders have colorspace modes, thanks to a help with displaycal with LUT maker. And sorry if it’s been long since I updated a link. I did get a lot of mails about access to the link, due to Drive changing its securities, so old links are no longer freely shared.
On something related, on Windows at least, there is a way to tune your whole monitor to sRGB, with GPU driver settings such as AMD and Nvidia.
https://pcmonitors.info/articles/taming-the-wide-gamut-using-srgb-emulation/On this case, what it does is it reads the monitor’s color matrix number axis that is sent from the HDMI to read the monitor’s data of a factory tested internal colorspace. Yep, it sounds useful and helped out with my monitor. Although both driver method does help, an even more accurate would be to use icc profiles and LUTs made from Displaycal.
And while I wanted to include my preset with LCD shaders, I find lcd-cgwg-v2 pretty odd in Android and as a slang shader. First off, the slang shader is a bit behind from glsl shader, as it doesn’t have LCD input gamma, just output gamma, which can’t emulate the internal gamma like my lcd shaders. Also in Android, when using a slang shader (in Vulkan), the LCD and grids are misaligned meaning each pixel are offset and are not placed well. It happens when I use 5x, and going lower kinda gives me either a bit blurry results or too dark or color shifts. It doesn’t happen in glsl at all as I can get full sharpness at 5x or higher. Also first lcd-cgwg has problems with android slang too, like at 5x, one side is lined up correctly, and other side looks like it’s poorly scaled, looking like jittering when scrolling ingane. Those doesn’t happen on my PC or Linux at either D3D11, OpenGL, or Vulkan.
Also I do like to make my preset of the lcd-cgwg-v2 shaders to just have one shader load up since the shader has rgb values on primariy colors, which means it can emulate the colorspace within the lcd-grid shader. Although it doesn’t take negative numbers, so I couldn’t use it on the blue color since it’s clipped out from sRGB display. However, when I did my test (put color values from DCI-P3 to the lcd shader for my phone), it looked outstanding as I can have a bit brighter lcd setting without clipping or dark display.
New shader update link: https://drive.google.com/file/d/0B5KxdoFEcyTkZ3I0WWZkM00zT0k/view?usp=sharing&resourcekey=0-O53MFkl9UTK8fxL40sR3Cg
Note for those who plans to implement the shader onto newly Analogue Pocket, Gameboy Interface, GBA Consolizer, etc, use the default sRGB colorspace values as those are often gonna be on a sRGB display.
While Rec.2020 hasn’t got near 100% yet, it’s useful for displays that are already targeting rec.2020, unless if a software or video driver is converting to sRGB. On phones like latest samsung or LG v60, just use either vivid (full color range) or an option that purely targets DCI-P3 to use with the shader for more color defininiton, usually the blue color.
Hey Pokefan! Thanks for all your effort in making the most accurate shader.
I wanted to downlaod the new shaders you linked in google drive, but it tells me access is denied when i try to download the files. Would you mind opening the shader files up again to everyone?
Also, do you know if the shaders on github for libretro are the most up to date ones? I am referring to this one: https://github.com/libretro/common-shaders/blob/master/handheld/shaders/color/gba-color.cg
I don’t think the Cg shader version has the latest updates that are in the glsl and slang versions.
Yeah my google drive has problems with permissions and I did try out new link but somehow permissions got problems. I plan to put them out on something like Mega once a new update comes out.
I’ve been working back on the display colorspace in the last month figuring out new tools and settings with countless hours of comparisons. I fixed up the NDS colorspace for the shaders so they have better saturation that really match the hardware, and same with GBA/GBC. More details will explain later.
Also the PSP 1000 wil arrive this week and will take a look at that precisely. I will address plans for the future of colorspace on gaming consoles and what I am implementing.
@Pokefan531 Yeah Google Drive can be a drag with permissions…
I just looked over at the Retroarch Github, and it says the GBA-Color.glsl hasnt been updated since 2016. Would you mind keeping those up2date so lots of people can enjoy them?
Looks like 2 yrs here: https://github.com/libretro/glsl-shaders/blob/master/handheld/shaders/color/gba-color.glsl
Which one were you looking at?
My last update was last October or November. Somehow permissions from drive still won’t be open for everybody despite setting it as well as a new link.
Also, to give you guys an update, I did do the PSP 1000 colorspace for sRGB, DCI-P3, and Rec-2020. Oh also, unexpectedly, I even made a Switch-OLED shader, to emulate the Switch vivid mode, a way to see how the Switch-OLED console looks at full colorspace from the screen, which gives off more saturation and change on hues, at least the green color.
So my next update is almost complete. I do have to play with the lcd shader combination as well as the glsl versions. My last update was only slang. Somehow my android only works better for LCD-cgwg-v2 in OpenGL than Vulkan as I get grid offset in Android but not on PC. I also plan on getting a spectrometer later on to get data from GBA or GBC screen.
Oh as for a sneak peek, here are my current implementations: GBC Colorspace and Gamma GBA Colorspace and Gamma NDS Colorspace PSP Colorspace Switch-OLED Colorspace (Vivid Mode)
The Switch-OLED data was taken from this guy’s video:
I was wondering, is it possible to apply your color correction settings to screenshots using a command line program like ImageMagick? I have a bunch of GBA screenshots but they look horrible without color correction.
If you use the imageviewer core (built-in or otherwise) to load the LUT shader’s passthru LUT and apply the GBA color shader, then take a screenshot, the resulting LUT should be suitable for applying the color transform via any program that can accept 2D LUTs for tone-mapping.
So long of a wait, I have returned! And I do apologize for not having my google link opened, I tried and failed to have it be shared for some reason, unlike other shares I’ve done.
Anyways, I got a major update for my shader pack!
GBC, GBA, NDS, PSP, GBA SP (backlit 101 version), and Switch OLED Vivid mode are updated and added in. Not only that, they all include DCI-P3 (or Display P3 for monitors) and Rec 2020 colorspaces for those with wider gamut displays over sRGB. As was used by HunterK’s shader edit to make this happen, all three modes in one shader, and some of them have white balance option, to use pure white or cold whites that those old handheld consoles displays.
https://mega.nz/file/PVpEHbha#ZfSlO3vKtl0lgMqpVQRyVQ5zsjMCyjkSCwvzihWFReE
Let me get over each of the handheld console shaders that emulates the displays.
GBC and GBA share the same colorspace. Had reworked to eyeball and light the screen to match the colorspace on a calibrated 4K monitor that took few hours to get each primaries right, and finding the correct blue matrix by solving and greatly match the rest of the matricies for primary and secondary colors. The blue color would be visible for colorspace greater than DCI-P3, so it’s clamped on sRGB and P3 modes. It is visible on Rec.2020 colorspace. Also to note, this is the least saturated look overall as that’s how the GBC and GBA looks with bright lights shooting to the screen all the way.
Sameboy’s correct curve that emulates the greyscale curve is very accurate to what my GBC shows. That’s how my GBC looks when I shoot around the center of the screen, and the gamma can get a bit brighter when shooting light at the top angle, but even still GBC’s average gamma is notably bright, with a special curve that is match from Sameboy’s correct curve. I even use that curve to be used onto an LUT texture. Yeah if you use an LUT, make sure its color correction is set to none, and for shaders, only correct curves if the shader’s lighten setting is set to 0.
GBA, well the greyscales to match by angle. GBA does 2.2 by average when shooting to the center of the screen, but gamma gets darker when light angle hits to the top, common for average GBA user when lights or sun comes from above a player. So I used 0.5 darken strength by default due to it, but you can toggle the option. Also, GBA’s dark areas sits between the appearance of how Gamma 2.2 and sRGB tone curve looked, and so I played with curve values on the LUT texture to replicate it. Although not a big difference unlike GBC, it is worth noting a small thing when flashing the screen with 240p test suite.
NDS, I finally got the color saturation to match exactly for the primaries, so they are noticably more different than GBA. All I did was use linearize than gamma correct when using slang shaders with linearize folder with colorimeter shader to experiment, in which I just used for all the shaders. Also, like GBA, the blue color is out of bounds from sRGB and DCI-P3 so they are clamped. The top screen has slightly more color volume but the bottom screen is less cold, so I used that for the shader on the white option to see the screen’s white when turning off white balance. It’s toggle-able.
GBA SP 101. This is a new one, thanks to MandL27 for requesting one when said I have one. While an overall improvement from GBA and NDS with backlit screens and wider colorspace, it’s still kinda different than sRGB standards. Green Color is warmer and outside of sRGB, and Blue color sits around between sRGB and GBA/NDS blue colors. Saturation looks almost like sRGB, but it is not exactly. The Blue color is most noticable even far from the GBA situation. Also, DS-Lite uses a very similar colorspace that the SP AGS-101 uses, but the SP has a little more color volume. It can be used for NDS games to have the feel of look from a DS-Lite and DSi family.
PSP got reworked, and was the one I tried to sent last year but got troubles with google drive for quite a long time for just one file. But nevertheless, it is available. The Blue color is quite deeper than the GBA and NDS, same hue, more saturation overall that it’s close to reaching the end volume of Rec.2020 colorspace. Yeah being futureproof, a display with very great rec.2020 (or BT.2020) would display the blue color exactly. The Green and Red colors almost reach the matrix of sRGB, but blue is more noticable than even the SP colorspace. It can also be used for GBA games if the goal was to retain the saturation with turquoise blue hue. But yeah this is what the PSP 1000/2000 models look. Not only that, the gamma is also important to the PSP. It uses Pure Power Gamma 2.2 instead of sRGB tone curve, so shadow areas will be darker when viewed on a monitor or screen using sRGB tone curve, even Display-P3 monitor or phone screen. It was meant to be a portable multimedia device alongside games so Sony uses Gamma 2.2 curve. A LUT preset and texture was created for those using sRGB Tone Curve displays if calibrated or used by default like all my phones that I have. The presets would be “(sRGB-Gamma2.2)” and textures have “(pure-gamma)” named at the end. Also unlike the other displays, the PSP does have poor response times with GTG and almost good with WTW, so pretty much maybe the response time shader preset emulates it quite well lol
And welcome, Switch OLED!!! Yep I used that person’s video above and showed the data from ColorHCFR, so I was able to get info of the Switch OLED display when using vivid mode internally. Yeah, it’s weird that I made this shader when there is no Switch emulator for Libretro or Retroarch available. I used screenshots from Switch games to load with image viewer core to load them to display what Switch OLED vivid mode would look, and it has much bigger saturation, even surpassing DCI-P3 on its wider Green color and color volume. Only Rec.2020 would look correct for it. But yeah that’s why I have all available LUT textures bundled in the pack so you can use them with reshade for Yuzu or Ryujinx to display Switch OLED’s colorspace in vivid mode. Also like the PSP, Switch OLED uses pure gamma 2.2 so same situation. Also I don’t have white balance option as the screen does have green tint issue with some early units and varies by its brightness settings, so I use scaled full white balance. Instead, I added in Full White Scale, for those that want 255 White color. With it off, the white is much darker, just to show unclipped colors due to being out of bounds from sRGB and P3. This option is done for experiment and to see how the luminance of color primaries would’ve looked on the OLED, and since it oversaturated by default due to very wide colors, the colors are clipped so that’s why that option exists, but I still recommend leaving Full White Scale enabled as it preserves the white to 255 and just see oversaturation.
So yeah it is a lot of work in the last few weeks to have these shaders get done. And it was worth it. Also I could suggest for an average user, to use sRGB preset if they don’t know which one to use for LUT presets, including for using textures for project such as Gameboy Interface. Shaders can also be ported to emulators like mGBA or PPSSPP with multiple modes if able to, but can have sRGB used by default. If they know their device’s colorspace and its color options to where it’s set to, it’s best to use sRGB or DCI-P3 if set accordingly by the device. Like (Phone DCI-P3 = Color Option Full/DCI-P3 or other name = GBA Shader DCI-P3). Also I do retain and improve LCD shader presets for those, and some do have BGR mode from LCD-cgwg enabled or disabled depending on the console’s display, as I know GBC and SP-101 uses BGR. Also don’t have the Switch OLED use any LCD shaders as it’s not needed to emulate a high res screen and no motion blur as the Switch LCD or OLED have good response times.
Yep that is my long explanation and thanks to those that helped me out along the way. Also tools I got between my last release and this one. Used Colormunki Display, Colormunki Photo, Samsung 4K S80UA, ColorHCFR, DispalyCal, ACM icc profiles for Windows 11, Colorimetry shader with Linearize shaders in between, and Color-Mangler shader.
EDIT: I forgot to mention, I included Nintendo Switch Online’s virtual console color filter. I did them with screencaps from Yuzu. GBA one just have a simple desaturation filter, except it’s done individually to each Red, Green, and Blue, and also it was easy to replicate to the same shader I used. The dark area is slightly more dark than my GBA situation, but it was easy to add in for the LUT shader but it remains similar to what I tried with the shader alone.
GBC on the NSO, well I have constant troubles. They not only use their filter without gamma correction or linearization for the primaries as well as bumping the black and white color up and down respectably, to show less contrast, but they also use very weird greyscale curve, like they have some sort of weirdness of color balance to the greys to give it a cold color than how the shader looks as a WIP. I tried…and while I have the color primaries match with its values and luminance, doing so makes the greyscale very redish, a hotter color and does look less like a greyscale than what their filter looked with their weird curve on the greys even if a bit cold. So yeah… it’s up in the package if you want to see, but it’s a WIP as stated inside the shader. However, I was able to replicate it with a LUT texture. Thanks to modding NSO-GBC on Yuzu to use test quite, I was able to get the color value and did my method to capture their filter perfectly to an LUT shader. Yeah I do recommend to use LUT shader for NSO-GBC for now.
hey @Pokefan531, I was working on getting these organized and committed to the repo and I see that you have the color+screen effect presets with the color changes after the screen effect. Is there a reason for that? We usually do the color/signal/whatever effects first and the screen effects after, but I figured I’d see if you had a reason for it (e.g., if you tweaked the settings to specifically incorporate the screen effects’ own changes) before changing anything.
Well for LCDs, to look really close to how the handhelds look, the RGB subpixels would also need to have their color gamuts changed so that’s why I put in color correction after applying the LCD shader effect. Otherwise it would look pretty odd to me as it wouldn’t look exactly how the LCD behaves on the handheld consoles.
With my setup, the color correction helps the shader subpixels look the same as original except being color corrected. When I compare the real GBC and GBA, and compare with my setup, they really match well, as I do see how the subpixels behaves well to each color, and gives a bit of a texture on certain spots just as it would if you just only apply the LCD shader without color correction.
If there is a preset that does the color correction first, it would be any other LCD shader that doesn’t involve subpixels of RGB and just grid like appearance, such as dot and retro-v3.
k, works for me. As long as you have a reason for it 
Another great news I have, I got GB Micro almost last week, and My Life in Gaming is right about being less saturated than GBA-SP AGS-101, which is appropriate for GBA games. The hues of the color primaries is more in line with GBA, but it is a bit more saturated than GBA, which is good enough to call it a good starter pack for a GBA color correction for average users. Yeah, it’s also different than then NDS Phat colorspace, as the red color is further and be neutral red than GBA or GB Micro. As much as this model of GBA isn’t well received nor financially, it is the last GBA model to take care of the color correction to GBA games, even though it does have a similar motion blur as the AGS-101 have. Aside from that, I was able to get the data from the screen and see its colorspace. Will post the sccreencaps and the new shader later on ^^
Interested in GBP?
When playing “GBA games that display the Game Boy Player logo” on GBP, the color palette automatically switches to the TV premise.
In the case of “GBA games that not display the Game Boy Player logo” or “GBC games”, when played with GBP, the low saturation will be lower and the brightness will be a little darker.
I would like to know the color correction in this case and the LUT that should be applied.
From what I found out from GBP, as well as a strip version of it in Pokemon Box Ruby and Sapphire, when seeing raw screencaps of it, the entire screen is dimmed down, from 255 white to 200. There are no gamma nor colorspace applied in GBP but the luminescence of the picture quality decreased by around 20%. It is the only difference when seeing GBA games on GBP, aside from GBP enhanced games such as SMB3 from Super Mario Advance 4 that has its gamma turn down, to give exact picture as from SNES All Stars version.
Thank you for the reply.
I am a little confused. I’ll clear my head.
GBC -> White only 255 to 200
GBA -> All colors reduced by 20%
GBP enhanced GBA -> Gamma correction is applied to be equivalent to SNES/SFC.
Do you agree with this? If so, I think GBP enhanced GBA is feasible with mGBA core. Is this correct?
My apologies for not replying for a week due to irl stuffs lol.
Well generally, the GBP dims down by 20% reduction in brightness, which leads to 255 white to 200 light grey. It is applied to any game for GBP regardless of which game is GBC, GBA, or GBP enhanced. Despite that, the games would still differ in appearance if its only enhancements are colors, in the case of SMB3 from SMA4. Also even certain games like Legend of Zelda do use regular colors matching from snes, on the game’s option. With Gameboy Interface, it is always using full brightness, and depending on the modes, if using GBP enhancements, then it will look best if color matches to snes