Project

General

Profile

Emulator Issues #8941

Color Consistency - Color Space

Added by eckso over 5 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

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.

History

#1 Updated by eckso over 5 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.

#2 Updated by phire over 5 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.

#3 Updated by eckso over 5 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).

#4 Updated by theincrediblemastere over 5 years ago

Any follow up for this issue?

#5 Updated by eckso over 5 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.

#6 Updated by BhaaL over 5 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.

#7 Updated by JosJuice over 5 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.

#8 Updated by eckso over 5 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.

Also available in: Atom PDF