Mipmap
Mipmap (from Latin multum in parvo, many in little), is a digital image
that is stored along with progressively smaller versions of itself;
mipmaps are useful in [1]computer graphics, especially as a representation
of [2]textures in which they may eliminate [3]aliasing during rendering.
But mipmaps also have other uses such as serving as [4]acceleration
structures or helping performance (using a smaller image can speed up
memory access). Mipmaps are also sometimes called pyramids because we can
imagine the images of different sizes laid one on another to form such a
shape.
A basic form of a mipmap can be explained on the following example. Let's
say we have an [5]RGB image of size 1024x1024 pixels. To create its mipmap
we call the base image level 0 and create progressively smaller versions
(different levels) of the image by reducing the size four times (twice
along one dimension) at each step. I.e. level 1 will be the base image
downscaled to the size 512x512. If we are to use the mipmap for the common
purpose of reducing aliasing, the downscaling itself has to be done in a
way that doesn't introduce aliasing; this can be done e.g. by downscaling
2x2 areas in the base image into a single pixel by averaging the values of
those 4 pixels (the averaging is what will prevent aliasing; other
downscaling methods may be used depending on the mipmap's purpose, for
example for a use as an accelerating structure we may take a maximum or
minimum of the 4 pixels). Level 2 will be an image with resolution 256x256
obtained from the 512x512 image, and so on until the last level with size
1x1. In this case we'll have 11 levels which together form our mipmap.
This RGB mipmap can be shown (and represented in memory) as a "[6]fractal
image":
_______________________________
| | |
| | |
| level 0 | level 0 |
| red | green |
| channel | channel |
| | |
| | |
|_______________|_______________|
| |level 1|level 1|
| | red | green |
| level 0 |channel|channel|
| blue |_______|_______|
| channel |level 1|l2r|l2g|
| | blue |___|___|
| |channel|l2b|_|_|
|_______________|_______|___|_|+|
This may be how a texture is represented inside a [7]graphics card if we
upload it (e.g. with [8]OpenGL). When we are rendering e.g. a 3D model
with this texture and the model ends up being rendered at the screen in
such size that renders the texture smaller than its base resolution, the
renderer (e.g. OpenGL) automatically chooses the correct level of the
mipmap (according to Nyquist-Shannon sampling theorem) to use so that
aliasing won't occur. If we're using a rendering system such as OpenGL, we
may not even notice this is happening, but indeed it's what's going on
behind the scenes (OpenGL and other systems have specific functions for
working with mipmaps manually if you desire).
Do we absolutely need to use mipmaps in rendering? No, some simple (mostly
software) renderers don't use them and you can turn mipmaps off even in
OpenGL. Some renderers may deal with aliasing in other ways, for example
by denser sampling of the texture which will however be slower (in this
regard mipmaps can be seen as precomputed, already antialiased version of
the image which [9]trades memory for speed).
We can also decide to not deal with aliasing in any way, but the textures
will look pretty bad when downscaled on the screen (e.g. in the distance).
They are kind of noisy and flickering, you can find examples of this kind
of messy rendering online. However, if you're using low resolution
textures, you may not even need mipmaps because such textures will hardly
ever end up downscaled -- this is an advantage of the [10]KISS approach.
One shortcoming of the explained type of mipmaps is that they are
isotropic, i.e. they suppose the rendered texture will be scaled uniformly
in all directions, which may not always be the case, especially in 3D
rendering. Imagine a floor rendered when the camera is looking forward --
the floor texture may end up being downscaled in the vertical direction
but upscaled in the horizontal direction. If in this case we use our
mipmap, we will prevent aliasing, but the texture will be rendered in
lower resolution horizontally. This is because the renderer has chosen a
lower resolution of the texture due to downscale (possible aliasing) in
vertical direction, but horizontal direction will display the texture
upscaled. This may look a bit weird, but its completely workable, it can
be seen in most older 3D games.
The above issue is addressed mainly by two methods.
The first is [11]trilinear filtering which uses several levels of the
mipmap at once and [12]linearly blends between them. This is alright but
still shows some [13]artifacts such as visible changes in blurriness.
The second method is [14]anisotropic filtering which uses different,
anisotropic mipmaps. Such mipmaps store more version of the image, resized
in many different ways. This method is nowadays used in quality graphics.
See Also
* [15]megatexture
Links:
1. graphics.md
2. texture.md
3. aliasing.md
4. acceleration_structure.md
5. rgb.md
6. fractal.md
7. gpu.md
8. opengl.md
9. space_time_tradeoff.md
10. kiss.md
11. trilinear_filtering.md
12. linear_interpolation.md
13. artifact.md
14. anisotropic.md
15. megatexture.md