I’m currently exploring converting my project to use Rec.2020 has the Working Color Space for HDR support. I found a weird issue with texture settings. Since most (nearly all) textures are authored with sRGB/rec.709 primaries, they should have their Color Space set to sRGB/Rec.709, so I’ve been testing that on a few different textures. And this is all it took for the engine Color Checker texture to appear correct. However, all other color textures appear incorrect, and only when also setting the Encoding Override to also be sRGB do they look correct.
Digging a little deeper, it looks like the Color Checker texture, which has sRGB checked in settings, is a 16bit source file which get’s treated as linear, so the Color Checker just ignore is and is already linear? What’s also strange that the 8bit version of the color checker texture is not affected by the encoding override at all.
However, all other textures are, even though they are seemingly setup the 8bit one with standard color texture settings, need Encoding Override to be set to sRGB in order for them to appear correctly.
When using rec.2020 as the working color space, what are settings are intended to be correct for color textures that were authored in rec.709? What other general rules or guidance is there for moving a project to rec.2020 working color space?
In the screenshots attached, all the images on the left are from an SDR version of the editor with rec.709 as the working color space, and the right side is an HDR version of the editor with rec.2020 set as the working color space.
What other general rules or guidance is there for moving a project to rec.2020 working color space?
The following post is related to this: [Content removed] however, it’s possible guidance has changed with the entrance of ACES2 so I’m assigning this question to a colleague who is more familiar with this work.
As for the texture conversions, can you clarify what source format each texture is in the screenshots? If that’s the 16bit checker texture then using the sRGB encoding override is likely causing the already linear data to be decoded as sRGB and crushing the values.
With a Rec.2020 working color space, any texture that has sRGB/Rec.709 color gamut should have its source color space explicitly set to sRGB/Rec.709 for the color gamut conversion into working color space. (You can batch process all your existing assets.) We’ve discussed supporting naming conventions or adding metadata support to the relevant formats, but for now the color space conversion has to be tagged manually with the override. After which, no further material/shader changes are needed, your colors will be in working color space. On output, the tone map process will automatically apply conversions from working colors place to the relevant display space.
As far as the source encoding override (transfer function), this is independent of the working color space. The texture import process should take care of it automatically as usual via the pre-existing sRGB checkbox depending on the formats. Linear floating-point textures will remain linear, and sRGB-encoded low-bit-depth color textures will usually be decoded (for linear mip generation), and use hardware encoding (_SRGB on the gpu) to avoid precision loss.
A (relevant) comment was recently added to Texture.h (which historically/incorrectly exposed properties directly as opposed to getters/setters):
Some important rules and guidelines when working with UTexture :
1. All changes to Texture properties must be wrapped in PreEditChange/PostEditChange , eg :
Texture->PreEditChange(nullptr);
Texture->SRGB = true;
Texture->PostEditChange();
You could even try calling ForceRebuildPlatformData(), but the above should cover it.
The color checker is the one from the engine, which I believe is 16bit float source, but the dirt texture is a 8bit tga source.
However, I did discover the issue. I wrote a small commandlet that sets the color space value to sRGB. However, if commandlet rendering is not allowed, when running UnrealEditor-cmd.exe without -AllowCommandletRendering, it will save the metadata and update the DDC key, but not actually update the platform data. This put the asset into a bad state where the settings were saying the data was correct but it was indeed wrong. That seems like a bug in in texture processing, since it will partially set the settings but then bail on setting the texture data.
I have read over that post, and it’s helpful!
For color parameters, what is the best way to handle it? Adding a node to every material graph seems not great, but some conversion to the working color space is clearly needed. I’ve been experimenting with a modification to the color picker so that it still picks in rec.709, and it’s number values in the color picker widget assume rec.709, but then stores in rec.2020. This means a manual rec.2020 color could be entered. But then that also means anyone interacting with colors in code or BP is forced to work in the working color space directly. I might try some “Set Classic(sRGB) Color” functions/nodes to help there.
Thank you! That was my understanding of the pipeline but an apparent DDC bug made me question it. It appears that the texture compiler will not always compile a texture fully but will generate the key, when changing the color space override in code. I had assumed that I fixed it, but after having to delete my Zen data textures re-compiled are back in the state where they say they have a color space override of sRGB/709, but the resource has not been converted to the working color space.
ah, so `Modify` is not enough? It must be PreEditChange/PostEditChange?
I am calling `ForceRebuildPlatformData` in my commandlet that sets the color space, and it seems to work until I have to clear my Zen DDC data folder, and then the textures are broken again.