Color Picker UX Limitation: Inconsistent sRGB Preview vs Actual Values

Development Pipeline & Plugins
, ,
1

Hi everyone,

I’d like to raise an issue with the Unreal Color Picker UX. This topic has appeared in community discussions for almost a decade, but there is still no actual solution in the editor, and it continues to cause daily workflow problems for artists.

First, to be clear, we understand and fully support Unreal’s linear rendering pipeline and the need for material parameters to store FLinearColor values. This request is not about rendering correctness.

The issue is strictly Editor UX, specifically how the Color Picker handles sRGB Preview and slider behavior.

Artists typically author colors in sRGB-encoded (perceptual) space, where the midpoint (0.5) corresponds to ~0.21 in linear. This provides even perceptual control, especially in dark shades.

However, the Unreal color picker’s gradient sliders always remain in linear value positions, even when sRGB Preview is disabled. The sRGB Preview option affects only how the gradient is displayed, not the actual value space being edited.

This leads to two major problems:

  1. sRGB Preview OFF – Gradient looks perceptual, but picking a “middle gray” produces linear 0.5 (not ~0.21), which results in a visible mismatch between picker and resulting output.
  2. sRGB Preview ON – Display is correct, but the linear slider becomes extremely compressed in the dark range, making it almost impossible for artists to adjust dark colors with any precision.

Both modes therefore create confusion and inconsistent results. This is a long-standing issue - multiple forum threads going back 10 years describe the same problem (here is a good example: https://forums.unrealengine.com/t/how\-to\-set\-the\-proper\-color\-in\-color\-picker/304386\).

For teams with a lot of runtime color customization (e.g., kits, characters, UI themes), this becomes a daily workflow bottleneck.

As an example, I’ve attached a GIF showing how Blender handles this correctly. Blender lets artists adjust colors using sRGB-encoded gradients, but the numeric value shown in the picker is always the correctly mapped linear value. When dragging the slider, you see the linear value change exponentially (as expected from the sRGB transfer curve), so the authoring remains perceptually intuitive while the underlying data remains physically correct.

Importantly, this approach affects only the widget behavior, not the underlying serialized data. The stored linear values remain exactly the same. Implementing a similar mapping in Unreal would not break existing assets or change engine behavior, but it would significantly improve the day-to-day workflow for artists working with color.

[Attachment Removed]

2

Hi Andrei,

If I understand correctly, the preferred behavior would be that:

  • the Color Sliders showed the “perceptually middle gray” at half their length (like when “sRGB Preview” is OFF), but
  • clicking or dragging the Color Sliders at half their length produced a color at 50% the sRGB range, which would correspond to a linear color value of ~0.216.
  • toggling sRGB on and off didn’t change the actual appearance of the color sliders, but rather changed the currently selected position on them (e.g. around 50% for sRGB on <-> around 21% for sRGB off)

Is this correct? I have also attached a video demonstrating the behavior.

[Attachment Removed]

3

I have prepared a patch for the Color Picker UI that changes the behavior as I explained above. If you are building the engine from source, would you mind testing these changes to verify if the new behavior matches your expectations?

Best regards,

Vitor

[Attachment Removed]

4

Hi Vitor,

I’ve tested the patch - thanks for sharing it. The perceptual editing behavior (when “sRGB Preview” is ON in your patch) works exactly as expected now: slider distribution feels right and midpoint maps correctly to ~0.216 linear. This is a big improvement.

There’s still a small UX issue when switching to linear editing mode (“sRGB Preview” OFF). While slider positions and numeric values are correctly remapped and preserved, the slider gradients themselves still appear perceptual, so in linear mode the visual ramp doesn’t match linear spacing. This makes it easy to pick unintended values. Ideally, in linear editing the gradients should switch to a true linear ramp, while keeping the picked color unchanged (same as stored color shown in the parameter).

Also, the label “sRGB Preview” feels misleading now, since we’re not switching color spaces (color values stay linear) but only the editing mapping. Something like “Perceptual Editing” / “Linear Editing” (or similar) would better describe the behavior.

However, now from a UX point of view, linear editing feels somewhat redundant, since values are always stored in linear space and perceptual editing already covers most practical authoring needs — but this is of course up to you to decide.

I’ve attached a gif showing the expected result. Happy to test any follow-up changes.

Best regards,

Andrei

[Image Removed]

[Attachment Removed]

5

Hi,

Quick update here, Vitor’s changes look good but it’ll take a bit of time to get those integrated and reviewed. If you’re happy with the patch for now, we can send along an update if we’re able to get those integrated so you can revert the patch and sync back up with an engine release.

Best,

Cody

[Attachment Removed]

6

Hi,

We don’t have anything to pass along just yet, but once the changes make it into mainline I can send over a changelist for you to grab. That would give you a chance to integrate it right away, rather than waiting for the next engine release. I’ll reach out once we have something to share.

Best,

Cody

[Attachment Removed]

7

Hi Andrei,

I’m glad my patch appears to be a move in the right direction. Now that the expected behavior seems a little more clear and that you have your hands on an improved version of the Color Picker, I will escalate this case so that the Epic devs that own this UI can take a look at this discussion and follow up from here. They might contact you in this thread so that this can possibly lead to an official feature request.

I will be out-of-office for the holidays over the next two weeks, but I’ll keep an eye out for any possible developments here. If the engine devs mention that this change is unlikely to make it into an official release, or that it will take a while to be officially developed, tested and integrated, then when I come back I’ll be happy to continue improving this unofficial version of the UI together with you so that it behaves exactly as you feel it should. It will probably be valuable for others that get here looking for this as well.

All the best,

Vitor

[Attachment Removed]

8

Hi Vitor,

Thanks a lot for taking the time to dig into this and for escalating the discussion internally - it’s very much appreciated. The patch really helped clarify the expected behavior and validate the direction, and I’m glad this is now visible to the team owning the UI.

Best regards,

Andrei

[Attachment Removed]

9

Hi Cody,

Thanks for the update - that makes sense.

Vitor’s changes are experimental, but they do a good job of validating the core idea. As mentioned earlier, there are still a few tweaks needed before this would be fully usable in production on our side, but the overall direction feels right. I completely understand that proper integration will take time and review, especially since this touches core editor UX and there are several possible design alternatives.

If it’s feasible, we’d be very happy to get access to a more production-ready version of the patch earlier (even as an interim solution) before it lands in an official release. That would already be a significant quality-of-life improvement for our artists.

Best regards,

Andrei

[Attachment Removed]