Bit packing

Maybe not shader-specific, but here goes.

I have two 0-127 values, I want to pack them into a single 0-255 value. There should be a way to do this with bit-shifting. This is more a programmer thing, but every explanation I’ve gotten has been over my head. Wondering if anyone could explain bit packing/bit shifting a bit more :laugh: I’d like to pass this value in on a texture and unpack it in the shader. Right now I’m using an R and G channel, but half of them are unused (since the values are between 0 and 127).

(also not so good at this stuff… ) I’m not sure you can: 0-127 is 7 bits, and you’re trying to pack two 7 bit values into 0-256: an 8-bit value. I guess you could pack two 4-bit values (2^4 = 16) in there.

If your values are between 0-127, you can pack in one more bit, not much use I guess!

I’m not sure how real bit math works, but for me I always just subtract the largest power of two, and work my way down. So if it’s > 128, the highest bit is 1. Subtract 128, repeat for 64, then 32 etc. That will generate the bit field like 10111011. Rebuild that in your range to get the values you want. I’m sure a programmer just does something with lots of >> and <<'s :slight_smile:

After consultation with two programmers and an engineer (hey, it was a slow day!), it appears it can’t be done mainly for the reasons Cody mentions. Two lots of 7-Bit numbers can’t be represented inside a single 8-Bit number.

If it were a much larger bit range, i’d say try binary run length encoding, but for such small values it seems unlikely to be functional (you’d end up with larger values than you started with!)

Are you needing to use the G and B values for other information, or do you just not want to waste those extra bits?

I’m not that clued up on other bitwise methods.

Yeah, after reading some Python stuff last night, I realized I can only probably pack 2 4 bits into an 8-bit (wow!), which means 16 values, not 128. Darn.

I wanted to try to put everything in one channel since I’m only currently using half of each (well actually, all of red and 1/4 of green, but I can make it half of each), mostly because these textures need to be uncompressed, wanted to reduce texture space. Alrighty, will need to figure out another plan to compress what I’m doing…

I came across Tom Forsyth’s blog again yesterday, and he had an interesting post about packing bits.
"]http://home.comcast.net/~tom_forsyth/blog.wiki.html](http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Texture formats for faster compression)

I vaguely recall another thread about people using luminance/chrominance space for compression, was that around here somewhere?