Make a single CLI tool

[lexaknyazev]

Although the existing CLI tools cover the most urgent needs, we should design and implement a single CLI entry point (e.g. ktxtool) that would provide extensive coverage over possible manipulations with KTX files. Tools like ffmpeg, openssl, magick, sox, etc are a good source for inspiration.

This is a long-term project that should be carefully planned and executed. The tool workflow should comprise three orthogonal steps as follows. Most of these features are already implemented, it's just a matter of consistently exposing them.

1. Ingest

Besides formats like PNG, JPEG, or netpbm, this step must accept KTX files. In the future, KTX fragment identifiers should be supported as well, so that a user could select e.g. a single array element. For individual levels, cubemap, array, and animation sequence targets, there should be means to conveniently specify multiple source images.

2. Convert pixel format

Besides applying BasisU supercompression, the tool should be able to:

• pass-through all known formats;
• decode all compressed formats to R8G8B8A8 (at very least) - this would enable OS-level thumbnail generation;
• convert or reinterpret all known uncompressed formats;
• transcode BasisU payloads to supported compressed targets.

There should be an option to apply/override/alter input file's swizzling metadata and color space.

3. Write output

Suggested features for this step are: fine control over metadata entries (editing existing entries, adding custom keys), extraction of raw image planes, scaling, cropping, padding, changing orientation, and mipmap generation.

/cc @pjcozzi @donmccurdy @bghgary

[MarkCallow]

I'm in general agreement with the goal.

I'd like to point out that toktx already has a convenient way to specify multiple source images. A file containing a list of files on which to operate can be given on the command line by prefixing its name with either @ or @@. The former will treat relative paths as relative to the current directory. The latter treats them as relative to the location of the listing file.

Converting or reinterpreting all known uncompressed formats is a pretty big ask. Note I'm taking this to mean all the file formats not just pixel formats. There are many tools available that can do conversion.

[lexaknyazev]

Note I'm taking this to mean all the file formats not just pixel formats.

The goal is to support GPU pixel formats conversion, (e.g. RGB9E5 from RGBA16F) as they are usually not known to general-purpose image tools.

Other file formats like HEIC or TIFF are absolutely out of scope.

[donmccurdy]

I'm still getting the hang of the CLI tools already provided by KTX-Software. No objection to the proposal here but I don't think I can provide particularly useful feedback yet.

[pjcozzi]

I'm still getting the hang of the CLI tools already provided by KTX-Software. No objection to the proposal here but I don't think I can provide particularly useful feedback yet.

Same here. So general 👍 from me.