Alignment & Registration in Industrial Vision Systems

Alignment and registration are where machine vision stops being “image processing” and becomes machine software.

A camera image is only useful if the software knows what the pixels mean in the real machine: where the wafer is, where the part is, where a defect is, and whether that defect location maps correctly back to the physical product or stage coordinate system.

This topic fits directly inside the roadmap’s Vision, Imaging & Inspection Systems domain, specifically “Alignment and registration,” and also connects to machine coordinate correction and alignment flows from the motion-control domain.

---

PART 1 — WHY ALIGNMENT & REGISTRATION MATTER

In industrial vision, an image can look perfectly clear and still be spatially wrong.

That is the key idea.

A camera may capture a beautiful image of a wafer, PCB, tray, panel, or mechanical part. The lighting may be good. The focus may be sharp. The defect detection may even work. But if the system does not know how that image relates to the real part position, then the inspection result may be useless or dangerous.

For example:

Camera Image
+----------------------------------+
|                                  |
|        defect detected here       |
|                X                 |
|                                  |
+----------------------------------+

Question:
Where is X physically?

- Pixel row/column?
- Wafer coordinate?
- Die coordinate?
- Stage X/Y?
- Product coordinate?
- Robot pick position?

A defect location in pixel coordinates is not enough. The machine needs to know:

Pixel location  →  product location  →  machine location

In a wafer inspection machine, this matters because the wafer is rarely loaded perfectly. It may be slightly shifted, slightly rotated, or not exactly centered on the chuck. The stage may move accurately, but the wafer itself may not be perfectly aligned to the expected product coordinate system.

In a PCB machine, the board may be placed with small X/Y offset or rotation. In a tray inspection system, the tray may be seated slightly differently each cycle. In a camera-guided robot system, the robot must know where the object is now, not where the CAD drawing says it should be.

So alignment exists because physical reality is never perfectly ideal.

The software must correct for:

Translation  → part shifted left/right/up/down
Rotation     → part slightly rotated
Scale        → image/reference size differs slightly
Local errors → some areas need local correction

The failure mode is subtle: the image looks fine, but the coordinate meaning is wrong.

That means:

Good image quality does not guarantee good spatial correctness.

A software engineer entering this domain must stop thinking of images as just arrays of pixels. In machine software, an image is usually:

Image pixels
+ acquisition timestamp
+ camera identity
+ exposure/light settings
+ stage/motion position
+ recipe context
+ coordinate frame
+ alignment result
+ transform/correction model

Without that metadata, inspection results become detached from physical reality.

---

PART 2 — ALIGNMENT VS REGISTRATION

Teams often use these terms loosely, but as an architect you should make the model explicit.

Alignment

Alignment means finding the actual position and orientation of the part, wafer, panel, image, or feature, then correcting for the difference from the expected position.

Example:

Expected wafer center: X=0, Y=0, Angle=0°
Actual wafer center:   X=0.12 mm, Y=-0.08 mm, Angle=0.04°

Alignment correction:
X offset = -0.12 mm
Y offset = +0.08 mm
Rotation = -0.04°

In practical language:

Alignment answers:
"Where is the part now compared with where I expected it to be?"

Registration

Registration means mapping one coordinate frame, image, or reference model to another.

Example:

Golden reference image  →  current image
CAD/product coordinates →  camera image coordinates
Image coordinates       →  machine stage coordinates
Camera A coordinates    →  camera B coordinates

In practical language:

Registration answers:
"How do I convert positions from this reference frame into that reference frame?"

How They Relate

Alignment often produces the data needed for registration.

For example:

Detect fiducials
      ↓
Compute current part pose
      ↓
Build transform from reference part coordinates to current image coordinates
      ↓
Apply transform to ROIs, measurements, or result locations

So you can think of it like this:

Alignment    = finding the mismatch
Registration = mapping between coordinate frames using that mismatch

