Jump to content

Texture filtering

From Wikipedia, the free encyclopedia
(Redirected from Texture lookup)

In computer graphics, texture filtering or texture smoothing is the method used to determine the texture color for a texture mapped pixel, using the colors of nearby texels (ie. pixels of the texture).

Filtering describes how a texture is applied at many different shapes, size, angles and scales. Depending on the chosen filter algorithm, the result will show varying degrees of blurriness, detail, spatial aliasing, temporal aliasing and blocking. Depending on the circumstances, filtering can be performed in software (such as a software rendering package) or in hardware, eg. with either real time or GPU accelerated rendering circuits, or in a mixture of both. For most common interactive graphical applications, modern texture filtering is performed by dedicated hardware which optimizes memory access through memory cacheing and pre-fetch, and implements a selection of algorithms available to the user and developer.

There are two main categories of texture filtering: magnification filtering and minification filtering.[1] Depending on the situation, texture filtering is either a type of reconstruction filter where sparse data is interpolated to fill gaps (magnification), or a type of anti-aliasing (AA) where texture samples exist at a higher frequency than required for the sample frequency needed for texture fill (minification).

There are many methods of texture filtering, which make different trade-offs between computational complexity, memory bandwidth and image quality.

The need for filtering

[edit]

During the texture mapping process for any arbitrary 3D surface, a texture lookup takes place to find out where on the texture each pixel center falls. For texture-mapped polygonal surfaces composed of triangles typical of most surfaces in 3D games and movies, every pixel (or subordinate pixel sample) of that surface will be associated with some triangle(s) and a set of barycentric coordinates, which are used to provide a position within a texture. Such a position may not lie perfectly on the "pixel grid," necessitating some function to account for these cases. In other words, since the textured surface may be at an arbitrary distance and orientation relative to the viewer, one pixel does not usually correspond directly to one texel. Some form of filtering has to be applied to determine the best color for the pixel. Insufficient or incorrect filtering will show up in the image as artifacts (errors in the image), such as 'blockiness', jaggies, or shimmering.

There can be different types of correspondence between a pixel and the texel/texels it represents on the screen. These depend on the position of the textured surface relative to the viewer, and different forms of filtering are needed in each case. Given a square texture mapped on to a square surface in the world, at some viewing distance the size of one screen pixel is exactly the same as one texel. Closer than that, the texels are larger than screen pixels, and need to be scaled up appropriately — a process known as texture magnification. Farther away, each texel is smaller than a pixel, and so one pixel covers multiple texels. In this case an appropriate color has to be picked based on the covered texels, via texture minification. Graphics APIs such as OpenGL allow the programmer to set different choices for minification and magnification filters.[1]

Note that even in the case where the pixels and texels are exactly the same size, one pixel will not necessarily match up exactly to one texel. It may be misaligned or rotated, and cover parts of up to four neighboring texels. Hence some form of filtering is still required.

Mipmapping

[edit]

Mipmapping is a standard technique used to save some of the filtering work needed during texture minification.[2] It is also highly beneficial for cache coherency - without it the memory access pattern during sampling from distant textures will exhibit extremely poor locality, adversely affecting performance even if no filtering is performed.

During texture magnification, the number of texels that need to be looked up for any pixel is always four or fewer; during minification, however, as the textured polygon moves farther away potentially the entire texture might fall into a single pixel. This would necessitate reading all of its texels and combining their values to correctly determine the pixel color, a prohibitively expensive operation. Mipmapping avoids this by prefiltering the texture and storing it in smaller sizes down to a single pixel. As the textured surface moves farther away, the texture being applied switches to the prefiltered smaller size. Different sizes of the mipmap are referred to as 'levels', with Level 0 being the largest size (used closest to the viewer), and increasing levels used at increasing distances.

Filtering methods

[edit]

This section lists the most common texture filtering methods, in increasing order of computational cost and image quality.

Nearest-neighbor interpolation

[edit]

Nearest-neighbor interpolation is the simplest and crudest filtering method — it simply uses the color of the texel closest to the pixel center for the pixel color. While simple, this results in a large number of artifacts - texture 'blockiness' during magnification,[3] and aliasing and shimmering during minification.[4] This method is fast during magnification but during minification the stride through memory becomes arbitrarily large and it can often be less efficient than MIP-mapping due to the lack of spatially coherent texture access and cache-line reuse.[5]

