We have seen how numbers, text and custom data can be encoded in binary; in this chapter we're gonna briefly go through some examples of other forms of encodings.

Colors can be encoded in pixels. A common pixel encoding is RGB.

RGB stands for Red Green Blue, which are the three main colors that are combined to represent all others.

Each one of them has an intensity, which can be stored in different ways based on the bit depth of the image; a common choice is to use one byte for each color, resulting in a pixel occupying 24 bits of memory: 8 for the intensity of red, 8 for green and 8 for blue.

Pixels are often referred to in hexadecimal form; for example, in CSS #ffffff represents the purest color white, having red, green and blue all set to maximum intensity ff (256 in hexadecimal form); and 000000 is the darkest black (having all the three colors at intensity 0).

Theoretically speaking, an image can be encoded as a simple sequence of pixels; and a video can be encoded as a simple sequence of images.

Most of the times though, we compress media to save space. A simple example of compression is RLE (run-legth encoding).

In RLE, you save space by representing repeating sequences of an element as (length + element). For example, if you have a sequence of 64 black pixels in an image, instead of using 192 bytes (3 bytes per pixel repeated 64 times) you can represent it with just 4 bytes as 40ffffff, with 40 being 64 in hexadecimal form, and ffffff indicating the color black.

The most used modern formats for images and videos (.webp, .webp, .mp4, etc.) use much more advanced compression techniques.

How are programs encoded? The instructions for x86 processors are complex and hard to parse; the ones for ARM are easier, but still well beyond the scope of this course.

A simpler example would be Java bytecode.

Java code gets translated into a .class file, that gets fed to the Java Virtual Machine to be executed.

The .class file usually starts with some bytes containing metadata: a 4-bytes "magic number" (which is the same in all Java class files), and 4 bytes that indicate the version of Java it was compiled for.

Next comes a segment containing all of the constants used in the program, and since different programs can use wildly different amounts of constants, this segment doesn't have a fixed size and it begins with 2 bytes indicating how many constants it contains. The interfaces, fields, methods and attributes of the class are also stored in analogous variable-sized segments.

If you zoom in on a specific method, the actual operations are encoded using opcodes. A Java opcode is an unsigned 8-bit integer, allowing for 256 possible opcodes, of which ~200 have been assigned a meaning as of the latest Java version. Each opcode expects a certain number of bytes as operands; for example, the opcode number 16 is bipush and it expects one byte as argument (that will push on the stack).

So when parsing the instructions, the virtual machine is supposed to

...until the end of the sequence of instructions.

This is a much simpler structure than the one used by the machine code of modern CPUs, but it's enough to encode any Java program (which includes most Android apps).

The scripting language used on the Bitcoin blockchain is also composed of opcodes, that get combined to program transactions and smart contracts.

The protocols that define how data is transferred on the net tend to have flexible binary formats, to accomodate a wide array of contents and situations.

The main protocol to transmit packets of data on the internet is ipv4. This is how an ipv4 packet is structured:

We're not gonna dive into every detail of the protocol, we'll just make a few observations.

The packet is divided into a header (metadata describing the packet and how to handle it) and a payload (the actual data being transmitted). All of the fields except the last one form the header.

The header starts with a small version field, indicating the version of the protocol we're using. In ipv4 this field is always carrying the value 4.

All of the fields in the header have a fixed size, that sum up to 20 bytes in total, except the options field, which can have a size ranging from 0 to 40 bytes (0 to 320 bits). Because of that, the header can have a size ranging from 20 to 60 bytes, and that's why it has a header length field, to communicate how big the header is. If you didn't know the exact length of the header, you might accidentally parse a piece of the payload as header, or viceversa.

The payload is also of variable size, that's why we also have a "total length of the packet" field, specifying how big the packet is in total (header + payload).

These are all things you'll find often when working with communication protocols. Data gets broken down into smaller packets with a minimum and maximum size; the packets get tagged with a header containing info about which version of the protocol we're using (leaving room for possible future revisions of the protocol, like ipv6 has improved over ipv4), various flags, specification of the length of the packet, and other types of metadata that the designers of the protocol considered useful.

Usually the expectations of the designers don't match exactly with how the protocol is actually used: for example, the options field in the ipv4 packets is almost never used in practice. This is a pattern we will see very often in the next sections of this course, as modern hardware and software are often constrained by decisions made decades ago, by people who had different expectations about what IT was going to be.