Image Representation

Every photograph, screenshot, icon and diagram on a computer is ultimately a pattern of bits. This lesson explains how bitmap (raster) images are built from pixels, how resolution and colour depth govern both quality and file size, how to calculate that file size from first principles, the role of metadata, and why vector graphics are a fundamentally different — and sometimes far better — way to describe an image.

Spec Mapping

This lesson addresses the H446 1.4.1 Data Types content on representing images:

Describe how a bitmap image is composed of pixels arranged in a grid, and define resolution as the pixel dimensions of that grid.
Explain colour depth as the number of bits used per pixel, and relate it to the number of representable colours ( $2^{n}$ ).
Calculate the storage requirement of a bitmap image from its dimensions and colour depth, and account for metadata.
Explain the purpose of image metadata.
Compare bitmap (raster) and vector representations, including how each behaves when scaled.

(This is a paraphrase of the specification content, not a verbatim quotation.)

Bitmap (Raster) Images

A bitmap — more precisely a raster image — is a rectangular grid of tiny coloured squares called pixels (a contraction of picture elements). Each pixel holds a single colour value, and from a normal viewing distance the eye blends the grid into a continuous picture. The whole representation is therefore just a long list of colour numbers, read row by row, plus enough information to know how wide each row is.

Term	Definition
Pixel	The smallest individually addressable element of a bitmap; holds exactly one colour value
Resolution	The dimensions of the pixel grid, written width $\times$ height (e.g. $1920 \times 1080$ )
Colour depth	The number of bits used to store each pixel's colour (also called bit depth)
Metadata	Data about the image — dimensions, colour depth, format, and more — stored in the file alongside the pixels

The crucial mental model is that a bitmap stores colour per pixel explicitly: there is no shortcut for "a large red rectangle" — every pixel inside it is recorded separately. That is exactly why bitmaps cope brilliantly with the irregular detail of photographs (where almost every pixel genuinely differs) and badly with large flat areas (where the same value is repeated thousands of times — the redundancy that compression later exploits).

Resolution

Resolution is the number of pixels making up the image, normally given as its width and height in pixels. The same word is sometimes used for pixel density — pixels per inch (PPI) for a display, or dots per inch (DPI) for a printer — which describes how tightly those pixels are packed onto a physical surface. For file-size work, what matters is the total pixel count:

$\text{total pixels} = \text{width} \times \text{height}$

So a $1920 \times 1080$ ("Full HD") image contains $1920 \times 1080 = 2{,}073{,}600$ pixels — roughly 2 megapixels.

Aspect	Higher resolution	Lower resolution
Detail	Sharper, finer detail	Blurred, blocky (pixelation)
File size	Larger	Smaller
Rendering cost	More pixels to process and draw	Fewer pixels

Resolution and density interact: a $2000 \times 3000$ photo printed at 300 DPI fills a crisp $6.7 \times 10$ inch print, but stretched to a billboard the same pixels spread so thinly that each becomes visible — the image is pixelated. The number of pixels did not change; the area each pixel must cover did. This is the root cause of the scaling weakness compared later with vector graphics.

Worked example — megapixels and print size. A camera advertised as "12 megapixel" produces images of roughly $4000 \times 3000$ pixels, since $4000 \times 3000 = 12{,}000{,}000$ . Printed at a photographic 300 DPI, the printable size is $4000 \div 300 \approx 13.3$ inches by $3000 \div 300 = 10$ inches — a sharp A4-ish print. Print the same file as a $40 \times 30$ inch poster and the effective density falls to $4000 \div 40 = 100$ DPI, so individual pixels begin to show. The pixel count is fixed at capture; enlarging only spreads those pixels over more area, which is precisely why "more megapixels" buys you bigger sharp prints rather than better small ones.

Colour Depth

Colour depth (bit depth) is the number of bits used to record each pixel's colour. Because each bit doubles the number of distinct patterns, the colours available follow the same power-of-two relationship met throughout this unit:

$\text{number of colours} = 2^{\,d} \quad\text{for a colour depth of } d \text{ bits}$

Colour depth	Colours $=2^{d}$	Typical use
1 bit	$2^{1}=2$	Pure black-and-white (e.g. fax)
4 bits	$2^{4}=16$	Early VGA palettes
8 bits	$2^{8}=256$	Indexed-colour GIF / simple graphics
16 bits	$2^{16}=65{,}536$	"High colour"
24 bits	$2^{24}=16{,}777{,}216$	"True colour" — 8 bits each for R, G, B
32 bits	$2^{32}\approx 4.3\text{ billion}$	True colour plus an 8-bit alpha (transparency) channel