The danger is when the team uses both words casually without a clear data model. One engineer may say “alignment offset” and mean pixel shift. Another may mean machine-stage correction. Another may mean recipe-to-image transform.

That ambiguity causes bugs.

Strong software architecture makes the coordinate model explicit.

---

PART 3 — REFERENCE FEATURES & FIDUCIALS

A vision system needs known features to anchor its coordinate system.

These are called fiducials or reference features.

A fiducial is a feature whose expected meaning is known. It might be:

- a dedicated alignment mark
- a cross mark
- a circle
- a notch
- a hole
- a board fiducial
- a wafer alignment mark
- a mechanical edge
- a corner
- a known product pattern

The key is not just that the feature is visible. The key is that the feature has known physical meaning.

For example:

Detected pixel: (1240, 780)

Meaning:
"This is the left wafer alignment mark"
or
"This is PCB fiducial F1"
or
"This is tray pocket origin"

A good reference feature provides three things:

Stable detection
Repeatable location
Known physical meaning

Stable Detection

The feature should be detectable under normal lighting, focus, surface variation, and production conditions.

A fiducial that only works in the lab is not good enough.

Repeatable Location

The detected position should be consistent. If the same part is imaged repeatedly, the fiducial result should not jump around randomly.

Small variation is normal. Large variation indicates unstable detection, poor image quality, bad feature design, or incorrect algorithm settings.

Known Physical Meaning

This is often underestimated by software engineers.

A feature is only useful if the software knows what it represents.

Bad model:

Point1 = detected point
Point2 = detected point

Better model:

FiducialId: WaferPrimaryMark
ExpectedPartCoordinate: X=10.0 mm, Y=5.0 mm
DetectedImageCoordinate: X=1240.2 px, Y=780.6 px
DetectionScore: 0.94

The second model allows the software to reason about correctness.

---

PART 4 — COORDINATE SYSTEMS IN ALIGNMENT

Alignment problems are often coordinate-system problems disguised as image-processing problems.

A typical industrial vision system may involve several coordinate systems:

Image coordinate system
Camera coordinate system
Part/product coordinate system
Machine/stage coordinate system
Reference/golden coordinate system

Image Coordinates

Image coordinates are pixel-based.

Image Coordinate System

(0,0)
  +---------------------------> X pixel / column
  |
  |
  |
  v
Y pixel / row

Many image libraries use top-left origin, X to the right, Y downward.

That already differs from many machine coordinate systems.

Part/Product Coordinates

Part coordinates describe locations relative to the product itself.

Example:

Wafer center = product origin
Die location = product coordinate
PCB fiducial = board coordinate
Tray pocket = tray coordinate

This coordinate system moves with the part.

Machine/Stage Coordinates

Machine coordinates describe physical machine position.

Example:

Stage X = 120.000 mm
Stage Y = 45.000 mm
Z focus = 2.300 mm
Theta = 0.050°

This coordinate system belongs to the machine.

Golden/Reference Coordinates

A golden reference may be:

- reference image
- recipe-defined ROI layout
- CAD coordinate model
- expected product layout
- trained pattern model

This is what the current part is compared against.

Coordinate Diagram

+-----------------------+
| Image Coordinates     |
| pixels: row/column    |
| origin usually top-left
+-----------+-----------+
            |
            | image-to-part transform
            v
+-----------------------+
| Part Coordinates      |
| mm or product units   |
| origin tied to part   |
+-----------+-----------+
            |
            | part-to-machine transform
            v
+-----------------------+
| Machine Coordinates   |
| stage / robot / axis  |
| physical machine mm   |
+-----------------------+

The architecture rule is simple:

Every inspection result must declare its coordinate frame.

Bad:

Defect at X=1200, Y=800

Good:

DefectLocation:
  CoordinateFrame: ImageFrame(CameraTop, FrameId=12345)
  X: 1200.4 px
  Y: 800.7 px

Better:

