I spent some time on this, because that colorization is not achievable with my implementation.
To understand why, I blindly tuned koko-aio as i would do normally:
So, by taking the bright hue and the dark hue, as explained here
…then i feeded tuned koko-aio and dmg.slangp with a dumb black to white gradient and found that the problem lies here:
koko-aio down: linearly fades hue and brightness without clamping at all.
dmg.slangp up: it clamps the dark for the first 10%, then starts to fade, but while the brightness fades linearly, the hue stays versus the blue for longer, it is not linear at all.
I don’t know why it acts that way, but it doesn’t look right to me.
Koko-aio maps the input grayscale picture from the core linearly to a hue gradient defined by hue-bright and hue-dark parameters, and optionally shifts the gradient edges to one of the two hues via the bias parameter:
The following are the default colors i copied from internet pictures of real hardware:
Here I tuned some color parameters to better match what you asked, but i don’t remember any blue tint on original gameboy honestly:
As you can see, the color shifting from the yellow background to the blueish foreground is different, less steep. Those are the parameter changed over the default gameboy preset just in case:
brightness 0.12 contrast -0.29 hue bright: 0.17 hue dark: 0.55 saturation: 1.10 Grid strength: 0.20
For gb mono color, unfortunately color schemes are not supported, you can still use the coloring done by the core itself, why not?
I tested my implementation again with gb pocket mono, by taking an online shot from a real gameboy:
Then I found the bright hue and the dark hue and reported them in koko-aio; this required a bias adjust, adjusted brightness/contrast/saturation by gut:
brightness -0.10 contrast -0.25 hue bright: 0.25 hue dark: 0.14 hue bright-dark bias: -0.58 saturation: 0.24
