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.
6 Likes
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.
3 Likes
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.
1 Like
k, works for me. As long as you have a reason for it 
2 Likes
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 ^^
2 Likes
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.
1 Like
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
1 Like
I don’t mind the delay in replying. I wish you success in your research.
OK. ”All Not Enhanced GBC/GBA have the same behavior." I understand that.
It seems that you are currently working on GBM (Gameboy Micro), but is there any possibility that you will also work on GBP?
I’m interested in how it will differ from the NSO color. I have lived with SGB and GBP. However, I am currently playing the actual NSO GB/GBC/GBA, and I feel that the colors are a little different.
I remember that GBP looked more natural than NSO. I don’t know if this memory is correct.
Emulating GBP is very simple. There is no gamma nor colorspace being emulated, and if there were any difference, it’s often the composite output that gives an inferior quality. I remember seeing a video gameplay recorded from GBP, the composite decoding on that one gameplay video, had clipped blacks being noticeable. When seeing the raw output, be it emulation in Dolphin from Pokemon Box Ruby and Sapphire, or raw HDMI Capture from the digital output, seeing the GBP post processing (200 white color instead of 255, and motion blur depending on the smooth settings) is pretty clear. I could use image adjust to decrease luminance to “0.79” on its setting to get the same picture as GBP.
I had finished up the GBM shader, for all targeted colorspaces and now ready to examine the GBC screen, had brought a portable light that has white temperature adjustments
1 Like
@Pokefan531 Is there any reason why you set both lighten_screen and darken_screen to 0 on the lcd-grid-v2 presets?
EDIT: And is there a reason why gbc-color.slang has lighten_screen's default set to maximum (1.0)?
That default looks extremely bright and de-saturated compared to my GBC screen.
@Pokefan531 Why do you use display_gamma=2.0 in gba-color/sp101-color/nds-color/psp-color? If I understand correctly, display_gamma should always be 2.2 which is the gamma of user’s display.
Here is my interpretation of your algorithm. The color correction has essentially three steps:
- convert from console-RGB to linear-RGB, which is implemented by gamma expansion/decode.
- change the basis of RGB vector, from console-primaries to sRGB/DCI-P3/Rec2020 primaries. This is done by multiplying a matrix.
- convert from linear-RGB to display-RGB (that is, the RGB value sent to user’s display), which is implemented by gamma compression/encode.
Now given that the standard gamma for monitors is 2.2, I think the display_gamma should be 2.2 instead of 2.0.
Another issue: The code of palm-color.slang says it is for PSP lol. I think you just copy-pasted and forgot to change the variable names and comment.
For lcd presets, the v2 one has an option to adjust the gamma in shader so you don’t need another post processing effect to change the gamma. Otherwise, not only the subpixels would get darkened, but also the whole lcd effects as well, and can look darker than needed. It’s best to just go with the lcd shader’s gamma settings.
Yeah I’m considering to change the default setting for lighting screen value to 0.5, as GBC’s average gamma is a lot lighter, even not perfect gamma to the screen’s curves. The best use is to use sameboy’s correct curves on top of the gbc shader with lighting screen to 0.0
1 Like
It was treated that way when I use linearize shaders within the libretro shader packs, from using two shaders from it, sandwiched with colorimetry shader to have any gamma correction. All it does is it gives out a gamma 2.0 effect when I used those shaders, in which they call linear correction? I wasn’t sure completely myself, but somehow when I get colors from my colorimeter and spectrometer, it gives a bit less saturated on those old LCDs for some reason, and having the linearization method from those shaders gives the better results to the actual screen’s colors. Btw I did buy camera portable flash lighting for those screens and gives out more range of colorspace on GBC/GBA than what a phone flashlight can do. It does show more of the proper color range by the portable light, much the same way as the light bulb and the sun. It does still fall short of less saturation than NDS so there is a difference.
Btw, somehow it happens on those old LCDs when I sample colors from it, but it does give a proper gamma 2.2 when sampling modern displays, like my phones, TVs and monitors. In fact I did sample gbc/gba off from my monitor when doing my insane method of sampling colors from the non-backlit screens, and noticed having gamma 2.0 for gbc/gba looks a little too inaccurate, so I’ll be reverting this on my next update.
It’s just the NDS, GBA-SP 101, PSP, and Micro that looks a bit less saturated when viewed from programs like ColorHCFR and Displaycal, so I wasn’t sure if it was the setting that I use on two color units, and I did try to load many kinds of color correction file for colorimeter and get same results on how far it can reach the color matrix. And when I did look at the colorspace inside colorimeter shader with two linearize shaders, they seem to make the primary colors look identical to the console’s screens, which was why I had it at 2.0 than 2.2. I would like to know how I can get them to look the same except in gamma 2.2 process. You can suggest if I can resample all colors from my monitor, but even my capable calibrated DCI-P3 monitor can’t show the blue color from any of those LCDs so I couldn’t be able to sample them than what I could from the LCDs.
As for Palm color shader, yeah I didn’t change the name, but also I maintain it pretty less as I only found one data from it, but haven’t kept it up to date as other ones here.
1 Like
I see, I understand now.
But then, shouldn’t the LCD presets have a default gamma that approximates to the GBC and GBA screens? As it stands now, both GBC and GBA LCD presets look practically the same, which I believe is not accurate.
Thank you for the feedback. I’ll go ahead and suggest that change to 0.5 on the libretro repo. As as things stand now, the bare gbc-color.slang shader is looking almost broken.
Looking forward to your updated shader!
EDIT: This post is WRONG. Please ignore it and see my next post.
I tend to disagree with this. And also from using the color correction after the LCD effect.
I’ve read why you did it this way on one of your previous posts, but I didn’t fully understand the reasoning.
From my experimentation, using the LCD shader gamma controls affects it’s subpixels, which should not be the case if our purpose is just doing color correction.
For example, a full white screen should look exactly the same regardless of gamma value, as gamma does not affect full white. But look at the following test:
Gamma 2.8:
Gamma 1.8:
These 2 pictures should look the exact same, as gamma doesn’t affect white, but they look very different here.
This also happens if we control the gamma with the lighten_screen and darken_screen parameters. The subpixels are being affected, even on full white.
I don’t feel like this is the intended behavior of color and gamma correction. Shouldn’t we be first correcting the color, and then applying the LCD shader on top?
Please disregard my previous post. I was wrong.
It seems the test I was doing was not on full-white pixels. My bad.
I have properly tested on full-white and the picture is not affected when correcting the gamma on the LCD pass, as is expected.
Furthermore, I think I now understand the reasoning for correcting the subpixels, instead of correcting only the original picture.
But, by default, the gamma is still not corrected on the lcd-grid-v2 presets. So I have proposed (on the libretro slang repository) an LCD Gamma value of 1.6 and 2.6 for the GBC and GBA lcd-grid-v2 presets, respectively.
I tried to get a picture as close as possible to the non-LCD color correction shaders with the lighten_screen and darken_screen values set at 0.5 for both. But if you want to suggest more accurate values from your measurements, please shout out, @Pokefan531
1 Like