DefectLocation:
  ImagePosition:    (1200.4 px, 800.7 px)
  ProductPosition:  (15.23 mm, 7.82 mm)
  MachinePosition:  (130.50 mm, 42.10 mm)
  TransformVersion: AlignmentResultId=AR-20260425-00123

That traceability is what makes debugging possible.

---

PART 5 — COMPUTING AND APPLYING OFFSETS / CORRECTIONS

Conceptually, alignment correction is straightforward.

The system knows where a reference feature should be. It detects where the feature actually is. The difference becomes a correction.

Expected fiducial position
        ↓
Detected fiducial position
        ↓
Difference
        ↓
Correction transform

The correction may include:

X/Y offset
Rotation
Scale
Local correction

Simple Offset Example

Expected fiducial:

X = 1000 px
Y = 800 px

Detected fiducial:

X = 1012 px
Y = 793 px

So the part appears shifted:

+12 px in X
-7 px in Y

The software can then shift inspection regions accordingly.

Without correction:

Expected ROI
+--------+
|        |
| target |
|        |
+--------+

Actual part feature is slightly shifted.
Inspection may look at the wrong area.

With correction:

Detected offset
      ↓
Move ROI to actual part position
      ↓
Inspect the correct physical area

Rotation Correction

One fiducial may be enough for X/Y shift, but not always enough for rotation.

With two fiducials, the system can estimate both translation and rotation.

Reference Part

F1 -------------------- F2


Current Image

   F1 -------------------- F2
      slightly rotated

If rotation is ignored, ROIs far from the fiducial may drift badly.

This is common in large parts, wafers, panels, and long objects.

A small angular error near the origin may become a large position error far away.

Data-Flow Diagram

+----------------------+
| Captured Image       |
| FrameId = 12345      |
+----------+-----------+
           |
           v
+----------------------+
| Detected Fiducials   |
| F1, F2, scores       |
+----------+-----------+
           |
           v
+----------------------+
| Alignment Transform  |
| dx, dy, rotation     |
| quality/confidence   |
+----------+-----------+
           |
           +----------------------+
           |                      |
           v                      v
+----------------------+   +----------------------+
| Corrected ROIs       |   | Corrected Results    |
| where to inspect     |   | where defect is      |
+----------------------+   +----------------------+
           |
           v
+----------------------+
| Inspection Logic     |
+----------------------+

Important architectural point:

The transform is not a temporary calculation.
It is production data.

It should be recorded, versioned, correlated to the image/frame, and available for replay.

---

PART 6 — ALIGNMENT FLOW IN A REAL MACHINE

A realistic alignment flow is not just “detect mark and continue.”

It is a controlled machine workflow.

1. Move/capture image
2. Detect reference feature
3. Validate detection quality
4. Compute offset/transform
5. Validate correction range
6. Apply correction
7. Run inspection or motion correction
8. Record alignment result

Sequence Diagram

Operator/Recipe      Machine Workflow      Motion/Stage       Camera        Alignment Service      Inspection
      |                    |                    |                |                  |                   |
      | Start inspection   |                    |                |                  |                   |
      |------------------->|                    |                |                  |                   |
      |                    | Move to align pos  |                |                  |                   |
      |                    |------------------->|                |                  |                   |
      |                    |                    | Position done   |                  |                   |
      |                    |<-------------------|                |                  |                   |
      |                    | Capture image      |--------------->|                  |                   |
      |                    |                    |                | Image frame      |                   |
      |                    |<--------------------------------------|                  |                   |
      |                    | Detect fiducials   |                |----------------->|                   |
      |                    |                    |                |                  | Fiducials + score |
      |                    |<------------------------------------------------------|                   |
      |                    | Validate result    |                |                  |                   |
      |                    | Compute transform  |                |----------------->|                   |
      |                    |                    |                |                  | Transform         |
      |                    |<------------------------------------------------------|                   |
      |                    | Apply correction   |                |                  |------------------>|
      |                    | Run inspection     |                |                  |                   |
      |                    |----------------------------------------------------->|
      |                    | Save alignment log |                |                  |                   |

