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
Here rise again on another major update to this project! A major update to the shader pack!
https://mega.nz/file/DAwyEZgQ#_er6RRa4m1d5d399upq52xrkAkcMKy9HGr6SNYf_0wI
Also here’s my big page of the project on Tumblr:
https://pokefan531.tumblr.com/post/766008194709454848/handheld-lcd-shader-projects
Changes:
-Gameboy Micro, DS Lite, and GBA SP (AGS-101) shader added.
-Used a bright portable light that makes out the saturation of GBC and GBA, being on par with Nintendo DS and Micro saturation levels. Previously used my phone’s light which isn’t ideal way to get colors without glass rainbowing on screen in the way.
-Added LUTs on shader presets to emulate the greyscales ramps on GBC, GBA, and PSP, plus colder greyscales for all displays that these old LCD screens have, for preservations. PSP uses pure power Gamma 2.2, GBA nearly uses power pure instead of sRGB curve, and GBC has its own bright curve.
-Removed white balance option since most would want full white balance. Was an option to tune in to my handheld’s whitepoint, but can vary between same units while using same colorspace.
-Fixed gamma correction on the shaders, all fixed 2.2 (was 2.0 due to not knowing how ColorHCFR displayed colors correctly, but now knowing how).
-Reshade LUTs uses MultiLUT to change between normal and cold greyscales between two LUT Textures.
-Added External Gamma option on GBA and GBC own shader to tune incase if you don’t have a specific LUT shader preloaded from the preset. Both default at 0 since the gamma for GBA are set by default, and GBC’s special gamma curve is in place from LUT.
Tools, comparisons, development info, and explanation are included on the tumblr link.
@nfp0 Well now, you can set it to default 2.2 because I have the LCD-cgwg presets configured differently to where GBA and GBC LUT shader have their own gamma before loading the LCD shader.
Edit: More update info
8 Likes
@Pokefan531 Fantastic news!! 
I’ll give that page a good read and test the new shaders as soon as I can.
It’s also good news that you have the gamma on the LUT now, so no need to change it on the parameters.
Looking forward to seeing this into the libretro repo!
Oh yes! Although I do have one issue with mGBA Core, that the white color isn’t completely white, like it’s 255,251,255, green being slightly lower, so a change in gamma would affect the white color unless a shader before the LUT (and after motion-blur shader) uppers the green color by 1.016 from something like image-adjustments to have the screen be consistent. Yeah a bug like this isn’t in the standalone mGBA. But yeah, no need to add in extra shader to fix only one emulator white balance. Hopefully one of its maintainers are able to solve it.
But yeah beside that, the shader should work like normal with LCD shaders.
Fun fact, the sameboy lcd shader seems to be more sharper than cgwg, and relying on seeing just the RGB subpixels by having low color at 0 and high color at 1. Can look similar like lcd-shader preset or the newly authentic-gbc shader, but does blend each subpixel a bit which gives a bit more brightness, and friendly for targeted colorspace that had to clip the blue primaries that balances the white color more by decreasing a bit of red to maintain its balance. Although I also would like to ask if BGR subpixels are possible on sameboy or authentic-gbc for something like GBA since it uses BGR aside from Micro. It simply is a 180 degree rotated RGB, even its small tail on each subpixel on a GBA when comparing with GBC.
Yep I’ve been testing different kinds of lcd shaders on the project. CGWG shader is pretty good which does have options for BGR and works constantly with any size starting from 3, but I see more sharpness on Sameboy and authentic-gbc. I also set LCD-shader preset to only use RGB instead of CYM colors for each subpixels to match the real lcd subpixels and looks how authentic-gbc looks. But yeah, they work best when the image is multiples of 3 to give balance each subpixel display, and I like sameboy’s blended subpixels that nearly matches on how it looks when only having the low color at 0. Although I do see errors when having these shader go exactly 3x as I see really bad moire pattern, but not anything higher somehow.
Also, yep I even give Micro lut shader a gamma control in handhelds due to GBA games needing gamma control to look less bright from raw RGB.
And last, a page for GBA database and measurements would come later this month, showing ColorHCFR data and its greyscale, plus my discovery on why GBA gamma looks dark