@Brankale Thanks for telling me about all of this. I’m glad to see you work with color matrix with proper conversions shown on your github. Now to answer your questions.
It seems there isn’t a full colorspace conversion pipeline (1) (RGB → linear RGB → XYZ → chromatic adaptation → XYZ → linear RGB → RGB). I saw matrix multiplications in the shaders suggesting RGB→XYZ conversion, but without documentation I’m unsure how recent measurements and conversions were handled, especially since tools and methods have changed over time.
Yeah that was long before any color shaders that relies on color matrix and chromatic adaptions has existed, such as Colorimetry, Grade, and Chromaticity from the “misc” folder inside the shader folders. So we relied on just gamma corrected to linear, handling color matrix manually by modifying RGB individually.
But as I recently got back and have multiple host colorspace such as DCI-P3, AdobeRGB, and Rec2020, I was thinking of switching from color-mangler to something like Colorimetry as it contains multiple targeted specified colorspaces. I did play around a bit with Colorimetry shader and added gamma correction to have linear behavior on the color matrix as it doesn’t have one originally. I did modify its XYZ for its host colorspace just to copy the given colors to my current shaders. I can add multiple host colorspace and targeted colorspace to the shader, as well as white balance.
But yeah, with the color mangler, I used it to give a much better understanding how the shaders work with modifying RGB channels as well as easier read to port it to their projects, being mGBA, PPSSPP, and even Gameboy Interface. It’s been ported multiple times, seeing a same similar code that I can easily adjust for just one colorspace for one standard.
It looks like the shaders assume a fixed gamma across RGB channels which is very problematic given how unstable gamma curves are on old consoles. In fact, even a small gamma deviation (e.g., 0.15) can cause DeltaE > 3 (5) , which is significant when aiming for accuracy. This issue is one of the reasons I paused my work after reading DisplayMate’s article on the DS Lite, which only included the grayscale gamma curve.
I used more of an average outside of GBC as I see the average of gamma of the display that is suitable for the viewer. Much of them seem to follow closely to Pure Power Gamma curve as I do now work with a display to Gamma 2.2 since KDE Wayland only color corrects to sRGB with Gamma 2.2 curve. I know a lot of those old TN displays have colder greyscales than how the shaders gamma handles it. It was why I had the handheld presets use the LUT shader to load up its greyscale gamma curves that changes its color temperature. I noticed the DS-Lite has colder greyscale than GBA-SP-101. Even the PSP has a really cold greyscales. But yeah, I did have the LUTs for my current version to contain the cold ones for each system, although made under sRGB curve, which I plan to change to just shader based gamma correction with colder greyscales. Also the reason I didn’t have the generic RGB gamma was the fact it mostly covers just the middle values rather than spreading it out to most of the greyscale. By the looks at your code, it seems to do 9 greyscales between black and white, which can help out. The current shader I have just specifies the gamma for the shader ports to use, as well as the fact the color-mangler doesn’t have RGB gamma control.
As for GBC, it uses its own abnormal gamma curve. I used my ColorMunki Photo with the SpotRead app to just scan luminance the screen while swapping the greyscale swatches from 240p test suite. I scanned all 32 swatches to produce a much more accurate as to how my GBC displays its own gamma to provide constant details. It also has its colder temps on the greyscale too, which I plan to add in later on.
Could you please share the HCFR CHC output files for the consoles you measured?
Sure. Once I get on, I’ll be sharing the data I got for GBA-SP-101, NDS Phat top and bottom, DS-Lite top and bottom, GB Micro, and the PSP 1000. As for GBC, GBA, and GBA-SP-001, they’re pretty much eyeballed on the colorspace with bunch of tools to use, and gamma seems closely identical to Pure Power Gamma, except just slightly darker on very dark swatches only. I did scan out the gamma, but I had to stabilize them in GIMP to see the best results since the colormunki photo had to scan at the very dark that has a slight noise variation to very dark luminance, and same with GBC. So I only have CHC data for any screens covered here that are emitted rather than refletive. As for the Switch OLED, it already has its HCFR data shown from a video I shared here last year or two.
So yeah, I see your code being more promising to have more options to target colorspace without having a lot of work to manually put in color numbers for each RGB for any four hosts colorspace.
I didn’t measure the New 3DS XL bottom LCD because it has a way too warm whitepoint. I plan on doing more measurements as well as measuring my DSi and DSi XL LCDs.
