On MBMs and Other Image Formats

Size on disk is not directly related to size in memory. On load, KSP will load all textures, uncompress them, and then recompress them to DXT1 or 5 (5 if the texture has an alpha channel). There are three exceptions: mbms which have a "do not compress ingame" flag will be left uncompressed; TGAs are subject to a loader bug; and DDS textures skip all those steps (they're already in DXT format) and are uploaded directly to GPU memory.

There are some loader bugs. TGAs are left as RGB or RGBA (i.e. uncompressed) rather than compressed to DXT (note that of course this still has nothing to do with whether your TGA was compressed on disk; as I said, all files are uncompressed on load first, before anything else happens.) The other loader bug is that PNGs sometimes don't get mipmaps generated. Active Texture Management (in basic or aggressive) fixes both of these issues. A new issue has arisen in 0.25: sometimes 0.25 just fails to load TGAs (but not every TGA and not every time, either).

If you see differences in memory ingame from converting files, that's due to the various loaders using more memory and garbage collection not freeing it yet. It will all even out in the end, unless the loaders have memory leaks (which, sadly, most KSP loaders do appear to).

There are two main reasons to convert your textures to DDS yourself, rather than having KSP do so at loading. The first is speed: it's incredibly faster, since the dds can be read directly into memory, whereas any other format will have to be loaded, uncompressed (if a compressed PNG, JPG, or otherwise), then recompressed to DXT, then finally uploaded (and all the original memory freed). The second is that last step is a bit lossy in KSP, so having KSP load DDS files has the lowest memory footprint since there aren't all those extra steps where leaks can occur.

Finally, as of version 0.20 of KSP, since all textures are the same formats ingame, the extension of a texture doesn't matter at all. In fact, models and textures are read in before anything else, and all models and textures in GameData are loaded, regardless of whether they will be used for anything. Since models are only "tied" to textures after both have been loaded, KSP will look for a texture in the same folder as the mu with the same name-before-extension as is requested by the mu. This is because it's requested from the GameDatabase. If you have multiple files of the same name (but different extension) only one will ever be referenced by models (but both will be loaded and take up space. So don't do this); and if you have a model000.png and the model requests model000.mbm that doesn't matter, because the extension isn't used; what it's actually requesting is "a texture in GameDatabase with the URI /path/to/model/requestedTextureName

That's also so that in a cfg in a MODEL node you can replace textures (i.e. you could do texture = model000, path/to/some/other/texture)