You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
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.
This lesson covers the image-representation strand of the AQA A-Level Computer Science (7517) Fundamentals of data representation area:
These ideas build directly on units of information (bits and bytes) and feed forward into compression, since uncompressed bitmaps are large.
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 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÷300=2 inches of paper and looks crisp; printed at 100 DPI it occupies 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 (also bit depth or bits per pixel, bpp) is the number of bits used to store the colour of each pixel. Since n bits encode 2n patterns, colour depth fixes the number of distinct colours available:
number of colours=2(colour depth in bits)
| Colour depth (bpp) | Distinct colours | Typical use |
|---|---|---|
| 1 | 21=2 | monochrome (black/white) |
| 4 | 24=16 | simple icons |
| 8 | 28=256 | indexed-colour images, greyscale |
| 24 | 224≈16.7 million | "true colour" photographs (8 bits each for R, G, B) |
| 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 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) — all three at full intensity — produces white, (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 size of an uncompressed bitmap follows directly from its definition — every pixel stores the same number of bits:
file size (bits)=width×height×colour depth
To convert to bytes, divide by 8; to larger units, divide by 1024 per step (binary prefixes).
A 32 × 32-pixel icon with a colour depth of 8 bits.
size=32×32×8=8192 bits 8192÷8=1024 bytes=1 KiB
A photograph is 1920 × 1080 pixels at 24-bit colour depth.
Step 1 — total pixels:
1920×1080=2,073,600 pixels
Step 2 — total bits (multiply by colour depth):
2,073,600×24=49,766,400 bits
Step 3 — convert to bytes (÷8):
49,766,400÷8=6,220,800 bytes
Step 4 — convert to mebibytes (÷ 220 = ÷1 048 576):
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.
Examiners often invert this. A storage budget of 2 MiB must hold an uncompressed 24-bit image — what is the maximum resolution?
2 MiB=2×220×8=16,777,216 bits pixels=2416,777,216≈699,050 pixels
A square image could therefore be at most about 699,050≈836×836 pixels. The same three relationships (size, resolution, depth) rearrange to solve for whichever quantity is unknown.
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:
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.
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 (R=255,G=128,B=0) — a vivid orange — is stored as the three bytes FF, 80, 00, which is precisely the hex colour code #FF8000. This direct correspondence is why image-editing software and web pages quote colours in hexadecimal.
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×200×24=960,000 bits (120 000 bytes). The same image as 8-bit indexed colour needs 200×200×8=320,000 bits (40 000 bytes) for the pixel indices, plus a tiny palette of 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.
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:
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.
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.
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.
Subscribe to continue reading
Get full access to this lesson and all 10 lessons in this course.