Talk:Mipmap

Technically...

"Mipmaps require 33% more memory than a single texture. "

Isn't this supposed to be 50%? It's clear from the picture as well that mipmapping adds exactly 50% of the surface area of the original to the new one (which is 33% of the new bigger image, not the old one). Please correct it back if I am wrong or misunderstood something. Choephix (talk) 15:23, 22 January 2013 (UTC)[reply]

Don't count the white area Striepan (talk) 21:45, 31 January 2013 (UTC)[reply]
The size of a Mipmap drops in two dimensions, so the next lower resolution down is only half the x and half the y, or 25% of the previous image. The sum of an infinite depth of mipmaps is 1 (original) + 1/4 + (1/4)^2 + (1/4)^3 .. = 4/3. In practice, its never exactly a 4/3 the original memory requirement. — Preceding unsigned comment added by Charles Merriam (talkcontribs) 03:18, 27 November 2020 (UTC)[reply]

Untitled

2 Things:

(1) This sentence doesn't seem to make sense: "Rendering speed increases since the number of texture pixels ("texels") being processed can be much lower than with simple textures."

(2) I don't think that "cache coherency" is the correct term here. "Cache coherency" goes down? It is also used again later.

128.83.144.47 (talk) 21:07, 29 January 2009 (UTC)RMS[reply]

Rendering speeds increased?

This seems not to be the case. I have Grand Theft Auto: San Andreas (PC), it gives you the option to turn on/off mip mapping. When its on my frames per second ratio drops to five fps. When I have mip mapping turned off however, the fps ratio is eighty fps. Mip mapping seems to be like anti aliasing, it draws more than the default would, in attempt to make the image smoother. So, it makes no sense for it to render it faster.

More textures = slower rendering speed Yakisan (talk) 08:27, 19 August 2009 (UTC) —Preceding unsigned comment added by 166.164.109.44 (talk) [reply]

if activating mipmaps brings your game from 80fps down to 5fps, it's more likely a problem with the game or your computer, not with mipmapping itself. if you have enough memory aviable, mipmaps speed it up. --83.77.196.218 (talk) 00:31, 9 October 2009 (UTC)[reply]
Mip-mapping counteracts one effect: oversampling. This occurs when more pixels are available to copy than available on the screen. Mip-mapping gives the rendering algorithm less pixels to choose from, resulting in smoother (but blurrier) rendered images.
Knight666 (talk) 16:00, 23 January 2010 (UTC)[reply]

Alpha considerations

There should probably be a mention of alpha in mipmaps. E.g. for transparent mipmaps, if you don't pre-multiply the alpha you can end up with artefacts bleeding in from the transparent pixels, as discussed here: http://blog.wolfire.com/2009/01/scaling-images-with-alpha/ —Pengo 05:15, 6 April 2011 (UTC)[reply]

MIP maps?

The subject is called "mipmaps" and everything else is also referenced as mipmap. BUT, the beginning references MIP maps first. Is it a good idea to swap these two words to make sense to the prioritized word (mipmaps)? 88.134.36.87 (talk) 16:07, 21 April 2011 (UTC)[reply]

Generating mipmaps using Fourier transform?

In the article it says that more sophisticated algorithms for generating mipmaps, "perhaps based on signal processing and Fourier transforms", can also be used. Is this just a qualified guess or is there actually some reference for this? —Kri (talk) 09:53, 10 July 2011 (UTC)[reply]

Isn't this strictly handled by the Hardware/API nowadays?

If yes, it has to be clearly shown on the article. --fs 09:34, 14 December 2011 (UTC)[reply]

I agree. I'm wondering for example if the partial derivatives that are generated to sample the mipmaps can work around the depth/stencil buffers or if say an interlaced stencil buffer would completely defeat vertical mipmapping because every other vertical pixel is missing, and so the derivatives cannot be generated. It's nigh impossible to find anything written about this (for example: http://bartwronski.com/2015/03/12/fixing-screen-space-deferred-decals/) largely due to how web search engines default to low information results. --184.63.132.236 (talk) 20:58, 18 September 2015 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Mipmap. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

  • Added archive https://web.archive.org/web/20140414134825/http://staff.cs.psu.ac.th/iew/cs344-481/p1-williams.pdf to http://staff.cs.psu.ac.th/iew/cs344-481/p1-williams.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:07, 12 June 2017 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Mipmap&oldid=1204020417"