The RGB colour model

In the RGB model a pixel's colour is the combination of three light channels — red, green and blue — each commonly stored in 8 bits (a value $0$ – $255$ ). The three channels together give $8+8+8 = 24$ bits per pixel, the "true colour" standard:

$2^{8}\times 2^{8}\times 2^{8} = 2^{24} = 16{,}777{,}216 \text{ colours}$

Colour	R	G	B	Hex
Red	255	0	0	#FF0000
Green	0	255	0	#00FF00
Blue	0	0	255	#0000FF
White	255	255	255	#FFFFFF
Black	0	0	0	#000000
Yellow	255	255	0	#FFFF00

The hexadecimal form (covered in number-systems) is simply the three byte values written in base 16 — #FF0000 is $R=255, G=0, B=0$ . A 32-bit pixel adds a fourth byte, alpha, recording how opaque the pixel is ( $0$ fully transparent, $255$ fully opaque), which is how PNGs achieve soft, anti-aliased edges over a web page.

A subtle but examinable point: increasing colour depth removes banding. With only a handful of bits, a smooth sky must be approximated by a few discrete shades, producing visible steps; 24-bit depth supplies enough intermediate shades that the gradient looks continuous.

How many bits do you need for N colours?

The $2^{d}$ rule runs in both directions, and the reverse direction is examined just as often as the forward one. Given a required number of distinct colours $N$ , the colour depth $d$ is the smallest number of bits with $2^{d} \geq N$ :

$d = \lceil \log_2 N \rceil$

You almost never need logarithms in the exam — you simply find the smallest power of two that is at least $N$ . Crucially, you must always round up: a depth must be a whole number of bits, and any depth that gives fewer patterns than $N$ cannot represent every colour.

Colours needed $N$	Smallest power of two $\geq N$	Bits $d$
2	$2^{1}=2$	1
5	$2^{3}=8$	3
16	$2^{4}=16$	4
100	$2^{7}=128$	7
256	$2^{8}=256$	8
1000	$2^{10}=1024$	10

Worked example. A simple flag-design tool must support exactly 40 distinct colours. How many bits per pixel are required? Test the powers of two: $2^{5}=32$ is too few (it represents only 32 colours, fewer than 40), but $2^{6}=64 \geq 40$ is enough. So the minimum colour depth is $d=6$ bits per pixel. A student who answered $5$ has made the classic error of taking the nearest power rather than the smallest power that is large enough.

Worked example — the other way. A 5-bit palette is offered. How many colours can it hold? $2^{5}=32$ . If a designer needs 40 colours, 5 bits is insufficient and the depth must rise to 6.

Calculating Bitmap File Size

The raw pixel data of a bitmap is exactly:

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

then convert to bytes and larger units:

$\text{bytes} = \frac{\text{bits}}{8}, \qquad \text{KB} = \frac{\text{bytes}}{1024}, \qquad \text{MB} = \frac{\text{KB}}{1024}$

Worked Example — a true-colour photograph

An image is $800 \times 600$ pixels with a colour depth of 24 bits.

$\text{bits} = 800 \times 600 \times 24 = 11{,}520{,}000 \text{ bits}$

$\text{bytes} = \frac{11{,}520{,}000}{8} = 1{,}440{,}000 \text{ bytes}$

$\text{KB} = \frac{1{,}440{,}000}{1024} = 1406.25 \text{ KB}$

$\text{MB} = \frac{1406.25}{1024} \approx 1.37 \text{ MB}$

This is the uncompressed pixel data only; the real file is slightly larger because of metadata and may be much smaller after compression.

Worked Example — including metadata

Suppose the same $800 \times 600$ , 24-bit image is stored in a format with a 54-byte header plus a 100-byte block of EXIF metadata. The total becomes:

$1{,}440{,}000 + 54 + 100 = 1{,}440{,}154 \text{ bytes}$

The metadata is a tiny fraction here, but in a small icon it can dominate — which is why "file size" questions sometimes ask you to add a stated header size.

Worked Example — effect of colour depth

Holding the $800 \times 600$ resolution fixed and varying only the depth:

Colour depth	Calculation (bytes)	File size
1 bit	$800 \times 600 \times 1 \div 8$	$60{,}000$ B $\approx 58.6$ KB
8 bits	$800 \times 600 \times 8 \div 8$	$480{,}000$ B $\approx 468.75$ KB
24 bits	$800 \times 600 \times 24 \div 8$	$1{,}440{,}000$ B $\approx 1406.25$ KB

