Representing Images: Bitmap and Vector

A computer screen shows a photograph, a logo, a map and a line of text, yet underneath it stores all of them as binary. There are two fundamentally different strategies for turning a picture into bits. A bitmap (raster) image records the colour of every individual point in a grid — it describes what each pixel is. A vector image instead records a list of geometric objects — lines, rectangles, curves — and their properties, describing how to draw the picture rather than storing the result. The two approaches have opposite strengths, and choosing the wrong one wastes storage or wrecks quality. This lesson develops both rigorously, with the all-important image-size calculation worked through in bits and bytes, the meaning of resolution, colour depth and metadata, and a clear-eyed comparison of when each representation wins.

---

Spec Mapping

This lesson covers the image-representation strand of the AQA A-Level Computer Science (7517) Fundamentals of data representation area:

• Bitmap (raster) images — pixels as the unit of a bitmap; resolution; colour depth / bits per pixel and the number of colours it yields; the image-size calculation in bits and bytes; the role of metadata.
• Vector graphics — images defined as a list of objects, each with properties; the drawing list; how vectors scale without loss.
• The trade-offs between bitmap and vector representation, and which suits which kind of image.

These ideas build directly on units of information (bits and bytes) and feed forward into compression, since uncompressed bitmaps are large.

---

Bitmap Images

A bitmap image divides the picture into a rectangular grid of pixels (picture elements). Each pixel is the smallest addressable element of the image and holds a single colour. To reconstruct the picture, the computer simply colours each cell of the grid according to the stored value — the image is the array of pixel colours.

flowchart TB
  A["Real image"] --> B["Divide into a grid<br/>of pixels (sampling)"]
  B --> C["Assign each pixel<br/>one colour value (quantising)"]
  C --> D["Store the grid of<br/>colour values as binary"]

Two numbers govern the quality and size of a bitmap: its resolution and its colour depth.

Resolution

Resolution is the number of pixels in the image, usually quoted as width × height (e.g. 1920 × 1080). A higher resolution means more pixels, finer detail, and — crucially — a larger file. A separate, often-confused term is pixel density, measured in dots/pixels per inch (DPI/PPI), which describes how tightly pixels are packed when the image is displayed or printed. Two images can share the same resolution (pixel count) yet differ in density: printed small they look sharp, printed large the same pixels are spread out and become visible as blocky squares. AQA's "resolution" in the size calculation always means the total pixel count (width × height), not the DPI.

The relationship between resolution and physical size is worth making concrete. An image that is 600 pixels wide, printed at 300 DPI, occupies $600 \div 300 = 2$600÷300=2 inches of paper and looks crisp; printed at 100 DPI it occupies $600 \div 100 = 6$600÷100=6 inches but the individual pixels are now three times larger and may be visible. The same file is sharp at one size and blocky at another — nothing about the data changed, only how widely its fixed number of pixels was spread. This is the fundamental reason a bitmap has no single "correct" size and why enlarging it past its native resolution degrades quality: there are only ever as many pixels as were originally captured.

Colour depth (bits per pixel)

Colour depth (also bit depth or bits per pixel, bpp) is the number of bits used to store the colour of each pixel. Since $n$n bits encode $2^n$2n patterns, colour depth fixes the number of distinct colours available:

$\text{number of colours} = 2^{\,(\text{colour depth in bits})}$number of colours=2(colour depth in bits)

Colour depth (bpp)	Distinct colours	Typical use
1	$2^1 = 2$21=2	monochrome (black/white)
4	$2^4 = 16$24=16	simple icons
8	$2^8 = 256$28=256	indexed-colour images, greyscale
24	$2^{24} \approx 16.7$224≈16.7 million	"true colour" photographs (8 bits each for R, G, B)
32	$2^{32}$232	true colour plus an 8-bit alpha (transparency) channel

The 24-bit case is worth dwelling on: it allocates 8 bits per colour channel — red, green and blue — so each channel takes one of 256 intensities, and the combinations give $256^3 = 2^{24} \approx 16.7$2563=224≈16.7 million colours, beyond what the human eye can distinguish, hence the name "true colour". A 24-bit colour is written compactly as six hexadecimal digits, two per channel: #FF8800 is full red (FF = 255), 88 green, 00 blue.

