Publication-quality figures — LaTeX labels, colormaps, DPI: Question bank

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

True or false — justify

dpi ko 300 se 600 karna printed page par text ko physically bada bana deta hai.

False. DPI sirf itna change karta hai ki kitne pixels usi inch canvas mein fill honge — sharper hoga, bada nahi. Physical text size figsize (inches) aur font size (points, 1 pt = 1/72 in) se fix hoti hai, jise DPI kabhi touch nahi karta.

Ek vector PDF ka "infinite DPI" hota hai.

True in spirit. PDF shapes (lines, glyph outlines) store karta hai, pixels nahi, isliye koi pixel grid nahi hoti jo blocky dikhe — ye kisi bhi zoom par sharp re-render hoti hai. "Infinite DPI" ka matlab hai "resolution-independent".

viridis ek achha default hai kyunki iske paas bahut saare bright, vivid colors hain.

False — ye reasoning jet ko describe karti hai. viridis isliye achha hai kyunki iska brightness monotonically badhta hai (perceptually uniform), isliye ye grayscale mein aur colorblind readers ke liye bhi honest rehta hai. Vividness goal nahi hai; monotonic brightness hai.

Ek dense photographic heatmap ko PDF ke roop mein save karna sabse sharp choice hai.

False. Ek PDF mein laakhon chhote rectangles embed ho jaate → badi file, kholne mein slow, aur sharp bhi nahi. Vector sirf line art ke liye jeetता hai; dense raster data high DPI par PNG/TIFF mein hona chahiye.

figsize=(3.5, 2.6) set karna guarantee karta hai ki saved image khulne par 3.5 inches wide hogi.

Half true. Ye intended physical size fix karta hai, lekin savefig.bbox="tight" margins trim karta hai aur actual inch dimensions ko shrink kar sakta hai. 3.5 in ek target hai, trimming on hone par locked output width nahi.

text.usetex=True aur mathtext identical-looking output produce karte hain.

False. mathtext matplotlib ka built-in TeX-jaisa engine hai; usetex=True ek real LaTeX install ko call karta hai taaki fonts (jaise Computer Modern) tumhare paper se exactly match karein. Math renders similarly hoti hai lekin fonts aur spacing alag hote hain.

String "$\alpha$" (koi r prefix nahi) safe hai jab tak usmein valid LaTeX command ho.

False. Python escapes ko pehle parse karta hai LaTeX ke string dekhne se pehle: \a ek bell character ban jaata hai, \n ek newline. Valid LaTeX se kuch nahi hoga — corruption Python mein pehle hi ho jaata hai.

Colorbar optional decoration hai jo space bachane ke liye drop ki ja sakti hai.

False. Colorbar hi color ki axis hai — iske bina, color se number tak ki mapping unknown hai aur plot unreadable hai. Ye meaning carry karta hai, decoration nahi.

Fixed DPI par dono figsize dimensions ko double karne se pixel count chaar guna ho jaata hai.

True. Pixels

= (w \cdot D) \times (h \cdot D)

;

w

aur

h

ko double karna har factor ko 2 se multiply karta hai, toh area

\times 4

. (Text bhi physical size mein double ho jaata hai, jo usually nahi chahiye hota.)

coolwarm hamesha viridis se safer choice hai.

False. coolwarm diverging hai — ye ek meaningful center assume karta hai. Plain low→high data par jahan koi special middle nahi hai, ye ek fake "neutral zone" banata hai aur mislead karta hai. Apne data ke hisaab se colormap type match karo, "safety" ke hisaab se nahi.

Spot the error

fig.savefig("f.png"); fig, ax = plt.subplots(figsize=(3.5,2.6)) — order theek lagti hai?

Error: tumne figure create aur draw karne se pehle save kar liya. figsize ko subplots ke time par set karna zaroori hai, aur savefig saari plotting ke baad aana chahiye. Order ulta hai.

ax.set_xlabel("$\lambda$ (nm)") — kya galat hai?

==raw-string r== missing hai. Python \l ko ek mangled escape sequence mein badal deta hai LaTeX run hone se pehle. Fix: r"$\lambda$ (nm)".

ax.set_title(r"E = mc^2") mein mc^2 plain text ke roop mein literal caret ke saath render hota hai — kyun?

Koi == $...$ == math delimiters nahi hain. Dollar signs ke bahar sab kuch upright text hai aur ^ ek literal character hai. Fix: r"$E = mc^2$".

plt.rcParams["savefig.dpi"] = 600 but printed 3.5-in column figure ka text unreadably tiny hai. Real bug kahan hai?

DPI problem nahi tha — ==figsize default 6.4 in par chhodi gayi thi==. 3.5 in column par ye ~45% shrink hoti hai, 9 pt font ko ~5 pt tak le jaati hai. Pehle figsize=(3.5, 2.6) set karo.

im = ax.imshow(Z, cmap="jet"); fig.colorbar(im) — colorbar present hai, toh kya ye theek hai?

Nahi. jet ki non-monotonic brightness ek labeled colorbar ke hote hue bhi deceptive hai — mid-scale ek bright band ek peak ki tarah read hoti hai jo wahan hai hi nahi. Ek sahi colorbar ek dishonest colormap ko fix nahi kar sakta. viridis use karo.

