Determining Texels in a Fragment

Question

Consider the following quote from this OpenGL ES for iOS Book:

OpenGL ES supports several different sampling modes: Consider what happens when fewer fragments are produced for a triangle than the number of texels available in the bound texture. That can happen any time the texture with a large number of texels is mapped to a triangle that covers only a few pixels in the frame buffer. The opposite can happen, too. A texture containing few texels might be mapped to a triangle that produces many fragments in the frame buffer.

And this quote:

Specifying the parameter GL_TEXTURE_MIN_FILTER [glTexParameteri] with the value GL_LINEAR tells OpenGLES that whenever there are multiple texels that correspond to a fragment, sample colors from several of the suitable texels and mix the colors using linear interpolation to produce the texture’s contribution for the fragment. The resulting fragment color might end up being a color that doesn’t exist in the texture. For example, if a texture is composed of alternating black and white texels, linear sampling will mix the texel colors and the fragment will end up being gray.

My question is how does one determine how many texels are in an image and how large those texels are. If I'm not mistaken 1 texel != 1 pixel, so you can't determine the number of texels by counting pixels. For example, the second quote describes an image with alternation black and white texels. How would you know if your image is composed of black and white texels.... who defines the texel size?? Whose to say one texel doesn't have both black and white in it. How can I possibly determine what one texel in a given image looks like considering that texels have no set size, bounds, etc.

Answer 1

When a texture is larger or smaller then the surface you are drawing to, the texel might be composed from many pixels on image. Even if image is rotated or translated it might happen the same. In idle situation when drawing a texture/image to the frame buffer the fragment will request a specific pixel on image and present it, but in most cases there are fragments that request a pixel at position between the pixels (magnification) or a position that corresponds to a set of pixels on texture (minifying). In any of the cases you need ether interpolate the color values GL_LINEAR or take the nearest pixel GL_NEAREST and openGL can do that quite nicely.

So, the question "how does one determine how many texels are in an image and how large those texels are" can not be answered as for the case you are asking it depends on how will you be drawing it.

"How would you know if your image is composed of black and white texels" is looking at it not an option or did I fail to understand the question? The quote you posted made a hypothetical situation that has black and white image: Lets say it is 2x2, 2 black(.0) and 2 white(1.0) pixels, if you draw this to a buffer 1x1 with GL_LINEAR you will get a pixel with gray color (.5), thus a pixel in frame buffer contains a color that does not exist on original image.

"who defines the texel size" I'm not too sure about saying texel size but lets just translate that to "who defines how many texture pixels will be used to compose a frame buffer pixel", then openGL should be the answer as it is build in how to process such situations.

"Whose to say one texel doesn't have both black and white in it" this is really a combination of matrix setup, the image itself, the developer... You may put GL_NEAREST and it will always be ether one or another but not both, in any other situation you could try to compute the outcome or make that black and white image and look at the output.

"How can I possibly determine what one texel in a given image looks like considering that texels have no set size, bounds, etc." You can get a basic idea from the ration of texture size and surface you are drawing to; from the output; Go step by step through what openGL does and try to compute it.

To sum this up it is not really that much important how all of this works in background as much as just knowing that this things do happen. Why you should know it for instance is try to draw some clear text and translate it for half of pixel in some direction, the result will be the fussiness of text (a very common problem) as the frame buffer pixels will have "blended" colors on letter borders. Another problem can be when the result is not meant to have colors at all but rather some values for post processing such as some table lookup values, normal deformation, coordinate deformation... in those cases you may get values that have no sense at all.