The reason red, green and blue are chosen is the additive RGB colour model used by screens: a display creates colour by emitting and combining light in these three primaries, so $(255,255,255)$(255,255,255) — all three at full intensity — produces white, $(0,0,0)$(0,0,0) produces black, and intermediate mixes produce every other colour. This contrasts with the subtractive (CMY/CMYK) model used in printing, where inks absorb light, which is why a colour that looks right on screen may need conversion before it prints correctly. For the size calculation only the number of bits per pixel matters, but understanding that those bits encode channel intensities explains why the file is exactly three bytes per pixel at 24-bit depth, and why a greyscale image — needing only one intensity value per pixel — can use a far smaller 8-bit depth.

The image-size calculation

The size of an uncompressed bitmap follows directly from its definition — every pixel stores the same number of bits:

$\text{file size (bits)} = \text{width} \times \text{height} \times \text{colour depth}$file size (bits)=width×height×colour depth

To convert to bytes, divide by 8; to larger units, divide by 1024 per step (binary prefixes).

Worked example 1 — a small icon

A 32 × 32-pixel icon with a colour depth of 8 bits.

$\text{size} = 32 \times 32 \times 8 = 8192 \text{ bits}$size=32×32×8=8192 bits $8192 \div 8 = 1024 \text{ bytes} = 1 \text{ KiB}$8192÷8=1024 bytes=1 KiB

Worked example 2 — a true-colour photograph (full method, in steps)

A photograph is 1920 × 1080 pixels at 24-bit colour depth.

Step 1 — total pixels:

$1920 \times 1080 = 2{,}073{,}600 \text{ pixels}$1920×1080=2,073,600 pixels

Step 2 — total bits (multiply by colour depth):

$2{,}073{,}600 \times 24 = 49{,}766{,}400 \text{ bits}$2,073,600×24=49,766,400 bits

Step 3 — convert to bytes (÷8):

$49{,}766{,}400 \div 8 = 6{,}220{,}800 \text{ bytes}$49,766,400÷8=6,220,800 bytes

Step 4 — convert to mebibytes (÷ $2^{20}$220 = ÷1 048 576):

$\frac{6{,}220{,}800}{1{,}048{,}576} \approx 5.93 \text{ MiB}$1,048,5766,220,800​≈5.93 MiB

So a single uncompressed Full-HD photograph is about 5.93 MiB — which is exactly why bitmap images are almost always stored compressed (JPEG, PNG), the subject of the next lesson.

Exam Tip: Lay the calculation out in labelled steps with units at every line — pixels, then bits, then bytes, then KiB/MiB. The mark scheme awards the method: width × height × depth = bits, ÷8 = bytes, ÷1024 per prefix. Watch the bit-vs-byte trap: forgetting the ÷8 inflates the answer by a factor of eight.

Working the calculation backwards

Examiners often invert this. A storage budget of 2 MiB must hold an uncompressed 24-bit image — what is the maximum resolution?

$2 \text{ MiB} = 2 \times 2^{20} \times 8 = 16{,}777{,}216 \text{ bits}$2 MiB=2×220×8=16,777,216 bits $\text{pixels} = \frac{16{,}777{,}216}{24} \approx 699{,}050 \text{ pixels}$pixels=2416,777,216​≈699,050 pixels

A square image could therefore be at most about $\sqrt{699{,}050} \approx 836 \times 836$699,050​≈836×836 pixels. The same three relationships (size, resolution, depth) rearrange to solve for whichever quantity is unknown.

Metadata

A bitmap file cannot consist of pixel data alone — the computer would not know how to interpret the stream of bits. The file must also store metadata ("data about the data"): information describing the image so it can be reconstructed and managed. Essential metadata includes:

• Width and height in pixels (so the linear stream of pixel values can be folded back into a 2-D grid).
• Colour depth (bits per pixel) and the colour model used.
• The file format / compression method, so the reader knows how to decode the pixel data.

