<p>Unsigned byte textures in a graphics API are usually "normalized"—the byte values are interpreted as ranging from 0.0 to 1.0, with a byte of 255 mapping to 1.0. So no, they aren't truly floating-point values, but the hardware will automatically convert them to/from float when you read/write the texture. If you try to write a value outside the [0, 1] range, it will be clamped.</p>

<p>As for the <code>precision highp</code> part, it doesn't directly affect the texture, but it can certainly affect any calculations of values you write to the texture. For example, to calculate an 8-bit texture you certainly want a <em>minimum</em> of 8 bits of mantissa precision (i.e. <code>lowp</code>)—and you <em>probably</em> want more than that, depending on what calculations you're doing. I'd advise you to check what the actual precision levels are on your device, since they vary widely depending on what GPU you have. See <a href="https://stackoverflow.com/questions/4414041/what-is-the-precision-of-highp-floats-in-glsl-es-2-0-for-iphone-ipod-touch-ipad">this question</a> for more.</p>

CC BY-SA 3.0
2017-07-28T20:14:28.357Z
So, when writing to the texture, WebGL internally does something like `floor(x*255)` to map the [0,1] float value _x_ to [0,255]? And then later, when reading from that texture again, _x_ will probably deviate from the original value. Is that correct?
And in case of a `gl.FLOAT` texture, no mapping to [0,255] occurs?
Muad
CC BY-SA 3.0
2017-07-28T22:08:37.137Z
@Muad It would be `round(x*255)` instead of `floor`, but yes. And yeah, when you read it back, you'll likely get a slightly different value due to the rounding. In a float texture, it just stores and retrieves the exact value you write, no remapping (and no clamping to [0, 1]).
Nathan Reed
CC BY-SA 3.0
2017-07-28T17:50:44.740Z
2017-07-28T17:50:44.740Z
Nathan Reed
<p>This is more a theoretical question. I'm wondering what happens when I write float values into an empty RGBA texture of type <code>gl.UNSIGNED_BYTE</code> in WebGL 1.0. Obviously, every channel then has 8 bits. But that wouldn't be enough to represent floating point values, would it? Nevertheless it somehow works, more or less. See part of a fragment shader code here:</p>

<pre><code>precision highp float;

uniform vec2 u_Resolution;

void main(void){
   gl_FragColor = vec4(gl_FragCoord.xy / u_Resolution, 0.0, 1.0);
}
</code></pre>

<p>When I specify the texture to be of type <code>gl.FLOAT</code> (using the OES_texture_float extension), the results of course look better. But I want to know exactly why they do.</p>

<p>In addition: does the specified precision have an effect on the texture (to be written)?</p>

<texture><glsl><webgl>
What happens to float values written to UNSIGNED_BYTE texture?
Muad
# What happens to float values written to UNSIGNED_BYTE texture?

(Asked by: username_0 on 2017-07-28)

This is more a theoretical question. I'm wondering what happens when I write float values into an empty RGBA texture of type `gl.UNSIGNED_BYTE` in WebGL 1.0. Obviously, every channel then has 8 bits. But that wouldn't be enough to represent floating point values, would it? Nevertheless it somehow works, more or less. See part of a fragment shader code here:

```
precision highp float;

uniform vec2 u_Resolution;

void main(void){
   gl_FragColor = vec4(gl_FragCoord.xy / u_Resolution, 0.0, 1.0);
}

```

When I specify the texture to be of type `gl.FLOAT` (using the OES\_texture\_float extension), the results of course look better. But I want to know exactly why they do.

In addition: does the specified precision have an effect on the texture (to be written)?

**Tags:** texture, glsl, webgl


---

## 1 answers

### Answer by username_1 on 2017-07-28. Score: 3 | Accepted answer

Unsigned byte textures in a graphics API are usually "normalized"—the byte values are interpreted as ranging from 0.0 to 1.0, with a byte of 255 mapping to 1.0. So no, they aren't truly floating-point values, but the hardware will automatically convert them to/from float when you read/write the texture. If you try to write a value outside the [0, 1] range, it will be clamped.

As for the `precision highp` part, it doesn't directly affect the texture, but it can certainly affect any calculations of values you write to the texture. For example, to calculate an 8-bit texture you certainly want a *minimum* of 8 bits of mantissa precision (i.e. `lowp`)—and you *probably* want more than that, depending on what calculations you're doing. I'd advise you to check what the actual precision levels are on your device, since they vary widely depending on what GPU you have. See [this question](https://stackoverflow.com/questions/4414041/what-is-the-precision-of-highp-floats-in-glsl-es-2-0-for-iphone-ipod-touch-ipad) for more.

> **Comments:**
> **username_0**: So, when writing to the texture, WebGL internally does something like `floor(x*255)` to map the [0,1] float value _x_ to [0,255]? And then later, when reading from that texture again, _x_ will probably deviate from the original value. Is that correct? And in case of a `gl.FLOAT` texture, no mapping to [0,255] occurs?  
> **username_1**: @username_0 It would be `round(x*255)` instead of `floor`, but yes. And yeah, when you read it back, you'll likely get a slightly different value due to the rounding. In a float texture, it just stores and retrieves the exact value you write, no remapping (and no clamping to [0, 1]).  

---

