The Mipmap reminds me a lot of Gaussian/Laplacian image pyramids in that an image is downsampled and stored somewhere to use later for useful computations/properties (such as scale invariance)
keenan
@raymondx Right, these are all examples of "image pyramids," and have slightly different (but related) purposes. MIP maps are used for prefiltering; Laplacian pyramids help with compression and other image processing operations. They all showed up around the similar time (early 1980s); not completely sure what the history is there.
emmaloool
I don't quite follow how the storage cost of mipmaps is a third of the storage cost of the original image...
potato
@emmaloool I think its a third because form the diagram in the slide, the original image is represented by the largest squares labeled R, G, and B. These squares are the red, blue, and green color values for each pixel in the image. The storage cost of mipmaps is represented by all the smaller squares in the top left, which in total take up the same space as any one of the large squares labeled R, G, or B. So then the total storage of the mipmaps is one third of the storage of the largest R, G, and B combined which is the storage cost of the original image.
keenan
@potato Yep, this is exactly the right idea. Though in a real implementation, this layout isn't great: to read a single pixel color, you'd have to grab values from very different locations in memory. In practice you want to store all three color channels RGB (plus alpha) in contiguous locations. Not sure what the memory layout looks like in real drivers/hardware.
The Mipmap reminds me a lot of Gaussian/Laplacian image pyramids in that an image is downsampled and stored somewhere to use later for useful computations/properties (such as scale invariance)
@raymondx Right, these are all examples of "image pyramids," and have slightly different (but related) purposes. MIP maps are used for prefiltering; Laplacian pyramids help with compression and other image processing operations. They all showed up around the similar time (early 1980s); not completely sure what the history is there.
I don't quite follow how the storage cost of mipmaps is a third of the storage cost of the original image...
@emmaloool I think its a third because form the diagram in the slide, the original image is represented by the largest squares labeled R, G, and B. These squares are the red, blue, and green color values for each pixel in the image. The storage cost of mipmaps is represented by all the smaller squares in the top left, which in total take up the same space as any one of the large squares labeled R, G, or B. So then the total storage of the mipmaps is one third of the storage of the largest R, G, and B combined which is the storage cost of the original image.
@potato Yep, this is exactly the right idea. Though in a real implementation, this layout isn't great: to read a single pixel color, you'd have to grab values from very different locations in memory. In practice you want to store all three color channels RGB (plus alpha) in contiguous locations. Not sure what the memory layout looks like in real drivers/hardware.