Color Spaces are ignored in editor texture/debug views

Development Pipeline & Plugins
, ,
1

We’re using the Rec 2020 color space in Unreal, to make use of the wider gamut, especially when the game is displayed on an HDR monitor. But we noticed that this causes textures and colors to not be displayed correctly in the editor.

I did make some engine content changes to fix this, but I’m not sure

a) if we’re just doing something wrong to cause this issue in the first place

b) how to proceed, as the current fix doesn’t fix all the instances of the problem and is prone to errors

As described in the repro steps, when working in a different color space than the default one (Rec 709), the colors look wrong in the texture editor and color visualization views, but fine in the rendered image. It seems that in some places, the option to use different color spaces wasn’t considered. Transforming the output colors back to the Rec 709 space fixes the issue. This can easily be done for the visualization views by editing the materials in /Engine/BufferVisualization/ (can be seen in the attached screenshots), but not for other places like the texture editor, thumbnails, etc.

My fix works okay for now, as we don’t have plans to switch to a different color space, but ideally, the visualization views would respect the working color space and transform the result to the output color space.

This issue is not just about textures: When using color parameters in a surface material and using the sRGBColorToWorkingColorSpace material expression to transform the colors to the working color space, the color looks identical to the previewed color in the color picker, but looks off in the visualization views.

Is the current state of this intended behavior or are there any changes planned to this? For artists, the current behavior is very confusing, as they can’t judge the colors of textures by looking at the textures or thumbnails in the editor, so any input on this is appreciated.

[Image Removed]

2

Thanks for the thorough explanation!

As you noted, the display handling for debug views and the texture editor do not take into account the Working Color Space. The mistake those modes make is that they assume the display color space is the same as the Working Color Space. The proper handling will involve using a WorkingColorSpaceTosRGBColor conversion (which is not yet in the current engine) to display those colors that do not go through the normal post processing. The more proper fix (targeted for 5.8) will use FColorSpaceTransform::GetWorkingColorSpaceToSRGB() to provide that functionality.

3

Thanks for confirming this bug, I’m looking forward to 5.8 then.

Any advice on how to proceed in the meantime?

I managed to fix the issue partially by doing the conversion back to sRGB in FBatchedElements::PrepareShaders():

[Image Removed]But from within that function, I can’t check which color space the original texture was using. And by just doing the conversion for all sRGB textures, UI textures are displayed incorrectly, as they are displayed in the game without any color space conversions, so they don’t have their source color space set.

4

Overall, the texture display window needs a refresh. It has other issues (zoom/pan is poor, pixel info is missing, etc).

I’d like to get your thoughts on what your expectations are for the view of a 2020 image on 709. If the texture editor always does the conversion from 2020 to 709, the display will likely show colors that appear clipped because they are different in 2020 but are forced to the same 709 values by the view. Which implies you would not always want the conversion to happen, to allow you to look at the values more directly (although not displayed as proper color). When you consider the artist workflow you are intending, how large of an issue do you feel that would be?

5

Right now, I’m telling artists to use the base color buffer visualization view if they want to know how their textures look like, and to ignore how the textures are displayed in the texture editor. Which works, but isn’t ideal, because people new to the team or non-artists who also work on art assets from time to time may not know about this + it’s cumbersome to apply a material using the texture to a surface in the level and enable the view mode just to see the texture with the correct colors.

Ideally, textures would be transformed from the working color space to the output color space when displayed in the editor, but only if their source color space is set to one that is not the working color space.

All our base color textures have their source color space set to Rec709, and look correct with the transformation applied.

Our UI textures don’t have their color space set, and are displayed correctly in this game, since the color space settings don’t affect the UI. So for these, no transformation is needed.

Regarding the clipping: Yes, that can occur, but it’s not a noticeable issue in most cases, so I’d be fine with that. If it really turns out to be a problem, perhaps there could be an override option in the texture editor to disable the transformation/change the output color space.

6

To summarize state for closing this case: We are looking at visualization modes for 5.8, as well as the texture editor. The issues you highlight are all recognized, and we want to integrate fixes for those issues as well as other aspects of viewing of render targets in general.