Contrast mipmapping

[sonix666]

Hi guys,

I had this idea floating in my head for years now, so I finally gotten myself to implementing it in a small demo application.

It shows different sizes of mipmaps with two different methods:

- Normal mipmaps
The normal averaging used to generate mipmaps.

- Contrast mipmaps
For these mipmaps the pixels that are used for averaging each have a different weight factor for contributing to the final color. This weight factor is calculated by looking at how much the pixel differs from surrounding pixels. The resulting mipmaps will exagurate pixels that contrast from their surroundings.

For example, look at a brick wall. The cement between the stones is what forms the contrast and thus gets exagurated. The resulting mipmap will look more clearer (at least in my opinion) because it has had the contrasts preserved.

Have a look and let me know what you think of the demo.

You can download it at the folowing page:

http://www.geocities.com/sonix666us/

PS: You will need the .NET Framework version 1.0 for this demo to work.

 

[Ante P]

Looks pretty good. I toyed around with a few different textures and even some stuff that most likely would never be used as textures etc. just to see how it worked. In almost all cases it looked better than normal mip mapping IMHO.
Though it looks as if it would introduce some aliasing with its sharp contrasts perhaps?

 

[Nick]

It probably looks bad in practice, because on a tilted wall you see the mipmap transitions as being a wall that get's another color...

 

[sonix666]

It probably looks bad in practice, because on a tilted wall you see the mipmap transitions as being a wall that get's another color...

OK, to address this problem of yours I have updated the demo so that you can choose for yourself which mipmap you want to view enlarged. That way you can compare mipmaps by switching between them. But indeed, best is still when I will test this in a real 3D environment. When I find the time I might do so.

 

[Nick]

OK, to address this problem of yours I have updated the demo so that you can choose for yourself which mipmap you want to view enlarged. That way you can compare mipmaps by switching between them. But indeed, best is still when I will test this in a real 3D environment. When I find the time I might do so.

It's not my problem, it's yours!

And, as expected, the 'contrast' mipmaps look too bright. But you also can't decrease the overall brightness, because then it looks more grey than red.

Sorry to discourage you, but it doesn't work. If it did, it would have been used long before. But keep trying and you might eventually invent something new that works...

 

[Humus]

I don't think the contrast mipmaps look "too bright". They look perfectly fine in terms of brightness IMO. I'd love to see this in action in a real app. Just a textured cube would be enough.

Sorry to discourage you, but it doesn't work. If it did, it would have been used long before.

There are plenty of mipmap generations algoritms out there, many that could be better than the standard boxfilter, but the majority of the apps don't use them simply because developers either don't know about them or just don't bother. Most people just use a boxfilter because it's simple to implement. Some don't even do that and just rely on stuff like gluBuild2DMipMaps().

 

[Simon F]

Hi guys,

I had this idea floating in my head for years now, so I finally gotten myself to implementing it in a small demo application.

It shows different sizes of mipmaps with two different methods:

- Normal mipmaps
The normal averaging used to generate mipmaps.

- Contrast mipmaps
For these mipmaps the pixels that are used for averaging each have a different weight factor for contributing to the final color.

I haven't actually run your app but it sounds a little like you are just taking gamma correction into account with your downfilter.

I'd also agree with Humus's post RE box filters. They really are pretty poor way of generating your MIP map levels.

 

[Rodéric]

I'd also agree with Humus's post RE box filters. They really are pretty poor way of generating your MIP map levels.

So which way of generating MIP maps do you recommand ?

 

[sonix666]

I am not applying gamma correction. But indeed, applying gamma correction before combining the four samples (like the FSAA of the Radeon 9xxx series) might indeed also be a better idea than the simple mipmap generation process.

 

[Nick]

I don't think the contrast mipmaps look "too bright". They look perfectly fine in terms of brightness IMO. I'd love to see this in action in a real app. Just a textured cube would be enough.

Quickly switch between normal and contrast modes, and you'll see the smaller mipmaps change in brightness. And a textured cube wouldn't show a lot of mipmap transitions. What you need is a tunnel.

There are plenty of mipmap generations algoritms out there, many that could be better than the standard boxfilter, but the majority of the apps don't use them simply because developers either don't know about them or just don't bother. Most people just use a boxfilter because it's simple to implement. Some don't even do that and just rely on stuff like gluBuild2DMipMaps().

