Worked examples — Semantic segmentation (U-Net, FCN)

This page is the "run the machine by hand" companion to Semantic segmentation (U-Net, FCN). We take every knob the topic exposes — output-size arithmetic, skip fusion, the pixel loss, degenerate inputs — and turn each into a fully worked, numerically checked example. Nothing here is hand-waved; every number reappears in the verification block.

Before we compute, a reminder of the two size laws we will lean on constantly. We only use symbols the parent note earned.

Why two different formulas? Because they answer opposite questions. The first asks "if I slide a $k$-window with steps of $s$, how many landing spots fit?" The second asks "if I first space the input pixels $s$ apart, then convolve, how big is the canvas?" Downsampling counts landing spots; upsampling counts a stretched canvas. Keep them mentally separate.

---

The scenario matrix

Segmentation math has a small, finite set of "shapes of problem." The table below lists every cell; the examples that follow are each tagged with the cell(s) they close.

#	Cell class	The tricky part it tests	Covered by
A	Clean downsample (padding, stride 1)	"same" convolution keeps size	Ex 1
B	Downsample with stride 2, no padding	floor division, size shrinks	Ex 2
C	Non-divisible input (odd size ÷ 2)	floor drops a pixel — the degenerate case	Ex 3
D	Transposed conv upsample	the other size law, ×2 growth	Ex 4
E	Skip connection mismatch → crop	encoder bigger than decoder (U-Net)	Ex 5
F	Channel bookkeeping: add vs concat	FCN addition vs U-Net concatenation	Ex 6
G	Pixel loss, single pixel	softmax + cross-entropy at one location	Ex 7
H	Class imbalance limiting case	why plain CE fails; weighted CE	Ex 8
I	Real-world word problem	self-driving frame, end-to-end sizes	Ex 9
J	Exam twist / degenerate loss	perfect prediction → loss $\to 0$; wrong class → loss blows up	Ex 10

Prerequisites used below: Pooling Layers (for the stride-2 shrink), Loss Functions (cross-entropy), Batch Normalization and Data Augmentation appear as side notes. If any symbol feels unfamiliar, it was built in the parent note.

---

Example 1 — Cell A: "same" convolution keeps the size

Forecast: guess before reading — does the size stay $284$, drop to $282$, or grow?

1. Write the shrink law. $H_{out}=\lfloor \frac{H_{in}+2p-k}{s}\rfloor +1$. Why this step? Convolution is downsampling arithmetic; this is the correct law (not the transposed one).
2. Substitute $H_{in}=284,p=1,k=3,s=1$: $\frac{284+2-3}{1}+1=\frac{283}{1}+1=284$. Why this step? Plugging numbers turns the abstract law into the concrete answer.
3. Read the meaning. With $p=1$ padding a $3\times 3$ kernel, one row/column of zeros on each side exactly compensates for the two rows/columns the kernel would otherwise "eat." Output $=284$.

Verify: the standard rule "for a $3\times 3$ kernel, $p=1$ gives same output" holds. Modern padded U-Nets rely on this so decoder and encoder sizes align without cropping. ✔

---

Example 2 — Cell B: stride-2 pooling, no padding

Forecast: halved? off-by-one?

1. Shrink law with $H_{in}=568,p=0,k=2,s=2$: $\lfloor \frac{568-2}{2}\rfloor +1=\lfloor 283\rfloor +1=284$. Why this step? Pooling Layers is just a convolution-shaped scan; same landing-spot counting applies.
2. Interpret. $568$ is even, so it halves cleanly: $568/2=284$. No pixel is lost.

Verify: matches the parent note's U-Net table ("$568\times 568\to$ pool $284\times 284$"). Even input ÷ stride-2 = exact halving. ✔

---

Example 3 — Cell C (degenerate): odd input, the floor bites

Forecast: $68$? $68.5$? $69$? A fraction is impossible — so which whole number?

