How to Write a Stray-Light Requirement and Verification Plan

A useful stray-light requirement identifies the unwanted source, geometry, spectrum, polarization when relevant, source intensity, scene or background, optical state, detector and processing state, environmental condition, measurement plane, metric, threshold, and verification method. Requiring simply ‘low stray light’ cannot guide design or support acceptance.

Why this decision matters

This choice affects more than nominal optical performance. It changes package volume, tolerance sensitivity, supplier options, alignment effort, calibration, test equipment, production yield, and the evidence required before release. The correct answer therefore comes from the complete operating condition and acceptance method, not from a single catalog value.

Key engineering decisions

Separate in-field ghosts, out-of-field veiling glare, scatter, thermal background, fluorescence, detector reflections, and contamination effects.
Define source-angle and spectral envelopes from the real sun, lamp, laser, display, hot structure, or illuminated scene.
Allocate unwanted signal among coatings, surfaces, edges, barrel paths, apertures, baffles, windows, detector stack, and processing.
Choose simulation, component measurement, subsystem bench test, calibrated source scan, or field test according to the dominant path and program stage.

These decisions should be captured in a requirement or trade study before the team commits long-lead components. Where requirements conflict, rank the product priorities explicitly so optimization does not hide a business decision.

Specification checklist

Source radiance or power, spectrum, size, polarization, distance, and angular envelope
Desired scene signal, background, exposure, gain, detector, and processing configuration
Optical focus, zoom, aperture, field, window, coating, cleanliness, and thermal state
Metric such as ghost ratio, point-source transmittance, veiling glare, or signal-to-background loss
Threshold, scan resolution, calibration, uncertainty, environment, and pass/fail method

Every value should state the condition where it applies and how it will be measured. A specification without a defined test condition is not yet an acceptance requirement.

Common failure mode

A non-sequential model reports low ghost energy for a few nominal source angles, while an unmodeled detector reflection, edge path, mount gap, coating variation, contamination state, or exposure setting dominates the measured system.

The practical remedy is to compare the nominal model, tolerance prediction, mechanical interfaces, and measured configuration together. Treating the symptom as an isolated lens or component problem often produces another build with the same system-level limitation.

Verification approach

Maintain a source-path-detector matrix linking modeled contributors to physical tests. Scan representative angle and spectrum, use calibrated source and dark/background controls, preserve raw detector data, verify dynamic range, and compare the as-built configuration with the model.

Record the hardware revision, source or scene, wavelength, aperture, field point, focus or alignment state, environmental condition, processing, and measurement uncertainty. This makes the result useful for design iteration and supplier transfer rather than only for a one-time demonstration.

What to send PAO

Send the unwanted source and geometry, desired scene, spectral bands, detector and processing settings, optical layout and CAD, coatings and surface properties, environment, observed artifact images, and the system-level performance loss that must be limited.

Related engineering decisions

PAO applies this framework through custom optical design, from requirements and architecture through detailed design, prototype evidence, and manufacturing transfer.