Visual walkthrough — Publication-quality figures — LaTeX labels, colormaps, DPI

We are re-deriving the central result of the parent topic from the ground up.

---

Step 1 — A figure has a physical size, measured in inches

WHAT we set first is the canvas size in inches, called figsize=(w, h). Here $w$ is the width in inches and $h$ is the height in inches.

WHY inches and not pixels? Because the paper is physical. A reviewer holds a printed page and their eye is a fixed distance away. What matters to legibility is how big the figure is on that page — and that is an inch measurement, nothing to do with pixels yet.

PICTURE — a blank rectangle labelled with its two physical side-lengths. No dots yet; just size.

---

Step 2 — A "dot" is one tiny square of the digital image

WHAT we do now is ask: along one physical inch of the figure, how many of these little squares do we lay down?

WHY ask this? Because that count is exactly what "resolution" means. Few dots per inch → big clumsy squares your eye can see individually → the picture looks blocky. Many dots per inch → squares too small to notice → smooth and sharp.

PICTURE — one inch of the width, sliced into equal little squares. Count them along the inch: that count is the thing we are about to name.

---

Step 3 — DPI is dots-per-inch: the conversion rate

WHAT the symbol $D$ is: a rate, a "how many per". Just like "60 miles per hour" tells you how far you go for each hour, "$300$ dots per inch" tells you how many squares you get for each inch.

WHY is this the right tool — why a rate and not a plain count? Because the number of dots isn't fixed until you also know how many inches you're covering. A rate lets you convert any inch-length into a dot-count by multiplying. That multiplication is the whole formula, coming in Step 4.

PICTURE — two strips of the same physical inch, one filled with $6$ fat dots ("low $D$"), one filled with $18$ tiny dots ("high $D$"). Same length, different sharpness. The accent-red strip is the sharp one.

---

Step 4 — Multiply and watch the units cancel

Now the payoff. We have inches (Step 1) and dots-per-inch (Step 3). Multiplying a length by a rate converts one unit into the other.

WHAT we compute — dots along the width:

$$\text{dots across}=\underset{\text{inches}}{\underbrace{w}}\times \underset{\text{dots}/\text{inch}}{\underbrace{D}}$$

WHY this exact multiply and not, say, adding or dividing? Because of the units. This is Dimensional analysis doing the reasoning for us:

PICTURE — the inch-arrow (black) crossing the dots-per-inch rate (red), landing on a clean "dots" result, with the little "inch" tokens visibly striking each other out.

---

Step 5 — Do it in both directions to get the full pixel grid

WHAT we do: apply Step 4 once for width, once for height, because an image is a 2-D grid.

$$\text{pixels}=\underset{\text{dots across, horizontal}}{\underbrace{(w\cdot D)}}\times \underset{\text{dots down, vertical}}{\underbrace{(h\cdot D)}}$$

WHY two multiplies? Because the picture has two independent directions and each inch-side must be converted separately. The same rate $D$ is used both times — dots are square, so the packing density is identical horizontally and vertically.

PICTURE — the full rectangle now filled with a grid; the top edge counts $w\cdot D$ squares, the left edge counts $h\cdot D$ squares, one corner cell painted red to show "one pixel".

---

Step 6 — Edge case: crank DPI, keep figsize → same size, sharper only

WHAT we test: double $D$ from $300$ to $600$, leave $w,h$ untouched.

$$(3.5\times 600)\times (2.6\times 600)=2100\times 1560\text{ px}$$

WHY show this? Because a common belief is "more DPI = bigger figure". The formula says the physical inches $w,h$ never entered the change — only the pixel count grew. On the printed page it's the same $3.5$ inches, just made of finer dots.

PICTURE — two rectangles of identical physical width side by side; left coarse grid, right (red-outlined) fine grid. Same ruler underneath both.

---

Step 7 — Edge case: shrink figsize, keep DPI → font looks bigger, image smaller

WHAT we test: halve the width to $w=1.75$ in at the same $D=300$.

$$(1.75\times 300)\times (2.6\times 300)=525\times 780\text{ px}$$

WHY this is the interesting knob: fonts are measured in points ($1$ pt $=1/72$ inch — a physical length). A $9$-pt label is always $9/72$ inch tall on paper. Shrink the canvas inches and that fixed-size label now covers a larger fraction of the figure — so text appears bigger relative to the plot. This is why figsize, not DPI, controls how prominent your labels look.

PICTURE — same $9$-pt "A" letter drawn on a wide canvas and a narrow canvas; the letter is physically identical but visually dominates the narrow (red) one.

---

Step 8 — Degenerate case: vector output, where DPI disappears

WHAT happens if we save as PDF/SVG instead of PNG?

WHY it matters: a vector format stores shapes and instructions ("draw a line from here to here"), not a grid of dots. There is no dot grid, so the term $D$ has nothing to multiply. DPI becomes irrelevant; the figure is razor-sharp at any zoom.

$$\text{raster: pixels}=(wD)(hD)\text{vector: pixels}=\text{undefined (no grid)}$$

PICTURE — left: a red curve made of blocky pixel-stairs (raster, zoomed in); right: the same red curve perfectly smooth (vector, zoomed in). The stairstep vs the smooth line is the whole distinction.

---

The one-picture summary

Everything compressed: two independent knobs feeding one grid. figsize (inches) sets how big it prints; DPI sets how many dots fill each inch; their product is the pixel count — and for vector output the DPI knob simply falls off.

Recall Feynman retelling — say it to a 12-year-old

Think of drawing on a rubber sheet. figsize is how big the rubber sheet actually is when you hold it up — measured with a real ruler, in inches. That's the size the picture will be in the book. DPI is how many tiny coloured tiles you glue onto each inch of that sheet — few big tiles look blocky like Minecraft, lots of tiny tiles look smooth. To count all the tiles you just multiply: tiles-across-one-inch times how-many-inches-wide gives tiles across, do the same going down, multiply the two — that's your total pixels, $(wD)\times (hD)$. The magic: stretching the sheet (figsize) doesn't change how fine the tiles are, and using finer tiles (DPI) doesn't stretch the sheet — two separate dials. And your text is like stickers of a fixed physical size: shrink the sheet and the same sticker suddenly looks huge on it. Finally, if instead of gluing tiles you write instructions — "draw a line from here to there" (that's a PDF) — there are no tiles at all, so the whole DPI question just vanishes and the picture is perfect at any zoom.

---

Connections

• Publication-quality figures — LaTeX labels, colormaps, DPI (parent)
• Matplotlib basics — figure and axes objects
• Dimensional analysis
• Raster vs vector graphics
• Reproducible research and rcParams
• LaTeX typesetting

Concept Map