File size scales linearly with colour depth: tripling the depth from 8 to 24 bits triples the size. It also scales with the product of width and height, so doubling both dimensions quadruples the pixel count and therefore the size — a result students routinely get wrong by only doubling.

Worked Example — effect of resolution at fixed depth

Now hold the depth at 24 bits and vary the resolution. Notice how the size tracks the pixel count, not either dimension alone:

Resolution	Pixels	Bits $=$ pixels $\times 24$	Bytes	Size
$100 \times 100$	$10{,}000$	$240{,}000$	$30{,}000$	$\approx 29.3$ KB
$200 \times 200$	$40{,}000$	$960{,}000$	$120{,}000$	$\approx 117.2$ KB
$400 \times 400$	$160{,}000$	$3{,}840{,}000$	$480{,}000$	$\approx 468.8$ KB

Each step doubles both dimensions, and each step quadruples the size (29.3 → 117.2 → 468.8). This is the single most common file-size trap: "doubling the resolution" doubles each side, so the area — and the file — grows by a factor of four, not two.

Worked Example — a thumbnail where metadata dominates

Take a tiny $16 \times 16$ icon at 24-bit depth, stored in a format with a 54-byte header and a 100-byte metadata block:

$\text{pixel bits} = 16 \times 16 \times 24 = 6{,}144 \text{ bits}$

$\text{pixel bytes} = \frac{6{,}144}{8} = 768 \text{ bytes}$

$\text{total} = 768 + 54 + 100 = 922 \text{ bytes}$

Here the 154 bytes of metadata are 17% of the file — far from negligible. Contrast this with the earlier $800 \times 600$ photo, where the same 154 bytes were about one-hundredth of one percent. The lesson: header/metadata overhead is irrelevant for large images but can dominate small ones, so always add a stated header size when the question gives one.

Worked Example — greyscale vs colour

A $640 \times 480$ image can be stored in 8-bit greyscale (256 shades of grey, one byte per pixel) or in 24-bit colour:

$\text{greyscale} = 640 \times 480 \times 8 \div 8 = 307{,}200 \text{ bytes} \approx 300 \text{ KB}$

$\text{colour} = 640 \times 480 \times 24 \div 8 = 921{,}600 \text{ bytes} \approx 900 \text{ KB}$

The colour version is exactly three times larger, because it stores three 8-bit channels (R, G, B) per pixel instead of one. This is the cleanest demonstration that file size is linear in colour depth.

Metadata

A bitmap file is not pixels alone: it begins with metadata describing how to interpret those pixels. Without the width, for instance, the decoder would not know where each row of pixels ends.

Metadata field	Purpose
Width and height	Dimensions of the pixel grid — needed to reconstruct rows
Colour depth	Bits per pixel — needed to read each colour value correctly
Colour space	RGB, CMYK, greyscale, indexed palette
Compression flag	Which algorithm (if any) was applied
Creation date	When the file was produced
EXIF data	Camera make/model, aperture, shutter speed, ISO, GPS location

Two points are commonly examined. First, metadata is essential, not optional: the dimensions and colour depth are exactly what the file-size formula needs, so the file must carry them. Second, EXIF metadata raises a privacy issue — photos shared online may silently embed GPS coordinates, revealing where they were taken.

Vector Graphics

A vector image takes the opposite approach to a bitmap: instead of recording every pixel, it stores a list of geometric objects described mathematically — lines, curves, rectangles, circles and paths — each with properties such as position, size and colour. The image is then drawn (rasterised) on demand at whatever size is required.

Each object is stored as a small set of attributes:

Attribute	Example
Object type	line, rectangle, circle, polygon, Bezier path
Position	x, y coordinates of key points
Size	width, height, radius
Fill / stroke colour	the interior colour and the outline colour
Stroke width / style	line thickness, dashing
Transformations	rotation, scaling, skew

For example, a red circle with a black outline might be stored as just six numbers and two colours:

Attribute	Value
Type	circle
Centre	$(200, 150)$
Radius	$50$
Fill	#FF0000
Stroke	#000000
Stroke width	$2$

Image Representation

Image Representation

Spec Mapping

Bitmap (Raster) Images

Resolution

Colour Depth

The RGB colour model

How many bits do you need for N colours?

Calculating Bitmap File Size

Worked Example — a true-colour photograph

Worked Example — including metadata

Worked Example — effect of colour depth

Worked Example — effect of resolution at fixed depth

Worked Example — a thumbnail where metadata dominates

Worked Example — greyscale vs colour

Metadata

Vector Graphics

More in Computer Science