Nearest-neighbor with mipmapping

[edit]

This method still uses nearest neighbor interpolation, but adds mipmapping — first the nearest mipmap level is chosen according to distance, then the nearest texel center is sampled to get the pixel color. This reduces the aliasing and shimmering significantly during minification but does not eliminate it entirely. In doing so it improves texture memory access and cache-line reuse through avoiding arbitrarily large access strides through texture memory during rasterization. This does not help with blockiness during magnification as each magnified texel will still appear as a large rectangle.

Linear mipmap filtering

[edit]

Less commonly used, OpenGL and other APIs support nearest-neighbor sampling from individual mipmaps whilst linearly interpolating the two nearest mipmaps relevant to the sample.

Bilinear filtering

[edit]

In Bilinear filtering, the four nearest texels to the pixel center are sampled (at the closest mipmap level), and their colors are combined by weighted average according to distance.[6] This removes the 'blockiness' seen during magnification, as there is now a smooth gradient of color change from one texel to the next, instead of an abrupt jump as the pixel center crosses the texel boundary.[7] Bilinear filtering for magnification filtering is common. When used for minification it is often used with mipmapping; though it can be used without, it would suffer the same aliasing and shimmering problems as nearest-neighbor filtering when minified too much. For modest minification ratios, however, it can be used as an inexpensive hardware accelerated weighted texture supersample.

The Nintendo 64 used an unusual version of bilinear filtering where only three pixels are used known as 3-point texture filtering, instead of four due to hardware optimization concerns. This introduces a noticeable "triangulation bias" in some textures.[8]

Trilinear filtering

[edit]

Trilinear filtering is a remedy to a common artifact seen in mipmapped bilinearly filtered images: an abrupt and very noticeable change in quality at boundaries where the renderer switches from one mipmap level to the next. Trilinear filtering solves this by doing a texture lookup and bilinear filtering on the two closest mipmap levels (one higher and one lower quality), and then linearly interpolating the results.[9] This results in a smooth degradation of texture quality as distance from the viewer increases, rather than a series of sudden drops. Of course, closer than Level 0 there is only one mipmap level available, and the algorithm reverts to bilinear filtering.

Anisotropic filtering

[edit]

Anisotropic filtering is the highest quality filtering available in current consumer 3D graphics cards. Simpler, "isotropic" techniques use only square mipmaps which are then interpolated using bi– or trilinear filtering. (Isotropic means same in all directions, and hence is used to describe a system in which all the maps are squares rather than rectangles or other quadrilaterals.)

When a surface is at a high angle relative to the camera, the fill area for a texture will not be approximately square. Consider the common case of a floor in a game: the fill area is far wider than it is tall. In this case, none of the square maps are a good fit. The result is blurriness and/or shimmering, depending on how the fit is chosen. Anisotropic filtering corrects this by sampling the texture as a non-square shape. The goal is to sample a texture to match the pixel footprint as projected into texture space, and such a footprint is not always axis aligned to the texture. Further, when dealing with sample theory a pixel is not a little square[10] therefore its footprint would not be a projected square. Footprint assembly in texture space samples some approximation of the computed function of a projected pixel in texture space but the details are often approximate,[11] highly proprietary and steeped in opinions about sample theory. Conceptually though the goal is to sample a more correct anisotropic sample of appropriate orientation to avoid the conflict between aliasing on one axis vs. blurring on the other when projected size differs.

In anisotropic implementations, the filtering may incorporate the same filtering algorithms used to filter the square maps of traditional mipmapping during the construction of the intermediate or final result.

Percentage Closer filtering

[edit]

