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

5.4.19 · D2 · Coding › Scientific Computing (Python) › Publication-quality figures — LaTeX labels, colormaps, DPI

Hum parent topic ka central result ground up se re-derive kar rahe hain.

---

Step 1 — Ek figure ka ek physical size hota hai, inches mein measure hota hai

KYA hum pehle set karte hain woh hai canvas size in inches, jise figsize=(w, h) kehte hain. Yahan $w$ width hai inches mein aur $h$ height hai inches mein.

KYUN inches aur pixels nahi? Kyunki paper physical hai. Ek reviewer printed page haath mein leta hai aur unki aankhein ek fixed distance par hoti hain. Legibility ke liye jo matter karta hai woh hai figure page par kitna bada hai — aur woh ek inch measurement hai, abhi pixels se koi lena-dena nahi.

PICTURE — ek blank rectangle jis par uske do physical side-lengths likhe hain. Abhi koi dots nahi; sirf size.

---

Step 2 — Ek "dot" digital image ka ek chota sa square hota hai

KYA hum ab poochhte hain: figure ke ek physical inch ke along, hum kitne chhote squares bichhaate hain?

KYUN yeh poochhen? Kyunki woh count exactly wahi hai jiska matlab "resolution" hota hai. Kam dots per inch → bade clumsy squares jo aankhein individually dekh sakti hain → picture blocky lagti hai. Zyada dots per inch → squares itne chhhote ki notice nahi hote → smooth aur sharp.

PICTURE — width ka ek inch, equal chhote squares mein kata hua. Inch ke along unhe gino: woh count hi woh cheez hai jise hum abhi naam dene wale hain.

---

Step 3 — DPI hai dots-per-inch: conversion rate

KYA symbol $D$ hai: ek rate, ek "per mein kitne". Bilkul jaise "60 miles per hour" batata hai har ghante mein kitna door jaate ho, "$300$ dots per inch" batata hai har inch mein kitne squares milte hain.

KYUN yeh sahi tool hai — kyun ek plain count nahi, rate kyun? Kyunki dots ki count tab tak fixed nahi hoti jab tak yeh bhi na pata ho ki kitne inches cover ho rahe hain. Ek rate tumhein kisi bhi inch-length ko dot-count mein convert karne ki suvidha deta hai multiply karke. Wahi multiplication poora formula hai, Step 4 mein aata hai.

PICTURE — usi physical inch ki do strips, ek mein $6$ mote dots ("low $D$"), ek mein $18$ chhote dots ("high $D$"). Same length, different sharpness. Accent-red strip sharp wali hai.

---

Step 4 — Multiply karo aur units ko cancel hote dekho

Ab payoff. Hamare paas inches hain (Step 1) aur dots-per-inch hain (Step 3). Ek length ko ek rate se multiply karna ek unit ko doosre mein convert karta hai.

KYA hum compute karte hain — width ke along dots:

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

KYUN exactly yahi multiply, aur add ya divide kyun nahi? Units ki wajah se. Yeh Dimensional analysis hai jo hamare liye reasoning kar raha hai:

PICTURE — inch-arrow (black) dots-per-inch rate (red) ko cross kar raha hai, clean "dots" result par land kar raha hai, aur chhhote "inch" tokens visibly ek doosre ko strike out karte dikh rahe hain.

---

Step 5 — Full pixel grid paane ke liye dono directions mein karo

KYA hum karte hain: Step 4 ko ek baar width ke liye apply karo, ek baar height ke liye, kyunki image ek 2-D grid hai.

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

KYUN do multiply? Kyunki picture ki do independent directions hain aur har inch-side ko alag se convert karna hoga. Wahi rate $D$ dono baar use hota hai — dots square hote hain, isliye horizontal aur vertical dono mein packing density identical hai.

PICTURE — poora rectangle ab grid se bhara hua; top edge $w\cdot D$ squares count karta hai, left edge $h\cdot D$ squares count karta hai, ek corner cell red paint kiya hua dikhata hai "ek pixel".

