Below is the next refined topic for Domain 5 — Vision, Imaging & Inspection Systems, aligned with the roadmap item “Illumination control basics / Focus, exposure, gain, and calibration”

Illumination & Image Quality Fundamentals

PART 1 — WHY IMAGE QUALITY IS A SYSTEM PROBLEM

In industrial vision, inspection correctness starts before the algorithm runs.

A camera may successfully return an image, but that does not mean the image is trustworthy. In machine software, this is a critical mindset shift:

Acquisition success is not the same as inspection readiness.

A captured image can be technically valid but operationally useless if it is too dark, saturated, blurred, noisy, unevenly lit, or affected by reflection.

For example:

• A wafer defect may disappear because the surface reflects light directly into the camera.
• An edge measurement may fluctuate because focus is slightly soft.
• A threshold-based inspection may work in the lab but fail in production after illumination changes.
• A shiny surface may create a bright hotspot that hides scratches or particles.
• A slightly longer exposure may look fine when the stage is stopped but blur during motion.

Image quality is affected by many things:

+------------------+
| Image Quality    |
+------------------+
        ^
        |
        +--> Lighting intensity
        +--> Lighting angle
        +--> Exposure time
        +--> Camera gain
        +--> Focus position
        +--> Lens / optics condition
        +--> Motion during capture
        +--> Surface material
        +--> Product height / flatness
        +--> Recipe parameters

The key point is this:

Image quality is not only a camera problem. It is a system problem involving lighting, optics, motion, recipes, hardware timing, and software validation.

Poor image quality causes:

• false defects: the system sees shadows, noise, reflection, or dust as defects
• missed defects: real defects are hidden by poor contrast or saturation
• unstable measurements: edges move because focus or lighting changes
• inconsistent production results: one batch passes, another fails, even though the machine software “did not change”

In real production, this is dangerous because operators may blame the inspection algorithm, while the real problem is often the imaging condition.

---

PART 2 — ILLUMINATION CONTROL BASICS

Illumination is not just “turn the light on.”

In industrial vision, lighting is part of the measurement system. The goal is not simply to make the image bright. The goal is to make the important features visible and stable.

Lighting affects:

• contrast: whether a defect stands out from the background
• shadows: whether geometry becomes visible or misleading
• reflections: whether shiny surfaces hide or reveal defects
• texture visibility: whether surface features become detectable
• measurement stability: whether edges and boundaries appear consistently

A simple software view looks like this:

+----------------+
| Recipe         |
| Imaging Params |
+-------+--------+
        |
        v
+-------------------------+
| Illumination Controller |
| - intensity             |
| - channel selection     |
| - strobe timing         |
| - wavelength/profile    |
+-----------+-------------+
            |
            v
+----------------+
| Light Source   |
+-------+--------+
        |
        v
+----------------+
| Object Surface |
+-------+--------+
        |
        v
+----------------+
| Camera Image   |
+----------------+

The important part is that lighting should usually be recipe-driven.

Different products, materials, inspection regions, or defect types may need different lighting. A wafer surface may need one illumination profile for scratch visibility and another for particle visibility. A reflective metal surface may need a different angle or intensity from a matte plastic surface.

Common lighting factors:

Intensity

Intensity controls how much light reaches the object.

Too low:

• image is dark
• noise becomes visible
• low-contrast defects disappear

Too high:

• pixels saturate
• bright regions lose detail
• reflective surfaces produce hotspots

Angle

Lighting angle changes what becomes visible.

Low-angle light may emphasize scratches or height changes. More direct light may make a surface look uniform but may also create reflection.

For software engineers, the key idea is:

Changing the light angle can change the “meaning” of the image even if the camera and algorithm stay the same.

Color / Wavelength

Different materials respond differently to different wavelengths.

You do not need deep optics theory at first. The practical point is:

Some defects are visible under one wavelength and nearly invisible under another.

That means wavelength or light channel may be a recipe parameter.

Strobe Timing

In high-speed systems, lights may be strobed only during image capture.

This matters because the timing relationship must be correct:

Motion Position Reached
        |
        v
Trigger Camera
        |
        v
Strobe Light ON
        |
        v
Exposure Window
        |
        v
Image Captured

If the strobe timing is wrong, the image may be inconsistent even when exposure and intensity values look correct.

Uniformity

Uniformity means the image is evenly illuminated.

Poor uniformity causes one area to be bright and another area to be dark. This can break inspection because the same defect may be visible in one region and invisible in another.

---

PART 3 — EXPOSURE, GAIN, AND BRIGHTNESS

Exposure controls how long the camera sensor collects light.

Gain amplifies the signal after capture.