Why Validation Is Critical

Alignment can fail in dangerous ways.

A system may still produce numbers even when the fiducial detection is wrong.

That is worse than a clean failure.

Bad alignment should usually block inspection, require operator review, or run in degraded mode depending on machine design.

Validation should check things like:

Was the fiducial found?
Is the score high enough?
Is the detected position within expected search range?
Is the computed offset physically plausible?
Is rotation within allowed tolerance?
Do multiple fiducials agree?
Is the image/frame ID correct?
Is the alignment result fresh?

A strong system does not merely ask:

Did the algorithm return a point?

It asks:

Is this alignment trustworthy enough to use for this machine action?

---

PART 7 — REAL-WORLD FAILURE SCENARIOS

1. Fiducial Not Found Due to Lighting or Focus

What It Looks Like

The machine intermittently stops with alignment failure.

Operators say:

"It worked yesterday."
"It fails only on some lots."
"It fails after maintenance."

The image may look acceptable to a human, but the fiducial detector cannot locate the mark reliably.

Why It Happens

Common causes:

- lighting intensity changed
- exposure changed
- focus drifted
- surface reflectivity changed
- contamination near mark
- mark contrast is poor
- recipe uses wrong lighting setup

How Experienced Engineers Handle It

They inspect the raw alignment images, not just the error message.

They compare:

Good alignment image
Bad alignment image
Lighting settings
Focus position
Camera settings
Detection score
Search region
Recipe version

Architectural lesson:

Always save enough alignment evidence to replay the failure.

---

2. Wrong Feature Detected as Reference Mark

What It Looks Like

Alignment “succeeds,” but inspection results are shifted.

The system reports high confidence, yet defects or measurements appear in the wrong locations.

Why It Happens

The detector found a similar-looking feature.

This can happen when:

- search area is too large
- product pattern resembles fiducial
- fiducial is damaged
- lighting makes another feature look stronger
- recipe uses wrong expected position

How Experienced Engineers Diagnose It

They overlay the detected point on the image.

They ask:

Did we find the correct physical feature?
Was it the correct fiducial ID?
Was it inside the expected search window?
Did other fiducials agree?

A good system should not only store the coordinate. It should store:

Detected feature image crop
Search region
Candidate matches
Score
Expected location
Final selected feature

---

3. Rotation Correction Missed or Applied Twice

What It Looks Like

Inspection is correct near the alignment origin but increasingly wrong farther away.

Or the correction appears exaggerated, as if the part was rotated in the wrong direction.

Why It Happens

Common causes:

- transform applied once to ROI and again to result
- degrees/radians confusion
- sign convention mismatch
- clockwise vs counterclockwise convention mismatch
- rotation origin is wrong
- one subsystem assumes already-corrected coordinates

How Engineers Handle It

They trace transform ownership.

They ask:

Who owns the transform?
Where is it applied?
Are coordinates raw or corrected?
Is the result in image frame or product frame?

Good architecture avoids ambiguous APIs like:

Point GetDefectLocation()

Better:

CoordinatePoint<ImageFrame> ImageLocation
CoordinatePoint<ProductFrame> ProductLocation
CoordinatePoint<MachineFrame> MachineLocation

Even if implemented simply, the conceptual distinction prevents many bugs.

---

4. Image Coordinate Used as Machine Coordinate

What It Looks Like

A downstream machine action moves to the wrong physical location.

For example:

Defect pixel X=1500 is treated as stage X=1500 mm

This is an extreme example, but subtler versions happen often.

Why It Happens

Software layers pass around raw numbers without coordinate-frame meaning.

A method accepts:

double x, double y

But nobody knows whether those values are:

pixels
millimeters
stage coordinates
part coordinates
corrected coordinates
uncorrected coordinates

How Engineers Handle It

They introduce coordinate-aware models and naming.

Bad:

MoveTo(x, y)

Better:

