Feature request: record mipmap generation options for ktx create/encode

[walcht]

Since I'm still working on OIIO KTX2 support, regenerating as-close-as-possible of the original KTX2 input to OIIO is crucial. One of the aspects is to re-generate the same (as usual, as close as possible given the lossy nature) mipmaps.

ktx create (probably also ktx encode) does not record mipmap re-generation options so the following command doesn't save any metadata about the used mipmap filter (among other options as well).

ktx create --testrun --format R8G8B8_SRGB --generate-mipmap --mipmap-filter quadratic_approx tests/resources/input/png/kodim17.png kodim17_quadratic_approx_filer.ktx2

If this is reasonable, I will open a PR + CTS PR to add this.

For the moment, from the OIIO side, I just default to the same defaults used by ktx tools for mipmap regeneration (same with all other defaults, e.g., for UASTC).

I might open quite a lot of issues since I deal with a lot of edge cases (however, no pressure at all to address these as soon as possible).

Edit: wrongly used --runtime-mipmap at first. Issue still stands.

[MarkCallow]

I have no objection to capturing non-default mipmap generation options but one question immediately arises. Does OIIO decode and keep the mipmap levels when loading? In other words, is regeneration only needed if the image has been edited?

[walcht]

Does OIIO decode and keep the mipmap levels when loading? In other words, is regeneration only needed if the image has been edited?

Even if the input texture hasn't been changed, regeneration is required (if the user specifies mipmaps on the file to be saved) when writing the texture again.

If we are writing to a KTX2 file (regardless of what the input is and whether it was modified or not), if the user requests saving of mip levels, these mips have to be regenerated.

Using OIIO to edit KTX2 files (same with DDS files) is usually a bad idea since when saving to the same KTX2 files the quality will degrade even further. Using OIIO to read KTX2 files and write them from other formats (e.g., PNGs, JPEGs, but definitely not DDS since the quality will also degrade) is main intended purpose of my addition of KTX2 to it.

There are some discussions and PoC on adding proper GPU texture support to OIIO (i.e., providing a shared API across different texture formats like KTX2 and DDS to directly load the data into the GPU).

[MarkCallow]

Why would somebody write a file, if it hasn't been edited?

If it hasn't been edited why not keep the loaded mipmaps and save those instead of regenerating?

Absolutely, an editing cycle on lossily compressed textures is a bad idea but don't forget that some KTX v2 files contain uncompressed or losslessly compressed images. Creating a lossily compressed texture from a JPEG image will also see a quality degradation.

I think adding proper GPU texture support to OIIO is a good idea.

[walcht]

Why would somebody write a file, if it hasn't been edited?

There is, obviously, no reason to do so. My point was that even if one loads a KTX2 texture via OIIO without editing it, writing it again requires regeneration of mipmaps because OIIO only loads to decompressed data (there is a draft PR for GPU support but it is still early).

If it hasn't been edited why not keep the loaded mipmaps and save those instead of regenerating?

Because OIIO only loads to decompressed data (no GPU support yet where mipmaps can directly be loaded).

Will open a PR that adds mipmap generation to KTXwriterScParams or some new KVD entry (like KTXwriterMipmapParams).

[MarkCallow]

Because OIIO only loads to decompressed data (no GPU support yet where mipmaps can directly be loaded).

Then how does OIIO cope with .exr and other potentially multi-level, multi-image file formats?

Will open a PR that adds mipmap generation to KTXwriterScParams or some new KVD entry (like KTXwriterMipmapParams).

Adding a new metadata item will require a spec update. Use KTXwriterScParams. It is already misnamed for how is used now.