---

Step 6 — Edge case: DPI badhaao, figsize rakho → same size, sirf sharper

KYA hum test karte hain: $D$ ko $300$ se $600$ par double karo, $w,h$ untouched rakho.

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

KYUN yeh dikhayein? Kyunki ek common belief hai "zyada DPI = bada figure". Formula kehta hai physical inches $w,h$ change mein kabhi enter hi nahi hue — sirf pixel count bada. Printed page par woh same $3.5$ inches hai, bas barik dots se bana hua.

PICTURE — identical physical width ke do rectangles side by side; left coarse grid, right (red-outlined) fine grid. Dono ke neeche same ruler.

---

Step 7 — Edge case: figsize shrink karo, DPI rakho → font bada lagta hai, image chhoti

KYA hum test karte hain: width ko half karke $w=1.75$ in karo same $D=300$ par.

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

KYUN yeh interesting knob hai: fonts points mein measure hote hain ($1$ pt $=1/72$ inch — ek physical length). Ek $9$-pt label paper par hamesha $9/72$ inch tall hota hai. Canvas inches shrink karo to woh fixed-size label figure ka bada fraction cover karta hai — isliye text relatively plot se bada lagta hai. Isliye figsize, DPI nahi, control karta hai ki tumhare labels kitne prominent dikhte hain.

PICTURE — same $9$-pt "A" letter ek wide canvas aur ek narrow canvas par drawn; letter physically identical hai lekin narrow (red) wale par visually dominate karta hai.

---

Step 8 — Degenerate case: vector output, jahan DPI gayab ho jaata hai

KYA hota hai agar hum PNG ki jagah PDF/SVG mein save karein?

KYUN yeh matter karta hai: ek vector format dots ka grid nahi, shapes aur instructions store karta hai ("yahan se wahan tak ek line draw karo"). Koi dot grid nahi hai, isliye term $D$ ke paas multiply karne ko kuch nahi. DPI irrelevant ho jaata hai; figure har zoom par razor-sharp hota hai.

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

PICTURE — left: blocky pixel-stairs se bana ek red curve (raster, zoomed in); right: wahi red curve perfectly smooth (vector, zoomed in). Stairstep vs smooth line — yahi poora distinction hai.

---

Ek-picture summary

Sab kuch compressed: do independent knobs ek grid ko feed kar rahe hain. figsize (inches) set karta hai yeh print par kitna bada hoga; DPI set karta hai har inch mein kitne dots fill honge; unka product pixel count hai — aur vector output ke liye DPI knob simply fall off ho jaata hai.

Recall Feynman retelling — ek 12-saal ke bacche ko samjhao

Socho ek rubber sheet par drawing kar rahe ho. figsize hai rubber sheet actually kitni badi hai jab tum use hold karo — real ruler se measure karke, inches mein. Woh size hai jo picture book mein hogi. DPI hai har inch par kitne chhote coloured tiles tum chipkaate ho — kam bade tiles Minecraft jaisa blocky lagta hai, bahut saare chhote tiles smooth lagta hai. Saare tiles count karne ke liye bas multiply karo: tiles-across-one-inch times how-many-inches-wide gives tiles across, same neeche ke liye karo, dono multiply karo — wahi tumhare total pixels hain, $(wD)\times (hD)$. Magic yeh hai: sheet stretch karna (figsize) tiles ki fineness nahi badlata, aur barik tiles use karna (DPI) sheet stretch nahi karta — do alag dials. Aur tumhara text fixed physical size ke stickers jaisa hai: sheet shrink karo aur wahi sticker achanak us par huge lagta hai. Finally, agar tiles chipkane ki jagah tum instructions likhte ho — "yahan se wahan tak line draw karo" (woh PDF hai) — to koi tiles hi nahi hain, isliye poora DPI ka sawaal gayab ho jaata hai aur picture har zoom par perfect hai.

---

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