Drop requirement for unsized formats to have bytesPlane of 0

[MarkCallow]

There is a lengthy discussion on this topic starting at KhronosGroup/KTX-Specification#216 (comment). (Unfortunately there is no easy way to move it over here.)

The conclusion of that discussion is that because bytesPlane provides information not otherwise available in the DFD for certain formats, such as those with packing (unused) bits in the most-significant bits of a sample, it should not be set to 0 when the data is "unsized" (compressed with variable length compression schemes such as zstd or ZLIB).

Formats such as KTX provide information indicating use of such schemes allowing apps to avoid using the DFD until the data has been inflated as well as indicating how to inflate it. An open question is do we want to provide an indicator in the DFD that the data is not in repetitive form. If so, how. The alternative is to require any uses of such schemes together with a DFD to provide the information out of band.

[fluppeteer]

I've got some wording for 5.19 Unsized formats:

First, changing:

In both cases an unsized format is indicated by setting all bytesPlane values to 0.

to

In both cases an unsized format can be indicated by setting all bytesPlane values to 0.

Secondly, adding:

Note that an implementation may associate a DFD with compressed (or other non-repetitive) data in the expectation that these aspects of the DFD will be valid only once a conversion has been made to an addressable format. If an implementation has other means to indicate that the content is not directly accessible, and clients of the interface are expecting this, it shoudl not be seen as inherently invalid for the DFD not to be usable directly in interpreting the compressed data.

Is that okay for these purposes? The intent of the original wording was to stop people from having to make up a nonsensical value for these fields, not to preclude useful content. If someone's trying to use a DFD as the only way to indicate whether content is compressed, obviously you wouldn't want to leave misleading values in place - but since you already have to store addressing information like line stride outside the DFD it seems unlikely that anything should get confused.

[lexaknyazev]

Yes, this all sounds good.

[fluppeteer]

Fixed in 1.4.0.