Skip to content

fix: encode sRGB in the shader when the surface format isn't sRGB - #31

Merged
CPritch merged 1 commit into
mainfrom
fix/srgb-output
Oct 11, 2026
Merged

CPritch merged 1 commit into
mainfrom
fix/srgb-output

Conversation

@CPritch

@CPritch CPritch commented Oct 11, 2026

Copy link
Copy Markdown
Owner

Some GLES screens offer no sRGB surface format, so the renderer drew to an Rgba8Unorm surface, which stores linear colour as it is. Wallpapers came out too dark.

A pipeline constant, ENCODE_SRGB, now has the fragment shader encode its output for Rgba8Unorm, Bgra8Unorm and Rgb10a2Unorm. sRGB formats are encoded by the GPU as before, and float formats such as Rgba16Float hold linear colour, so both are unchanged.

Tested in the Android app on an emulator whose GLES screen has no sRGB format. A photo's mean brightness:

Before After
Vulkan (Rgba8UnormSrgb) 193 193
GLES (Rgba8Unorm) 163 193

cargo test -p shiftpaper-render passes, with a test of which formats get the encoding.

Some GLES screens offer no sRGB format, so the renderer drew to an
Rgba8Unorm surface, which stores what it's given: linear colour, shown
too dark. A pipeline constant, ENCODE_SRGB, now has the fragment shader
encode its output for the unorm formats without the sRGB suffix. Float
formats hold linear colour and are left as they were.

On an Android emulator whose GLES screen has no sRGB format, a photo
drew at a mean brightness of 163 against 193 on Vulkan; with this it
draws at 193 on both.
@CPritch
CPritch merged commit 642b34d into main Oct 11, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant