Sounds like some exciting stuff in the pipeline 
I can help you get the shaders set up. It shouldnât be too hard to get them all combined into one shader that just uses a parameter to choose among the different colorspace presets, if that sounds attractive.
Cool! I only have the updated NDS shaders included in the package below. I also did GBA, but still in experiment currently.
I do want to see options like: colorspace_type (sRGB, DCI-P3, Rec.2020) (Default:sRGB) 0-2 white_balance (Use 6500k White Balance) (Default: 1) 0-1
So only [r, g, b, rg, rb, gr, gb, br, bg, and lum] have different values of each preset, six of them. For the White balance, the default one is tuned for 6500k. I made a comment below the default values to show NDSâs bit cooler white balance affecting the colors as does from hardware, having a second preset for each sRGB, DCI-P3, and Rec.2020 shaders.
Currently, theyâre all in Slang shader, as I only worked with them. You can do a combination with the glsl and cg shader too.
(edited) Need to fix something quick DONE! https://drive.google.com/file/d/1a7XrMrJe9dokUKgB4FnsAbkCNd1BNUyP/view?usp=sharing
UPDATE: I have got my LG V60, and it fully supports DCI-P3. The blue color is a bit deeper than the blue primary from DCI-P3 and sRGB. I was able to redo GBA colorspace more accurately.
The LG V60 had a couple of color profiles, until I got it updated overnight to have four color profiles: Natural, Vivid, Cinema, and Custom. âVividâ uses the full colorspace that the phone has, and Cinema tries to have the screen calibrated to DCI-P3. There was Web, which was meant for sRGB, but it was removed on that update. Could be because some apps such as video apps (YouTube, MPV, VLC), photo apps (Gallary) or social media apps (Discord, Twitter) are color-managed, which tries to be converted to sRGB. Using sRGB cal lead to noticable desaturation as those apps are meant to convert DCI-P3 colorspace to sRGB. Somehow Google Chrome or other web broswer arenât color-manageable by Android, so I successfully used Displaycal via Web @ localhost method with Colormunki Display.
Also, Retroarch isnât color-managed so I was able to use full colorspace via Vivid profile, and use my custom made LUT shaders from Displaycalâs 3Dlut Maker. I tested GBA shader I just created. Yep, the Blue color actually fits on DCI-P3 colorspace than on sRGB, and sees a bit more deeper blue color. So I just use LUT texture to convert the screen to DCI-P3, and use the appropriate GBA shader, and wow!! Itâs even replicating it so perfectly.
By the way, LG V60âs phone has a flashlight, and it really manages to make GBA screen shoot nearly by 6500k whitepoint, and compared it with my phone, and wow, it really is that close that I coulsnât tell much of a difference on the white color between GBA with V60âs flashlight, and the phoneâs screen with LUT shader (which was a cold screen, but set to 6500k by Displaycalâs LUT), and colors pretty much matched so well.
Here was the process: Use color apps with values to each RGB>Flash GBA screen with 240pee_mb (240p Test Suite)>Match the exact colors much more closely>sees a clear match on chroma colors>Use ColorHCFR on the already made .chc file tested to check colors from V60âs vivid mode>Use xy values on Displaycalâs tools (somehow surprising it worked better than NDS situation from previous post)>match the colors to GBA shader>use Photoshop to load the shader by Print Screen button>Use .cube file from 3DLUT Maker to see colorspace made for DCI-P3 and Rec.2020
And thatâs not all! With the flashlight by my new phone, as I said the screen is pretty much in line to around 6500k whitepoint, the overall screen is appropriately warm! Yes, the Red color is no longer too cold, and the hues looks more correct. GBA doesnât have its whitepoint, only based on the light source. This was a challenging, but fun experiment, and Iâm about to be done with the shaders to release them, but gotta have them ready by having a shader that switches the color values for sRGB, DCI-P3, and Rec.2020.
I tried last year with an i1 Pro 2 on a GBC but with little success. I think I would have to at the very least remove the glossy window first to get decent results. But in principle, I donât think the fact that itâs reflective should be a problem in itself.
I donât know how I missed this post 2 weeks ago, but now that Iâve seen it, Iâll get started on those shaders.
Nice to see how you tried. Yeah, shining the light does give the screens a rainbow effect due to the glass. So it was pretty challenging to take the colors by flashing the screen and use the colorimeter to see it in project mode. I didnât have any success either. So I just want to see if a spectro would do a better job, and thankfully, you tried. If you do manage to remove the glass thatâs a bit far from the screen and instead have some thin glass to protect the screen at least, let me know if you succeed.
Good. I was doing other things, but I did manage to do my last time taking primary color samples from GBA with my screen flashing, so the GBA colorspace is ready for three profiles. It doesnât need white balance option as GBA or GBC doesnât have a constant white point as NDS and PSP do.
I just set my screen to vivid, to get phoneâs colorspace, and just get color samples that closely match, done for couple of hours. I pretty much match the colorspace well as well as the luminance for each primary. This time, using my Colormunki Display to calibrate the phone screen with AMOLED correction file, use ColorHCFR with the correction file, sample each color primaries from the phone taken from the GBA at best, and have three (and white point by the flashlight to GBA screen) primariesâs xy values inserted to a icc file. It matched the chroma much closely from HCFR when using 3DLUT Makerâs texture output. Now me using my phone to play GBA game with Retroarch flashing the GBA, play the same game. Well, as I see the screen a bit step warmer, it still pretty much match the colors pretty well, making this my best method than any other ones Iâve done in the past.
Iâm gonna have fun playing GBA games on the phone with the shader, as I stated that the blue color is visible on DCI-P3 displays. I also plan to have shader profiles for screens with wide color range to have sRGB content be color corrected to the display. Hoping Libretro doesnât use Androidâs color management any day as the GBA shaders can perfectly emulate the screen without it, and so as the NDS and PSP shaders too. Yeah, me trying out full color range on a SDR video on MPV and other players, doesnât show DCI-P3 colors fully as those apps assume the contents are meant to be sRGB by Androidâs CMS system, which canât be controlled unfortunately. In Retroarch, I can see full range of colors as my phone can display, so it was necessary to not use androidâs cms.
Howâs this (slang only at the moment)?
#version 450
/*
Shader Modified: Pokefan531
Color Mangler
Author: hunterk
License: Public domain
*/
// Shader that replicates the LCD dynamics from a Nintendo DS Phat --
layout(std140, set = 0, binding = 0) uniform UBO
{
mat4 MVP;
vec4 OutputSize;
vec4 OriginalSize;
vec4 SourceSize;
float mode, white_toggle;
} global;
#pragma parameter mode "Color Profile (1=sRGB, 2=DCI, 3=Rec2020)" 1.0 1.0 3.0 1.0
int color_mode = int(global.mode);
#pragma parameter white_toggle "Toggle White Balance" 0.0 0.0 1.0 1.0
bool white = bool(global.white_toggle);
#define target_gamma 2.2
#define display_gamma 2.2
/*
We'll define our color weights in this pattern:
r, rg, rb, 0.0, //red channel
gr, g, gb, 0.0, //green channel
br, bg, b, 0.0, //blue channel
blr, blg, blb, lum //alpha channel; we'll hide lum at the end, too
*/
const mat4 NDS_Rec2020 = mat4(
0.58, 0.13, 0.09, 0.0, //red channel
0.38, 0.645, 0.20, 0.0, //green channel
0.04, 0.225, 0.71, 0.0, //blue channel
0.0, 0.0, 0.0, 1.0 //alpha channel
);
const mat4 NDS_Rec2020_white = mat4(
0.535, 0.12, 0.09, 0.0, //red channel
0.345, 0.585, 0.20, 0.0, //green channel
0.04, 0.215, 0.71, 0.0, //blue channel
0.0, 0.0, 0.0, 1.0 //alpha channel
);
const mat4 NDS_DCI = mat4(
0.745, 0.10, 0.09, 0.0, //red channel
0.315, 0.665, 0.195, 0.0, //green channel
-0.06, 0.235, 0.715, 0.0, //blue channel
0.0, 0.0, 0.0, 0.95 //alpha channel
);
const mat4 NDS_DCI_white = mat4(
0.685, 0.095, 0.09, 0.0, //red channel
0.29, 0.605, 0.19, 0.0, //green channel
-0.06, 0.215, 0.715, 0.0, //blue channel
0.0, 0.0, 0.0, 1.0 //alpha channel
);
const mat4 NDS_sRGB = mat4(
0.815, 0.07, 0.075, 0.0, //red channel
0.215, 0.62, 0.155, 0.0, //green channel
-0.12, 0.22, 0.77, 0.0, //blue channel
0.0, 0.0, 0.0, 0.89 //alpha channel
);
const mat4 NDS_sRGB_white = mat4(
0.815, 0.07, 0.075, 0.0, //red channel
0.215, 0.62, 0.155, 0.0, //green channel
-0.12, 0.22, 0.77, 0.0, //blue channel
0.0, 0.0, 0.0, 0.97 //alpha channel
);
#pragma stage vertex
layout(location = 0) in vec4 Position;
layout(location = 1) in vec2 TexCoord;
layout(location = 0) out vec2 vTexCoord;
layout(location = 1) out mat4 profile;
void main()
{
gl_Position = global.MVP * Position;
vTexCoord = TexCoord;
if (color_mode == 3) profile = (!white) ? NDS_Rec2020 : NDS_Rec2020_white;
else if (color_mode == 2) profile = (!white) ? NDS_DCI : NDS_DCI_white;
else if (color_mode == 1) profile = (!white) ? NDS_sRGB : NDS_sRGB_white;
}
#pragma stage fragment
layout(location = 0) in vec2 vTexCoord;
layout(location = 1) in mat4 profile;
layout(location = 0) out vec4 FragColor;
layout(set = 0, binding = 2) uniform sampler2D Source;
void main()
{
// bring out our stored luminance value
float lum = profile[3].w;
// our adjustments need to happen in linear gamma
vec4 screen = pow(texture(Source, vTexCoord), vec4(target_gamma)).rgba;
screen = clamp(screen * lum, 0.0, 1.0);
screen = profile * screen;
FragColor = pow(screen, vec4(1.0 / display_gamma));
}
EDITed to remove the saturation calculation altogether, since itâs always 1.0 in these.
Thatâs a good look and really works so far. I would have the color profile ordered by: sRGB,DCI-P3,Rec2020 (and sRGB be the default) White toggle, I will name it âToggle White Balanceâ and seems to work pretty good too. I seem to like the setup. Iâll be doing the same for GBA and few other profiles too. Now Iâll be releasing the new GBA shader pretty shortly. With that shader setup, it gives me a few ideas for other displays to do color corrections. They will be up once I uploaded an updated pack in just a few days with me giving info for each config
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.