It’s been mentioned here by Stravant, but you can actually pack the data even tighter than that.
Right now, you’re selecting the largest of the 4 numbers in the quaternion, dropping it and reconstructing it using the other three since it’s normalized, which is great. But that means that since we already know the largest of the squared numbers has been subtracted, we can actually also know for sure that none of the remaining numbers will have a square larger than 1/2 (since if it was greater than 1/2, then it would be the largest number, not the number we already removed). Hence why we can actually assume all values to be between -1/sqrt(2) and 1/sqrt(2). (instead of the -1 to 1 range you currently use)
The other optimization you could make (which is probably not necessary unless you really needed to squeeze out every bit or encode a lot of data) would be to encode on the bit-level, not byte level. This way, you could encode your index in 2 bits, not 8. And, you could have more freedom to do odd bit counts like 15 for the 3 numbers, instead of sticking to multiples of 8.
If anyone’s reading this and wants to do bit-level packing, one way you could do it is to write to a table of booleans (representing your bits), and then once you’ve “encoded” all of your data, you would go through the table in 8-sized chunks and encode/decode with read/writeu8 (unsigned 8 bit). This also has the benefit that if you know the layout of your data (i.e serializing an object with known parameters) on the sending and receiving end, you can stuff a bunch of dissimilar data types back to back in one giant “bitstring” without having to waste space on padding.