Why does ktx create convert everything to RGBA on loading then convert to the desired format?

[MarkCallow]

This question is primarily for @aqnuep. I have noticed that ktx create gets imageio to load everything as RGBA then it applies a conversion to the wanted format. I'm sure there must be good reasons for it but at first glance it wastes a lot of cpu cycles in many cases by e.g causing to loaders to add fake alpha channels which are then removed by its convert function. As image.hpp is a template class that supports most image formats, it seems possible to have the loaders deliver the wanted format and perform any subsequent processing in that format.

What are the reasons?

[aqnuep]

Originally, things worked by only loading the necessary channels based on the specified VkFormat. In practice, that meant that sometimes we could get away with only loading RGB instead of RGBA.

However, due to #751, we had to allow arbitrary swizzle, e.g. imagine the input file being RGBA, the target format being RG8, but using a swizzle of "ra00". In this case you sort of must have an alpha channel, even if it's a "default 1" channel, to be present.

We could have solved this by adding support for the imaging framework to be able to substitute non-existent channels, but that's a solution that would have taken significantly more time to implement.

As in practice the original code anyway could only ever optimize the RGB vs RGBA case, which is a small optimization, the current solution loads everything as RGBA instead so any discrepancy between the source and destination formats, and any swizzle combination would work naturally.

Later, if needed, we could revisit this and try to optimize this through extending the imaging framework to handle missing channels everywhere, but it would take a more moderate effort compared to the original fix for #751.

[MarkCallow]

Thanks @aqnuep. I knew there had to be good reasons. I think we have more important things to work at present than optimizing this.