Optional metadata commonly stored (e.g. in a photo's EXIF block) includes the date and time taken, camera make and model, exposure settings, and — a notable privacy concern — GPS coordinates of where the photo was shot. Metadata adds a small overhead to the file but is indispensable: without the width, height and colour depth the pixel data is meaningless.

How pixel data is laid out

It is worth being precise about how the grid of pixels becomes a one-dimensional stream of bytes, because this is what makes the metadata essential. The pixels are stored row by row (a process called raster scanning): the top row left-to-right, then the next row, and so on. Each pixel's colour occupies the agreed number of bits (the colour depth). To turn the flat stream back into a picture the decoder must know the width, so it can break the stream into rows of the correct length — this is exactly why width is mandatory metadata. If a 100-pixel-wide image were mistakenly read as 99 pixels wide, every row would be offset by one from the row above, producing a diagonally sheared image: the pixel data is intact, but without the correct width it cannot be reassembled.

For a 24-bit image, each pixel is three consecutive bytes — one each for red, green and blue intensity (0–255). So the first three bytes of the data are the red, green and blue values of the top-left pixel, the next three the pixel to its right, and so on. A pixel of value $(\texttt{R}=255, \texttt{G}=128, \texttt{B}=0)$(R=255,G=128,B=0) — a vivid orange — is stored as the three bytes $\texttt{FF}$FF, $\texttt{80}$80, $\texttt{00}$00, which is precisely the hex colour code #FF8000. This direct correspondence is why image-editing software and web pages quote colours in hexadecimal.

Indexed colour: a storage compromise

Storing three bytes per pixel is wasteful for images that use only a handful of distinct colours (logos, cartoons, screenshots). Indexed colour addresses this: the file stores a small colour palette (a lookup table) of, say, 256 chosen 24-bit colours, and each pixel then stores only an 8-bit index into that palette rather than a full 24-bit colour. A pixel that would have needed 24 bits now needs 8 — a threefold saving — at the cost of being limited to the 256 colours in the palette. This is how 8-bit PNG and GIF images work, and it is a neat illustration that colour depth (bits per pixel) and the number of distinct colours available need not be the same thing once a palette is involved.

Worked comparison: a 200 × 200 image stored in full 24-bit colour needs $200 \times 200 \times 24 = 960{,}000$200×200×24=960,000 bits (120 000 bytes). The same image as 8-bit indexed colour needs $200 \times 200 \times 8 = 320{,}000$200×200×8=320,000 bits (40 000 bytes) for the pixel indices, plus a tiny palette of $256 \times 24 = 6{,}144$256×24=6,144 bits — roughly a third of the size. For an image with few colours the saving is dramatic and lossless; for a photograph with millions of subtle shades, squeezing it into 256 palette colours would visibly degrade it, so full colour depth is kept.

---

Vector Graphics

A vector image takes the opposite approach. Instead of recording the colour of every pixel, it stores a list of geometric objects and the properties of each. The image is reconstructed by executing that list — drawing each object in turn — so it is sometimes called a drawing list or display list.

Each object is a primitive shape (line, rectangle, circle/ellipse, polygon, Bézier curve, or text), and each carries properties describing how to draw it. Typical properties include:

• Geometry — coordinates, radius, width/height, the control points of a curve.
• Stroke — line colour and thickness.
• Fill — interior colour or gradient.
• Layer / z-order — which object is drawn on top.

Worked example: a simple drawing list

Consider a vector image of a red-outlined blue circle and a black diagonal line. The drawing list might read:

canvas width=200 height=200

object1: type = circle
         centre = (100, 100)
         radius = 60
         stroke_colour = red
         stroke_width = 3
         fill_colour = blue

object2: type = line
         from = (20, 20)
         to   = (180, 180)
         stroke_colour = black
         stroke_width = 2

To display the image, the renderer reads each object and draws it. Notice what is — and is not — stored: there are no pixels, only a compact mathematical description. The entire image above is a few dozen bytes regardless of how large it is eventually drawn.

Why vectors scale without loss

Because the image is stored as geometry, resizing simply re-evaluates the maths at the new scale. To draw the circle twice as large, every coordinate and radius is multiplied by two and the shape is re-rendered crisply at the higher size — there are no pixels to stretch, so edges stay perfectly sharp at any magnification. This is resolution independence, and it is the defining advantage of vectors. By contrast, enlarging a bitmap must invent new pixels by interpolation (or duplicate existing ones), so it becomes blurred or blocky — pixelation.

File sizes scale with complexity, not size

A vector file's size depends on the number and complexity of objects, not on the displayed dimensions. A logo with twenty shapes is the same small file whether shown on a business card or a billboard. But a photorealistic image would need millions of tiny objects to capture every subtle tonal variation — at which point a vector file becomes vastly larger and slower than the equivalent bitmap. This is the heart of the trade-off below.

Editing: objects versus pixels