Clarify the use of non-8-bit-channels in property textures
javagl opened this issue · 1 comments
(This does not refer to 3D Tiles at the core, but to the EXT_structural_metadata extension - but I think that here's the best place to keep track of this)
The Property Texture Data Storage section may not be explicit enough about how to handle property textures where channels have more than 8 bits.
There is an implementation note that says
Specialized texture formats may allow additional channels, or channels with a higher number of bits per channel. The usage of such texture formats for property textures has to be defined by additional extensions.
But some of the following statements (e.g. about how to assemble a FLOAT32 from four 8-bit channels) could be generalized to cover the cases of e.g. assembling a FLOAT64 from four 16-bit channels. Care has to be taken (maybe again in form of an implementation note) about the implications of this statement. Specifically: We probably do not want to make support for 16-bit channels a requirement in the specification. But we could be clearer about how they are supposed to be handled, iff they are supported.
The feature ID texture channels property defines which channels are supposed to be combined (i.e. shifted and ORed together) to generate the feature ID. Beyond the question about non-8-bit channels (mentioned above), further clarifications that could be added:
Should there be a limit on the number of channels that can be combined for a feature ID?
For example, should it be possible to define the channels = [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17] (if an image format with this many channels existed)?
Should it be possible to use the same channel multiple times in order to generate the feature ID? For example, would channels = [0,1,0,1] be allowed?
At the first glance, this looks like it could not yield sensible IDs. But as some brainstorming (even though it is a bit of a stretch): People might want to use the bits like "tags". One could create one texture object with RGBA channels, and A always being 0. Then, one could create feature IDs with channels = [0,1,2,3] yielding 0x00BBGGRR, or with channels = [0,3,3,3] yielding 0x000000RR, which could be "disassembled" by the client, to see whether the center bits are BBGG or 0000...