MoveToMachinePosition(MachinePosition position)

Bad:

InspectionResult.X
InspectionResult.Y

Better:

InspectionResult.ImagePosition
InspectionResult.ProductPosition
InspectionResult.MachinePosition

This is not overengineering. In vision-guided machines, this is basic safety and correctness.

---

5. Alignment Succeeds Numerically but Confidence Is Poor

What It Looks Like

The system produces unstable measurements. Results drift. False defects increase. Operators complain that the machine is “sensitive” or “random.”

Why It Happens

The alignment algorithm returns a result, but the result quality is weak.

Maybe the match score is low. Maybe fiducials disagree. Maybe the correction is near the allowed limit. Maybe the image is noisy.

How Engineers Handle It

They treat alignment as a quality-gated result, not a boolean.

Bad:

AlignmentSuccess = true

Better:

AlignmentResult:
  Status: Passed / Failed / Degraded
  Confidence: 0.82
  FiducialScores: [...]
  ResidualError: ...
  Correction: dx, dy, angle
  ValidationMessages: [...]

The inspection system can then decide:

- proceed normally
- proceed with warning
- reduce confidence in measurements
- block inspection
- request operator review

---

6. Stale Alignment Result Reused for a New Part

What It Looks Like

The first part after setup is fine. Later parts are shifted. Or after a retry, the system uses an old correction.

Why It Happens

Alignment state is stored globally or cached without proper correlation.

Bad design:

CurrentAlignmentTransform

This is dangerous if it is not tied to:

- frame ID
- part ID
- wafer ID
- recipe version
- camera ID
- stage position
- timestamp

How Engineers Handle It

They make alignment results immutable and correlated.

Example:

AlignmentResultId: AR-00123
FrameId: IMG-54321
PartId: Wafer-25
RecipeId: Recipe-A-v17
CameraId: TopCam-1
CreatedAt: 2026-04-25T...
ValidFor: Wafer-25 / InspectionRun-778

The system should reject using an alignment result outside its valid context.

---

7. Different Cameras Use Different Coordinate Conventions

What It Looks Like

Camera A works. Camera B produces mirrored or inverted results.

Defect overlays appear flipped. Motion correction moves in the wrong direction.

Why It Happens

Different cameras, lenses, frame grabbers, or image libraries may use different conventions:

origin top-left vs bottom-left
Y axis down vs Y axis up
rotated sensor orientation
mirrored image
cropped image origin
binned/scaled image

How Engineers Handle It

They define a normalized coordinate convention at system boundaries.

For example:

RawCameraFrame
      ↓
Camera-specific normalization
      ↓
StandardImageFrame
      ↓
Alignment / inspection

The raw coordinate system should not leak everywhere.

---

8. Local Distortion Makes Global Alignment Insufficient

What It Looks Like

Global alignment looks correct overall, but local measurements are wrong in certain areas.

For example:

- center of wafer is correct
- edge dies are slightly shifted
- one panel corner is off
- large flexible part is warped

Why It Happens

A simple global X/Y/rotation correction assumes the part is rigid and distortion-free.

That may not be true for:

large panels
flexible materials
thermal expansion
lens distortion residuals
warped substrates
mechanical deformation

How Engineers Handle It

They avoid pretending that one global transform solves everything.

Depending on the machine, they may use:

- local alignment per region
- multiple fiducials
- zone-based correction
- higher-level correction maps
- tighter mechanical constraints

From an architecture perspective, the key is to model whether a correction is:

global
local
camera-specific
region-specific
product-specific

---

PART 8 — SOFTWARE DESIGN IMPLICATIONS

Alignment must be explicit, traceable, and owned by a clear component.

It should not be hidden inside image-processing code as some private offset.

Bad Architecture

ImageProcessor
  - detects fiducial
  - stores offset internally
  - shifts ROIs silently
  - returns corrected-looking results

This is dangerous because other systems cannot know:

