Use 4 character code for compression type over uint

[dewilkinson]

ISV feedback: Instead of using a UInt32 for the supercompression scheme, why not use 4 byte characters (or at least use those instead of 1, 2, 3, 4), i.e. ZLIB, ZSTD, CRNC. This would be strongly preferred

[MarkCallow]

I have no strong feeling either way. Why is this "strongly preferred" over the UInt32?

[dewilkinson]

Reviewed on 12/21 call.

It was agreed that , as long as values are unique, it does not matter what system is used. However, it is beneficial for development and debugging to assign human readable tags to image formats.

We will go ahead and implement a 4-byte string encoding for these formats

Additionally it is proposed that a user can never override a default CTTF/KTX2 predefined value, so some mechanism must exist to ensure a custom FOURCC can never conflict with a default type.

Suggestions include special characters (underscore?) for built in codes.

[MarkCallow]

If we use, e.g. an _ as a prefix for KTX reserved scheme names then we will only have a 3 character code. So on further reflection I prefer to stick with the binary values where it is easy to reserve a block for KTX.

[lexaknyazev]

@MarkCallow My understanding is a bit different: it's app-specific schemes that should use "_" prefix. Khronos-maintained will use all four chars.

[dewilkinson]

Hmm. then we're left with same problem of 3 character codes for custom types, which could be tricky (It's hard enough to condense a formatID into a fourCC value , let alone 'threeCC')

We could utilize byte values of less that 20h in the uint32 to represent reserved KHR types (effectively just a binary range as Mark suggests) , user defined formats could then be safely limited to alphanumeric ASCII values - this way there'd be no collision.

[lexaknyazev]

we're left with same problem of 3 character codes for custom types

Why is it a problem? Custom schemes are not a priority and are not supposed to be interoperable, so in the worst case they can use names like "_001". However, I still think that they will be able to choose one of 46k available options within "threeCC" space.

[dewilkinson]

It’s really just a matter of preference , but if we are to use an underscore, I guess I’d prefer it not to be for the standard types, so using it to distinguish custom formats would be fine with me.

[MarkCallow]

I changed the title because the original causes confusion with FOURCC.org (www.fourcc.org). I do not want KTX to get tangled up in the flawed MS registration process for FOURCC.

I would prefer to stick with hex identifiers whose registration we can fully control. For development, one would normally create a header file with #defines for the values and it is just as easy to remember the name of a define as a 4cc. When debugging, looking at a file via a binary viewer, I agree a 4cc is easier but I expect tools to emerge that will dump all the header info of a KTX2 file which will be much easier than staring at binary dumps.

[MarkCallow]

As noted, I prefer to stick with binary values to identify the supercompression scheme. Using a four cc will likely be confused with fourcc.org and people may think they can use any value from there and should register new values there. Furthermore using "_3CC" for proprietary is likely to lead those companies with their own schemes to conclude there is no need to register them.

I'l give it a couple more days then, absent any objections, I'll close this.

[dewilkinson]

As long as a dedicated range is reserved for future ‘built in’ types as the spec evolves that can’t clash with user defined values this is fine with me

[MarkCallow]

As long as a dedicated range is reserved for future ‘built in’ types ...

Done in PR #55.