dds_image icon indicating copy to clipboard operation
dds_image copied to clipboard

Is `dds::Image::data`'s size equal to sum of mip map sizes?

Open cone-forest opened this issue 3 months ago • 1 comments

Since changing dds::Image::data from vector to unique_ptr info about the byte size of the actual data is lost, no? Is it always equal to w * h * sum(mipmaps[i].size()) that can easily be computed from dds::Image fields?

I have this question because libktx seems to separate these things. A BC7 compressed texture seems to actually allocate 1 byte per pixel on the CPU using KTX and 16 bytes per pixel using DDS. Am I missing something?

Encountered this problem while trying to upload this model (doesn't have DDS equivalent)

cone-forest avatar Nov 15 '25 20:11 cone-forest

Since changing dds::Image::data from vector to unique_ptr info about the byte size of the actual data is lost, no?

While that's fair that that information is "lost", it shouldn't concern you. The only thing that should interest you is the mipmaps vector, that defines a span of bytes used for each mipmap. I don't think anything else should really be relevant, ever.

Is it always equal to w * h * sum(mipmaps[i].size()) that can easily be computed from dds::Image fields?

No, obviously not, since that would never work with any packed or compressed image format.

A BC7 compressed texture seems to actually allocate 1 byte per pixel on the CPU using KTX and 16 bytes per pixel using DDS. Am I missing something?

"using DDS" does not give any information about the image format that is used. "16 bytes per pixel" sounds heavily like R32G32B32A32 which I would assume is very likely not what you want, so there's something else going wrong. And if it's a compressed image format I could also imagine that "bytes per pixel" does not mean what you think it means. However, this is all speculation since I don't know what images you're exactly working with.

spnda avatar Nov 16 '25 10:11 spnda