Mark Callow

> My understanding is that the ktx2 branch of KTX-Software doesn't yet generate mipmaps It is toktx that does not generate mipmaps yet. libktx is fully capable of handling files...

mipmap generation is next on my list. I'm not planning to add jpeg support as you will be starting with an already compressed image. But perhaps in view of all...

@zeux you'll be glad to hear that the files in Avocado-newpadding all pass the updated validator. https://github.com/KhronosGroup/KTX-Specification/pull/117 and the matching https://github.com/KhronosGroup/KTX-Software/pull/170 will be merged soon.

I am transcoding a file with 12 levels in my libktx.js test and a 12-level cubemap (hence 72 images) in my native tests. Both work fine so I don't think...

Probably msc_basis_transcoder should do `std::vector dst = new std::vector;` and the JS side should call .delete() on the typed array buffer it receives back once it is finished with it....

> I believe @zeux's fix has no effect on the libktx version. Correct.

Here are the values I am seeing, with `ktxinfo` in `avocado_normal.ktx2` - the version compliant with the padding requirements that were changed in draft 18 of the KTX 2 spec....

It is compressing an entire level. As with the OpenGL API for uploading textures, what is stored in the mip level of a cubemap is all 6 faces at that...

> I finished KTX and KTX2 support in my viewer. It's working well, and converting KTX -> KTX2 and then using ETC/BC/ASTC + zstd supercompression really smashes them down. Also...

> I think I was looking at just UASTC and RDO. So with zlib on the KTX2 file, that brought it down. I thought the intent was then the overall...