Shaders and colorspaces, brightness wrong

[andrewbaxter]

I put together a dumb shader in shadertoy:

void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
    vec2 uv = fragCoord/iResolution.xy;
    fragColor = vec4(vec3(uv.y),1.0);
}

This shows a grayscale gradient, black at the bottom, white at the top (as I'd expect). My knowledge of color spaces is weak, but I assume this is sRGB (because devices use srgb internally? and the shader doesn't do anything more than it needs to?)

In Bevy I tried the same shader

@fragment
fn fragment(in: VertexOutput) -> @location(0) vec4<f32> {
    out_color = vec4<f32>(vec3<f32>((in.world_position.y + material.size.y / 2.) / material.size.y), 1.);
#ifdef TONEMAP_IN_SHADER
    out_color = tone_mapping(out_color);
#endif
    return out_color;
}

When I run this, it's mostly white/grey all the way down to the bottom where there's a little bit of black.

I had the tonemapping_luts feature disabled, but tried turning it on and adding those TONEMAP_IN_SHADER bits but no change.

I can only guess that bevy has some other code in the pipeline that converts the shader output color into a different color space, maybe assuming it's linear rgb or something. I googled bevy srgb bevy linear rgb bevy shader bevy gamma etc and couldn't find anything though. AFAICT the shader examples, etc don't do anything like correcting colors (although they're pretty trivial).

So I think my main question is, how do I get this to look like shadertoy's output? But aside from that are there any other gotchas for doing 2d design-style (instead of physical modeling) shaders I should be aware of?

Bevy on the left, shadertoy on the right.

[andrewbaxter]

I'm using textures too, here and there, and I guess bevy is massaging the colors from the texture before passing them into the shader... will that complicate things?

[andrewbaxter]

I found this... although it seems to be doing the opposite (converting the good shadertoy srgb generating code into incorrect linear generating shadertoy code). https://stackoverflow.com/questions/72243378/shadertoys-glsl-and-rust-bevy-wgsl-incoherence .

I did some reading. It sounds like the framebuffer is by default srgb, so shadertoy's behavior is normal and expected.

Bevy is either using a linear srgb framebuffer or has a step in the pipeline that converts all the colors to srgb for the srgb framebuffer, assuming it's linear srgb coming in.

So basically I need to convert my non-linear to linear so bevy can convert the linear to non-linear for the frame buffer which then gets converted to linear for output...

And for textures I need to convert the linear (I assume) texture samples into non-linear to do math, then (as above) convert the non-linear final fragment color to linear for bevy, bevy converts the linear to non-linear for fb, something else converts the non-linear fb to linear for output.

Awesome.

[andrewbaxter]

So I think the workaround is

fn from_linear(linear: vec4<f32>) -> vec4<f32> {
    let cutoff = step(linear, vec4<f32>(0.0031308));
    let higher = vec4<f32>(1.055) * pow(linear, vec4(1.0 / 2.4)) - vec4(0.055);
    let lower = linear * vec4<f32>(12.92);
    return mix(higher, lower, cutoff);
}

fn to_linear(nonlinear: vec4<f32>) -> vec4<f32> {
    let cutoff = step(nonlinear, vec4<f32>(0.04045));
    let higher = pow((nonlinear + vec4<f32>(0.055)) / vec4<f32>(1.055), vec4<f32>(2.4));
    let lower = nonlinear / vec4<f32>(12.92);
    return mix(higher, lower, cutoff);
}

Call from_linear on colors sampled from textures and from colors passed in the uniform as Color (or else convert to Vec4 in the uniform).

Call to_linear in the fragment shader on the final color.

[bokubeam]

I'm working on a color picker and was having the same issue. Thank you for the workaround.