Depth-based shadow mapping can use an interesting Percentage Closer Filter (PCF) with depth-mapped textures that broadens one's perception of the kinds of texture filters that might be applied. In PCF a depth map of the scene is rendered from the light source. During the subsequent rendering of the scene this depth map is then projected back into the scene from the position of the light and a comparison is performed between the projective depth coordinate and the fetched texture sample depth. The projective coordinate will be the scene pixels depth from the light but the fetched depth from the depth map will represent the depth of the scene along that projected direction. In this way a determination of visibility to the light and therefore illumination by the light can be made for the rendered pixel. So this texturing operation is a Boolean test of whether the pixel is lit, however multiple samples can be tested for a given pixel and the Boolean results summed and averaged. In this way in combination with varying parameters like sampled texel location and even jittered depth map projection location a post-depth-comparison average or percentage of samples closer and therefore illuminated can be computed for a pixel. Critically, the summation of Boolean results and generation of a percentage value must be performed after the depth comparison of projective depth and sample fetch, so this depth comparison becomes an integral part of the texture filter. This percentage can then be used to weight an illumination calculation and provide not just a Boolean illumination or shadow value but a soft shadow penumbra result.[12][13] A version of this is supported in modern hardware where a comparison is performed and a post Boolean comparison bilinear filter by distance is applied[14]

See also

[edit]

References

[edit]
  1. ^ a b "Chapter 9 - OpenGL Programming Guide". Glprogramming.com. 2009-02-13. Filtering. Retrieved 2018-01-14.
  2. ^ Williams, Lance (1983). "Pyramidal parametrics" (PDF). ACM SIGGRAPH Computer Graphics. 17 (3): 1–11. doi:10.1145/964967.801126. ISSN 0097-8930. Archived from the original (PDF) on 2016-06-06. Retrieved 2017-02-14.
  3. ^ "Game Engine Design: Texture Mapping" (PDF). uncc.edu. Texture Magnification. Archived from the original (PDF) on 2021-04-17. Retrieved 2017-02-14.
  4. ^ "Game Engine Design: Texture Mapping" (PDF). uncc.edu. Texture Minification. Archived from the original (PDF) on 2021-04-17. Retrieved 2017-02-14.
  5. ^ Hendrik Lensch (2007-11-29). "Computer Graphics: Texture Filtering & Sampling Theory" (PDF). Max Planck Society. MipMaps. Retrieved 2018-01-14.
  6. ^ Markus Hadwiger (2015-03-09). "GPU and GPGPU Programming Lecture 12: GPU Texturing 2" (PDF). KAUST. Texture Reconstruction: Magnification. Archived from the original (PDF) on 2021-01-24. Retrieved 2017-02-14.
  7. ^ Markus Hadwiger (2015-03-09). "GPU and GPGPU Programming Lecture 12: GPU Texturing 2" (PDF). KAUST. Texture Anti-Aliasing: MIP Mapping. Archived from the original (PDF) on 2021-01-24. Retrieved 2017-02-14.
  8. ^ "Video game system with coprocessor providing high speed efficient 3D graphics and digital audio signal processing". Retrieved 14 November 2022.
  9. ^ Hendrik Lensch (2007-11-29). "Computer Graphics: Texture Filtering & Sampling Theory" (PDF). Max Planck Society. MipMapping II. Retrieved 2018-01-14.
  10. ^ Alvy Ray Smith (1995-07-17). "A Pixel Is Not A Little Square! (And a Voxel is Not a Little Cube) - Technical Memo 6" (PDF). cs.princeton.edu. Retrieved 2018-01-14.
  11. ^ Hendrik Lensch (2007-11-29). "Computer Graphics: Texture Filtering & Sampling Theory" (PDF). Max Planck Society. Anisotropic Filtering. Retrieved 2018-01-14.
  12. ^ Reeves, William T.; Salesin, David H.; Cook, Robert L. (1987-08-01). "Rendering antialiased shadows with depth maps" (PDF). ACM SIGGRAPH Computer Graphics. 21 (4). Association for Computing Machinery (ACM): 283–291. doi:10.1145/37402.37435. ISSN 0097-8930. S2CID 18320563. Archived from the original (PDF) on 2018-01-15.
  13. ^ Randima Fernando (2008-07-02). "Percentage-Closer Soft Shadows" (PDF). NVIDIA Corporation. Retrieved 2018-01-14.
  14. ^ "WebGL WEBGL_depth_texture Khronos Ratified Extension Specification". Khronos.org. 2014-07-15. Retrieved 2018-01-14.