Homebrew Screen calibration app

Deleted member 42501 · Sep 24, 2020

Seeing as the 3DS is entirely open and stuck on the realness can we get a screen calibration app up in here yet? If yes, then hop to devs and create a Patreon as many people will donate for this as none of the screens were ever calibrated, ever. If no, why not?

There are a couple of points that make me think its doable:

These are numbers from 00 to FF that Nintendo calibrates before shipping a 3DS. If they're approximately right, you won't notice any difference at all. But if they're off by maybe 0x20 or more the screen will appear brighter, somewhat washed out, and flickers in a 1x1 pixel checkerboard pattern when there's motion. The further off it is, the worse it looks.

https://github.com/hacks-guide/Guide_3DS/issues/794

The "Blue Light Reduction" in the main menu was renamed to "Screen Filter".
Accessibility features including "Grayscale" and "Invert Colors" were added into the "Screen Filter" menu.

https://github.com/44670/BootNTR/releases

Well, now I fully reverse-engineered a GPU register which controls this, and thus I recreated the old design based on the new color lookup table mechanism, and it works!

https://gbatemp.net/threads/ctr_redshift-hardware-based-blue-light-filter-for-old3ds-and-2ds.493736/

As an app it really could literally change the game for 3DS owners worldwide because the difference between a non and calibrated screen is literally night and day. Most people have TNs which all have the Gamma ramped up way higher than it should be which leads to complaints of it looking washed out. The IPS give the illusion of more depth/being vivid but only do so by crushing the black (black pixels don't matter, eh Nintendo?) and introduce mild banding artifacts.

IPS gradient test:

TN gradient test:

Heck, guys, heck!

So both screens have their ups and downs and both could be immensely improved with a calibration app. What say?

DSoryu · Sep 24, 2020

@Sono may know if this is doable. AFAIK, messing with the calibration setting could mess up the screens, but I'm not entirely sure.

Deleted member 42501 · Sep 24, 2020

Dartz150 said:
@Sono may know if this is doable. AFAIK, messing with the calibration setting could mess up the screens, but I'm not entirely sure.

I agree, the calibration tool from the devkit isn't the way to go as it doesn't alter the variables that are needed to balance the screens. Its interesting how every Nintendo handheld from the Gameboy range upto the DSi had a potentiometer for the screen:

https://gbatemp.net/threads/my-top-screen-on-dsi-is-a-bit-too-dark.494805/

Does the 3DS have such a thing tucked away on its logic board? Anyone looked? Thread about scanlines and the devkit settings tool here for further reading:

https://gbatemp.net/threads/scanlines-on-n3ds-xl.381530/page-5

Interesting quote here about the Gamma which confirms what I suspected:

Pereb said:
The "black crush" you're describing is actually a gamma issue, the IPS has something like ~2,8 gamma whereas the non-IPS has ~1,8 gamma. Basically, the IPS is too dark and the non-IPS too bright. Ideally it should be 2,2 but Nintendo gives no fucks. (Personally also I prefer the non-IPS in that regard)

From this thread:

https://gbatemp.net/threads/guide-tn-and-ips-displays-which-does-my-3ds-have.409925/page-3

If this app is doable it really could be a game changer because its obvious the hardware is just outputting non optimised images to whatever screens they could find and this is what causes them to look less than stellar.

Sono · Sep 24, 2020

(Unrelated to the topic, but the shot of the IPS screen looks so artistic that I didn't even notice the screen was displaying content until I scrolled down; I thought it was just very clever diffuse lighting)

The best tool currently available yet is CTR_Redshift for adjusting the colorramp, and either Config (CON FIG) or my MCU test application to adjust the "LCD flicker" option.

I have mentioned that the problem with the lookup table is that it's only for the final stage in the display output, and it literally only "remaps" the digital color output pins going to the LCD (or in simpler terms, it changes what color is actually output to the LCD based on the content of what would actually go to the LCD otherwise). And because the final stage is capped at 8bits (because the LCD is 3x8bits, so more doesn't make sense in the output stage), any color correction will create visible color banding and other weird artifacts.

But if the colors being correct outweigh the compromises, then sure, why not, it's possible to create a color correction ramp. Sadly only a ramp is supported though, so don't expect fancy 4x4 matrix filters to work here. No desaturation filters or other fancy things are supported.

As for the "LCD flicker" option, that's most likely the LCD driving bias which has to be flipped to make the raw LC panel's life longer by not accumulating charge inside of it. The "flicker" part comes from the way the signal is driven. It has to be flipped somewhat frequently, at least once a second. But you can feed any low-frequency polarity-flipping signal to it, no problem, as long as it's flipped with a somewhat low frequency at least once a second.

tl;dr: color correction is yes possible with compromises, don't touch LCD flicker option unless HWCAL missing

Deleted member 42501 · Sep 24, 2020

Thanks for the insight, very interesting. I was reading how you'd reverse engineered the GPU side of things and that intrigued me as incorporating those elements in with your idea could do some good things.

From what you say your approach with blue blocking is similar to the pixel overlay method non jailbroken apps use on phones as the APIs don't allow low level access whereas things like flux work from the root upwards and completely remove the blue instead of mixing it to change the output and the end results are totally different.

Ultimately its mainly the Gamma aspect that we need to change, everything else is incidental as this is main problem with both IPS and TN screens.

Theoretically I think that a combination of GM9 and your code with a bit more tweaking could definitely achieve a greater image quality.

If anyone else knows any devs who are knowledgeable in these areas please @ them so we can make this happen.

Sono · Sep 24, 2020

replicashooter said:
From what you say your approach with blue blocking is similar to the pixel overlay method non jailbroken apps use on phones as the APIs don't allow low level access whereas things like flux work from the root upwards and completely remove the blue instead of mixing it to change the output and the end results are totally different.

Nope, it's the other way around. NTR does an overlay-like thing, and I do the "root" counterpart. I can explain.

For those who don't know, rootless "blue light filtering" works by showing a partially transparent panel with passthrough events (so you can interact with what's behind it). The downside to this approach is that you can TELL that it's an overlay, because when the screen would be fully black, you can see the panel blending the black to red. Not only does it look awful, it messes with the colors too for this same reason.

The "root" counterpart however can use proper curves (and in most cases 4x4 matrixes make the highest quality redshift), which can make black be truly black, not dark red.

Think of it this way:
- with the overlay you're literally just like putting a transparent red plastic in front of the screen, hence it looks so awfully bad
- with the "root" method, you're using color maths to subtract/reduce non-red in the image, more closer to real life color blending, hence it looks much better

replicashooter said:
Theoretically I think that a combination of GM9 and your code with a bit more tweaking could definitely achieve a greater image quality.

It's actually most likely Luma which would need to implement this, since you need userland code to do this. Although it could be solved like CTR_Redshift, but you'd need to fix the curve every damn time the screen changes mode by manually opening a tool which refreshes these curves.

The problem with GM9 is that it has to turn off the screens and the display controller, so the curves get wiped, and Nintendo's driver code initializes the curves to linear anyways, so these settings would be lost on startup either way.

Homebrew Screen calibration app

Well-Known Member

GBA/NDS Maniac

Well-Known Member

cripple piss

Well-Known Member

cripple piss

Similar threads

Popular threads in this forum