Brightness is the visible result, but brightness alone is not enough. Two images can have similar brightness but very different reliability.

More exposure  -> more light collected
More gain      -> signal amplified
More brightness -> image appears lighter

But each comes with trade-offs.

Exposure Trade-Offs

Longer exposure improves brightness, but it can cause blur if the object or camera is moving.

Short Exposure:
[ sharp but darker ]

Long Exposure:
[ brighter but motion blur risk ]

In an inspection machine, this matters because the stage, conveyor, wafer, or camera may not be perfectly still.

A setting that works during manual testing may fail during automatic production because production motion timing is different.

Gain Trade-Offs

Gain makes the image brighter by amplification.

But gain also amplifies noise.

Low gain:
- cleaner image
- may be too dark

High gain:
- brighter image
- more noise
- unstable small details

Gain is sometimes used as a quick fix:

“The image is dark, just increase gain.”

That may make the image look acceptable to the human eye, but it can make inspection less stable because noise increases.

Saturation

Saturation happens when pixels become too bright and lose detail.

A saturated pixel no longer tells you how bright the real surface was. It is clipped.

Normal region:
Pixel values preserve detail

Saturated region:
Pixel values all hit maximum
Detail is gone

This is especially dangerous on reflective surfaces. A shiny wafer region may saturate and hide a real defect.

Too Dark

If the image is too dark, small features may disappear into noise.

The camera still returns an image, but the inspection result becomes unreliable.

This is why software should not simply trust configured exposure and gain values. It should validate the image that was actually captured.

---

PART 4 — FOCUS & SHARPNESS

Focus affects whether edges and fine details are clear.

A poorly focused image may still look “okay” to a human, but it may not be reliable for measurement.

In machine vision, focus affects:

• edge location stability
• defect visibility
• repeatability
• measurement accuracy
• confidence of inspection results

Example:

Sharp edge:

Dark | Bright
     |
     | clear transition


Blurred edge:

Dark |||||| Bright
     gradual transition

With a sharp edge, measurement is stable.

With a blurred edge, the detected edge may move depending on noise, lighting, or threshold behavior.

Autofocus Conceptually

Autofocus is usually a search process.

The system changes focus position, captures images, calculates a focus score, and chooses the best position.

+-------------------+
| Move Focus Axis   |
+---------+---------+
          |
          v
+-------------------+
| Capture Image     |
+---------+---------+
          |
          v
+-------------------+
| Compute Sharpness |
| / Focus Score     |
+---------+---------+
          |
          v
+-------------------+
| Pick Best Focus   |
+-------------------+

This does not require you to understand the full optics. From a software architecture perspective, autofocus is a controlled workflow involving:

• motion
• camera acquisition
• image quality metric
• decision rule
• timeout/failure handling
• recipe constraints

Why Focus Drifts

Focus may drift because of:

• wafer height variation
• product thickness differences
• lens position drift
• mechanical vibration
• temperature changes
• fixture tolerance
• stage flatness issues

In production, this creates painful failures because the software may still capture images successfully, but inspection results become unstable.

---

PART 5 — IMAGE QUALITY METRICS SOFTWARE CAN USE

Image quality metrics do not replace inspection logic.

They answer a different question:

Is this image trustworthy enough to inspect?

Common practical metrics include:

Brightness Range

Checks whether the image is too dark or too bright.

Example:

Average brightness too low  -> underexposed
Average brightness too high -> overexposed risk

Saturation Percentage

Checks how many pixels are clipped at maximum value.

High saturation means detail may be lost.

This is especially useful for reflective materials.

Contrast

Checks whether important regions have enough separation.

Low contrast means defects or edges may not stand out.

Sharpness / Focus Score

Checks whether the image has enough fine detail.

This helps detect focus drift, lens issues, or motion blur.

Noise Level

Checks whether the image is unstable or grainy.

Noise can produce false defects or unstable measurements.

Uniformity

Checks whether lighting is consistent across the image.

Poor uniformity can make the same object appear different depending on location.

Histogram Checks

A histogram shows the distribution of pixel brightness.

Software can use it to detect:

• too dark images
• too bright images
• saturation
• low contrast
• abnormal lighting changes

A simple quality gate looks like this:

+---------------+
| Capture Image |
+-------+-------+
        |
        v
+----------------------+
| Image Quality Check  |
| - brightness         |
| - saturation         |
| - contrast           |
| - sharpness          |
| - noise              |
| - uniformity         |
+----------+-----------+
           |
           v
   +---------------+
   | Quality OK?   |
   +---+-------+---+
       |       |
      Yes      No
       |       |
       v       v
