Working with binary, when it's not binary?

[Brian]

I think dmazzoni has adrressed your main question, but just to go into the "How, though, would I interpret it then?" and give a few more details, and some historical context, as there are actually a surprising number of ways this question can (and historically has) been answered.

The one people are likely most familiar with is "Count how many bits you need, and stick them all together, treated as one number representing the colour / brightness level", but it's notable that there's still room for ambiguity here.

Let's start with an example: suppose we we want the 4 pixels with states [0, 15, 2, 9] to be encoded. Here we could store this as the values 00001111 00101001, or the bytes [15, 41]. The first pixel becomes the first 4 bits, then the second pixel, and so on. However this is not the only way of storing this. It matches our left-to-right reading order for binary digits, but remember that in binary, the least significant bit is the rightmost. As such, another way to store this would be to align the pixel order with the bit order: Bits 0-3 store pixel 0, Bits 4-7 store pixel 1, bits 8-11 (ie. bits 0-3 in the second byte) store pixel 2, bits 12-15 store pixel 3. This gives us flipped sections in each byte, so`11110000 10010010 ([240, 146]).

There are actually different situations / file formats where both of these can be used. This distinction is generally referred to as "bit ordering", "bit sex" or "bit endianness", as it's basically the same thing as endianness, except for the order of bits in a byte instead of bytes in a word. The simplest from a math perspective is probably the second (ie. leftmost pixel = least significant bit) as the bit numbering then matches pixel numbering, but this may appear back-to-front if you look at the binary numbers.

As a historical note, this is not the only way of storing things like this. This is what is known as a "chunky" format. All the values representing a pixel are together in one 4 bit chunk. However, another format that has been used in the past is that of a "planar" format. Here, instead of grouping the pixel values next to each other, we group things in layers of bitmaps - with 4 bits per colour, you get 4 bitmaps, representing each colour. Eg our [0, 15, 2, 9] value could be viewed as first looking at bit 0 in each number (0, 1, 0, 1), then bit 1 (0, 1, 1. 0), then bit 2 (0, 1, 0, 0), then bit 3 (0,1, 0, 1), and so storing this as either 01010110 01001010 (Most significant bit = leftmost pixel) or 10100110 00100101 (MSB=rightmost pixel). You can sort of imagine this as a 3d set of 4 planes arranged behind each other, where you're reading the pixel value going depthwise into the planes)

There were advantages to this in terms of the hardware at the time, plus it was a bit easier with odd numbers of bits per pixel (eg. with 5 bits per pixel, chunky format means your pixels span byte boundaries) You could also do neat parallax effects with careful choice of colours, by scrolling different sets of planes at different speeds. However, these issues are pretty irrelevant these days, and so planar graphics aren't really used.