In the specification, it states that custom color tables are "defined undefined", and that it's the implementation's job to handle it. While this absolutely would work for certain applications, it could get quite complex to sort out different custom color tables that could be implemented in vastly different ways.
I think a simple solution that's easy to implement can be done like so: custom color tables should be defined as a 4 byte ID appended to the TVG file, immediately followed by the size of the table (u32?), and then the table itself. This way, we have a standard way of defining custom color tables that an implementation could easily check support for without making TVG itself any more complex.
Depending on how the implementation handles it, this could even be used for things like named colors while keeping files compatible with implementations that don't support it. Say we define a custom color table that uses 16 named colors. We can make a TVG with approximations for those colors in a standard table (like RGBA8888), then the palette at the end of the file. If the implementation doesn't understand named colors, it would simply use the RGB(A) values, but if it did, then a color palette could be applied.
In the specification, it states that custom color tables are "defined undefined", and that it's the implementation's job to handle it. While this absolutely would work for certain applications, it could get quite complex to sort out different custom color tables that could be implemented in vastly different ways.
I think a simple solution that's easy to implement can be done like so: custom color tables should be defined as a 4 byte ID appended to the TVG file, immediately followed by the size of the table (u32?), and then the table itself. This way, we have a standard way of defining custom color tables that an implementation could easily check support for without making TVG itself any more complex.
Depending on how the implementation handles it, this could even be used for things like named colors while keeping files compatible with implementations that don't support it. Say we define a custom color table that uses 16 named colors. We can make a TVG with approximations for those colors in a standard table (like RGBA8888), then the palette at the end of the file. If the implementation doesn't understand named colors, it would simply use the RGB(A) values, but if it did, then a color palette could be applied.