Colored mipmap - oxymoron?

[croc_mak]

Isn't definition of a mipmap that each level is a lower-sampled version of the highest detail version....I'm a bit confused about all the discussion about colored mipmaps here..can someone enlighten?

How can one judge the quality of an mipmapping implementation with something that's not a mipmap?

 

[bloodbob]

Isn't definition of a mipmap that each level is a lower-sampled version of the highest detail version....I'm a bit confused about all the discussion about colored mipmaps here..can someone enlighten?

How can one judge the quality of an mipmapping implementation with something that's not a mipmap?

Okay to generate a perfect lower minification you would need to sample the higher quality filter with an infinite number of samples of course which can't be done so how can we calculate mipmaps at all we use approximations don't we. A colour mipmap is really really bad approximation

Of course their are many situation where we don't want to do perfect filtering such as in non-photorealistic filtering. ( If your doing shadering with pencil strokes you want to keep the pencil stroke texture even at a high LOD ).

Generally colour mipmaps are used deliberatly because of the contrast to show the effectiveness of filtering.

 

[KimB]

Isn't definition of a mipmap that each level is a lower-sampled version of the highest detail version....I'm a bit confused about all the discussion about colored mipmaps here..can someone enlighten?

How can one judge the quality of an mipmapping implementation with something that's not a mipmap?

Well, in reality, a MIP map is simply a texture that is smaller than the base texture by a power of two, and it is defined to be used via a specific mathematical equation. This mathematical equation was made with the assumption that each MIP map would be a simply-downsampled version of the higher-detail map, but there is nothing that forces this to be the case. As it turns out, it's typically up to the developer to do this creation of MIP maps on their own, and so the hardware doesn't care whether or not the higher-level MIP maps are what they're supposed to be or not. It just cares that they're the right size.

So, it was discovered some time ago that one could upload MIP maps that were different from a simple box filter by being colored. This essentially allows for a nice picture of how these graphics cards filter textures, without having to resort to careful scrutiny of screenshots.

 

[croc_mak]

Well, in reality, a MIP map is simply a texture that is smaller than the base texture by a power of two,

Well..in reality you are just referring to how it's specified in the API....if I do a google search on mipmapping..the whole point of them appears to be for texture anti-aliasing...I can't see how you can acheive this anti-aliasing with a colored mip level

 

[bloodbob]

From
Pyramidal Parametrics
Lance Williams
Computer Graphics Laboratory
New York Institute of Technology
Old Westbury, New York

If you don't know the significants of the paper maybe you should check out how often it is referenced

"Mip" mapping is a particular format
for two-dimensional parametric functions,
which, along with its associated addressing
scheme, has been used successfully to
bandlimit texture mapping at New York
Institute of Technology since 1979. The
acronym "mip" is from the Latin phrase
"multum in parvo," meaning "many things in
a small place." Mip mapping supplements
bilinear interpolation of pixel values in
the texture map (which may be used to
smoothly translate and magnify the texture)
with interpolation between prefiltered
versions of the map (which may be
used to compress many pixels into a small
place). In this latter capacity, mip
offers much greater speed than texturing
algorithms which perform explicit convolution
over an area in the texture map for
each pixel rendered , [6].
Mip owes its speed in compressing
texture to two factors. First, a fair
amount of filtering of the original texture
takes place when the mip map is first
created. Second, subsequent filtering is
approximated by blending different levels
of the mip map. This means that all
filters are approximated by linearly
interpolating a set of square box filters,
the sides of which are powers-of-two pixels
in length. Thus, mapping entails a
fixed overhead, which is independent of
the area filtered to compute a sample.

Structure of a Color Mip Map
Smaller and smaller images diminish into
the upper left corner of the map. Each of
the images is averaged down from its
larger predecessor.

Now to acturatly generate a mipmap you need to take an inifinite number of smaples this can't be done in reality. So we are left to use aproximiations.

Now a coloured mipmap is an approximation a very bad one

But getting serious their are many cases you dn't want a ideal mipmap such as non-photorealistic rendering where you may be useing pen strokes and as you minify you wish to retain the pen strokes as they can only be finitely small so an analytical minification would be wrong.

ULtimately people use coloured mipmap as a test for the effectiveness of mipmap blending Trilnear filtering isn't the only way you can do things ( please note what ATI and NV are doing isn't trilinear ) you could go off and do 8 sample spline interpolation of mipmaps which might give you a better result of photorealistic fitlering.

 

[KimB]

Well..in reality you are just referring to how it's specified in the API....if I do a google search on mipmapping..the whole point of them appears to be for texture anti-aliasing...I can't see how you can acheive this anti-aliasing with a colored mip level

We're not talking about a theoretical technique here. We're talking about a real-world implementation, one which differs from the theoretical technique in a few key aspects. One being that the MIP maps aren't forced to be what the technique asks for.

 

[pcchen]

I think the point is, how far can you go?
Consider this: suppose a display card have a "bilinear optimization" which is claimed to be "virtually the same quality as real bilinear," can you accept it? I don't think many people can accept it, since some developers may want to use some tricks to accelerate things (I used it once, actually).

Now go back to the "trilinear" issues. Of course real trilinear is more expensive, and the "fake trilinear" is a pretty good approximation (even the NV3X "brilinear" is pretty good, despite some people often claimed otherwise). But isn't it much better to have the original "real trilinear" as an option? There are quality hints in OpenGL, and they should be used. It is pretty simple.

 