Possibly sonix666's method is closer to the mathematical ideal resampling method (sinc), but then he might have forgotten about gamma correction... a common error with mipmap genertion.

 

[Nick]

I am not applying gamma correction. But indeed, applying gamma correction before combining the four samples (like the FSAA of the Radeon 9xxx series) might indeed also be a better idea than the simple mipmap generation process.

Current box filter mipmap genertion methods all use gamma correction. Personally I do it with a lookup table so it's quite fast. Without it the mipmap transitions without trilinear filtering are much too apparent.

 

[Humus]

Quickly switch between normal and contrast modes, and you'll see the smaller mipmaps change in brightness.

Well, that was just what I did and saw no change in brightness. Now I even loaded a screenshot into psp and applied a blur filter. The result was pretty much identical for all mipmap levels. I even used to dropper tool and found that the color was pretty much the same, like +/- 1 or 2 on all components.

 

[Nick]

Well, that was just what I did and saw no change in brightness. Now I even loaded a screenshot into psp and applied a blur filter. The result was pretty much identical for all mipmap levels. I even used to dropper tool and found that the color was pretty much the same, like +/- 1 or 2 on all components.

Did you use a blur filter with or without gamma correction?

Have a look at this image:

If your monitor and graphics card gamma is calibrated correctly, the dithered parts should have the same color as the plain parts. Now apply a non-gamma corrected blur filter and watch the brightness change dramatically.

Or look at this: http://softwire.sourceforge.net/q3dm1.jpg. It's one of the first pictures of my software renderer using per-pixel mipmapping, when I didn't have gamma correted mipmap generation yet. You can clearly see the transitions between the mipmap levels on the floor. There is no lighting applied, but you see the near part of the floor is brighter...

 

[GameCat]

Nick, that isn't a very good gamma test pattern. Using a one pixel raster makes mathemathical sense but doesn't work on most display devices. Try viewing two squares side by side, one with alternating white and black vertical lines, and one with horizontal. They won't look equally bright. You usually need to use thicker lines, 2 pixels thick horizontal lines generally work well.

 

[Simon F]

Have a look at this image:

If your monitor and graphics card gamma is calibrated correctly, the dithered parts should have the same color as the plain parts. Now apply a non-gamma corrected blur filter and watch the brightness change dramatically.

I'm just going to be a bit picky with your test image; you should have your horizontal transistions in the chequer-board region a bit wider than 1 pixel as the monitor/display circuitry is frequently very bandwidth limited. I suggest using 5 to 10 pixel wide runs.

The vertical can obviously change with every pixel.

 

[Nick]

I'm just going to be a bit picky with your test image; you should have your horizontal transistions in the chequer-board region a bit wider than 1 pixel as the monitor/display circuitry is frequently very bandwidth limited. I suggest using 5 to 10 pixel wide runs.

The vertical can obviously change with every pixel.

I have an LCD.

 

[Simon F]

I'm just going to be a bit picky with your test image; you should have your horizontal transistions in the chequer-board region a bit wider than 1 pixel as the monitor/display circuitry is frequently very bandwidth limited. I suggest using 5 to 10 pixel wide runs.

The vertical can obviously change with every pixel.

I have an LCD.

In which case the gamma curve might be S-shaped and can vary with viewing angle

 

[GameCat]

Ahem...

Try viewing two squares side by side, one with alternating white and black vertical lines, and one with horizontal. They won't look equally bright.

Just do it You'll find that the fact that you have an LCD doesn't help much. I have one, and that test pattern still doesn't work. I find that the biggest problem with a gamma corrected display is that so many webpages and games look crap since they've already been gamma corrected at the source.

 

[Simon F]

Ahem...

Try viewing two squares side by side, one with alternating white and black vertical lines, and one with horizontal. They won't look equally bright.

Just do it You'll find that the fact that you have an LCD doesn't help much. I have one, and that test pattern still doesn't work. I find that the biggest problem with a gamma corrected display is that so many webpages and games look crap since they've already been gamma corrected at the source.

That probably means that you haven't got your monitor's brightness and contrast set up correctly. It's a common problem. I suggest reading Charles Poynton's excellent Gamma FAQ. His colour FAQ is also worthy of mention.

 

[Rockman]

what is a mipmap ?