dragwx / palgen Goto Github PK

Currently it uses sin for I and cos for Q, but I think it should be cos for I and sin for Q judging by what little I know of cylindrical transformations of luma + opposing chroma models. I'm basing it on http://www.brucelindbloom.com/index.html?Eqn_LCH_to_Lab.html and http://www.brucelindbloom.com/index.html?Eqn_Lab_to_LCH.html and my own implementation of YUV hue + chroma adjustments by using these maths with YUV instead of Lab which is

vec3 RGBtoYCHuv(vec3 Photo) {
Photo = RGB_to_YUV;
float Chroma = sqrt((Photo.yPhoto.y)+(Photo.z*Photo.z));
float Hue = atan(Photo.z,Photo.y);
Photo = vec3(Photo.x,Chroma,Hue);
return Photo;
}

vec3 YCHuvtoRGB(vec3 Photo) {
Photo = vec3(Photo.x,Photo.ycos(Photo.z),Photo.ysin(Photo.z));
Photo *= YUV_to_RGB;
return Photo;
}

I mean it doesn't look wrong with the current code but it seems inconsistent with what I expect and I don't fully understand what's going on so I worry that something is being done wrong somewhere.

Provide a library of screenshots which can be rendered with the current palette. This can potentially take the place of the CIE graph, but I can also see worth in displaying a row of different screenshots for comparison.

• Is there an intuitive way to allow users to use their own screenshots?
• Focus on "problem colors", particularly $x1, $x8, and $0x.
  • Also colors which typically go out of gamut often.
• Include examples of contrast, e.g. sky blue vs white text on SMB's title screen.

https://forums.nesdev.org/viewtopic.php?p=282178#p282178

Due to some goofiness* with how the PPU works, the lighter rows of the palette tend to have hues which are more offset than the darker rows. On the 2C02G, the skew is about -5 degrees per row, while on the 2C02E, the skew is about -2.5 degrees per row.

(*) A more technical explanation for why this happens can come later since I don't fully understand it just yet; the more important thing is that it does happen.

While trying to implement something that'd let me use different decoders like the Sony CXA2025AS US decoder instead of the FCC Standard I (without knowing much about the math behind it so it may be useless for this) replaced the global Hue adjustment with Hue I and Hue Q and used it as

var I = Math.sin((((hue - 7) / 12) * 6.2832)+2.5656+hueAdjI) * irange;
var Q = Math.cos((((hue - 7) / 12) * 6.2832)+2.5656+hueAdjQ) * qrange;

I saw the Sony CXA2025AS US decoder described as this:
R = Y + sin(112°)0.832 + cos(112°)0.832
G = Y + sin(252°)0.32 + cos(252°)0.32
B = Y + sin(0°)12 + cos(0°)12
Which had me thinking of separate I and Q hue adjustments. No idea if it's in any way related in effect but it does let me better approximate different palettes based on xyY charts.

I was thinking about RGB values exceeding 0-1 and came up with a way to scale it down by fading it toward white, similar to how dividing the image by max(Red,Green,Blue,1.0) will fade it toward black as the values decrease. Fading toward white is a kind of analog film-like overexposure look I think but it's definitely not best for everything. It's suitable for clipping YIQ -> RGB as well as RGB.

First you need the max of Red, Green, Blue, or 1.0. Then you take 1.0 and subtract the image from that, then divide that by the max, and then subtract that from 1.0.

When I use this on a test image with extremely scaled up chroma it becomes soft and pastel as it further exceeds 0-1 range which may work well with some palettes.

There's a relatively recent colorspace that's been developed for image processing, called Oklab, which is meant to mimic perceptual color transformations more accurately than what we've had now. Specifically, lightness, chroma, and hue can all be modified independently without causing any perceptual changes to the other two properties.

Oklab would be a new clipping mode that would do something like this:

1. sRGB to Oklab
2. Scale a,b until max(R, G, B) is 1.
3. Oklab to sRGB

Something I'm not sure is, let's say B was out of gamut. Is there a situation where bringing B down to 100% would cause another channel to go above 100%? I really doubt it, but it's still something to check.

Why check this out? Something that bothers me is color $22. It's an extremely vibrant cerulean color, but it looks pretty distinct from pure white on the palette, noticeable on SMB's title screen. I wonder if some colors actually get perceptually darker as they get more vibrant, and if Oklab accounts for that in its L value?