Many people may be aware, that the texture dungeons\fortruins\exterior\rffloor01.dds in QTP3 Redimized appears to be speckled. There is a much larger number of textures in the pack, that have the same issue, although not as severely.

I am not sure if many people are aware of the reason for it: In simple terms, it is an unintended random transparency in a DXT1 texture. More specifically, in DXT1 compression, the texture is divided into 4x4 blocks, and the coloration of each pixel in a block is derived from two colors that are given for the block. If color1 > color2, there are no transparencies in the block, and this would be the standard case for all blocks in a normal non-transparent DXT1 texture. However, if color1 <= color2, there can be transparent pixels in a block, depending on the data for each pixel. As it happens, in this case there are a number of blocks in the texture, where color1 <= color2, and where certain pixels indicate a transparency. This is clearly an error, as the texture is supposed to be completely non-transparent, and Oblivion does not even recognize or properly render DXT1 textures with a transparency. The result is a speckle at those pixels involved.

This whole thing appears to be an artifact created by the process whereby the original QTP3 textures have been reduced for the Redimized package, as it does not occur in the original textures.

Mechanically searching through the QTP3 Redimized textures reveals, that this error actually occurs for at least 85 textures to a varying degree, and perhaps for even as many as 848 textures. The large range is because for 763 textures, the error occurs within the smallest mipmaps, which display less than the 4x4 pixels, which is the minimum stored for each one, so the actually displayed pixels may not necessarily be impacted.

The error can be simply fixed by processing the texture so, that within those blocks where color1 <= color2 creates a possibility for transparencies, the pixel data is changed (from 11 to 00) for any pixel that would indicate a transparency, so that no transparencies occur.

Now, to fully correct this error would require a rather large patch (around 255 MB as .7z) to the texture pack, and as far as I can see, that presents two problems:
- I am not sure if the original pack creators are around to approve such a patch.
- I have long ago realized, that I don't have a modder's temperament suitable for creating or maintaining a patch like this.

However, if somebody, who has the appropriate connections to the original QTP3 Redimized creators, and who is willing to take such a patch on his or her shoulders appears, I would be more than happy to convey all my information on the issue, and even supply the fixed textures.

Edit:
Or perhaps, just the description of the issue given above may help somebody to act on it even without assistance. Anyway, I do not wish to retain any rights whatsoever to the information given above, and it is free for anybody to make use of within normal modder ethics.

so basically you're saying that this fix: http://www.4shared.com/archive/quo_X7H0/QTP3FortFloorFix.html

should be applied to many other textures as well?

thanx for the info!

Yes and no.

Yes, because the issue is the same.

No, because (and if I remember this correctly) that is a poor patch, as it is a non-transparent texture compressed as DXT5, which wastes half the file size in encoding a constant non-transparent alpha channel. I think one might be better off just using the original QTP3 texture instead.

Edit:
Or not really, I just checked, that it is still not as big in size as the original QTP3 texture, but it really is poorly compressed being twice the size of the original Redimized texture, and should ideally be compressed as DXT1 instead.

@Inki
If the "color1 <= color2" thing is a rule, perhaps Ethatron ( http://www.gamesas.com/user/656326-ethatron/ , http://oblivion.nexusmods.com/mods/41423 , http://obge.paradice-insight.us/wiki/DDSopt , https://github.com/Ethatron ) can write an algorithm into his DDSopt- program to correct this problem?

That is not a bad idea. And indeed, the error occurs whenever color1 <= color2 for a block, and a pixel within it has 11-data indicating a transparency. (Or to put it simply, it is merely an unintended random transparency in an Oblivion DXT1 texture.) Based on my observations, the solution is simply to change the pixel data to 00, which would refer to color1. That seems to be the most appropriate alternative to 01 (color2) or 10 (color average) in all the cases I looked at, and I suspect that might also be a working rule for the fix, or at least I have used it as such myself,

Now, that fix will still leave color1 <= color2, which I guess normally does not occur in a non-transparent texture (unless it might be used to be able to refer to the average color specifically*), but that is still perfectly in line with the DXT1 specification, and does not seem to cause any issues.

The only thing to note is, that DXT1 textures can also have intentional transparencies, so the fix cannot be used indiscriminately, and one has to know that a non-transparent texture is intended. For Oblivion, that should not be a problem, however, because Oblivion does not really use transparent DXT1 textures generally, although it might be able to have them for icons and such.

I have glanced at DDSOpt, but only briefly, because I immediately got the impression, that it would not be compatible with my current Windows XP setup. Anyway, like I said, I have absolutely no issues with anybody working to fix this thing. If you have been following DDSOpt, perhaps you might best know how to bring up the possibility, and leave a hint in a suitable place? (I don't wish to sound rude or anything, but I just don't feel like running after people to try to persuade them in this matter.)

---
* When color1 > color2, the available colors are color1, color2, and two colors at 1/3 and 2/3 points along the line connecting them in color space.

---
P.S.:
Just as a curiosity, the same issue and the same fix would also apply to a small number of vanilla Skyrim textures. A nice example are the eye and mouth slits in several of the vanilla dragon priest masks. However, Skyrim does display DXT1 transparencies so there are no speckles, and having some transparent pixels in a mouth or eye slit doesn't really matter much, so it is probably not worth making a fuss about (and before you ask, their configuration is clearly not intentional). Anyway, these things can sometimes be quite nicely observed with WTV.exe, which is a dds texture viewer downloadable from nVidia where they also have their texture tools available.