[davepermen]

I think the point is, how far can you go?
Consider this: suppose a display card have a "bilinear optimization" which is claimed to be "virtually the same quality as real bilinear," can you accept it? I don't think many people can accept it, since some developers may want to use some tricks to accelerate things (I used it once, actually).

Now go back to the "trilinear" issues. Of course real trilinear is more expensive, and the "fake trilinear" is a pretty good approximation (even the NV3X "brilinear" is pretty good, despite some people often claimed otherwise). But isn't it much better to have the original "real trilinear" as an option? There are quality hints in OpenGL, and they should be used. It is pretty simple.

if you have a simple, one coloured texture, do you really need 8 samples and a complex filter to get that one, simple, colour out again? no. every programer i know of that cares a bit about optimisation would, if he realises this is often the case, take that out as a special case to handle, and solve it with one sample.

ordinary trilinear can be done faster, without quality loss. but only in certain restrictions. those restrictions are that common that its worth to special-case them, and this is what ati did. you always have full triilinear, mathematically seen. that there are specialisations for certain situations doesn't change that fact. it does only change the fact that you always need full 8 samples mixed together. this isn't the case.

 

[pcchen]

If this "optimization" is acceptable, why shouldn't NVIDIA's shader replacement? And others?

My point is, there will be some special cases I want my textures to be correctly linear interpolated, and I know when I need it. However, ATI forces me to use their "optimization," and rely on an unknown detection method to disable it. ATI does not publish how they detect the texture to disable the optimization (they don't even reveal the fact that the "optimization" exists). Of course, NVIDIA is no better here. But that's not the point. The point is to let the programmer to choose, not to try to hide the fact.

 

[Simon F]

However, ATI forces me to use their "optimization," and rely on an unknown detection method to disable it. ATI does not publish how they detect the texture to disable the optimization

[Speculation_mode]
I would guess that they are simply computing the box filtered version of each MIPmap level and taking the difference of it and the user supplied lower level. If these differ by less than a certain RMS and/or don't exceed a certain maximum tolerance, then the driver switches on "fast mode" otherwise it stays with the standard trilinear filter.
[/Speculation_mode]

 

[croc_mak]

If this "optimization" is acceptable, why shouldn't NVIDIA's shader replacement? And others?

My point is, there will be some special cases I want my textures to be correctly linear interpolated, and I know when I need it. However, ATI forces me to use their "optimization," and rely on an unknown detection method to disable it. ATI does not publish how they detect the texture to disable the optimization (they don't even reveal the fact that the "optimization" exists). Of course, NVIDIA is no better here. But that's not the point. The point is to let the programmer to choose, not to try to hide the fact.

Important point people.....bilinear and trilinear exactly give you the same results when the texture footprint in screen space is a close to match to a particular miplevel..trilinear kicks in and makes a difference only when this foot-print isn't an exact match - but is "in-between" two levels.....So, this in-between two levels thing is decided by what's known as "lod calculation"....So, the lod-calculation part is as the key factor

It is really treading on dangerous grounds if a developer relies on this behaviour heavily - as pointed our elsewhere no 2 implementations have the same lod calculation...

My understanding of the "optimized trilinear" is that you are getting the same exact behaviour as regular trilinear..except that the "window" of when you are in-between mip-levels v/s in-one level is skewed

ATI's technique does this "window skewing" bit more selectively based on the texture content and only does it a tiny amount..Nvidia's technique is a bit all over the place and gets aggressive in app-detect mode.

My point is that whenever the blend happens it happens linearly in all the techniques

Let's stop bickering uselessly about trilinear v/s bilinear please and have an educated discussion...

The real discussion we should be having is what are the positive and negative effects of such a "skew" on image quality.....Anyone with any image processing and filtering background that's lurking around? May be they can shed some light on this

The one positive impact I could think of is that the picture could look more detailed and less fuzzy in some scenarios where close to exact match happens with higher detailed levels...It should also generally help make "pre-filtered" mipmaps to look less blurrier

The cons appear to be a potential for visible mipboundaries and may be some aliasing....both of will be un-noticeable for pre-filtered mipmaps.


the cons will dominate the pros when the "skew factor" starts to increase...a minor skew factor could actually be nice in many cases given how the majority of the content gets generated these days

 

[pcchen]

[Speculation_mode]
I would guess that they are simply computing the box filtered version of each MIPmap level and taking the difference of it and the user supplied lower level. If these differ by less than a certain RMS and/or don't exceed a certain maximum tolerance, then the driver switches on "fast mode" otherwise it stays with the standard trilinear filter.
[/Speculation_mode]

This is also my first thought... If someone could do some experiments on this subject, it would be better (such as using a texture where half is normal and another half is colored).

Important point people.....bilinear and trilinear exactly give you the same results when the texture footprint in screen space is a close to match to a particular miplevel..trilinear kicks in and makes a difference only when this foot-print isn't an exact match - but is "in-between" two levels.....So, this in-between two levels thing is decided by what's known as "lod calculation"....So, the lod-calculation part is as the key factor

Ugh, no. Real trilinear requires linear interpolation between two LODs all the time. The whole point of "brilinear" is to just linear interpolate near the boundary. Actually, this works well for most of textures, as I said in a previous post. However, it would be better if the programmers can control this behaviour.

When looking at the screenshots, it is important to understand that sometimes "details" are actually aliasing. The aliasing will become apparent when the viewer is moving. You can see them in this test program.