Portrait: The Rigid Case

"A face barely bends, so one solve gives you the whole head. It's the cleanest of the four — and even it needs a human knob in one spot."

The Loomis Head, Computed

Portrait is where Track 2's hand-drawn scaffold becomes a computed one. From the rigid face solve, the engine draws the full Loomis construction onto the photo: the ball of the cranium, the flattened side planes, the brow-nose-chin thirds, the sagittal center line, and the perspective head box — plus a numeric yaw / pitch / roll readout. Everything you learned to draw by eye in the Construction track, now recovered from a real photograph and laid back over it.

The Rigid Advantage

The face is the easy subject precisely because it barely deforms. Expressions move things a little, but the skull is effectively rigid, so a single canonical head plus one solvePnP pins down the entire orientation at once. No articulated joints, no per-limb volumes — one solve, one box, the whole scaffold. Among the four constructions, portrait is the one where geometry does the most with the least, which is why it was the engine's first track and still its cleanest.

When the Auto-Fit Mis-aims

There is one soft spot. On a near-frontal face, pitch (the nod) and focal length are both weakly constrained — a slightly-nodded head and a straight one project almost identically. So the automatic solve, doing its honest best, can aim the box a few degrees off exactly where you'd most notice. For this, the engine added a pose override: manual yaw, pitch, and roll that swap the recovered rotation after the solve, letting a human correct the aim the data couldn't pin down. It's the same move as the focal override in Track 3 — a knob placed at precisely the parameter geometry is weakest on, and nowhere else.

FIT Is a Readout, Not a Knob

The override's design carries the whole quest's discipline in one detail. When you override the pose, the reprojection error (the FIT number) is recomputed honestly against your override and labelled as overridden — it is a readout, not a knob you tune toward. That distinction matters enormously: if FIT were something you optimized by hand, you could fool yourself into a low error that fits nothing. Kept as an honest readout, it keeps telling the truth even about your own corrections. The human takes the wheel exactly where the data is weak, and the honesty meter never stops measuring.

Code

Portrait construction, with the honest override·python

# Portrait: the rigid case. One canonical head, one solve, the full scaffold.
R, t, err = solve_pose(face_landmarks, CANONICAL_HEAD, focal)
head = build_loomis_head(R, t)   # ball + side planes + thirds + sagittal + box
readout = pose_angles(R)         # yaw / pitch / roll, from forward/up vectors

# Near-frontal faces weakly constrain pitch & focal, so a human may override:
if pose_override is not None:                     # manual yaw / pitch / roll
    R    = rotation_from_angles(pose_override)    # swap the rotation AFTER the solve
    head = build_loomis_head(R, t)
    err  = reprojection_error(face_landmarks, CANONICAL_HEAD, R, t, focal)
    # FIT (err) is RECOMPUTED as a readout and labelled 'overridden' --
    # never a knob you tune toward. The honesty meter keeps measuring.

Exercise

Take a nearly frontal selfie and try to judge, by eye alone, whether your head is pitched slightly up, slightly down, or level. Notice how uncertain that call is compared to judging a clear three-quarter turn. That uncertainty is exactly the weak constraint that makes the portrait pose override necessary — and why the override exists for pitch but you'd rarely want it for a strong yaw.

Hint

A near-frontal face hides pitch because a small nod barely changes the projected landmarks, so both the auto-solve and your own eye struggle. A strong three-quarter turn, by contrast, spreads the features across the box and pins the orientation firmly. Manual overrides earn their place on the ambiguous axis, not the well-determined one.