1. Shrink law: $\lfloor \frac{137-2}{2}\rfloor +1=\lfloor 67.5\rfloor +1=67+1=68$. Why this step? The floor is the whole point of this cell — $67.5$ landing spots is nonsense, so we round down.
2. What just happened geometrically? The last column of the input had no room for a full $2\times 2$ window, so it is silently dropped. Output $68$, not $69$.

Verify: $\lfloor 67.5\rfloor +1=68$. This is exactly why FCN needs its input divisible by 32 (five stride-2 stages, $2^5=32$) — otherwise dropped edge pixels make encoder/decoder sizes disagree. ✔

---

Example 4 — Cell D: transposed convolution upsamples ×2

Forecast: exactly $56$? more? less?

1. Choose the correct law. We are growing, so use $H_{out}=s(H_{in}-1)+k-2p$. Why this step? Using the shrink law here would give a wrong, smaller number — this cell exists to force the right choice.
2. Substitute $s=2,H_{in}=28,k=2,p=0$: $2(28-1)+2-0=54+2=56$. Why this step? Plug the bottleneck size to get the first decoder level.
3. Picture it. Transposed conv spaces the 28 input pixels 2 apart (making a $55$-wide gappy grid), then a $2$-kernel sweep fills to $56$. Clean doubling.

Verify: matches the parent U-Net table "$28\times 28\to$ upsample $56\times 56$." ✔

---

Example 5 — Cell E: skip mismatch, so we crop

Forecast: crop 8 total? 4 total? from where?

1. Difference in size: $64-56=8$ pixels of extra encoder width. Why this step? Valid (no-pad) convs shrink each map slightly differently along the path, leaving the encoder larger — this cell tests that reality.
2. Split symmetrically. Center-crop removes $8/2=4$ pixels from each side. Why this step? Cropping the center keeps the feature that best aligns spatially with the decoder pixel it will be fused with.
3. Result: encoder $64\times 64\to 56\times 56$, now matching the decoder for augmentation-robust concatenation.

Verify: $56+2(4)=64$ ✔. This is exactly the crop-and-concat step in the parent's decoder walkthrough. ✔

---

Example 6 — Cell F: channel arithmetic, add vs concat

Forecast: are they the same number? which is bigger?

1. Addition (FCN): element-wise sum requires identical shapes; channels stay $512$. Output $56\times 56\times 512$. Why this step? Addition is a fold, not a stack — it cannot change channel count.
2. Concatenation (U-Net): stack along channel axis: $512+512=1024$. Output $56\times 56\times 1024$. Why this step? Concat preserves all information from both paths, letting the next conv choose what to keep — the parent note's key U-Net argument.
3. Cost note. The concat doubles channels, so the following $3\times 3$ conv has more input channels (more compute) — the price of keeping everything.

Verify: add $\to 512$, concat $\to 1024$. ✔

---

Example 7 — Cell G: cross-entropy at a single pixel

Forecast: will it be near $0$ (confident-correct) or large (confused)?

1. Softmax denominator $Z=e^{2.0}+e^{1.0}+e^{0.1}$. Why this step? Cross-entropy needs a probability; softmax turns raw logits into one (see Loss Functions).
2. Numbers: $e^{2.0}=7.389,e^{1.0}=2.718,e^{0.1}=1.105$, so $Z=11.212$.
3. Probability of true class 0: $P=7.389/11.212=0.6590$.
4. Loss $=-\ln P=-\ln (0.6590)=0.4170$. Why this step? The parent's pixel-wise CE is exactly $-\log$ of the true-class probability.

Verify: $-\ln (0.659)\approx 0.417$. Moderate loss — correct class but not fully confident. ✔

---

Example 8 — Cell H (limiting case): why plain CE fails under imbalance

Forecast: does plain CE "reward" the lazy model? does weighting punish it?