- what correction was applied
- whether alignment was good
- which frame was used
- whether result coordinates are raw or corrected
- how to replay the result

Better Architecture

+----------------------+
| Image + Metadata     |
| frame, camera, time  |
+----------+-----------+
           |
           v
+----------------------+
| Reference Feature    |
| Detector             |
+----------+-----------+
           |
           v
+----------------------+
| Alignment /          |
| Registration Service |
+----------+-----------+
           |
           v
+----------------------+
| Transform / Offset   |
| Model                |
+----------+-----------+
           |
           +--------------------------+
           |                          |
           v                          v
+----------------------+     +----------------------+
| Corrected ROIs       |     | Result Coordinates   |
| for inspection       |     | image/part/machine   |
+----------------------+     +----------------------+

Alignment Result Model

A strong alignment result model should include:

AlignmentResult
  Id
  Status
  FrameId
  CameraId
  RecipeId
  PartId / WaferId / PanelId
  DetectedFeatures
  ExpectedFeatures
  Transform
  Confidence
  ValidationResults
  Timestamp
  CoordinateFrames
  DiagnosticArtifacts

This allows the system to answer:

What image was aligned?
Which fiducials were used?
How good was the match?
What correction was applied?
Which inspection results depended on this alignment?
Can we replay it?

Coordinate Frame Types

Even if the implementation is simple, the design should distinguish coordinate meanings.

Conceptually:

ImagePoint
ProductPoint
MachinePoint
ReferencePoint

Avoid raw double x, double y flowing through the system.

In real teams, many alignment bugs come from “just passing X/Y.”

Transform Ownership

There should be one clear owner responsible for producing the transform.

Bad:

Camera service applies offset
Inspection service applies offset
Motion service applies offset
Recipe service also stores offset

Good:

AlignmentRegistrationService produces transform.
Other components consume it explicitly.

Frame/Result Correlation

Every alignment result should be tied to the image and product context.

Bad:

latestAlignment

Good:

alignment for FrameId=IMG-10021 and WaferId=W25

This prevents stale or mismatched alignment use.

Replayable Diagnostics

For production support, save enough data to reconstruct alignment behavior.

Useful diagnostics:

raw image or cropped alignment image
detected fiducial overlay
expected position overlay
search region
match score/confidence
computed transform
validation messages
recipe parameters
camera/light settings
stage position

Without this, field debugging becomes guesswork.

---

PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS

A strong explanation:

Alignment is how the system determines where the part actually is compared with where the recipe expects it to be. Registration is how we map coordinates between image space, product space, reference space, and machine space. In industrial vision, the image itself is not enough. Every result must be spatially meaningful and tied to a coordinate frame. That is why alignment results need confidence, validation, transform ownership, and traceability.

Another strong version:

The biggest risk is not that the camera cannot see the part. The bigger risk is that the system sees the part but assigns the wrong spatial meaning to the result. That can lead to wrong defect locations, wrong measurements, or even wrong machine motion. So I would design alignment as an explicit service that produces validated, immutable alignment results correlated to frame ID, part ID, recipe, camera, and coordinate frames.

Common mistakes software engineers make:

- treating pixel coordinates as universal coordinates
- hiding offsets inside image-processing code
- not modeling coordinate frames explicitly
- using global mutable alignment state
- ignoring confidence and validation
- assuming one camera convention applies everywhere
- applying correction twice
- reusing stale alignment results
- saving pass/fail only without diagnostic evidence

What strong engineers understand:

- fiducials are not just visual marks; they anchor coordinate meaning
- alignment result quality matters as much as success/failure
- transform ownership must be explicit
- every result must declare its coordinate frame
- bad alignment should block or degrade inspection
- replayable diagnostics are essential for production support
- coordinate correctness is a system-level concern, not just a vision algorithm concern

The architectural mindset is:

Do not let raw pixels escape as business truth.

Convert them through explicit, validated, traceable coordinate models.

That is the heart of alignment and registration in real industrial vision software.