ScepticDope
commented
4 years ago Some possible future improvements beyond the scope of this proposal, as previously mentioned here: https://github.com/godotengine/godot/issues/27956
I'd very much like to import some HDR .png files for my game. And be able to toggle HDR on and off on viewports that then start using the correct import version of the PNG.
Also at some point would love a HDR Video Content video format support for the VideoPlayer.
@fire I read your post here: https://github.com/godotengine/godot-proposals/issues/1004#issuecomment-639721193 The Frostbite engine forces monitors to switch to HDR mode automatically. Even on Windows 8.1 it automatically switched my monitor to HDR, only other application I know of that does that is MadVR. Sadly they are both closed source, besides some very limited information, I have no clue how to go about this specific problem involving HDR.
For Windows it seems to involve sending specific HDR meta data to monitors and exclusive fullscreen somehow and well, that is all I got so far. But that would mean Godot would need to implement that feature first, some references have been made to this issue: https://github.com/godotengine/godot/issues/14542 But there seems to be no actual mention of it specifically there.
Godot's current available OpenGL 3D graphics API's possibly don't actually have a exclusive fullscreen mode. So it might be an idea to wait with more HDR features until the Vulkan build is ready, as Vulkan does support it. I am yet to find if this is a cross platform issue or this exclusive fullscreen is only something specific to Windows to bypass its compositor: https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VK_EXT_full_screen_exclusive
*Something I stumbled upon is that Nvidia and AMD drivers might also create some differences around exclusive fullscreen.
I haven't found a lot of specific info on the HDR meta data you'd need to send over your display signal to the monitor. But I did find this in the Vulkan Specs:
https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#_hdr_metadata
After all this I wondered if a quick and dirty alternative to all this low-level stuff, for Windows 10, could be to simply force the Windows HDR mode to toggle on? I found that someone managed to do exactly that using the Nvidia driver!: https://github.com/bradgearon/hdr-switch
fire
mysterycoconut
MJacred
Calinou
allenwp
alvinhochun
huwpascoe
Describe the project you are working on: 3d multiplayer game project
Describe the problem or limitation you are having in your project: Rewrote https://github.com/godotengine/godot/issues/26826 as a proposal. Thanks to @toasteater.
Expected: Godot is aware of ICC profiles, and render correctly on wide-gamut displays. Actual: Godot is not aware of ICC profiles. Colors are distorted and over-saturated.
Many systems (including Windows and X11 platforms) do not have end-to-end color management, and it's up to applications to convert images to device gamuts for display.
Currently, Godot converts all output to sRGB and pushes that directly to the device. The colors are then interpreted as coordinates in the device color gamut, which is usually not exactly sRGB either, but significantly different in case of wide gamut displays. This causes major color distortions, both in the editor and in the exported games.
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
ff0000)Expected: Same color rendered. Actual: The color rendered by Godot is much more saturate.
Unfortunately, the effect is much less observable on a normal sRGB-ish display. On my device GIMP renders the sRGB
ff0000asd53b1a, if that puts it into any perspective.While arbitrary gamut conversion can be nice, the most currently needed feature is conversion from sRGB to display gamut, in the editor. One possible way is to allow users to specify an ICC profile in preference, which will be used to generate a 3D LUT texture on load. This resulting texture will then be used to transform the entire editor interface as the last step of rendering. This should suffice for the current use case.
Possible further improvements outside the scope of this feature proposal may include:
It's possible to take LittleCMS (MIT license) on as a dependency for this feature, which I understand won't be a very lightly made decision. ICC profiles are rather complex, so writing one's own parser can be quite slow and error prone. I'm also not experienced with Godot's code base, so I'm seeking feedback before coding anything.
If this enhancement will not be used often, can it be worked around with a few lines of script?:
No. A workaround is possible, but significant work is required:
It's possible to use a custom postprocessing shader and a LUT to convert sRGB (or Linear with sRGB primaries) to whichever color gamut desired. However, custom postprocessing is not currently very wieldy, and it does not apply to UI elements (e.g. color choosers) on the editor side. It's also requires users to somehow generate their own LUTs from ICC profiles.
The Color Correction option in Environment is not fit for this purpose, as it can't be used for 2D, and also conflicts with scene grading within the sRGB gamut.
See https://github.com/godotengine/godot/pull/26869 for a draft in 3.2.
Is there a reason why this should be core and not an add-on in the asset library?:
Changing the rendering pipeline is part of the core.