1. Plain average CE. Background pixels contribute $\approx -\ln (1)=0$. Cell pixels ($5\%$) contribute $-\ln (0.01)=4.605$ each. Average $=0.95(0)+0.05(4.605)=0.2303$. Why this step? The rare class is diluted by the majority — the loss looks small even though every cell is wrong.
2. Weighted CE. Multiply each pixel's loss by its class weight, then divide by total weight. Weighted sum $=0.95(1)(0)+0.05(10)(4.605)=2.3025$; total weight $=0.95(1)+0.05(10)=1.45$. Weighted mean $=2.3025/1.45=1.588$. Why this step? Up-weighting the rare class ($w_1=10$) re-inflates its influence so the optimizer can no longer ignore cells.
3. Read the contrast. Plain loss $0.230$ vs weighted $1.588$ — nearly $7\times$ larger. The weighted objective forces the network to care about the $5\%$.

Verify: plain $=0.2303$, weighted $=1.588$. Weighted $\gg$ plain, confirming imbalance handling. ✔

---

Example 9 — Cell I: real-world self-driving pipeline

Forecast: does it land exactly on $512$ or overshoot?

1. Encoder shrink: five halvings ⇒ divide by $2^5=32$. $512/32=16$. Encoder output $16\times 16$. Why this step? Each stride-2 stage halves; five stages compose to $÷32$ (uses ResNet/VGG-style backbones via Transfer Learning).
2. Upsample with the transposed law: $H_{out}=s(H_{in}-1)+k-2p=32(16-1)+64-32=32\cdot 15+32=480+32=512$. Why this step? We must recover the original resolution to label every road/pedestrian pixel.
3. Interpret. Output $512\times 512\times C$ — one class per original pixel, ready for the drivable-mask. Because $512$ is divisible by $32$, no floor pixel was lost in step 1 (contrast Ex 3).

Verify: $512/32=16$; $32(15)+64-32=512$. Exact round-trip. ✔

---

Example 10 — Cell J (exam twist): the two loss extremes

Forecast: does perfect give exactly $0$? does wrong give exactly $\infty$?

1. Case (i) probability of true class 1: $P=\frac{e^{10}}{e^{-10}+e^{10}}=\frac{1}{1+e^{-20}}\approx 0.99999999794$. Loss $=-\ln P\approx 2.06\times 10^{-9}$. Why this step? A confident-correct prediction drives $P\to 1$, so $-\ln P\to 0^{+}$ — small but never exactly zero (asymptote).
2. Case (ii) probability of true class 1: $P=\frac{e^{-10}}{e^{10}+e^{-10}}=\frac{1}{1+e^{20}}\approx 2.06\times 10^{-9}$. Loss $=-\ln P\approx 20.0$. Why this step? A confident-wrong prediction drives $P\to 0$, so $-\ln P\to +\infty$. Here it's $\approx 20$, and grows without bound as logits diverge.
3. The limit picture. Cross-entropy is a funnel: $0$ at perfect, $+\infty$ as the model confidently backs the wrong class. This unboundedness is why Batch Normalization and careful init matter — a single confidently-wrong pixel can dominate the gradient.

Verify: case (i) $\approx 2.06\text{e-}9$; case (ii) $\approx 20.0$. ✔

---

Recall Self-test

Why does an odd-sized map lose a pixel under stride-2 pooling? ::: The floor in $\lfloor (H-k)/s\rfloor +1$ discards the leftover edge that has no room for a full window. Add vs concat: which changes channel count? ::: Concatenation ($C_e+C_d$); addition keeps channels fixed. What does cross-entropy loss approach for a confident-correct pixel? ::: $0$ from above (asymptotically, never exactly). Why crop encoder features in the original U-Net? ::: Valid (no-pad) convs leave the encoder map larger; center-crop aligns it to the decoder before concat.

Related tasks that reuse this size algebra: Object Detection (anchor grids) and Attention Mechanisms (token grids) both depend on the same $÷2^n$ downsampling bookkeeping.