<p><strong>Updated answer, now that pow is getting valid arguments:</strong></p>

<p>What you are seeing is called "banding" and it comes from the fact that the color channels are quantized into 8 bits - in other words, it comes from the fact that there are only 256 different shades of green, even though the math generating the colors is capable of much larger resolution.</p>

<p>The banding on my system isn't as bad as what you are describing but it's still present.  The reason it isn't as bad on my system is because you and I have different displays.</p>

<p>Some computer displays don't actually even have a full 256 different shades of green.  For instance, instead of having 8 bit color, they may only have 6 bit color, and they either dither it, temporally dither it, or neither and just let it look worse.</p>

<p>One way to get around this problem is by dithering.  There are various algorithms for dithering, with different computation and quality trade offs.</p>

<p>A good modern dithering algorithm is called "interleaved gradient noise" which is fairly close to blue noise - which is the ideal - and is pretty cheap to calculate.</p>

<p>Check out this link for more detailed information on different types of dithering, and how they compare:</p>

<p><a href="https://bartwronski.com/2016/10/30/dithering-part-three-real-world-2d-quantization-dithering/" rel="nofollow noreferrer">https://bartwronski.com/2016/10/30/dithering-part-three-real-world-2d-quantization-dithering/</a></p>

<p><strong>First answer, from when pow was getting a negative value parameter:</strong></p>

<p>The issue is that you are passing a negative value to pow for the first argument, which has undefined behavior.</p>

<p>What shows up on my screen is completely different than what shows up on yours.</p>

<p><a href="https://i.sstatic.net/swsUt.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/swsUt.png" alt="enter image description here"></a></p>

<p>You shouldn't rely on the behavior of anything in the red pixel areas in this image:</p>

<p><a href="https://i.sstatic.net/cVHfO.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/cVHfO.png" alt="enter image description here"></a></p>

<p>More info:</p>

<p><a href="https://www.opengl.org/sdk/docs/man4/html/pow.xhtml" rel="nofollow noreferrer">https://www.opengl.org/sdk/docs/man4/html/pow.xhtml</a></p>

CC BY-SA 3.0
2016-11-27T03:04:38.090Z
Just updated the code so you can see what I see now
J.Doe
CC BY-SA 3.0
2016-11-27T05:26:56.953Z
Ah ok. The negative was a red herring.  Answer updated.
Alan Wolfe
CC BY-SA 3.0
2016-11-26T22:34:48.407Z
2016-11-27T05:26:41.540Z
2016-11-27T05:26:41.540Z
Alan Wolfe
<p>I was messing with glowing lighting when I noticed an odd artifact in my first try.</p>

<p>For some reason I can see three defined edges inside of the glowing pattern. I downloaded the image and marked where I see the edges.
<a href="https://i.sstatic.net/HRuu4.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/HRuu4.png" alt="enter image description here"></a></p>

<p>I am just curious why they appear to be there as I can see no mathematical reason why they should be there. Is it just the way I am displaying it, or is there some sort of computational precision issue? </p>

<p>For reference here is the ShaderToy code that created this:</p>

<pre><code>void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
    vec2 uv = fragCoord.xy / iResolution.xy;
    float disty = abs(uv.y - 0.5);
    float distx = abs(uv.x - 0.5);
    distx *= 100.0;
    disty *= 100.0;
    fragColor = vec4(0.0, 1.0 / pow(abs((1.0 - distx) + (1.0 - disty)), 0.5), 0.0, 1.0);
}
</code></pre>

<p>Although I am not sure it is physically accurate to have those spikes on the edges of the diamond I sure do like the effect that creates.</p>

CC BY-SA 3.0
2016-11-26T22:04:13.613Z
When i copy/paste that into shadertoy I don't get anything like the output you are seeing, and just have a small green diamond.  Did you post the right code?
Alan Wolfe
CC BY-SA 3.0
2016-11-26T22:31:22.193Z
Correct the shader is just a triangle. It should be glowing. Those are lines I marked in to express where I am seeing edges in the gradient. They are not apart of the shader code.
J.Doe
<lighting>
Are these edges a result of display color accuracy, computational accuracy, or something else?
J.Doe
# Are these edges a result of display color accuracy, computational accuracy, or something else?

(Asked by: username_0 on 2016-11-26)

I was messing with glowing lighting when I noticed an odd artifact in my first try.

For some reason I can see three defined edges inside of the glowing pattern. I downloaded the image and marked where I see the edges.
[![enter image description here](https://i.sstatic.net/HRuu4.png)](https://i.sstatic.net/HRuu4.png)

I am just curious why they appear to be there as I can see no mathematical reason why they should be there. Is it just the way I am displaying it, or is there some sort of computational precision issue?

For reference here is the ShaderToy code that created this:

```
void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
    vec2 uv = fragCoord.xy / iResolution.xy;
    float disty = abs(uv.y - 0.5);
    float distx = abs(uv.x - 0.5);
    distx *= 100.0;
    disty *= 100.0;
    fragColor = vec4(0.0, 1.0 / pow(abs((1.0 - distx) + (1.0 - disty)), 0.5), 0.0, 1.0);
}

```

Although I am not sure it is physically accurate to have those spikes on the edges of the diamond I sure do like the effect that creates.

**Tags:** lighting

> **Comments:**
> **username_1**: When i copy/paste that into shadertoy I don't get anything like the output you are seeing, and just have a small green diamond.  Did you post the right code?  
> **username_0**: Correct the shader is just a triangle. It should be glowing. Those are lines I marked in to express where I am seeing edges in the gradient. They are not apart of the shader code.  

---

## 1 answers

### Answer by username_1 on 2016-11-26. Score: 3 | Accepted answer

**Updated answer, now that pow is getting valid arguments:**

What you are seeing is called "banding" and it comes from the fact that the color channels are quantized into 8 bits - in other words, it comes from the fact that there are only 256 different shades of green, even though the math generating the colors is capable of much larger resolution.

The banding on my system isn't as bad as what you are describing but it's still present. The reason it isn't as bad on my system is because you and I have different displays.

Some computer displays don't actually even have a full 256 different shades of green. For instance, instead of having 8 bit color, they may only have 6 bit color, and they either dither it, temporally dither it, or neither and just let it look worse.

One way to get around this problem is by dithering. There are various algorithms for dithering, with different computation and quality trade offs.

A good modern dithering algorithm is called "interleaved gradient noise" which is fairly close to blue noise - which is the ideal - and is pretty cheap to calculate.

Check out this link for more detailed information on different types of dithering, and how they compare:

<https://bartwronski.com/2016/10/30/dithering-part-three-real-world-2d-quantization-dithering/>

**First answer, from when pow was getting a negative value parameter:**

The issue is that you are passing a negative value to pow for the first argument, which has undefined behavior.

What shows up on my screen is completely different than what shows up on yours.

[![enter image description here](https://i.sstatic.net/swsUt.png)](https://i.sstatic.net/swsUt.png)

You shouldn't rely on the behavior of anything in the red pixel areas in this image:

[![enter image description here](https://i.sstatic.net/cVHfO.png)](https://i.sstatic.net/cVHfO.png)

More info:

<https://www.opengl.org/sdk/docs/man4/html/pow.xhtml>

> **Comments:**
> **username_0**: Just updated the code so you can see what I see now  
> **username_1**: Ah ok. The negative was a red herring.  Answer updated.  

---

