Take any image and compress it to BC1, BC2, or BC3, and the last mip levels (2x2, 1x1) won’t always have the same value. The same goes for images sizes that are not a multiple of the block size. All blocks on the edge (those that have pixels outside the actual image) have non-deterministic values. This is a problem, in our case, for automatic version control of compressed images, because most of the times changes are detected even if the original image did not change.
This is using version 2020.1.3. We have only noticed this with BC[1-3] formats, but not with BC6 nor BC7. We have not tried with other formats.
Hi Francois,
This is a known issue, and should be fixed in the next version. For the cases we’ve seen, a workaround for the moment (for all compressors other than BC3n) is to make sure you’re using the GPU compressor instead of the CPU compressor (more details on why below) - you can check which compression qualities use a CPU or a GPU compressor by looking at the tooltips for the different compression qualities in the standalone exporter GUI (the text will change depending on the format and whether or not the GPU supports CUDA), or the command-line version will sometimes print out messages when using the CPU version. It looks like not all CPU compressors are affected by this.
What I think is going on here is that although all of the compressors process images block-by-block, some of the older CPU compressors might be trying to read from uninitialized memory (or possibly reading from memory that was used for past computation results) when processing blocks that extend past the boundaries of the image (which happens when the image isn’t divisible by the block size, as you pointed out). The GPU compressors all seem to handle this correctly to the best of my knowledge - they use a map to ignore texels that won’t be visible in the final result. Some of the CPU compressors appear to handle this correctly as well.
BC3n is the only format that doesn’t include a GPU compressor (though it’s the result of composing a swizzle and BC3 compression), so that’s why this workaround doesn’t work for BC3n.
Hope this helps!
Good know it’ll be fixed soon. Looking forward for that new release. Thanks!
One more little question: may I inquire about when is that next version planned to be released?
Hi Francois,
We just released Texture Tools Exporter 2021.1.1 today, which should fix all the determinism issues I know about with image compression. (It was in fact reading from past computation results.) Thanks for your patience, and I hope this helps!
1 Like