+------------+  +--------------------+
| Inspection |  | Reject / Reacquire |
| Pipeline   |  | Refocus / Alarm    |
+------------+  +--------------------+

The validator should not decide whether the product is good or bad.

It decides whether the image is valid enough for inspection.

---

PART 6 — IMAGE QUALITY AS PART OF MACHINE CONTROL

Image quality is not only an offline analysis concern.

In a real machine, image quality affects machine behavior.

If quality fails, the machine may need to:

• adjust light intensity
• change exposure
• refocus
• reacquire the image
• slow down motion
• reject the frame
• stop the workflow
• raise an alarm
• ask for operator or service intervention

A production workflow may look like this:

+----------------+
| Load Recipe    |
+-------+--------+
        |
        v
+----------------------+
| Apply Imaging Setup  |
| Camera + Lighting    |
+-------+--------------+
        |
        v
+----------------------+
| Move To Capture Pos  |
+-------+--------------+
        |
        v
+----------------+
| Capture Image  |
+-------+--------+
        |
        v
+----------------------+
| Validate Quality     |
+----+-------------+---+
     |             |
     v             v
 Inspection     Recovery Path
                - reacquire
                - refocus
                - adjust light
                - alarm

The key architectural idea:

Image quality validation should be part of the machine workflow, not an optional debug tool.

---

PART 7 — REAL-WORLD FAILURE SCENARIOS

1. Light Intensity Drifts Over Time

What it looks like:

• inspection works in the morning
• false defects increase later
• operators say “nothing changed”
• images are slightly darker or brighter than before

Why it happens:

• LED aging
• controller output drift
• heat effects
• dirty optics
• unstable power
• light source degradation

How experienced engineers handle it:

• log brightness and exposure metrics over time
• compare current images with golden/reference images
• add maintenance alarms
• require illumination calibration
• avoid relying on fixed settings forever

---

2. Exposure Works in Lab but Fails on Production Material

What it looks like:

• demo images look good
• production batch produces unstable results
• some materials are too dark or too reflective
• inspection quality varies by lot

Why it happens:

• lab sample does not represent real material variation
• surface finish differs
• production speed differs
• lighting response differs by product

How engineers diagnose it:

• compare histograms across material lots
• capture sample images from real production
• review recipe-specific imaging parameters
• avoid tuning only on ideal samples

---

3. Gain Hides a Low-Light Problem but Increases Noise

What it looks like:

• image brightness appears acceptable
• inspection becomes noisy
• false small defects increase
• measurements jitter

Why it happens:

• gain amplifies weak signal and noise
• lighting or exposure is insufficient
• gain was used as a shortcut

How engineers handle it:

• reduce gain if possible
• improve lighting intensity or exposure
• check noise metrics
• log gain values with inspection results
• prevent recipes from using unsafe gain ranges

---

4. Focus Score Passes but Inspection Is Still Unstable

What it looks like:

• focus metric says OK
• edge measurements still fluctuate
• defects appear inconsistent
• some regions are sharp, others are not

Why it happens:

• focus metric checks the wrong region
• wafer or product is not flat
• image has local blur
• focus score threshold is too weak
• lighting creates artificial sharpness

How engineers handle it:

• calculate focus score on relevant regions
• use multiple regions when needed
• correlate focus score with measurement stability
• review actual failed images, not only metric values

---

5. Reflective Surface Causes Saturation

What it looks like:

• bright white hotspots
• missing texture in shiny regions
• defects disappear inside saturated areas
• false pass or false fail depending on algorithm

Why it happens:

• light reflects directly into camera
• intensity is too high
• angle is wrong
• exposure is too long

How engineers handle it:

• check saturation percentage
• adjust illumination angle or intensity
• reduce exposure
• use recipe-specific lighting profiles
• reject images with excessive saturation

---

6. Strobe Timing Mismatch Causes Inconsistent Brightness

What it looks like:

• same recipe gives different brightness frame to frame
• some images are darker
• issue appears random
• manual capture may work, automatic capture fails

Why it happens:

• light strobe does not align with camera exposure window
• trigger delay is wrong
• hardware timing is inconsistent
• motion/capture sequence is not synchronized

How engineers diagnose it:

• log trigger timestamps
• compare camera exposure timing and light strobe timing
• test with stationary object
• use hardware timing traces if available
• separate acquisition success from illumination correctness

---

7. Recipe Uses Wrong Illumination Profile

What it looks like:

• one product type fails unexpectedly
• another product type works fine
• images look valid but contrast is poor
• operators may select wrong recipe or wrong variant

Why it happens:

• recipe parameter mapping error
• copied recipe not updated
• wrong light channel
• wrong intensity or exposure
• missing compatibility validation

