KTX2 iOS Mipmap Issue

Bugs
,
1

Hi,

we encountered the following issue when using KTX2 textures on iOS. If the texture has certain dimensions and mipmaps are used, it seems that some mip levels are not transcoded properly as they contain artifacts.
We do assure that the initial image size is dividable by 4 in both dimensions. Our initial assumption was that it’s always the case if a mip level cannot be divided by 2 anymore without a modulo. But it’s not that simple as we have many cases where this is not the case and things still look fine. After quite some debugging we found that it has to do with the texture resolution but we cannot really figure out a pattern.

We have created a minimal repro: https://playground.babylonjs.com/#1BKO5H#3

For this specific case the initial image size is 1028x1468 and the broken mip level is #3 with 129x184px.

Here is a screenshot of how things look when a certain mip level is used on an iPad (we have the same issue on iPhones and Macs - but it seems that it’s only ARM related as Intel based Macs do not behave the same way)

IMG_0069.PNG
IMG_0069.PNG1920×1341 123 KB

Using the texture inspector one can go through the mip levels and verify the broken mip level:

IMG_0070.PNG
IMG_0070.PNG2388×1668 145 KB

We’ve tried different ways how to create the KTX2 texture but nothing seemed to change anything. Therefore our conclusion was that it probably has something to do with the transcoding.
Anyways, the given example was created using KTX 4.4.0 via ktx create --encode uastc --zstd 20 --format R8G8B8_SRGB --generate-mipmap --assign-tf srgb checkerboard.png checkerboard.ktx2

One possible workaround seems to be to use POT textures but then again, we have thousands of examples where non-pot textures work just fine.

Does anyone have a clue what’s going on here and where the issue is?

2

let me add @bghgary to this thread

4

We have more insights on that issue. After more debugging we were able to find a pattern for all our failure cases.

If the width of either the image itself or one of its mip levels is 2^n+1 then the consecutive mip levels are faulty. This is the case for all mip levels where the width is >= 129.

We could reliably reproduce this with all kinds of Apple ARM devices and various resolutions that fulfill the criteria.

It sounds like a weird bug to me but maybe someone has experience with it and has more insights. :slight_smile:

5

We are able to repro. I only have an Intel mac which doesn’t repro but my iPhone and @alexchuber’s mac repros. The reason why it doesn’t repro on Intel is probably because it doesn’t support ASTC. I’m guessing there is a bug with the transcoder going to ASTC. I will keep digging.

1 Like