feat(ktx): add initial ktx input/output support.

[walcht]

Description

Fixes #2329.
Add initial KTX2 format support (closest similar plugin/format in OIIO is DDS).

Important

This is still a very early draft PR.

Consequently, there are a lot of TODO comments, and code snippets that haven't
been properly tested yet. All of these will be addressed after fixing CI issues.

This KTX plugin support obviously nullifies the benefits of using KTX in the
first place. That being said, this plugin is still useful so that end users
don't have to convert back and forth between KTX <-> supported format (e.g., PNG).
It is also useful to convert to and from KTX2 format using OIIO.

An example usecase would be Blender and its glTf import/export plugin.
(see KhronosGroup/glTF-Blender-IO#1896).

Ideally, at some point in the future, OIIO may introduce a new API to accomodate
texture formats that are mainly used for fast texture uploads to GPUs.

For details on KTX2 and what this PR supports and what it doesn't (alongside a
description of current limitations), see src/ktx.imageio/README.md (copied parts
of it at the end of this).

Tests:

Added initial testsuite but only for the input (i.e., info_command) part of the plugin.
Ideally, after fixing CI issues, the tests will be adjusted for ktxouput.

Checklist:

• I have read the guidelines on contributions and code review procedures.
• I have read the Policy on AI Coding Assistants
  => Haven't used any AI coding assistant tools in any capacity whatsoever.
• I have updated the documentation if my PR adds features or changes
  behavior.
  => Not yet. But will add docstrings alongside custom "ktx:" ImageSpec
  attribute descriptions.
• I am sure that this PR's changes are tested in the testsuite.
  => Partially. As stated above, I mainly opened the PR now in the hope of speeding
  up fixes for the CI issues.
• I have run and passed the testsuite in CI before submitting the
  PR, by pushing the changes to my fork and seeing that the automated CI
  passed there.
  => Only 2 jobs pass (clang-format, ABI check).
• My code follows the prevailing code style of this project and I
  fixed any problems reported by the clang-format CI test.
• If I added or modified a public C++ API call, I have also amended the
  corresponding Python bindings. If altering ImageBufAlgo functions, I also
  exposed the new functionality as oiiotool options.
  => No new API is introduced. This is just a plugin.

CI Issues:

1. latest version of libktx requires CMake >= 3.23 which causes failures in the CI.
   Tried adjusting the build_cmake script but still CMake 3.18.2 is used in some
   runners.
2. undefined symbol references to _ktxTexture (essentially, linking with libktx.a fails for
   some reason). This is probably due to me missing some crucial setup step (I thought
   LINK_LIBRARIES KTX::ktx is sufficient for linking to libktx to work - which, again, is on
   my machine).
3. failure to find KtxConfig.cmake on MacOS => Absolutely no idea why (passes in other
   Windows/Linux jobs).
4. IntelLLVM Not Supported => probably some libktx dependency causes this (there are
   some libktx build instruction details that I haven't looked at yet).

Feel free to edit this directly.

The sections below are copied from src/ktx.imageio/README.md. These will be updated
as this PR progresses.

Supported Encoders/Decoders

• Supported/Tested texture kinds:

  • SINGLE_TEXTURE_1D (TODO)
  • SINGLE_TEXTURE_2D
  • SINGLE_TEXTURE_3D (TODO)
  • CUBEMAP_TEXTURE (TODO)
  • ARRAY_TEXTURE_1D (TODO)
  • ARRAY_TEXTURE_2D (TODO)
  • ARRAY_TEXTURE_3D (not planned)
  • ARRAY_TEXTURE_CUBEMAP (not planned)

• Supported/Tested raw VkFormats (decoder + encoder):

  • VK_FORMAT_R8_UNORM
  • VK_FORMAT_R8G8_SRGB
  • VK_FORMAT_R8G8B8_SRGB
  • VK_FORMAT_R8G8B8A8_SRGB

• Block-compressed formats (decoder + encoder):

  • ASTC
  • BCn (waiting on libktx BCn support PR merge)

• Basis Universal schemes (encoder + decoder):

  • UASTC
  • ETC1S

• Supercompression schemes (decompressor + compressor):

  • ZLIB
  • ZSTD

Dependencies (only one - libktx)

• libktx: for general KTX@ format support (loading of KTX2 files, transcoding
  support, supercompression decompression support, etc.).

  • Commit hash: see OpenImageIO/src/cmake/build_Ktx.cmake
  • License: Many subresources. lib/etcdec.cxx's license is not permissive.

Resources

• KTX2 Specs: https://registry.khronos.org/KTX/specs/2.0/ktxspec.v2.html
• Official Implementation (KTX-Software): https://github.com/KhronosGroup/KTX-Software
• Basis Universal Supercompression Implementation (used by libktx): https://github.com/BinomialLLC/basis_universal
• Comparing-BCn-texture-decoders: https://aras-p.info/blog/2022/06/23/Comparing-BCn-texture-decoders/

[walcht]

Update: I'm working on integrating BCn decoders/encoders directly within libktx so that this PR gets significantly simpler (e.g., from 12_000 lines most of which are from dependencies to circa 2_000).

[walcht]

Update2: significantly simplified the whole PR. Now only dependency is libktx (since I offloaded most work to libktx via a PR that will be probably merged soon).

Can you please not approve workflows unless I explicitly request a workflow run? (to avoid filling the actions log with CIs that I know will certainly fail).

[lgritz]

Can you please not approve workflows unless I explicitly request a workflow run? (to avoid filling the actions log with CIs that I know will certainly fail).

Sure, in this case I can do so, but only because you are a a first-time contributor to this project, so admins have to approve workflow runs on the project's main account. Once you have any PR accepted and merged, the workflows will run automatically.

Here is the general solution that you or others can do, in this situation and after you no longer need admin approval:

Let's say you have pushed to your fork's branch "mypr" and submitted a PR to the project from that branch. (Aside: I strongly recommend working in topic branches, and never submitting a PR from your "main".)

After submitting the PR, you realize you need to iterate (you want to add things, or CI is not passing and you need to make repairs, or you have review comments to address), but you don't want to do a series of many many pushes as you go, each of which will trigger a CI run on the main branch as well as sending email alerts to everybody "watching" this project, since pushing to your branch is technically a PR update.

Instead, push to a different branch!

git push origin mypr:test

This pushes your fork's "mypr" branch to your fork in a "test" branch. This will run the CI on your fork in your account (allowing you to see if CI passes for the changes you've made), but since your "test" branch is not associated with the PR, it will not send the rest of us alerts and will not trigger a CI run on the project's main repo account. Then when you finally have it right and are ready for the rest of us to see it, you can git push origin mypr to update "mypr", which the system will know is the branch you are making the PR from.