What is causing this gradient texture to decode incorrectly?

While working on a shader effect, I noticed some visual errors from certain values in my gradient texture used for input. The merged steps/values issue appears to be occurring on Firefox(Linux, android versions cannot seem to reproduce), and I assume cannot be fixed other than filing a bug to Firefox.

There is still an obvious value that renders as a much darker shade than it should be, and this shows up in all browsers I tested. Is there a way to fix it at all? (My shader is not used on a gradient but grayscale texture data)

To clarify, if you inspect the source texture png in an image editor, the values are consistent without these issues. I’ve also had the shader just display the image without any additional processing and still had the issue reproduced(although it’s not perceivable at those dark values, an image editor checking the values showed something went wrong decoding the image.

Here is the issue in Firefox(Linux) - Left(texture only), Middle(texture + shader), Right(gradient generated in glsl with shader applied):

And in Chrome(Linux), same result in Android:

CodeSandbox for reproducing:

Can you please explain in more detail the visual error? TBH, your issue is not clear so far.

Maybe it helps to explain the expected and actual result?

Here is your gradient image:

It seems it is rendered correctly

Sorry, spent all day looking into it and seeking help on the discord server, missed that detail.

The right plane shows the expected result, it works because it is generating the gradient within the shader.

The middle plane is the result with texture, of you look at the images I’ve provided at the lower quarter there is a transition from white to black further up, but along the way one of those lines/values has ended up a much darker shade than it should be.

With Firefox there is more issues on top of that, if you look more carefully there is several times that the lines are twice as thick, one of the lines took the same shade of the neighbor when they should be distinct values, not the same.

This issue with Firefox is not caused by my shader but by the texture before the shader uses it. That texture is on the left, it is the first 32 values of 0-255 for an 8-bit texture channel. If you screenshot it those same thick lines should still be sharing the same value, however if you inspect via an image editor the source image in the linked codesandbox, the values are unique…

When I animate the shader uThreshold over time, the visual error was more noticeable. There is an included 256 shade full black to white gradient source image in the code sandbox for further reference it’s just most of the visual error is within these darker values, with one more near 128.

For further clarification, I will reiterate that the gradient is for debugging as it’s easier to make sense of. The actual texture input I use in my project is more detailed /varied, I can’t just generate its values in glsl.

Sorry, the intended result is the right plane with no issues in its remapped gradient values.

The middle plane shows the result when the shader is applied to the gradient texture instead, which causes errors as explained above.

The left plane is just the input gradient texture with no shader processing, it is to demonstrate that the texture did not decode to the same values correctly as the source image has when viewed in an image inspector. So something went wrong that jas nothing to do with my shader code.

I received help via a user on the discord server. Turned out that I didn’t look at the values close enough, especially the x4 variants where my image editor used Bicubic instead of NearestNeighbor for scaling.

So the gradient wasn’t evenly distributed, and the darker line was in fact faithful to the input texture which for some reason interleaved/backtracked the previous value. My low contrast monitor could not notice the issue well, but it was obvious to the user helping me that the gradient input was wrong to begin with.

Setting the textures magFilter to NearestFilter also helped quality wise with the stepped values no longer blurring between each step, and this fixed the related issue I was seeing only on Firefox.

Well this was embarrassing…

1 Like