How engineers handle it:

• version illumination profiles
• validate recipe compatibility
• log active recipe + imaging parameters with every image
• provide operator-visible imaging setup information
• prevent silent fallback to default settings

---

PART 8 — SOFTWARE DESIGN IMPLICATIONS

Image quality control must be explicit in architecture.

Bad design:

Camera.Capture()
Inspection.Run(image)

This assumes every image is trustworthy.

That is dangerous.

A stronger design looks like this:

+----------------+
| Recipe Manager |
+-------+--------+
        |
        v
+-----------------------+
| Imaging Setup Service |
| - camera parameters   |
| - light parameters    |
| - focus settings      |
+-------+---------------+
        |
        v
+-----------------------------+
| Camera + Light Controller   |
+-------+---------------------+
        |
        v
+----------------+
| Acquisition    |
+-------+--------+
        |
        v
+-------------------------+
| Image Quality Validator |
+-------+-----------------+
        |
        v
+---------------------+
| Inspection Pipeline |
+---------------------+

Key Architecture Practices

1. Recipe-Based Imaging Parameters

Exposure, gain, light intensity, light channel, strobe mode, and focus settings should usually come from recipe/configuration, not hard-coded values.

Bad:

camera.Exposure = 5000;
light.Intensity = 80;

Good:

imagingSetup.Apply(recipe.ImagingProfile);

The recipe should define what imaging conditions are expected for a product or inspection step.

2. Illumination Controller Abstraction

Software should not scatter light-control calls throughout the codebase.

Create a clear abstraction:

+-----------------------------+
| ILightController            |
+-----------------------------+
| SetIntensity(channel, value) |
| Enable(channel)             |
| Disable(channel)            |
| ConfigureStrobe(profile)    |
| GetStatus()                 |
+-----------------------------+

This gives you:

• testability
• simulation support
• logging
• consistent error handling
• vendor independence

3. Image Quality Validation Step

The system should validate image quality before inspection.

Capture -> Validate -> Inspect

Not:

Capture -> Inspect blindly

The validator can check brightness, saturation, focus score, contrast, noise, and uniformity.

4. Logging Image-Quality Metrics

For every important image, log:

• recipe ID
• camera ID
• exposure
• gain
• light profile
• focus position
• brightness metric
• saturation percentage
• sharpness score
• acquisition timestamp
• motion position if relevant
• quality validation result

This is extremely useful during production debugging.

Without this, engineers only see “inspection failed” but cannot know whether the image was bad.

5. Clear Failure / Retry Policy

Image quality failure needs an explicit policy.

Example:

Quality Fail
    |
    +--> Reacquire once?
    |
    +--> Refocus?
    |
    +--> Adjust lighting?
    |
    +--> Reject frame?
    |
    +--> Stop machine?
    |
    +--> Raise alarm?

Do not let each inspection module invent its own behavior.

6. Calibration and Maintenance Awareness

Image quality changes over time.

Software should support:

• illumination calibration
• focus calibration
• reference image capture
• maintenance reminders
• dirty optics detection hints
• drift trending
• service diagnostics

Strong machine software treats imaging stability as a lifecycle concern, not a one-time setup.

---

PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS

A strong interview answer could sound like this:

In industrial vision, I would not treat camera capture as simply receiving an image buffer. The reliability of the inspection depends heavily on whether the imaging conditions are valid: lighting, exposure, gain, focus, motion state, and recipe context. So I would design the system with an explicit imaging setup step, controlled illumination, recipe-based parameters, and an image-quality validation gate before inspection. If quality fails, the workflow should have a defined recovery path such as reacquire, refocus, adjust lighting, or raise an alarm. I would also log image-quality metrics with every inspection result so production issues can be diagnosed later.

Common mistakes software engineers make:

• assuming a captured image is automatically valid
• hard-coding camera and light settings
• treating brightness as the only quality indicator
• increasing gain to fix dark images without considering noise
• ignoring saturation on reflective surfaces
• not tying imaging parameters to recipe context
• not logging exposure/gain/light/focus values with results
• letting inspection algorithms handle bad images silently
• designing no recovery path for image-quality failure

What strong engineers understand:

• lighting changes what defects are visible
• exposure affects brightness but can cause blur
• gain improves apparent brightness but increases noise
• focus affects measurement repeatability
• image quality must be validated before inspection
• recipes must own imaging conditions
• production failures often come from imaging instability, not algorithm bugs
• diagnostics matter as much as the first implementation

The key principle:

In industrial vision software, image quality is part of machine control. The system must set it, validate it, log it, and react when it is not trustworthy.