Emulator Issues #8941
closedColor Consistency - Color Space
0%
Description
Rendered output should conform to known color spaces in order to present a consistent color reproduction throughout the different display devices.
For example on SD (some mobile, software renderer, etc) BT.601 should be used, HD outputs should adhere to BT.709 standard (mobile, monitors, HDTVs), UHD outputs should render with BT.2020 coefficients (UHDTV, 4k monitors).
By doing this you ensure that the image looks the same in all three devices, furthermore if you calibrate your display and assign a profile to it you can ensure a correct color reproduction of the content.
This along the previous HQ kernel options can finally put an end to the most critical points still lacking in Dolphin, since audio is well covered just like 3D rendering options. One thing to note is that scaling (discussed in the previous opened issue) must be color space aware, so for example you might render the game with the software renderer engine (SD) so it should adhere to the BT.601 color space standard, but you might want to play it fullscreen (HD) so a BT.601->BT.709 color space conversion must be performed on the upscaling process.
Updated by eckso about 9 years ago
I realized that this is true if the output of the video is in YCbCr color format, if this format is never used in any step of the rendering pipeline and all is done in RGB then a RGB space should be used. I guess rendering is done in float point so a suitable space could be WideGamutRGB, in rasterization a color transfer should be performed with a rendering intent of choice to sRGB which should be fine for most displays (with a dither down algo of choice). This ensures color fidelity through the whole pipeline.
Updated by phire about 9 years ago
In most modes, dolphin keeps everything in RGB color space. (though at many points RGB666 or RGB565 is used)
The exception is when realxfb is enabled, in which case dolphin emulates the parts of the gamecube's pipeline that converts the video from RGB to YUVU color formats (in the BT.601 color space). On a real gamecube this would be output to the TV, but dolphin eventually converts it back to RGB.
Updated by eckso about 9 years ago
So Dolphin never renders in float point? If that's the case maybe RGB666 can fit inside the sRGB space. But I actually thought (and expected) to render in float point at some stage so a dithering algo could be used (output has severe visible banding).
Updated by eckso about 9 years ago
Still waiting for developer feedback. Currently all main features seem to be broken.
-Subpar raster scaling (bilinear maybe?) https://bugs.dolphin-emu.org/issues/8940
-Broken Aspect Ratios https://forums.dolphin-emu.org/Thread-correct-aspect-ratio-option?pid=380580#pid380580
-Broken Stereo 3D https://bugs.dolphin-emu.org/issues/9043 https://forums.dolphin-emu.org/Thread-broken-stereoscopic-3d-since-4-0-7924 https://github.com/dolphin-emu/dolphin/pull/3076#issuecomment-148892153
-No CMA (Color Management Aware -false colors-) https://bugs.dolphin-emu.org/issues/8941
-Broken DPLII https://bugs.dolphin-emu.org/issues/9047
I think they are all busy with gimmicky Android emulation or fixing minor cyclical issues in an endless loop. I suggets you to use 4.0-7924, it's currently the best compromise.
Updated by BhaaL about 9 years ago
I'd rather guess that none of the currently active developers (that also understand the gist of what those terms actually mean) have the time to dive into this right away. We can only do so much all at the same time.
But its important to make us aware of such issues by creating a report like this one - otherwise we might not even know which things are broken and in which way.
And we really appreciate higher quality reports (beyond your run-off-the-mill "it doesn't work") that goes into more detail and lists references of how to improve things.
We certainly don't mind if you want to try and tackle it yourself by grabbing the source off GitHub and helping us improve those parts of Dolphin. At pretty much all times, we also have both active and (somewhat) retired developers sitting on IRC ready to give you a hand in getting started.
Updated by JosJuice about 9 years ago
What I would call a broken main feature would be things like games crashing, major graphical glitches or controllers not working. Improved scaling and color profiles are just enhancements in comparison. Issues like broken stereoscopic 3D are among the more serious ones, but like BhaaL says, we can't work on everything at once. All of your issues (except the Star Fox aspect ratio?) seem to be valid, and we haven't forgotten about them, there just hasn't been anyone who's gotten to it yet.
Updated by eckso about 9 years ago
IMHO, you can't promise rocking bleeding edge image quality with an outdated or subpar bilinear scaler and no dithered quantization, more proper of 20th century technology. It's akin to using RealVideo or MPEG1 to encode video these days, an anachronism that I rightfully understand as 'broken feature'.
I'm not a programmer (not interested or my field) I only do some scripting on AHK and Avisynth, but I work with digital imaging from long ago and understand the concepts and foundations, even if not at a math level. Maybe I failed to think there were many capable individuals working in Dolphin as everything is basically related to graphics/image.
Updated by filoppi over 1 year ago
I've been implementing this with a post process shader.
Updated by filoppi over 1 year ago
https://github.com/dolphin-emu/dolphin/pull/11850
implements this
Updated by eckso over 1 year ago
Thanks! Almost 8 years, a long ago, but still partially valid.
I presume most mobile now adhere to Rec709, and I wouldn't mind the same space for 4K displays, unless you can in some way signal the space to the display so it can understand it's Rec2020.
That's on the ODT side. On the content side we should (or not?) assume the titles were developed on a 170M primaries display, in the case of Japan with a cool (~8600K) temperature.
I've been working on this as a RetroArch shader so I can port it to Dolphin.
Updated by filoppi over 1 year ago
Could you post some documents regarding japan having a different white point?
I saw this regarding RetroArch:
https://forums.libretro.com/t/dogways-grading-shader-slang/27148/31
This is the conversion shader btw:
https://github.com/dolphin-emu/dolphin/blob/db3737888498c5bc2af16b71eeeedcffe538ee39/Data/Sys/Shaders/default_pre_post_process.glsl
I know japan might have used a different color standard, I have the matrices already:
NTSC-J_D93->BT.709
1.32745087664703, -0.380214678733890, -0.100329573150289,
-0.0241884654923695, 0.954431246666081, 0.0807083191208534,
-0.0239666552881284, -0.0409804675743561, 1.40744062346599
NTSC-J_D65->BT.709
1.46069746871630, -0.384577572321753, -0.0761198963945517,
-0.0266164503247607, 0.965383169879572, 0.0612332804451890,
-0.0263723753012927, -0.0414507109111025, 1.06782308621239
But I wasn't sure it had been actively used.
I guess I should indeed implement these as well (at least the D93 one?).
I'd like to hear more :),
would you like to join the dolphin discord server (https://discord.gg/dolphin-emu)? You will find us in the #dolphin-development channel.
Updated by filoppi over 1 year ago
Updated by JosJuice over 1 year ago
- Status changed from New to Fixed
- Fixed in set to 5.0-19716
Updated by eckso over 1 year ago
I don't think this is addressing color management, just phosphor emulation + HDR.
For proper color management this is dealt in https://github.com/dolphin-emu/dolphin/pull/11888 with a post-processing shader for Rec709, sRGB or P3-D65 calibrated displays, along a gamut compression for those not with a wide gamut display.
Read more here: https://github.com/dolphin-emu/dolphin/blob/5c6f36a42e4981b0fd9745707e8cd1adddf5184d/Data/Sys/Shaders/grade-mini.glsl#L502