PVRTexTool creates broken KTX mip level

Hi,

I seem to have found a bug in the KTX generator. I have a texture in format RGB 8 8 8 and the second to last mip level has size 2x2. This results in the following entry for this mip level in the KTX file:

0C 00 00 00 // imageSize = 12
35 06 06 3C 08 08 00 00 // first row
27 10 10 2F 12 12 00 00 // second row
03 00 00 00 // next imageSize = 3

So the file says the face has a data size of 12, which is true if you do 2 * 2 * 3, but it doesn’t consider the row padding because KTX files assume GL_UNPACK_ALIGNMENT = 4. This results in the loader reading 12 bytes, then encountering 12 12 00 00 (which is 4626 and breaks everything) instead of the actual 03 00 00 00. I think the correct content should be either imageSize=14 with implicit mipPadding=2 bytes, or imageSize=16 and treat the last 2 bytes as row padding.

Either:
0E 00 00 00 // imageSize = 14
35 06 06 3C 08 08 00 00 // first row
27 10 10 2F 12 12 00 00 // second row + 2 padding
03 00 00 00 // next imageSize = 3

Or:
10 00 00 00 // imageSize = 16
35 06 06 3C 08 08 00 00 // first row
27 10 10 2F 12 12 00 00 // second row
03 00 00 00 // next imageSize = 3

I checked this with https://www.khronos.org/opengles/sdk/tools/KTX/file_format_spec/#2.16 and the libktx implementation at https://github.com/KhronosGroup/KTX/blob/master/lib/loader.c#L539 seems to agree with this.

This is with 4.1.6 (SDK build 3.5@3523712) on OS X 10.10.5.

Miro

Hi Miro,

Thanks for reporting the issue. I’ll discuss this with the TexTool lead engineer.

Joe

Hi Miro,

Apologies for not following up yet. We’ve had a busy couple of weeks. I’ll give the TexTool lead another nudge and will try to give you an answer in the next few days.

Thanks,
Joe

Hi Miro,

The TexTool lead hasn’t had a chance to investigate yet. I’ve reported the issue as BRN57752 in our tracker. We’ll aim to resolve the problem in a future release.

Thanks,
Joe