ax.imshow(Z) bina origin="lower" ke jab data mein row 0 sabse chhota y hai.

Error: imshow default origin="upper" hai, jo tumhara data top-to-bottom flip kar deta hai taaki low y upar dikhe. origin="lower" add karo taaki axis data ki orientation se match kare.

Why questions

Font sizes points mein kyun measure hote hain, pixels mein kyun nahi?

Points (1/72 in) physical inches se tied hain, isliye ek 9 pt label paper par print hone par apna real size rakhe ga chahe DPI kuch bhi ho. Pixels apparent size badal dete jab bhi DPI change hota.

Journal column match karte waqt font sizes se pehle figsize kyun choose karna padta hai?

Kyunki font size points-per-inch mein fixed hai; inch canvas (figsize) ye determine karta hai ki woh points page par kitne bade dikhte hain. Pehle canvas set karo, phir fonts sahi physical scale par baith jaate hain.

[inches] \times [dots/inch]

ka dimensional analysis pixels kyun deta hai?

Numerator mein "inch" denominator ke "inch" ko cancel kar deta hai, sirf pure dots (= pixels) baar jaate hain. Ye prove karta hai ki DPI aur figsize coupled factors hain, independent knobs nahi. Dekho Dimensional analysis.

Ye knobs per-plot arguments ki jagah rcParams ke through set karna kyun prefer karte hain?

rcParams unhe ek baar globally set karta hai taaki project ki har figure consistent ho aur styling ek single block se reproducible ho — ye Reproducible research and rcParams ka dil hai.

Grayscale printing ek buri colormap ko kyun expose karta hai jo color mein theek lagti hai?

Grayscale sab kuch sirf brightness par collapse kar deta hai. viridis jaisi perceptually uniform map sahi rank karti rehti hai; jet ki non-monotonic brightness do alag values ko same gray print karti hai, information mita deti hai.

Strictly positive data par ek diverging colormap kyun mislead kar sakta hai?

Iska neutral midpoint ek "zero/baseline" imply karta hai jo data mein hai hi nahi, isliye tumhari aankhein ek meaningless split ko significant padhti hain. Diverging maps ek real center assume karte hain. Dekho Colormaps and color theory in visualization.

savefig.bbox="tight" convenient kyun hai lekin exact sizing ke liye ek subtle trap?

Ye whitespace trim karta hai, isliye saved image declared figsize se thodi chhoti hoti hai. Margins ke liye convenient, lekin matlab hai ki output inches figsize ke exactly equal nahi rahi.

Edge cases

Tumhe ek talk slide ke liye figure chahiye, journal nahi. Kya 300-dpi rule abhi bhi apply hota hai?

Zarroori nahi — screens ~96–150 dpi hote hain aur slides bade dekhe jaate hain, isliye bada figsize aur bade fonts 300 dpi se zyada matter karte hain. Principle (pehle physical size fix karo) valid hai; exact number nahi.

Tumhare data mein exactly ek meaningful value hai (sab constant). Kaun si colormap?

Koi bhi type help nahi karega — ek single value ek color mein map hoti hai, isliye colorbar ek flat band hai. "Trap" ye expect karna hai ki ek colormap woh structure reveal karega jo data mein hai hi nahi.

Ek journal EPS maangta hai lekin tumhari figure mein semi-transparent overlay hai. Kya toot jaata hai?

EPS (ek vector format) ka transparency support poor/nahi ke barabar hai, isliye alpha blending flat ya drop ho sakta hai. Ye ek raster-vs-vector edge hai: transparency-heavy figures ko often PDF ya high-DPI PNG chahiye hota hai. Dekho Raster vs vector graphics.

text.usetex=True ek aisi machine par jahan koi LaTeX installed nahi — kya hoga?

Rendering fail hogi ek error ke saath, silent fallback nahi hogi. usetex ko ek real external LaTeX toolchain chahiye; iske bina, default mathtext engine use karo.

Tumne figsize centimeters mein habit se set ki: figsize=(9, 6.6). Kya galat ho jaata hai?

matplotlib hamesha figsize ko inches mein interpret karta hai, isliye ek "9 cm" figure ek 9-inch monster (~23 cm) ban jaati hai. Convert karo: pehle cm ko 2.54 se divide karo.

Data range 0 se 1 hai lekin almost saari values 0 ke paas cluster hain. Kya viridis abhi bhi honestly read hota hai?

Colormap perceptually uniform rehta hai, lekin ek linear scale khaali high-end par zyadatar colors waste karta hai. Honesty ka masla ab scale hai (log/normalization consider karo), colormap choice nahi.

Recall Ek-line self-test

Agar tum bina hesitate kiye "kya DPI physical size change karta hai?" (nahi), "raw strings kyun?" (Python pehle backslashes kha jaata hai), aur "jet ke upar viridis kyun?" (monotonic brightness = grayscale/colorblind mein honest) answer kar sako, toh tumne teen sabse bade traps disarm kar diye. ::: Baki sab unhi teeno ideas ki variations hain: size vs sharpness, string parsing order, aur perceptual honesty.

Connections

Publication-quality figures — LaTeX labels, colormaps, DPI
Colormaps and color theory in visualization
Raster vs vector graphics
Dimensional analysis
Reproducible research and rcParams
LaTeX typesetting