MIPMap bug

[Volodymyr Kachurovskyi]

I think that MIPMap has a bug that makes the upper levels of the
pyramid fade out when TEXTURE_BLACK mode is used and when the input
image is highly non-square (i.e. when it's width to height ratio is
far from 1).

The issue is in how a texel for an upper level is computed
(*pyramid[i])(s, t) = .25f * (
Texel(i-1, 2*s, 2*t) +
Texel(i-1, 2*s+1, 2*t) +
Texel(i-1, 2*s, 2*t+1) +
Texel(i-1, 2*s+1, 2*t+1));

If the previous layer has width or height equal to 1 the call to Texel
(i-1, 2*s+1, 2*t+1) will result in a black value returned. When this
black value is averaged with the other texels (see the code above) it
will give an incorrect result.

The overall result is that the levels are faded out starting from the
edges of the image to its center.

P.S. I think that triangle() method suffers from the same bug when the
texture is looked up near the image's edges.

[tomwindcloud]

I think you are right. Fortunately, TEXTURE_BLACK isn't a common
mode as TEXTURE_REPEAT and TEXTURE_CLAMP. I seems never use it.

[Matt Pharr]

(Sorry for the late response on this...)

I agree, there is a bug there. Nice find. Do you (or does anyone) have an idea for a clean way to fix it? I expect that there is a relatively elegant/compact fix, but any way I think of fixing it just works out to be too long and clunky.

Thanks,
-matt

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "pbrt" group.
> To post to this group, send email to pb...@googlegroups.com
> To unsubscribe from this group, send email to pbrt+uns...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/pbrt?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

[Kevin Egan]

Would it fix the problem to stop generating new levels of the mip-map
pyramid when either the width or height of the current level is one
pixel? That makes the most sense to me.

Kevin

> --

> You received this message because you are subscribed to the Google Groups "pbrt" group.

> To post to this group, send email to pb...@googlegroups.com.
> To unsubscribe from this group, send email to pbrt+uns...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pbrt?hl=en.
>
>

[Volodymyr Kachurovskyi]

Well, I fixed it by averaging only those texels that are actually in
the image and skipping the ones that are out of bounds. I do so not
only for TEXTURE_BLACK but for all other modes as well.

Also, there are more bugs in the MIPMap implementation that appear
when using TEXTURE_BLACK mode. I don't recall all of them now but at
least one of them is in the Lookup() method:

else if (level >= nLevels - 1)
return Texel(nLevels-1, 0, 0);

This will return the same value for all values of s and t which is
obviously wrong for TEXTURE_BLACK mode when the coordinates are far
out of bounds.

[Kevin Egan]

I don't quite understand how the current implementation is giving
wrong answers as long as you stop mip-map creation when the width or
height is 1.

If a mip-mapped texture uses the highest level mip-map level (one
pixel width or height), and TEXTURE_BLACK is used, then I would expect
the resulting texture lookup to be very dark. When using the highest
level mip-map the texture lookup is over a very large area (roughly
50-100% of the texture width / height), and if the lookup is not
perfectly centered a good portion of that area will be out of bounds.

Kevin

> --

> You received this message because you are subscribed to the Google Groups "pbrt" group.

> To post to this group, send email to pb...@googlegroups.com.
> To unsubscribe from this group, send email to pbrt+uns...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pbrt?hl=en.
>
>

[Matt Pharr]

One problem with stopping building MIP maps when one dimension does to one is the risk of aliasing: in an extreme case, if you had a 256x1 texture, thence didn't build any MIP Maps, and then had that texture map to a single pixel's area, you'd want to have something along the lines of a 1x1 MIP level that gave you its average value. (This is admittedly a somewhat obscure case.)

(I think that Volodymyr's proposed fix makes sense; I'll update the pbrt source distribution to include this fix as well as the other issue (hopefully before too long).)

Thanks,
-matt