# Need help with texture linear filtering

I am having an issue with getting the correct result from what I thought a texture read with linear filtering would produce, so I consulted the programming guide. It says that for a 1D case, the texture value returned is:

tex(x) = (1-a)T[i] + (a)T[i+1]
where:
xb = x - 0.5
i = floor(xb)
a = fraction part(xb)

Using a simple example, suppose the first 3 elements of a 1D float array (bound to a texture reference) are: 4.0, 5.0 and 6.0 (index 0.0, 1.0 and 2.0, respectively).

Using the equation in the programming guide, a tex fetch of 0.75 (tex(0.75)) would give (0.75)(4.0) + (0.25)(5.0) = 3.0 + 1.25 = 4.25 (should be 4.75). Additionally, a tex fetch of 1.0 (tex(1.0)) would give (0.5)(4.0) + (0.5(5.0) = 2.0 + 2.5 = 4.5 (should be 5.0).

The only way I can see to make the math work is to artificially add 0.5 to the desired tex reference. Using the above example values, a desired text fetch of 0.75, artificially adjusted to 1.25 (0.75 + 0.5), to give tex(1.25), would yield (0.25)(4.0) + (0.755.0) = 1.0 + 3.75 = 4.75 (correct value). Additionally, a desired tex fetch of 1.0, artificially adjusted to 1.5 (1.0 + 0.5), to give tex(1.5), would yield (1.05.0) + (0.06.0) = 5.0 + 0.0 (correct value).

What am I missing? I have seen posts that say only normalized tex fetches can be used with linear filtering, but the programming guide does not seem to say this. Even is this is required, I still don’t see how the math works out. Please help–I am working of this as part of a project at work and I am stuck!!!

Yes, there is a 0.5 offset. I don’t particularly like it either, but that’s the way the hardware works! This is explained in Appendix F of the programming guide.

Yes, there is a 0.5 offset. I don’t particularly like it either, but that’s the way the hardware works! This is explained in Appendix F of the programming guide.

It sort of makes sense if you think about them literally as textures - little patches of finite pixels. The value stored is the value at the centre of each texel, hence the 0.5 offset.

It sort of makes sense if you think about them literally as textures - little patches of finite pixels. The value stored is the value at the centre of each texel, hence the 0.5 offset.