DDS Texture Inspector

Because writers fill it in inconsistently and Direct3D itself recomputes the value rather than trusting it. The field is meant to be the row pitch for an uncompressed surface or the total byte size of the top level for a block-compressed one, but plenty of exporters write something else: Pillow, for instance, stores (width + 3) × 4 for every block-compressed file, which is 76 for a 16×16 DXT1 whose data is 128 bytes. Nothing rejects such a file, because nothing needs the field — the loader derives the layout from width, height and format anyway. This page does the same and shows the declared number next to the derived one, so you can see the disagreement instead of inheriting it.

Block-compressed formats store 4×4 blocks and nothing smaller. A level of 1×1, 2×2 or 3×3 pixels still occupies one whole block — 8 bytes for BC1 and BC4, 16 for BC2, BC3, BC5, BC6H and BC7 — with the unused texels simply ignored on decode. The same padding applies at every level of a non-power-of-two texture: a 13×7 surface is ceil(13/4) × ceil(7/4) = 4 × 2 blocks, which is 8 blocks for 91 pixels. Summing width × height × bytes-per-pixel instead of counting blocks under-counts every level, and since levels are stored back to back with no headers, one wrong size misaligns everything after it.

The original pixel format block can only name a format through a four-character code or a set of channel masks, and it has nowhere to put a texture array, a typed-but-uncompressed format or the newer block formats. DDS_HEADER_DXT10 solves that with a numeric DXGI format enum (BC7_UNORM is 98, R8G8B8A8_UNORM is 28), a resource dimension, a misc flag whose 0x4 bit marks a cube map, an array size and an alpha mode that records whether the stored colours are straight or premultiplied. It sits between the 128-byte header and the pixel data, which is why the data offset shown here becomes 148 for those files — a reader that assumes 128 decodes the header as though it were pixels.

BC7 has eight block modes with different partition tables, endpoint precisions and index layouts, and BC6H is a half-float HDR format that needs tone mapping before it can be shown on an ordinary display at all. Both are decodable in principle, but a wrong implementation of either produces plausible-looking garbage rather than an obvious failure, so this page reports the format, the mip chain and the whole header, and says plainly that it is not decoding the pixels. To see them, convert with texconv or Compressonator, or open the file in a viewer that hands the blocks to the GPU.

Almost certainly not. BC5 stores exactly two channels, each as an independent 8-bit interpolated block of the same kind BC3 uses for alpha, and normal maps are stored that way on purpose: X and Y are kept, and Z is reconstructed in the shader as sqrt(1 − X² − Y²) because a unit normal has only two degrees of freedom. Nothing is missing. The same is true of BC4, which keeps one channel and is used for roughness, height or ambient occlusion masks; it is shown here as greyscale because a single channel has no colour of its own.

A cube map holds a complete mip chain per face, stored in the order +X, −X, +Y, −Y, +Z, −Z, with no separator between them; the caps2 field carries one bit per face plus the 0x200 cube-map bit. Six faces of a 16×16 BC1 texture with a full chain is 1104 bytes of surface data rather than 184. Faces genuinely can be absent — the format allows any subset, and the file then holds only the faces whose bits are set, which is why the expected size here is computed from the bits rather than assuming six. When the bits claim more faces than the file can hold, that shows up as a shortfall in the layout block.