Kyle M. Douglass (Posts about optics)

Ray-Surface Intersections with the Newton-Raphson Algorithm

Kyle M. Douglass — Thu, 09 Apr 2026 18:26:02 GMT

A few weeks ago I restarted work on Cherry, my sequential ray tracer, by porting the GUI from Javascript/React to pure WASM with egui. I am very happy with the results. It's much easier to add features with egui, and I have no regrets about giving up the DOM in the web application. I was never very good at web developement, and I always felt that React has too much unseen magic happening behind the scenes.

Having gotten the frontend work out of the way, I turned my attention back to adding features to Cherry. One of the applications that interests me in the lab is scan lenses, i.e. lenses that translate an angular deviation of a laser beam into a lateral displacement. These lenses are designed so that their scanning plane is as flat as possible over a large field of view. They often must work across multiple wavelengths and at large field angles.

As a starting point, I put the f-theta scan lens example from Optiland, which itself comes from Milton Laikin's Lens Design, 4th ed., into Cherry and began varying the incident field angle. It did not take long before problems in the ray tracing routine appeared.

At a field angle of exactly 5.6 degrees, the marginal ray from the Fraunhofer C line ( $ \lambda = 0.6563 \, \mu m$ ) reflects backwards off the first lens surface and intersects the origin. It propagates correctly for field angles of 5.5 degrees and 5.7 degrees, which to me suggests that there is a numerical accident that happens at exactly this value. Furthermore, the spot diagram shows ray-surface intersections across all wavelengths in the image plane disappearing and reappearing randomly as the field angle increases, with the overall number of ray trace errors increasing with field angle. Small angles do not seem to have the problem, and indeed I had not yet tried examples with highly curved surfaces such as this f-theta lens.

As it turns out, the cause of this problem was a silly bug that came from code I wrote three years ago. At the time, I didn't truly and fully understand the Newton-Raphson (NR) root finding algorithm for finding ray-surface intersections. I wanted surface normal vectors to always be unit vectors by convention, and this subtlety ended up degrading and in some cases, ruining the algorithm's ability to find the intersection point, especially at large angles of incidence.

This post is a recap about my journey in debugging the issue and better understanding the NR algorithm. I hope you learn as much as I did from it.

Debugging Ray-Surface Intersections

Running Traces through Algorithms

In practice there are a lot of ray-surface intersections to compute; tracing 1000 rays through 8 surfaces, for example, yields 8000 intersections. This means the algorithm loops 8000 individual times. When only a subset of these fail, it pays to have good debugging tooling in place to identify the state of the algorithm during a failure.

For this I turned to the excellent tracing crate, which has become something of a de facto standard for logging in Rust. The primary abstractions in tracing are events and spans. Events are the most straightforward to understand because they are the same thing as log messages in other languages.

tracing's documentation provides a good, high-level explanation of spans¹:

Unlike a log line that represents a moment in time, a span represents a period of time with a beginning and an end. When a program begins executing in a context or performing a unit of work, it enters that context’s span, and when it stops executing in that context, it exits the span.

The value in using spans is that you can attach data to them, forming a context. Every event that is emitted during a span is associated with this data, regardless of where the event was emitted. In pseudocode, my ray tracing algorithm roughly works like this:

for field in fields.iter():
  for (surface_id, surface) in surfaces.iter().enumerate():
    for (ray_id, ray) in rays.iter().enumerate():
        // coordinate system transformations

        intersect(ray, surface)

        // ray transformations
        // coordinate system transformations

When an intersection failure occurs, I'd like to know the ray_id, but I'd also like to know the state of variables inside the intersection method. Using spans, I do not have to thread ray_id inside the intersect method to attach it to log messages. Instead, I create a span at the top of the inner-most loop that contains ray_id in its context. Then, any events inside the intersection method will be associated to that context. I can then filter by, say, ray_id=42 to see all events that happened for that ray inside intersect().

for field in fields.iter():
  for (surface_id, surface) in surfaces.iter().enumerate():
    for (ray_id, ray) in rays.iter().enumerate():
        let _span = trace_span!("trace_ray", ray_id, surface_id).entered();  // <-- Span begins
        // coordinate system transformations                                        |
                                                                                    |
        intersect(ray, surface)                                                     |
                                                                                    |
        // ray transformations                                                      |
        // coordinate system transformations                                        |
        // <----------------------------------------------------------------------- Span ends

A Failing Test Case

I recreated the same lens in an integration test with a single wavelength at $ \lambda = 0.5876 $ and an off-axis tangential ray fan consisting of 9 rays and incident at 20 degrees. I simplified the test case to reduce the total number of errors, which in turn allowed me to better isolate problems. There were two notable types of errors. In the first, I saw NaNs appear in some of the values manipulated by the Newton-Raphson algorithm:

  2026-03-26T07:49:32.552835Z ERROR cherry_rs::views::ray_trace_3d::rays: Ray intersection did not converge, ctr: 999, s: NaN, residual: NaN
    at cherry-rs/src/views/ray_trace_3d/rays.rs:97

  2026-03-26T07:49:32.552896Z ERROR cherry_rs::views::ray_trace_3d::trace: Ray terminated due to intersection failure, ray_id: 8, surface_id: 2, reason: Ray intersection did not converge
    at cherry-rs/src/views/ray_trace_3d/trace.rs:57

In the second type of error, the ray-surface intersection simply did not converge.

  2026-03-26T07:49:32.553113Z ERROR cherry_rs::views::ray_trace_3d::rays: Ray intersection did not converge, ctr: 999, s: 0.339233626291856, residual: -2.220446049250313e-16
    at cherry-rs/src/views/ray_trace_3d/rays.rs:97

  2026-03-26T07:49:32.553139Z ERROR cherry_rs::views::ray_trace_3d::trace: Ray terminated due to intersection failure, ray_id: 3, surface_id: 3, reason: Ray intersection did not converge
    at cherry-rs/src/views/ray_trace_3d/trace.rs:57

The first type of error was easy to fix. The NaN occurs because the first guess at the intersection point lies further from the axis than the surface's radius of curvature. To correct for this, I now check for NaNs and bisect the guess backwards until I am inside the domain of the surface.

The second error type was the tricky one, and I'll spend the rest of this post discussing it.

The Newton-Raphson Algorithm

At this point while debugging, I began to feel like I needed a refresher in the NR algorithm. It has been about three years since I first implemented it and quite frankly I have forgotten a lot of the details. So I'm going to circle back to the basics to better prepare myself to fix this thing.

Root Finding

The Newton-Raphson algorithm is a well-known numerical routine for finding the roots (a.k.a. zeros) of a function. I think it's best illustrated by way of example. I found one at https://atozmath.com/example/CONM/Bisection.aspx?q=nr&q1=E1 that involves finding the single zero of the function $ f(x) = x^3 - x - 1 $. The function is plotted below:

The algorithm is derived as follows: assume we want to find the root of a function $ f(x) $. Choose a starting point $ x_0 $ close to the root and find the slope of the line tangent to the curve of the function at this point. Extend this line to $ x_1 $, the x-intercept where $ y = 0 $. The expression for the slope of $ f (x) $ at $ x_0 $ is

$$ f'(x_0) = \frac{\Delta y}{ \Delta x} = \frac{f(x_0) - f(x_1)}{x_0 - x_1} = \frac{f(x_0) - 0}{x_0 - x_1}. $$

Below you can see what this construction looks like using $ x_0 = 1.5 $.

Solving this expression for $ x_ 1 $ gives

$$ x_1 = x_0 - \frac{f(x_0)}{f'(x_0)}. $$

Repeat the process using $ x_1 $ as the new starting point:

$$ x_2 = x_1 - \frac{f(x_1)}{f'(x_1)}. $$

The more you repeat the process, the closer you get to the root.

Before I Go On, Some Vocabulary

The function $ f(x) $ is often called the residual in the NR literature because it can be thought of as a distance-based error from the the value $ f(x) = 0 $.

As far as I can tell there's no standard term for $ f'(x) $. I'll refer to it as the denominator for simplicity. Once I reach the part of this post on surface representations, I will also refer to it as the surface normal because it is related to the normal vector to the lens surface.

Termination Criteria

There are two common stopping criteria for NR. In the first, you stop iterating whenever the difference between successive steps $ x_i $ and $ x_{i+1} $ is less than some tolerance. In the second, you stop when $ | f(x_n) | $ is less than some tolerance. You can also combine the two so that you stop when either is satisfied. This helps terminate the algorithm when it is converging so slowly that $ \Delta x_i $ is large even but the residual is small.

Here are the first six iterations of the algorithm for finding the root of $ f(x) = x^3 - x - 1 $ when starting at $ x_0 = 1.5 $.

After 6 steps, the algorithm has identified the root $ x = 1.324718 $ with a precision better than $ 10^{-6} $.

Oscillations

Now of course I deliberately diverted your attention away from the important point that you need to choose the starting point such that it is already close to the root. Here's what happens when I choose a starting point close the local maximum at -0.5:

The algorithm struggles to converge because the initial tangent line is nearly horizontal. This results in the next guess being very far off target and ultimately the algorithm oscillates irregularly around the starting point. However, at step 12, it happens to land just to the right of the local minimum at $ x = 0.7425 $, which sends the next guess far to the right of all local extrema.

From this point, the algorithm can simply descend downhill, where by step 19 it has found the root with a tolerance better than $ 10^{-6} $.

Convergence Guarantees

If the starting point is close to the root, the Newton-Raphson algorithm has quadratic convergence. This means that the error $ \epsilon_{i+1} $ in step $ i + 1 $ is proportional to the square of the error at the previous step, $ \epsilon_i^2 $. But if the starting point is not sufficiently close, then the algorithm can display quite erratic behavior and the assumptions that led to the conclusion about quadratic convergence are no longer valid.

The Importance of the Magnitude of $ f'(x) $

The preceding discussion demonstrates that the choice of starting point is of great importance. Is there some way to identify a good or bad starting point?

The above figure shows that when the slope of the tangent line is small, the next guess is relatively far away from the current position. Oscillations are more likely to occur when this happens, especially when local extrema are between the trial position and the root.

Conversely, when the slope of the tangent line is large, the next guess is relatively close to the current position. This is what happened with an initial guess of 1.5 as seen here.

We can see this behavior by rewriting the equation for the next guess $ i + 1 $ as:

$$\begin{eqnarray} x_{i+1} &=& x_i - \frac{f(x)}{f'(x)} \\ x_{i+1} - x_i &=& - \frac{f(x)}{f'(x)} \\ \Delta x_i &=& - \frac{f(x)}{f'(x)} \end{eqnarray}$$

So two quantities determine the magnitude of the step. Large step sizes occur when:

the residual function $ f(x) $ is large, and
the magnitude of $ f'(x) $ is small.

The magnitude of $ f'(x) $ is therefore an indicator of the likelihood of convergence problems. In the extreme case of $ f'(x) = 0 $, the NR algorithm will never converge because of a division by zero in the above equation.

Ray-Surface Intersections

The central problem in ray tracers is to find the 3D intersection of a ray with a surface. The problem has analytical solutions when the surface is planar or spherical, though care must be taken to avoid numerical artifacts such as catastrophic cancellation in their solutions².

When a surface is not flat or spherical, however, we turn to numerical routines such as NR. One early paper describing the approach was from Spencer and Murty in 1962. Spencer and Murty were particularly interested in tracing rays through systems containing general surface shapes like conic section surfaces, aspheres, cylinders, and toroids. They were also interested in an algorithm that would easily accommodate new surface types.

Ray Parameterization

Regardless of whether you use an analytical or numerical solution, you usually approach the problem by first expressing ray propagation in parametric form. I illustrate this construction below:

A ray is defined by two, 3D vectors $ \vec{p} $ and $ \hat{d} $. The position vector $ \vec{p} $ points to any point on the ray. $ \hat{d} $ is a vector of unit magnitude whose elements are the direction cosines of the ray. The parameter $ s $ denotes the distance along the ray from the point $ \vec{p} $ so that the set of all points on the ray is expressed as

$$ \vec{r}(s) = \vec{p} + s \hat{d}. $$

When $ s = 0 $, we are at the point $ \vec{p} $ on the ray. Increasing $ s $ moves us in the direction of the ray; decreasing it moves in the opposite direction.

Surface Representations

An implicit representation of a surface in 3D is

$$ F ( x, y, z) = 0. $$

Seen this way, a surface is the zero level set of a 3D scalar function.

A more useful representation for optical design is to place a single vertex or point of the surface at the origin and let the $ z $ axis represent the optical axis. Let the so-called surface sag, or $ sag(x, y) $, represent the distance from the $ z = 0 $ plane to the surface for all points $ x, y $ within the aperture of the surface³.

We can now rewrite $ F $ as

$$ F(x, y, z) = z - \text{sag}(x, y) = 0 $$.

Saggita for Rotationally Symmetric Conic Section Surfaces

The most common surface types used in optical design are

flat surfaces, and
rotationally symmetric conic section surfaces, also known as quadrics of rotation.

The surface sag of a flat surface is zero everywhere in the local coordinate system of the surface, which by my definition is the $ z=0 $ plane.

A conic section surface is a surface whose intersection with a plane is a conic section curve, i.e. a circle, parabola, hyperbola, or ellipse. The surface sag of a rotationally symmetric conic section surface with a vertex at the origin and oriented along the $ z $ direction is

$$ \text{sag}(r) = \frac{r^2 C}{1 + \sqrt{1 - (1 + K) C^2 r^2}} $$

where $ r = \sqrt{x^2 + y^2} $ is the radial distance from the origin and $ C $ is the curvature of the surface⁴. It is expressed in terms of curvature and not radius of curvature $ R $ to avoid numeric difficulties with flat surfaces where $ R = \pm \infty $.

The conic constant $ K $ determines the conic's type. The types are defined by:

Hyperbola : $ K < -1 $
Parabola : $ K = -1 $
Ellipse : $ K > -1 $
Circle (special case of an ellipse): $ K = 0 $

The implicit surface representation for a conic section surface is

$$ F (x, y, z) = z - \frac{r^2 C}{1 + \sqrt{1 - (1 + K) C^2 r^2}} = 0 $$.

Partial Derivatives of Rotationally Symmetric Conic Section Surfaces

The last bit of information that I need to calculate ray intersections with conic section surfaces are their partial derivatives. I got these by hand by computing them in polar coordinates and converting them back to Cartesian coordinates using the chain rule. The results are

$$\begin{eqnarray} \frac{\partial F}{ \partial x} &=& \frac{-x C}{\sqrt{1 - (1 + K) C^2 (x^2 + y^2)}} \\ \frac{\partial F}{ \partial y} &=& \frac{-y C}{\sqrt{1 - (1 + K) C^2 (x^2 + y^2)}} \\ \frac{\partial F}{ \partial z} &=& 1 \end{eqnarray}$$

Newton-Raphson for Ray-Surface Intersections

The NR algorithm for computing ray intersections with general surfaces is

$$s_{i+1} = s_i - \frac{F(x,y,z)}{\nabla F (x, y, z) \cdot \hat{d}}.$$

I think most notable is that the denominator has been replaced with the directional derivative of the surface's equation along the direction of the ray's propagation. Another thing worth noting is that $x$, $y$, and $z$ are constrained to lie on the ray by writing $x = p_x + sl $ and so on for the other two quantities⁵.

At this point I'm at last able to understand where problems in the Newton-Raphson algorithm for ray tracing arise. Remember that oscillations and non-convergence often occur when the derivative of the residual is small or there are local extrema between the starting point and the actual root. In ray tracing, the derivative is expressed as $ \nabla F (x, y, z) \cdot \hat{d} $. This can become small when:

A ray is traveling nearly parallel to the surface at a point $ x, y $.
The gradient of $ F $ is small.

Geometrical Interpretation of Newton-Raphson Failures

I think the small gradient of $ F $ is more easily understood geometrically. To see this, consider that the $ \nabla F $ is parallel to the surface normal vector at all points on the surface. I can write this as a product of the magnitude of the normal vector and a unit vector pointing in its direction:

$$ \nabla F = |\eta| \hat{\eta}. $$

Now the denominator in the NR update equation is the dot product of the above expression with the direction of the ray, or $ |\eta| \hat{d} \cdot \hat{\eta} $. But both $ \hat{d} $ and $ \hat{\eta} $ are unit vectors, so I can replace their dot product with the cosine of the angle $ \alpha $ between them:

$$ \nabla F \cdot \hat{d} = |\eta| \cos \alpha. $$

So the directional derivative becomes small for large angles of incidence and small normal vectors.

Normal Vectors and Surface Representations

There are two parts of the gradient that can make the denominator in the Newton-Raphson update equation small:

The magnitude of the normal vector $ | \eta |$
The angle between the ray direction cosine vector and the unit normal vector $\hat{d} \cdot \hat{\eta} = \cos \alpha $

To get a sense of the magnitude of the normal vector, consider the plot of the gradient of $ F $ as a function of radial distance from the vertex of the curved surface of a $f = 50 \, mm$, 1" diameter, spherical, convexplano lens. The radius of curvature of this surface is 25.8 mm.

Compare this to the same plot but for the first surface of the scan lens from the beginning of this post, whose radius of curvature is -2.2136 mm.

In neither case is the gradient very small, and we are in some sense rescued by the fact that $ \frac{\partial F}{\partial x} $ is 1 everywhere.

But wait. Shouldn't the normal vector of a spherical surface be a vector of constant magnitude and perpendicular to the surface everywhere? I expected this:

But got this:

So the magnitude of the normal vector varies with distance from the z-axis⁶. And though it's hard to see in these plots, the "normal vectors" are not normal to the surface except at $ x = y = 0 $!

I was really disturbed by this at first. As it turns out, this is due to representing the surface by its sag, which is effectively a height field above the xy plane. If instead I had used the sphere's symmetric implicit form $F_s = x^2 + y^2 + (z - R)^2 - R^2 = 0 $ then I would have obtained a normal vector whose magnitude was constant everywhere on the sphere. This is because

$$\begin{eqnarray} \frac{\partial F_s}{ \partial x} &=& 2x \\ \frac{\partial F_s}{ \partial y} &=& 2y \\ \frac{\partial F_s}{ \partial z} &=& 2(z - R). \end{eqnarray}$$

In other words, representing the sphere as a height field has the effect of breaking spherical symmetry with respect to its normal vector⁷.

All of this aside, the magnitude of the normal vector doesn't really become that large in the scan lens example, so the cause of the Newton-Raphson failure is likely coming from near-grazing incidence rays where $\cos \alpha \approx 0 $.

Back to Debugging

At this point I wanted to confirm that the problematic rays were at near-grazing incidences, so I turned back to the code. Here is a trace of the first five NR iterations of one particular ray that fails to converge at the first surface of the lens:

 2026-04-09T07:25:02.768031Z TRACE cherry_rs::views::ray_trace_3d::rays: intersect_init, pos_x: 3.0616169978683836e-17, pos_y: 0.5, pos_z: -5.0, dir_l: 2.094269368838496e-17, dir_m: 0.3420201433256687, dir_n: 0.9396926207859084, s_init: 5.320888862379561
    at cherry-rs/src/views/ray_trace_3d/rays.rs:69
    in cherry_rs::views::ray_trace_3d::rays::intersect
    in cherry_rs::views::ray_trace_3d::trace::trace_ray with ray_id: 8, surface_id: 2

  2026-04-09T07:25:02.768093Z TRACE cherry_rs::views::ray_trace_3d::rays: newton-raphson iteration data, ctr: 0, s: 4.775443550511577, s_1: 0.0, p_x: 8.633304277606096e-17, p_y: 1.4099255856655057, p_z: -2.5, sag: -0.5071021819862234, residual: -1.9928978180137766, denom: 0.94226
88642314074
    at cherry-rs/src/views/ray_trace_3d/rays.rs:125
    in cherry_rs::views::ray_trace_3d::rays::intersect
    in cherry_rs::views::ray_trace_3d::trace::trace_ray with ray_id: 8, surface_id: 2

  2026-04-09T07:25:02.768118Z TRACE cherry_rs::views::ray_trace_3d::rays: newton-raphson iteration data, ctr: 1, s: 2.8626356840250526, s_1: 4.775443550511577, p_x: 1.306268214832213e-16, p_y: 2.1332978875896096, p_z: -0.5125509346046124, sag: -1.6227826993006131, residual: 1.110
2317646960007, denom: 0.5804199073769454
    at cherry-rs/src/views/ray_trace_3d/rays.rs:125
    in cherry_rs::views::ray_trace_3d::rays::intersect
    in cherry_rs::views::ray_trace_3d::trace::trace_ray with ray_id: 8, surface_id: 2

  2026-04-09T07:25:02.768148Z TRACE cherry_rs::views::ray_trace_3d::rays: newton-raphson iteration data, ctr: 2, s: 4.7418998688939, s_1: 2.8626356840250526, p_x: 9.056747225066086e-17, p_y: 1.479079066939422, p_z: -2.3100023717232365, sag: -0.5666786072973584, residual: -1.74332
3764425878, denom: 0.9276629536509492
    at cherry-rs/src/views/ray_trace_3d/rays.rs:125
    in cherry_rs::views::ray_trace_3d::rays::intersect
    in cherry_rs::views::ray_trace_3d::trace::trace_ray with ray_id: 8, surface_id: 2

  2026-04-09T07:25:02.768181Z TRACE cherry_rs::views::ray_trace_3d::rays: newton-raphson iteration data, ctr: 3, s: 2.997895475725084, s_1: 4.7418998688939, p_x: 1.299243264339216e-16, p_y: 2.1218252727950615, p_z: -0.5440716846947353, sag: -1.5828207424715346, residual: 1.038749
0577767993, denom: 0.5956114914879407
    at cherry-rs/src/views/ray_trace_3d/rays.rs:125
    in cherry_rs::views::ray_trace_3d::rays::intersect
    in cherry_rs::views::ray_trace_3d::trace::trace_ray with ray_id: 8, surface_id: 2

  2026-04-09T07:25:02.768222Z TRACE cherry_rs::views::ray_trace_3d::rays: newton-raphson iteration data, ctr: 4, s: 4.714415826981489, s_1: 2.997895475725084, p_x: 9.340017663658938e-17, p_y: 1.525340640282867, p_z: -2.182899743573678, sag: -0.6094301551576737, residual: -1.57346
95884160044, denom: 0.9166623554823017
    at cherry-rs/src/views/ray_trace_3d/rays.rs:125
    in cherry_rs::views::ray_trace_3d::rays::intersect
    in cherry_rs::views::ray_trace_3d::trace::trace_ray with ray_id: 8, surface_id: 2

In table form:

ctr	s (after step)	residual	denominator
0	4.775	-1.993	0.942
1	2.863	1.110	0.580
2	4.742	-1.743	0.928
3	2.998	1.039	0.596
4	4.714	-1.573	0.917

The denominator is not anywhere near small enough to indicate that the problem is caused by near-grazing incidence angles, so there must be something else going on.

The first thing to note is that the residual $z - \text{sag} (x, y) $ is oscillating in sign which indicates that the algorithm is hopping back and forth between different sides of the surface. The root estimate s appears to slowly be converging to some value but hasn't yet done so. In fact, it took 100,000 iterations to converge to within 0.0004 of the root, which was somewhere around s=4.14. This rate of convergence is much too slow. What could be causing it?

I plotted the residual function and it didn't seem too bad:

I then plotted the NR steps for this particular ray and found that I could not reproduce the oscillations. In fact, NR converged quite rapidly.

So my two different implementations did not agree. After about 2 hours of digging I found the problem: I was normalizing the normal vector to 1 in the Rust code rather than retaining its magnitude.

// 💣💣💣
let norm = Vec3::new(dfdx, dfdy, dfdz).normalize();
// 💣💣💣

This has a subtle effect on the value of the NR denominator such that the step size isn't quite what it should be.

I can't begin to explain to you how subtle this bug was. I nearly face-palmed by head off when I found it. It was in code that I wrote nearly three years ago. Smart people can do really dumb things with computers.

Discussion

I am actually quite happy to have had to solve this bug even if there was no deeper, numerical reason behind it. It forced me to do a deep dive into the Newton-Raphson algorithm and I feel much more knowledgable as a result. Still, it's frustrating because I clearly was experimenting in the early days, and I wonder whether some other careless coding choices still await to be discovered.

I only briefly mentioned it, but in this journey I also implemented a fallback to a bisection method when the initial NR guess fails due to a negative discriminant in the sag function of a conic section surface. I think this is a win because rays that would have initially failed can be recovered by the fallback routine. But what's more, both of these changes led to some impressive improvements in the benchmark tests: the convexplano lens example runs 43% faster because of faster NR convergence and fewer early ray terminations.

Out of curiosity I looked into what Optiland does to compute Ray-Surface intersections. I believe that it analytically computes intersections for flat and spherical surfaces and falls back to NR when things get more complicated. I use NR for everything, and to be honest, I'm happy with this approach so far. The ray-surface interection function in my ray tracer is a single long function, but it reads linearly and is very clear about what it does. If I were to add if/else branches to check for surface types (or, more properly, employ polymorphism to make the intersection logic a Surface-level method), then the logic would diffuse throughout the codebase. An essay by John Carmack on inlining code that I read a couple years ago had a profound effect on me when it comes to mission-critical, high performance sections of code. Ray-surface intersection logic is one such example where "good" software engineering practices are counter-productive, and just inlining the whole damn thing makes a lot of sense.

The real lesson here is that it always pays to really understand what your algorithms are doing, and having the proper tooling in place for debugging pays off enormously.

Happy ray tracing.

Spans remind me a lot of Sentry, which I used to perform tracing on distributed code bases when I worked for a photogrammetry company doing image processing on the Cloud. ↩
See for example Chapter 7 of Ray Tracing Gems. ↩
When I first learned this term, I thought the name came from the idea that the surface "sags" away from the $z=0$ plane. As it turns out, it's short for sagitta, the Latin word for arrow. ↩
Surface curvature is related to the radius of curvature $ R $ as $C = 1 / R $. ↩
$l^2 + m^2 + n^2 = 1 $ are the direction cosines of the ray. ↩
I don't show this, but for a lens with positive curvature, the normal vectors point to the left in these plots for the symmetric implicit representation. In other words, it always points outwards from the sphere's center in the symmetric implicit representation, but in the +z direction in the saggital representation. ↩
There is a name for this height field representation in the theory of surfaces; it's called the Monge patch. ↩

Completing the Square and the Normal Form of Quadrics

Kyle M. Douglass — Mon, 07 Jul 2025 06:42:35 GMT

I am working on rendering cross section views of optical systems for my ray tracer. The problem is one of finding the intersection curve between a plane (the cutting plane) and a quadric surface which represents an interface between two media with different refractive indexes. Quadric surfaces are important primitives for modeling optical interfaces because they represent common surface types in optics, such as spheroids and paraboloids. A pair of quadrics, or a quadric and a plane, models a common lens.

In 3D, the implicit surface equation for a quadric is

$$ A x^2 + B y^2 + C z^2 + D x y + E y z + F x z + G x + H y + I z + J = 0 $$

Any quadric can be reduced to a so-called normal form that identifies its class, i.e. ellipsoid, hyperbolic paraboloid, etc. Except for paraboloids, none of the normal form equations contain linear terms in $ x $, $ y $, or $ z $.

A quadric of revolution occurs when two or more of the parameters of the the quadric's normal form are equal, such as $ x^2 / R^2 + y^2 / R^2 + z^2 / R^2 = 1 $, which is the equation for a spheroid with radius parameter $ R $¹. Quadrics of revolution are the surface types most-often encountered in optics².

The surface sag of a quadric surface is a very important quantity for ray tracing. The sag of a quadric is usually given in terms of the conic constant, $ K $. One obtains the sag by solving the following quadric equation for $ z $:

$$ x^2 + y^2 - 2 R z + ( K + 1 ) z^2 = 0 $$

Here, $ R $ is the radius of curvature of the surface at its apex, $ x = y = z = 0 $.

At this point I asked myself how I could rewrite the above expression in its normal form, and for a while I was unable to do it. After a bit of searching on the internet, I eventually realized that the solution involves completing the square, a topic that was not given much attention during my high school education. After this exercise, I realize now that the purpose of completing the square is to essentially move any linear terms of a quadratic equation into squared parantheses. This allows one to then remove the linear terms entirely by applying a suitable transformation, leaving only quadratic and constant terms.

Converting the Quadric to its Normal Form

The conversion of the above equation proceeds as follows. We first factor out $ ( K + 1 ) $ from the terms involving $ z $.

$$ x^2 + y^2 + ( K + 1 ) \left[ z^2 - \frac{ 2 R z }{ K + 1 }\right] = 0 $$

Next, we "add zero" to the term inside the square brackets by adding $ [ 2 R / 2 ( K + 1 ) ]^2 - [ 2 R / 2 ( K + 1 ) ]^2 = [ R / ( K + 1 ) ]^2 - [ R / ( K + 1 ) ]^2 $:

$$ x^2 + y^2 + ( K + 1 ) \left[ z^2 - \frac{ 2 R z }{ K + 1 } + \left( \frac{ R }{ K + 1 } \right)^2 - \left( \frac{ R }{ K + 1 } \right)^2 \right] = 0 $$

We can understand this a bit more generally by considering the expression $ z^2 - a z $. Here I need to add and subtract $ ( a / 2 )^2 $. The reason is that now we can rewrite the first three terms inside the square brackets as a squared binomial:

$$ x^2 + y^2 + ( K + 1 ) \left[ \left( z - \frac{ R }{ K + 1 } \right)^2 - \left( \frac{ R } { K + 1 } \right)^2 \right] = 0 $$

These last two steps complete the square. To place the equation into its normal form, I apply the Euclidean transformation $ z' = z - \frac{ R }{ K + 1 } $ and carry through the $ K + 1 $.

$$ x^2 + y^2 + ( K + 1 ) z^{ \prime 2 } - R^2 / ( K + 1 ) = 0 $$

The above equation is almost a normal form expression for a quadric. To finish the job, I would need to substiute in a specific value for the conic constant and divide through so that the constant is either -1, 0, or 1.

The coefficients of each term need not be equal in general. ↩
A cylindrical lens does actually contain a quadric, but rather would consist of at least one toroidal surface. These are less common than lenses with spherical profiles, however. ↩

Why is Camera Read Noise Gaussian Distributed?

Kyle M. Douglass — Thu, 19 Jun 2025 08:40:12 GMT

As a microscopist I work with very weak light signals, often just tens of photons per camera pixel. The images I record are noisy as a result¹. To a good approximation, the value of a pixel is a sum of two random variables describing two different physical processes:

photon shot noise, which is described by a Poisson probability mass function, and
camera read noise, which is described by a Gaussian probability density function.

Read noise has units of electrons, which must be discrete, positive integers. So why is it modeled as a continuous probability density function²?

The Source(s) of Read Noise

Janesick³ defines read noise as "any noise source that is not a function of signal." This means that there is not necessarily one single source of read noise. It is commonly understood that it comes from somewhere in the camera electronics, but "somewhere" need not imply that it is isolated to one location.

The signal from a camera pixel is the number of photoelectrons that were generated inside the pixel. I imagine readout of this signal as a linear path consisting of many steps. The signal might change form along this path, such as going from number of electrons to a voltage. At each step, there is a small probability that some small error is added to (or maybe also removed from?) the signal. The final result is a value that differs randomly from the original signal.

Importantly, I do not think that it matters which physical process each step actually represents; rather there just has to be many of them for this abstraction to be valid.

"But aren't there only a handful of steps?" you might ask. After all, linear models of photon transfer typically consist of a few processes such as detection, amplification, readout, and analog-to-digital conversion. I am not referring to these when I use the term "step." Rather, I am referring to processes that are much more microscopic, such as passage of a signal through a transistor or amplifier chip. At the very least Johnson noise, or random currents induced by thermal motion of the charge carriers, will be present in all of the camera's components.

Read Noise is Gaussian because of the Central Limit Theorem

The reason for my conclusion that I can ignore the details so long as there are many steps is the following:

I can model the error introduced by each step as a random variable. Let's assume that each step is independent of the others. The result of camera readout is a sum of a large number of independent random variables. And of course the Central Limit Theorem states that the distribution of the sum of random variables tends towards a normal distribution, i.e. Gaussian, as the number of random variables tends towards infinity. This happens regardless of the distributions of the underlying random variables.

So read noise can appear to be effectively Gaussian so long as there are many steps along the path of conversion from photoelectrons to pixel values and each step has a chance of introducing an error.

Sums of Discrete Random Variables

I encountered one conceptual difficulty here: the sum of discrete random variables is still discrete. If I have several variables that produce only integers, their sum is still an integer. I cannot get, say, 3.14159 as a result. Does the Gaussian approximation, which is for continuous random variables, still apply in this case?

This question is relevant because the signal in a camera is transformed between discrete a continuous representations at least twice: from electrons to voltage and from voltage to analog-to-digital units (ADUs).

Let's say that I have a discrete random variable that can assume values of 0 or 1, and the probability that the value is 1 is denoted $ p $. This is known as a Bernoulli trial. Now let's say that I have a large number $ n $ of Bernoulli trials. But the sum of $ n $ Bernoulli trials has a distribution that is binomial, and this is well-known to be approximated as a Gaussian when certain conditions are met, including large $ n $⁴. So a sum of a large number of discrete random variables can have a probability distribution function that is approximated as a Gaussian.

This does not mean that the sum of discrete random variables can take on continuous values. Rather, the probability associated with any one output value can be estimated by a Gaussian probability density function.

But how exactly can I use a continuous distribution to approximate a discrete one? After all, if the random variable $ Y $ is a continuous, Gaussian random variable, then $P (Y = a) = 0 $ for all values of $ a $. To get a non-zero probability from a probability density function, I need to integrate it over some interval of its domain. I can therefore integrate the Gaussian in a small interval around each possible value of the discrete random variable, and then associate this integrated area with the probability of the obtaining that discrete value. This is called a continuity correction.

Example of a Continuity Correction

As a very simple example, consider a discrete random variable $ X $ that is approximated by a Gaussian continuous random variable $ Y $. The probability of getting a discrete value 5 is $ P (X = 5) $. The Gaussian approximation is $ P ( 4.5 \lt Y \lt 5.5 ) $, i.e. I integrate the Gaussian from 4.5 to 5.5 to compute the approximate probability of getting the discrete value 5.

I wrote a blog post about this a while back: https://kmdouglass.github.io/posts/modeling-noise-for-image-simulations/ ↩
This is often asserted without justification. See for example Janesick, Photon Transfer, page 34. ↩
https://doi.org/10.1117/3.725073 ↩
https://en.wikipedia.org/wiki/Binomial_distribution#Normal_approximation ↩

A Very Brief Summary of The Analytic Signal in Fourier Optics

Kyle M. Douglass — Tue, 01 Apr 2025 13:53:21 GMT

The Analytic Signal Representation of a Monochromatic Wave

Monochromatic Scalar Waves

A monochromatic, scalar waveform is described by the expression:

$$ u \left( \mathbf{r}, t\right) = A ( \mathbf{r} ) \cos \left[2 \pi f_0 t + \phi \left( \mathbf{r} \right) \right] $$

The signal is real-valued
The signal has a known phase for all $ t $

The Analytic Signal

An analytic signal is a generalization of a phasor. It is used to represent a real-valued signal as a complex exponential or a sum of complex exponentials. When Goodman¹ refers to a phasor, he often means the analytic signal. This is made clear in Chapter 6 where he describes the construction of the phasor for a narrowband signal as follows:

compute its Fourier transform
set the positive frequency components to zero
double the amplitudes of the negative frequency components
inverse Fourier transform the resulting one-sided spectrum

Strictly speaking, the analytic signal is obtained by setting the negative frequencies to zero and doubling by application of the Hilbert transform. However, many engineering fields have adopted the convention of setting the positive frequencies to zero instead. The results will be the same, except that the direction of power flow will be reversed (if I recall correctly).

The Fourier transform of $ u \left( \mathbf{r}, t\right) $ is:

$$ \mathcal{F} \left\{ u \left( \mathbf{r}, t\right) \right\} = \frac{A ( \mathbf{r} ) }{2} \left[ e^{j \phi \left( \mathbf{r} \right) } \delta \left( f - f_0 \right) + e^{-j \phi \left( \mathbf{r} \right) } \delta \left( f + f_0 \right) \right] $$

Drop the positive frequency term $ e^{j \phi \left( \mathbf{r} \right) } \delta \left( f - f_0 \right) $ and double the result. This produces:

$$ A ( \mathbf{r} ) e^{-j \phi \left( \mathbf{r} \right) } \delta \left( f + f_0 \right) $$

Let $ U ( \mathbf{r} ) := A ( \mathbf{r} ) e^{-j \phi \left( \mathbf{r} \right) } $. The inverse Fourier transform of this signal is:

$$ \mathcal{F}^{-1} \left\{ U ( \mathbf{r} ) \delta \left( f + f_0 \right) \right\} = U ( \mathbf{r} ) e^{-j 2 \pi f_0 t } $$

We can recover the original field by taking the real part of this expression, which is equivalent to applying Euler's identity and dropping the imaginary part:

$$ u \left( \mathbf{r}, t \right) = \Re \left[ U ( \mathbf{r} ) e^{-j 2 \pi f t} \right] $$

Polychromatic Scalar Waves

To model a polychromatic wave, we integrate over the analytic signals of each spectral component and take the real part of the result:

$$ u \left( \mathbf{r}, t\right) = \Re \left[ \int_{-\infty}^{\infty} \tilde{U} \left( \mathbf{r}, f \right) e^{-j 2 \pi f t} \,df \right] $$

The Narrowband Assumption

We get a useful representation to the expression above if we assume that the bandwidth of the signal is much smaller than its center frequency $ \Delta f \ll f_0 $:

$$ \int_{-\infty}^{\infty} \tilde{U} \left( \mathbf{r}, f \right) e^{-j 2 \pi f t} \,df = U \left( \mathbf{r}, t \right) e^{-j 2 \pi f_0 t} $$

To better understand the meaning of this assumption, make the substitution $ \nu = f - f_0 $ into the expression on the left hand side:

$$\begin{eqnarray} \int_{-\infty}^{\infty} \tilde{U} \left( \mathbf{r}, f \right) e^{-j 2 \pi f t} \,df &=& \int_{-\infty}^{\infty} \tilde{U} \left( \mathbf{r}, \nu + f0 \right) e^{-j 2 \pi \left( \nu + f_0 \right) t} \,d\nu \\ &=& e^{-j 2 \pi f_0 t} \int_{-\infty}^{\infty} \tilde{U} \left( \mathbf{r}, \nu + f0 \right) e^{-j 2 \pi \nu t} \,d\nu \end{eqnarray}$$

Under the narrowband assumption, the integration in the expression above is constrained to small values around $ \nu = 0 $ that are much less than the phasor term that is oscillating at frequency $ f_0 $. If we define the following function:

$$ U \left( \mathbf{r}, t \right) := \int_{-\infty}^{\infty} \tilde{U} \left( \mathbf{r}, \nu + f0 \right) e^{-j 2 \pi \nu t} \,d\nu $$

then it will vary slowly with respect to the carrier frequency $ f_0 $.

As a result, under the assumptions of narrowbandedness, we can interpret the complex function $ U \left( \mathbf{r}, t \right) $ as an "envelope" modulating the amplitude of the fast oscillating carrier wave. If the assumption is not valid, then this interpretation fails.

The Slowly Varying Envelope Assumption

It is instructive to reverse our reasoning and see why a slowly-varying envelope implies a narrowband signal. Compute the Fourier transforms of the narrowband waveform, along with the Fourier transform of the derivative of $ U \left( \mathbf{r}, t \right) $.

The Fourier transform of the analytic signal:

$$ \int_{-\infty}^{\infty} \left[ U \left( \mathbf{r}, t \right) e^{-j 2 \pi f_0 t} \right] e^{-j 2 \pi f t} \,dt = \tilde{U} \left( \mathbf{r}, f + f_0 \right) $$

The Fourier transform of the derivative of $ U $:

$$\begin{eqnarray} \int_{-\infty}^{\infty} \frac{d}{dt} \left[ U \left( \mathbf{r}, t \right) \right] e^{-j 2 \pi f t} \,dt &=& j 2 \pi f \tilde{U} \left( \mathbf{r}, f \right) \end{eqnarray}$$

Now, apply the slowly varying envelope approximation (SVEA) by asserting that the rate of change of $ U $ with respect to time is much less than the value of $ U $ multiplied by the center frequency, or $ \left| \frac{d}{dt} U \left( \mathbf{r}, t\right) \right| \ll \left| 2 \pi f_0 U \left( \mathbf{r, t} \right) \right| $

$$\begin{eqnarray} \left| j 2 \pi f \tilde{U} \left( \mathbf{r}, f \right) \right| &=& \left| \int_{-\infty}^{\infty} \frac{d}{dt} \left[ U \left( \mathbf{r}, t \right) \right] e^{-j 2 \pi f t} \,dt \right| \\ &\ll& \left| \int_{-\infty}^{\infty} 2 \pi f_0 U \left( \mathbf{r}, t \right) e^{-j 2 \pi f t} \,dt \right| \\ &\ll& 2 \pi f_0 \left| \tilde{U} \left( \mathbf{r}, f \right) \right| \end{eqnarray}$$

This expression means that the appreciable frequency components of $ U \left( \mathbf{r} , t \right) $ are much less than the frequency $ f_0 $². And when we consider the spectrum of $ U \left( \mathbf{r} , t \right) $ centered around $ f_0 $, we find that the bandwidth $ \Delta f $ is small with respect to $ f_0 $.

Assumptions, not Approximations!

The narrowband and slowly varying envelope assumptions are usually referred to as approximations. This is misleading! The resulting expression for the field is not an approximation at all; instead, under the assumptions of narrowbandedness, we can interpret the complex function $ U \left( \mathbf{r}, t \right) $ an "envelope" modulating the amplitude of the fast oscillating carrier wave. If the assumption is not valid, then this interpretation is not correct.

Narrowband Polychromatic Waves

In summary, narrowband polychromatic waves with a center frequency $ f_0 $ are modeled as the product of a fast rotating phasor and slowly varying envelope:

$$ u \left( \mathbf{r}, t \right) = \Re \left[ U \left( \mathbf{r}, t \right) e^{-j 2 \pi f_0 t} \right] $$

The amplitude and the phase of the envelope are the amplitude and phase of the real optical wave.

Coherence

While the expression for the analytic signal $ U \left( \mathbf{r}, t \right) $ as an integral over frequency components appears deterministic, the phase relationships between the spectral components are often unknown and vary randomly in time. As a result, the envelope of the optical wave will vary unpredictably and must be analyzed in terms of its statistical properties.

Monochromatic Light is Coherent

Since monochromatic light has only one spectral component by definition, it is completely coherent.

I mean monochromatic in the ideal sense, not like how we sometimes describe lasers.
Monochromatic waves, like plane waves, cannot exist in real life. The uncertainy principle requires that a monochromatic wave exist for an infinite duration.

Goodman, Joseph W. Introduction to Fourier optics. Roberts and Company publishers (2005). ISBN 978-0974707723. ↩
https://physics.stackexchange.com/questions/451239/slowly-varying-envelope-approximation-what-does-it-imply ↩

A Very Brief Summary of Fresnel and Fraunhofer Diffraction Integrals

Kyle M. Douglass — Fri, 28 Mar 2025 08:06:03 GMT

Fourier Optics is complicated, and though I have internalized its concepts over the years, I often still need to review the specifics of its mathematical models. Unfortunately, my go-to resource for this, Goodman's Fourier Optics¹, tends to disperse information across chapters and homework problems. This makes quick review difficult.

Here I condense what I think are the essentials of Fresnel and Fraunhofer diffraction into one blog post.

Starting Point: the Huygens-Fresnel Principle

Ignore Chapter 3 of Goodman; it's largely irrelevant for practical work. The Huygens-Fresnel principle itself is a good intuitive model to start with.

The Model

An opaque screen with a clear aperture $ \Sigma $ is located in the $ z = 0 $ plane with transverse coordinates $ \left( \xi , \eta \right ) $. It is illuminated by a complex-valued scalar field $ U \left( \xi, \eta \right) $. Let $ \vec{r_0} = \left( \xi, \eta, 0 \right) $ be a point in the plane of the aperture and $ \vec{r_1} = \left( x, y, z \right) $ be a point in the observation plane. The Huygens-Fresnel Principle provides the following formula for the diffracted field $ U \left( x, y \right) $ in the plane $ z $:

$$ U \left( x, y; z \right) = \frac{z}{j \lambda} \iint_{\Sigma} U \left( \xi , \eta \right) \frac{\exp \left( j k r_{01} \right)}{r_{01}^2} \, d\xi d\eta $$

with the distance $ r_{01}^2 = \left( x - \xi \right)^2 + \left( y - \eta \right)^2 + z^2 $.

We assumed an obliquity factor $ cos \, \theta = z / r_{01}$. The choice of obliquity factor depends on the boundary conditions discussed in Chapter 3, but again this isn't terribly important for practical work.
The integral is a sum over secondary spherical wavelets emitted by each point in the aperture and weighted by the incident field and the obliquity factor.
The factor $ 1 / j $ means that each secondary wavelet from a point $ \left( \xi, \eta \right) $ is 90 degrees out-of-phase with the incident field at that point.

Approximations used in the Huygens-Fresnel Principle

The electromagnetic field can be approximated as a complex-valued scalar field.
$ r_{01} \gg \lambda $, or the observation screen is many multiples of the wavelength away from the aperture.

The Fresnel Diffraction Integral

The Fresnel Approximation

Rewrite $ r_{01} $ as:

$$ r_{01} = z \sqrt{ 1 + \frac{\left( x - \xi \right)^2 + \left( y - \eta \right)^2}{z^2} } $$

Apply the binomial approximation:

$$ r_{01} \approx z + \frac{\left( x - \xi \right)^2 + \left( y - \eta \right)^2}{2z} $$

In the Huygens-Fresnel diffraction integral, replace:

$r_{01}^2 $ in the denominator with $ z^2 $
$r_{01}$ in the argument of the exponential with $ z + \frac{\left( x - \xi \right)^2 + \left( y - \eta \right)^2}{2z} $

The Diffraction Integral: Form 1

Perform the substitutions for $ r_{01} $ into the Huygens-Fresnel formula that were mentioned above to get the first form of the Fresnel diffraction integral:

$$ U \left( x, y; z \right) = \frac{ e^{jkz} }{j \lambda z} \iint_{-\infty}^{\infty} U \left( \xi , \eta \right) \exp \left\{ \frac{jk}{2z} \left[ \left( x - \xi \right)^2 + \left( y - \eta \right)^2 \right] \right\} \,d\xi \,d\eta $$

It is space invariant, i.e. it depends only on the differences in coordinates $ \left( x - \xi \right) $ and $ \left( y - \eta \right) $.
It represents a convolution of the input field with the kernel $ h \left( x, y \right) = \frac{e^{j k z}}{j \lambda z} \exp \left[ \frac{j k}{2 z} \left( x^2 + y^2 \right) \right] $.

The Diffraction Integral: Form 2

Expand the squared quantities inside the parantheses of Form 1 to get the second from of the integral:

$$ U \left( x, y; z \right) = \frac{ e^{jkz} }{j \lambda z} e^{\frac{j k}{2 z} \left( x^2 + y^2 \right)} \iint_{-\infty}^{\infty} \left[ U \left( \xi , \eta \right) e^{\frac{j k}{2 z} \left( \xi^2 + \eta^2 \right)} \right] e^{-j \frac{2 \pi }{\lambda z} \left( x \xi + y \eta \right) } \,d\xi \,d\eta $$

It is proportional to the Fourier transform of the product of the incident field and a parabolic phase curvature $ e^{\frac{j k}{2 z} \left( \xi^2 + \eta^2 \right)} $.

Phasor Conventions

Section 4.2.1 of Goodman is an interesting practical aside about how to identify whether a spherical or parabolic wavefront is converging or diverging based on the sign of its phasor. It is useful for solving the important homework problem 4.16 which concerns the diffraction pattern from an aperture that is illuminated by a converging spherical wave.

Unfortunately, Figure 4.2 does not align well with its description in the text about negative z-values, and it's not clear how the interpretations change for point sources not at $ z = 0 $. I address this below.

Let the point of convergence (or center of divergence) of a spherical wave sit on the z-axis at $ z = Z $.
The phasor describing the time-dependent part of the field in Goodman's notation is $ e^{-j 2 \pi f t} $.
If we move away from the center of the wave such that $ z - Z $ is positive and we encounter wavefronts emitted earlier in time, then $ t $ is decreasing and the argument to the phasor is increasing. The wave is therefore diverging if the argument is positive.
If we move away from the center of the wave such that $ z - Z $ is negative and we encounter wavefronts emitted earlier in time, then $ t $ is decreasing and the argument to the phasor is increasing. However, a negative $ z - Z $ makes the phasor negative again so that it is in fact decreasing. The wave is therefore diverging if the argument is negative.
Likewise for converging waves.

To summarize:

Phasor	$ \left( z - Z \right) $ positive	$ \left( z - Z \right) $ negative
$ e^{ j k r} $	diverging	converging
$ e^{ -j k r} $	converging	diverging

The Fraunhofer Diffraction Integral

The Fraunhofer Approximation

Assume we are so far from the screen that the quadratic phasor inside the diffraction integral is effectively flat. This means:

$$ z \gg \frac{k \left( \xi^2 + \eta^2 \right)_{\text{max}}}{2} $$

The Diffraction Integral

Applying the approximation above allows us to drop the quadratic phasor inside the Fresnel diffraction integral because it is effectively 1:

$$ U \left( x, y; z \right) = \frac{ e^{jkz} }{j \lambda z} e^{\frac{j k}{2 z} \left( x^2 + y^2 \right)} \iint_{-\infty}^{\infty} U \left( \xi , \eta \right) e^{-j \frac{2 \pi }{\lambda z} \left( x \xi + y \eta \right) } \,d\xi \,d\eta $$

Apart from the phase term that depends on $ z $, this expression represents a Fourier transform of the incident field.
It appears to break spatial invariance because we no longer depend on differences of coordinates, e.g. $ x - \xi $. However, we can still use the Fresnel transfer function (the Fourier transform of the Fresnel convolution kernel) as the transfer function for Fraunhofer diffraction because if the Fraunhofer approximation is valid, then so is the Fresnel approximation.

Solution to Homework Problem 4.16

Problem 4.16 is important because it is a basis for the development of the frequency analysis of image-forming systems in later chapters of Goodman.

The purpose of 4.16 is to show that the diffraction pattern of an aperture that is illuminated by a spherical converging wave in the Fresnel regime is the Fraunhofer diffraction pattern of the aperture.

Part a: Quadratic phase approximation to the incident wave

Let $ z = 0 $ be the plane of the aperture and $ z = Z $ be the observation plane. Additionally, let $ \left( \xi, \eta \right) $ represent the coordinates in the plane of the aperture, and $ \left( x, y \right) $ the coordinates in the observation plane. The spherical wave that illuminates the aperture is convering to a point $ \vec{r}_P = Y \hat{ \jmath} + Z \hat{k} $ in the observation plane.

To find a quadratic phase approximation for the incident wave, start with its representation as a time-harmonic spherical wave of amplitude $ A $:

$$ U \left( x, y, z \right) = A \frac{e^{j k |\vec{r} - \vec{r}_P|}}{|\vec{r} - \vec{r}_P|} $$

Note that $ \vec{r} - \vec{r}_P = x \hat{\imath} + \left( y - Y \right) \hat{\jmath} + \left( z - Z \right) \hat{k} $. Its magnitude is

$$\begin{eqnarray} | \vec{r} - \vec{r}_P | &=& \sqrt{x^2 + \left( y - Y \right)^2 + \left( z - Z \right)^2} \\ &=& \left( z - Z \right) \sqrt{1 + \frac{x^2 + \left( y - Y \right)^2}{\left( z - Z \right)^2} } \\ &\approx& \left( z - Z \right) + \frac{ x^2 + \left( y - Y \right)^2 }{2 \left( z - Z \right)} \end{eqnarray}$$

At first glance, there's a problem here because allowing $ \left( z - Z \right) $ to be negative will result in a negative value for the magnitude of the vector $ \left( \hat{r} - \hat{r}_P \right) $. However, if we use the above table for selecting $ e^{j k r} $ as the phasor for a converging wave when $ \left( z - Z \right) $ is negative, then we will have the correct sign of the argument to the phasor. We do however need to take the absolute value of the $ z - Z $ term in the denominator of the expression of the spherical wave.

Replacing the distance in the phasor's argument with the two lowest order terms in the binomial expansion and the lowest order term in the denominator:

$$ U \left( x, y, z \right) \approx A \frac{e^{j k \left(z - Z \right)} e^{j k \left[ x^2 + \left( y - Y \right)^2 \right] / 2 \left(z - Z \right) }}{\left|z - Z \right|} $$

In the $ z = 0 $ plane, this becomes:

$$ U \left( x, y; z = 0 \right) \approx A \left(x, y \right) \frac{e^{-j k Z} e^{-j k \left[ x^2 + \left( y - Y \right)^2 \right] / 2 Z }}{Z} $$

I moved the finite extent of the aperture into a new function for the amplitude $ A $ above. This function is zero outside the aperture and a constant $ A $ inside it.

Part b: Diffraction pattern at the point $ P $

Use the second form of the Fresnel diffraction integral to compute the diffraction pattern at $ P $:

$$\begin{eqnarray} U \left( x = 0, y = Y, z = Z \right) &=& \frac{ e^{jkZ} }{j \lambda Z} e^{\frac{j k Y^2}{2 Z}} \iint_{-\infty}^{\infty} \left[ U \left( \xi , \eta ; z = 0 \right) e^{\frac{j k}{2 Z} \left( \xi^2 + \eta^2 \right)} \right] e^{-j \frac{2 \pi }{\lambda Z} y \eta } \,d\xi \,d\eta \\ &\approx& \frac{ e^{jkZ} e^{-jkZ} }{j \lambda Z^2} e^{\frac{j k Y^2}{2 Z}} \iint_{-\infty}^{\infty} A \left(\xi, \eta \right) \left[ e^{-\frac{j k}{2Z} \left[ \xi^2 + \left( \eta - Y \right)^2 \right]} e^{\frac{j k}{2 Z} \left( \xi^2 + \eta^2 \right)} \right] e^{-j \frac{2 \pi }{\lambda Z} y \eta } \,d\xi \,d\eta \\ &\approx& \frac{1}{j \lambda Z^2} e^{\frac{j k Y^2}{2 Z} } \iint_{-\infty}^{\infty} A \left(\xi, \eta \right) \left[ e^{-\frac{j k}{2Z} \left( \xi^2 + \eta^2 - 2 \eta Y + Y^2 \right)} e^{\frac{j k}{2 Z} \left( \xi^2 + \eta^2 \right)} \right] e^{-j \frac{2 \pi }{\lambda Z} y \eta } \,d\xi \,d\eta \\ &\approx& \frac{1}{j \lambda Z^2} \iint_{-\infty}^{\infty} A \left(\xi, \eta \right) e^{\frac{j k \eta Y}{Z}} e^{-j \frac{2 \pi}{\lambda Z} y \eta } \,d\xi \,d\eta \\ &\approx& \frac{1}{j \lambda Z^2} \iint_{-\infty}^{\infty} A \left(\xi, \eta \right) e^{-j \frac{2 \pi }{\lambda Z} \left(\eta - Y \right) } \,d\xi \,d\eta \end{eqnarray}$$

The final expression above is proportional to the Fraunhofer diffraction pattern of the aperture. The reason that the Fraunhofer diffraction pattern appears as the result is that the converging spherical wavefronts exactly cancel the diverging quadratic phase term inside the Fresnel diffraction formula, leaving a simple Fourier transform of the aperture as a result.

Goodman, Joseph W. Introduction to Fourier optics. Roberts and Company publishers (2005). ISBN 978-0974707723. ↩

Coordinate Systems for Modeling Microscope Objectives

Kyle M. Douglass — Thu, 21 Nov 2024 09:52:48 GMT

A common model for infinity corrected microscope objectives is that of an aplanatic and telecentric optical system. In many developments of this model, emphasis is placed upon the calculation of the electric field near the focus. However, this has the effect that the definition of the coordinate systems and geometry are conflated with the determination of the fields. In addition, making the model amenable to computation often occurs as an afterthought.

In this post I will explore the geometry of an aplanatic system for modeling high NA objectives with an emphasis on computational implementations. My approach follows Novotny and Hecht¹ and Herrera and Quinto-Su².

The Model Components

The model system is illustrated below:

A high NA, infinity corrected microscope objective as an aplanatic and telecentric optical system.

In this model, we abstract over the details of the objective by representing it as four surfaces:

A back focal plane containing an aperture stop
A back principal plane, $ P $
A front principal surface, $ P' $
A front focal plane

The space to the left of the back principal plane is called the infinity space. The space to the right of the front principal surface is called the sample space.

We let the infinity space refractive index $ n_1 = 1 $ because it is in air. The refractive index $ n_2 $ is the refractive index of the immersion medium.

The unit vectors $ \mathbf{n} $ are not used in this discussion; they are relevant for computing the fields.

Assumptions

We make one assumption: the system obeys the sine condition. The meaning of this will be explained later.

An aplanatic system is one that obeys the sine condition.

We will not assume the intensity law to conserve energy because it is only necessary when computing the electric field near the focus.

The Aperture Stop and Back Focal Plane

The aperture stop (AS) of an optical system is the element that limits the angle of the marginal ray.

The system is telecentric because the aperture stop is located in the back focal plane (BFP). We can shape the focal field by spatially modulating any of the amplitude, phase, or polarization of the incident light in a plane conjugate to the BFP.

The Back Principal Plane

This is the plane in infinity space at which rays appear to refract. It is a plane because rays coming from a point in the front focal plane all emerge into the infinity space in the same direction.

Strictly speaking, focus field calculations require us to propagate the field from the AS to the back principal plane before computing the Debye diffraction integral, but this step is often omitted³. The assumptions of paraxial optics should hold here.

The Front Principal Surface

The front principal surface is the surface at which rays appear to refract in the sample space. It is a surface because

this is a non-paraxial system, and
we assumed the sine condition.

The sine condition states that refraction of a ray coming from an on-axis point in the front focal plane occurs on a spherical cap centered upon the focal point. The distance from the optical axis of the point of intersection of the ray with the surface is proportional to the sine of the angle that the ray makes with the axis.

The principal surface is in the far field of the electric field coming from the focal region. For this reason, we can represent a point on this surface as representing a single ray or a plane wave¹.

The Front Focal Plane

This plane is located a distance $ n_2 f $ from the principal surface⁴. It is not at a distance $ f $ from this surface. This is a result of imaging in an immersion medium.

Geometry and Coordinate Systems

The Aperture Stop Radius

The aperture stop radius $ R $ corresponds to the distance from the axis to the point where the marginal ray intersects the front prinicpal surface. In the sample space, the marginal ray travels at an angle $ \theta_{max} $ with respect to the axis.

Under the sine condition, this height is

$$ R = n_2 f \sin{ \theta_{max} } = f \, \text{NA} $$

The right-most expression uses the definition of the numerical aperture $ \text{NA} \equiv n \sin{ \theta_{max} } $.

Compare this result to the oft-cited expression for the entrance pupil diameter of an objective lens: $ D = 2 f \, \text{NA} $. They are the same. This makes sense because an entrance pupil is either

an image of an aperture stop, or
a physical stop.

The Back Principal Plane

There are two independent coordinate systems in the back principal plane:

the spatial coordinate system defining the far field positions $ \left( x_{\infty} , y_{\infty} \right) $, and
the coordinate system of the angular spectrum of plane waves $ \left( k_x, k_y \right) $.

The Far Field Coordinate System

The far field coordinate system may be written in Cartesian form as $ \left( x_{\infty} , y_{\infty} \right) $. It also has a cylindrical representation as

$$\begin{eqnarray} \rho &=& \sqrt{x_{\infty}^2 + y_{\infty}^2} \\ \phi &=& \arctan \left( \frac{y_{\infty}}{x_{\infty}} \right) \end{eqnarray}$$

The cylindrical representation appears to be preferred in textbook developments of the model. The Cartesian representation is likely preferred for computational models because it works naturally with two-dimensional arrays of numbers, and because beam shaping elements such as spatial light modulators are rectangular arrays of pixels².

The Angular Spectrum Coordinate System

Each point in the angular spectrum coordinate system represents a plane wave in the sample space that is traveling at an angle $ \theta $ to the axis according to:

$$\begin{eqnarray} k_x &=& k \sin \theta \cos \phi \\ k_y &=& k \sin \theta \sin \phi \\ k_z &=& k \cos \theta \end{eqnarray}$$

where $ k = 2 \pi n_2 / \lambda = n_2 k_0 $.

Along the y-axis ( $ x_{\infty} = 0 $ ), the maximum value of $ k_y $ is $n_2 k_0 \sin \theta_{max} = k_0 \, \text{NA} $.

Substitute in the expression $ \text{NA} = R / f $ and we get $k_{y, max} = k_0 R / f$. But $ R = y_{\infty, max} $. This (and similar reasoning for the x-axis) implies that:

$$\begin{eqnarray} k_x &=& k_0 x_{\infty} / f \\ k_y &=& k_0 y_{\infty} / f \end{eqnarray}$$

The above equations link the angular spectrum coordinate system to the far field coordinate system. They are no longer independent once $ f $ and $ \lambda $ are specified.

Numerical Meshes

There are four free parameters for defining the coordinate systems of the numerical meshes:

The numerical aperture, $ \text{NA} $
The wavelength, $ \lambda $
The focal length, $ f $
The linear mesh size, $ L $

Below is a figure that illustrates the construction of the meshes. Both the far field and angular spectrum coordinate systems are represented by a $ L \times L $ array. $ L = 16 $ in the figure below. In general the value of $ L $ should be a power of 2 to help ensure the efficiency of the Fast Fourier Transform (FFT). By considering only powers of 2, we need only consider arrays of even size as well.

A numeric mesh representing the far field and angular spectrum coordinate systems of a microscope objective. Fields are sampled at the center of each mesh pixel.

The fields are defined on a region of circular support that is centered on this array. The radius of the domain of the far field coordinate system is $ f \text{NA} $; the radius of the domain of the angular spectrum coordinate system is $ k_0 \text{NA} $.

The boxes that are bound by the gray lines indicate the location of each field sample. The $ \left( x_{\infty} , y_{\infty} \right) $ and the $ \left( k_x, k_y \right) $ coordinate systems are sampled at the center of each gray box. The origin is therefore not sampled, which will help avoid division by zero errors when the fields are eventually computed.

The figure suggests that we could create only one mesh and scale it by either $ f \text{NA} $ or $ k_0 \text{NA} $ depending on which coordinate system we are working with. The normalized coordinates become $ \left( x_{\infty} / \left( f \text{NA} \right), y_{\infty} / \left( f \text{NA} \right) \right) $ and $ \left( k_x / \left( k_0 \text{NA} \right), k_y / \left( k_0 \text{NA} \right) \right) $.

1D Mesh Example

As an example, let $ L = 16 $. To four decimal places, the normalized coordinates are $ -1.0000, -0.8667, \ldots, -0.0667, 0.0667, \ldots, 0.8667, 1.0000 $.

The spacing between array elements is $ 2 / \left( L - 1 \right) = 0.1333 $. Note that 0 is not included in the 1D mesh as it goes from -0.0667 to 0.0667.

A 2D mesh is easily constructed from the 1D mesh using tools such as NumPy's meshgrid.

Back Principal Plane Mesh Spacings

In the x-direction, the mesh spacing of the far field coordinate system is

$$ \Delta x_{\infty} = 2 R / \left( L - 1 \right) = 2 f \text{NA} / \left( L - 1 \right) $$

In the $ k_x $-direction, the mesh spacing of the angular spectrum coordinate system is

$$ \Delta k_x = 2 k_{max} / \left( L - 1 \right) = 2 k_0 \text{NA} / \left( L - 1 \right) $$

Note the symmetry between these two expressions. One scales with $ f \text{NA} $ and the other $ k_0 \text{NA} $. Recall that these are free parameters of the model.

Sample Space Mesh Spacing

It is interesting to compute the spacing between mesh elements $ \Delta x $ in the sample space when the fields are eventually computed.

The sampling angular frequency in the sample space is $ k_S = 2 \pi / \Delta x $.

The Nyquist-Shannon sampling theory states that the maximum informative angular frequency is $ k_{max} = k_S / 2 $.

From the previous section, we know that $ k_{max} = \left(L - 1 \right) \Delta k_x / 2 $, and that $ \Delta k_x = 2 k_0 \text{NA} / \left( L - 1 \right) $.

Combining all the previous expressions and simplifying, we get:

$$\begin{eqnarray} k_S &=& 2 k_{max} \\ 2 \pi / \Delta x &=& \left(L - 1 \right) \Delta k_x \\ 2 \pi / \Delta x &=& \left(L - 1 \right) \left[ 2 k_0 \text{NA} / \left( L - 1 \right) \right] \\ 2 \pi / \Delta x &=& \left(L - 1 \right) \left[ 2 \left(2 \pi / \lambda \right) \text{NA} / \left( L - 1 \right) \right] \end{eqnarray}$$

Solving the above expression for $ \Delta x $, we arrive at

$$ \Delta x = \frac{\lambda}{2 \text{NA}} $$

which is of course the Abbe diffraction limit.

Effect of not Sampling the Origin

Herrera and Quinto-Su² point out that an error will be introduced if we naively apply the FFT to compute the field components in the $ \left( k_x, k_y \right) $ coordinate system because the origin is not sampled, whereas the FFT assumes that we sample the zero frequency component. The effect is that the result of the FFT has a constant phase error that accounts for a half-pixel shift in each direction of the mesh.

Consider again the 1D mesh example with $L = 16 $: $ -1.0000, -0.8667, \ldots, -0.0667, 0.0667, \ldots, 0.8667, 1.0000 $

In Python and other languages that index arrays starting at 0, the origin is located at $L / 2 - 0.5 $, i.e. halfway between the samples at index 7 and 8. A lateral shift in Fourier space is equivalent to a phase shift in real space:

$$ \phi_{shift} \left(X, Y \right) = -j 2 \pi \frac{0.5}{L} X - j 2 \pi \frac{0.5}{L} Y $$

where $ X $ and $ Y $ are normalized coordinates.

At this point, I am uncertain whether the phasor with the above argument needs to be multiplied or divided with the result of the FFT because 1. there are a few typos in the signs for the coordinate system bounds in the manuscript of Herrera and Quinto-Su, and 2. the correction was developed for use in MATLAB, which indexes arrays starting at 1. Once the fields are computed, it would be easy to verify the correct sign of the phase terms following the procedure outlined in Figure 3 of Herrera and Quinto-Su's manuscript.

Structure of the Algorithm

The algorithm to compute the focus fields will proceed as follows:

(optional) Propgate the inputs fields from the AS to the back principal plane using paraxial wave propagation
Input the sampled fields in the back principal plane in the $ \left( x_{\infty}, y_{\infty} \right) $ coordinate system
Transform the fields to the $ \left( k_x, k_y \right) $ coordinate system
Compute the fields in the $ \left(x, y, z \right) $ coordinate system using the FFT

Additional Remarks

Zero padding the mesh will increase the sample space resolution beyond the Abbe limit, but since the fields remain zero outside of the support, no new information is added.
On the other hand, zero padding might be required when computing fields going from the sample space to the back principal plane to faithfully reproduce any evanescent components.
Separating the coordinate system and mesh construction from the calculation of the fields reveals that the two assumptions of the model belong separately to each part. The sine condition is used in the construction of the coordinate systems, whereas energy conservation is used when computing the fields.
This post did not explain how to compute the fields.
Herrera and Quinto-Su (and possibly also Novotny and Hecht) appear to use an "effective" focal length which can be obtained by multiplying the one that I use by the sample space refractive index. I prefer my formulation because it is consistent with geometric optics and the well-known expression for the diameter of an objective's entrance pupil. When the fields are calculated, however, I do not yet know whether the arguments of the phasors of the Debye integral will require modification.

Lukas Novotny and Bert Hecht, "Principles of Nano-Optics," Cambridge University Press (2006). https://doi.org/10.1017/CBO9780511813535 ↩↩
Isael Herrera and Pedro A. Quinto-Su, "Simple computer program to calculate arbitrary tightly focused (propagating and evanescent) vector light fields," arXiv:2211.06725 (2022). https://doi.org/10.48550/arXiv.2211.06725 ↩↩↩
Marcel Leutenegger, Ramachandra Rao, Rainer A. Leitgeb, and Theo Lasser, "Fast focus field calculations," Opt. Express 14, 11277-11291 (2006). https://doi.org/10.1364/OE.14.011277 ↩
Sun-Uk Hwang and Yong-Gu Lee, "Simulation of an oil immersion objective lens: A simplified ray-optics model considering Abbe’s sine condition," Opt. Express 16, 21170-21183 (2008). https://doi.org/10.1364/OE.16.021170 ↩

The Mono16 Format and Flir Cameras

Kyle M. Douglass — Tue, 27 Aug 2024 12:15:36 GMT

For a long time I had found the Mono16 image format of Flir's cameras a bit strange. In the lab I have several Flir cameras with 12-bit ADC's, but the images they output in Mono16 would span a range from 0 to around 65535. How does the camera map a 12-bit number to a 16-bit number?

If you search for the Mono16 format you will find that it's a padded format. This means that, in the 12-bit ADC example, 4 bits in each pixel are always 0, and the remaining 12 bits represent the pixel's value. But this should mean that we should get pixel values only between 0 and 2^12 - 1, or 4095. So how is it that we can saturate one of these cameras with values near 65535?

Today it occurred to me that Flir's Mono16 format might not use all the values in the range [0, 65535]. This is indeed the case, as I show below with an image stack that I acquired from one of these cameras:

>>> sorted_unique_pixels = np.unique(images.ravel())
>>> np.unique(np.diff(sorted_unique_pixels))
array([ 16,  32,  48,  64,  96, 144], dtype=uint16)

This prints all the possible, unique differences between the sorted and flattened pixel values in my particular image stack. Notice how they are all multiples of 16?

Let's look also at the sorted array of unique values itself:

>>> sorted_unique_pixels
array([ 5808,  5824,  5856, ..., 57312, 57328, 57472], dtype=uint16)

There are more than a million pixels in this array, yet they all take values that are integer multiples of 16.

It looks like Flir's Mono16 format rescales the camera's output onto the interval [0, 65535] by introducing "gaps" between the numbers equal to 2^16 - 2^N where N is the bit-depth of the camera's ADC.

But wait just a moment. Above I said that 4 bits in the Mono16 are zero, but I assumed that these were the most significant bits. If the least significant bits are the zero padding, then the allowed pixel values would be, for example, 0000 0000 = 0, 0001 0000 = 16, 0010 0000 = 32, 0011 0000 = 48, etc. (Here I ignored the first 8 bits for clarity.)

So it appears that Flir is indeed padding the 12-bit ADC data with 0's in its Mono16 format. But, somewhat counter-intuitively, it is the four least significant bits that are the zero padding. I say this is counter-intuitive because I have another camera that pads the most significant bits, so that the maximum pixel value is really 2^N - 1, with N being the ADC's bit-depth.

Automated Testing of Simulation Code via Hypothesis Testing

Kyle M. Douglass — Tue, 21 May 2024 07:54:40 GMT

Missing a Theory of Testing for Scientific Code

If you search the Internet for resources on the theory of testing code, you will find information about the different types of tests and how to write them. You will also find that it is generally accepted among programmers that good code is tested and bad code is not. The problem for scientists and engineers, however, is that the theory concerning the testing of computer code was developed primarily by programmers that work on systems that model business processes. There is little theory on how, for example, to test the outcome of physics simulations. To further exacerbate the problem, scientific programmers feel obliged to write tests without the guidance of such a theory because of the imperative to test their code. This leads to convoluted tests that are difficult to understand and maintain.

Scientific Code is Different

Code that models business processes is based on explicit rules that are developed from a set of requirements. An example of a rule that a business system might follow is "If a customer has ordered an item and has not paid, then send her an invoice."

To test the above rule, we write out all the possible cases and write a test for each one. For example:

A customer orders an item without paying. Expected result: an invoice is sent.
A customer orders an item and pays at the time of checkout: Expected result: no invoice is sent.

I have found that a good way to identify test cases in business logic is to look for if/else statements in a rule. Each branch of the statement should be a different test.

Now let's consider a physics simulation. I am an optical engineer, so I will use an example from optics. One thing I have often done in my work is to simulate the image formation process of a lens system, including the noise imparted by the camera. A simple model of a CMOS camera pixel is one that takes an input signal in photons, adds shot noise, converts it to photoelectrons, adds dark noise, and then converts the electron signal into analog-to-digital units. Schematically:

photons --> electrons --> ADUs

A simplified Python code snippet that models this process, including noise, is below. An instance of the camera class has a method called snap that takes input array of photons and converts it to ADUs.

from dataclasses import dataclass

import numpy as np


@dataclass
class Camera:
    baseline: int = 100  # ADU
    bit_depth: int = 12
    dark_noise: float = 6.83  # e-
    gain: float = 0.12  # ADU / e-
    quantum_efficiency: float = 0.76
    well_capacity: int = 32406  # e-
    rng: np.random.Generator = np.random.default_rng()

    def snap(self, signal):
        # Simulate shot noise and convert to electrons
        photoelectrons = self.rng.poisson(
            self.quantum_efficiency * signal, size=signal.shape
        )

        # Add dark noise
        electrons = (
            self.rng.normal(scale=self.dark_noise, size=photoelectrons.shape)
            + photoelectrons
        )

        # Clip to the well capacity to model electron saturation
        electrons = np.clip(electrons, 0, self.well_capacity)

        # Convert to ADU
        adu = electrons * self.gain + self.baseline

        # Clip to the bit depth to model ADU saturation
        adu = np.clip(adu, 0, 2 ** self.bit_depth - 1)

        return adu.astype(np.uint16)

How can we test this code? In this case, there are no if/else statements to help us identify test cases. Some possible solutions are:

An expert can review it. But what if we don't have an expert? Or, if you are an expert, how do we know that we haven't made a mistake? I have worked professionally as both an optical and a software engineer and I can tell you that I make coding mistakes many times a day. And what if the simulation is thousands of lines of code? This solution, though useful, cannot be sufficient for testing.
Compute what the results ought to be for a given set of inputs. Rules like "If the baseline is 100, and the bit depth is 12, etc., then the output is 542 ADU" are not that useful here because the output is random.
Evaluate the code and manually check that it produces the desired results. This is similar to expert review. The problem with this approach is that you would need to recheck the code every time a change is made. One of the advantages of testing business logic is that the tests can be automated. It would be advantageous to preserve automation in testing scientific code.
We could always fix the value of the seed for the random number generator to at least make the test deterministic, but then we would not know whether the variation in the simulation output is what we would expect from run-to-run. I'm also unsure whether the same seed produces the same results across different hardware architectures. Since the simulation is non-deterministic at its core, it would be nice to include this attribute within the test case.

Automated Testing of Simulation Results via Hypothesis Testing

The solution that I have found to the above-listed problems is derived from ideas that I learned in a class on quality control that I took in college. In short, we run the simulation a number of times and compute one or more statistics from the results. The statistics are compared to their theoretical values in a hypothesis test, and, if the result is outside of a given tolerance, the test fails. If the probability of failure is made small enough, then a failure of the test practically indicates an error in the simulation code rather than a random failure due to the stochastic output.

Theoretical Values for Test Statistics

In the example of a CMOS camera, both the theoretical mean and the variance of a pixel are known. The EMVA 1288 Linear Model states that

$$ \mu_y = K \left( \eta \mu_p + \mu_d \right) + B $$

where $ \mu_y $ is the mean ADU count, $ K $ is the gain, $ \eta $ is the quantum efficiency, $ \mu_p $ is the mean photon count, $ \mu_d $ is the mean dark noise, and $ B $ is the baseline value, i.e. the average ADU count under no illumination. Likewise, the variance of the pixel describes the noise:

$$ \sigma_y = \sqrt{K^2 \sigma_d^2 + \sigma_q^2 + K \left( \mu_y - B \right)} $$

where $ \sigma_y $ is the standard deviation of the ADU counts, $ \sigma_d^2 $ is the dark noise variance, and $ \sigma_q^2 = 1 / 12 \, \text{ADU} $ is the quantization noise, i.e. the noise from converting an analog voltage into discrete ADU values.

Hypothesis Testing

We can formulate a hypothesis test for each test statistic. The test for each is:

Null hypothesis : the simulation statistics and the theoretical values are the same
Alternative hypothesis : the simulation statistics and the theoretical values are different

Let's first focus on the mean pixel values. To perform this hypothesis test, I ran the simulation code a number of times. For convenience, I chose an input signal of 1000 photons. Here's the resulting histogram:

The mean of this distribution is 190.721 ADU and the standard deviation is 3.437 ADU. The theoretical values are 191.2 ADU and 3.420 ADU, respectively. Importantly, if I re-run the simulation, then I get a different histogram because the simulation's output is random.

The above histogram is called the sampling distribution of the mean, and its width is proportional to the standard error of the mean. (Edit 2024/05/30 Actually, I think I am wrong here. This is not the sampling distribution of the mean. To get it we would need to repeat the above experiment a number of times and compute the mean each time, much like I do in the following section. The set of all means from doing so would be its sampling distribution. Fortunately, the estimate of the confidence intervals in what follows should still hold because the sampling distribution of the mean tends to a normal distribution for large $N $, and this allows for the expression in the equation that follows.)

Hypothesis Testing of the Mean Pixel Value

To perform the hypthosesis test on the mean, I build a confidence interval around the simulated value using the following formula:

$$ \mu_y \pm X \frac{s}{\sqrt{N}} $$

Here $ s $ is my estimated standard deviation (3.437 ADU in the example above), and $ N = 10,000 $ is the number of simulated values. Their ratio $ \frac{s}{\sqrt{N}} $ is an estimate of the standard error of the mean. $ X $ is a proportionality factor that is essentially a tolerance on how close the simulated value must be to the theoretical one to be considered "equal". A larger tolerance means that it is less likely that the hypothesis test will fail, but I am less certain that the value of the simulation is exactly equal to the theoretical value.

If this looks familiar, it should. In introductory statistics classes, this approach is called Student's one sample t-test. In the t-test, the value for $ X $ is denoted as $ t $ and depends on the desired confidence level and on the number of data points in the sample. (Strictly speaking, it's the number of data points minus 1.)

As far as I can tell there's no rule for selecting a value of $ X $; rather, it's a free parameter. I often choose 3. Why? Well, if the sampling distribution is approximately normally distributed, and the number of sample points is large, then the theoretical mean should lie within 3 standard errors of the simulated one approximately 99.7% of the time if the algorithm is correct. Alternatively, this means that a correct simulation will produce a result that is more than three standard errors from the theoretical mean about every 1 out of 370 test runs.

Hypothesis Testing of the Noise

Recall that standard deviation of pixel values is a measure of the noise. The approach to testing it remains the same as before. We write the confidence interval as

$$ \sigma_y \pm X \left( s.e. \right) $$

where we have $ s.e. $ as the standard error of the standard deviation. If the simulated standard deviation is outside this interval, then we reject the null hypothesis and fail the test.

Now, how do we calculate the standard error of the standard deviation? Unlike with the mean value, we have only one value for the standard deviation of the pixel values. Furthermore, there doesn't seem to be a simple formula for the standard error of the variance or standard error of the standard deviation. (I looked around the Math and Statistics Stack Exchanges, but what I did find produced standard errors that were way too large.)

Faced with this problem, I have two options:

run the simulation a number of times to get a distribution of standard deviations
draw pixel values from the existing simulation data with replacement to estimate the sampling distribution. This approach is known as bootstrapping.

In this situation, both are valid approaches because the simulation runs quite quickly. However, if the simulation is slow, bootstrapping might be desirable because resampling the simulated data is relatively fast.

I provide below a function that makes a bootstrap estimate of the standard error of pixel values to give you an idea of how this works. It draws n samples from the simulated pixel values with replacement and places the results in the rows of an array. Then, the standard devation of each row is computed. Finally, since the standard error is the standard deviation of the sampling distribution, the standard deviation of resampled standard deviations is computed and returned.

def se_std(data, n = 1000) -> float:
    samples = np.random.choice(data.ravel(), (n, data.size), replace=True)
    std_sampling_distribution = samples.std(axis=1)

    return np.std(std_sampling_distribution)

Of course, the value of n in the function above is arbitrary. From what I can tell, setting n to be the size of the data is somewhat standard practice.

Automated Hypothesis Testing

At this point, we can calculate the probability that the mean and standard deviation of the simulated pixel values will lie farther than some distance from their theoretical values. This means that we know roughly how often a test will fail due to pure luck.

To put these into an automated test function, we need only translate the two hypotheses into an assertion. The null hypothesis should correspond to the argument of the assertion being true; the alternative hypothesis corresponds to a false argument.

TOL = 3

def test_cmos_camera(camera):
    num_pixels = 32, 32
    mean_photons = 100
    photons = (mean_photons * np.ones(num_pixels)).astype(np.uint8)
    expected_mean = 191.2
    expected_std = 3.42

    img = camera.snap(photons)

    tol_mean = TOL * img.std() / np.sqrt(num_pixels[0] * num_pixels[1])
    tol_std = TOL * se_std(img)

    assert np.isclose(img.mean(), expected_mean, atol=tol_mean)
    assert np.isclose(img.std(), expected_std, atol=tol_std)

With a TOL value of 3 and with the sampling distributions being more-or-less normally distributed, each assertion should fail about 1 / 370 times because the area in the tails of the distribution beyond three standard errors is 1 / 370. We can put this test into our test suite and continuous integration (CI) system and run it automatically using whatever tools we wish, e.g. GitHub Actions and pytest.

Discussion

Non-deterministic Tests

It is an often-stated rule of thumb that automated tests should never fail randomly because it makes failures difficult to diagnose and makes you likely to ignore the tests. Here however it is in the very nature of this test that it will fail randomly from time to time. What are we to do?

An easy solution would be to isolate these sorts of tests and run them separately from the deterministic ones so that we know exactly where the error occurred. Then, if there is a failure of the non-deterministic tests, the CI could just run them again. If TOL is set so that a test failure is very rare, then any failure of these tests twice would practically indicate a failure of the algorithm to produce the theoretical results.

Testing Absolute Tolerances

It could be argued that what I presented here is a lot of work just to make an assertion that a simulation result is close to a known value. In other words, it's just a fancy way to test for absolute tolerances, and possibly is more complex than it needs to be. I can't say that I entirely disagree with this.

As an alternative, consider the following: if we run the simulation a few times we can get a sense of the variation in its output, and we can use these values to roughly set a tolerance that states by how much the simulated and theoretical results should differ. This is arguably faster than constructing the confidence intervals like we did above.

The value in the hypothesis testing approach is that you can know the probability of failure to a high degree of accuracy. Whether or not this is important probably depends on what you want to do, but it does provide you with a deeper understanding of the behavior of the simulation that might help debug difficult problems.

Testing for Other Types of Errors

There are certainly other problems in testing simulation code that are not covered here. The above approach won't tell you directly if you have entered an equation incorrectly. It also requires theoretical values for the summary statistics of the simulation's output. If you have a theory for these already, you might argue that a simulation would be superfluous.

If it's easy to implement automated tests for your simulation that are based on hypothesis testing, and if you expect the code to change often, then having a few of these sorts of tests will at least provide you a degree of confidence that everything is working as you expect as you make changes. And that is one of the goals of having automated tests: fearless refactoring.

Testing the Frequency of Failures

I stated often that with hypothesis testing we know how often the code should fail, but we never actually tested that. We could have run the simulation a large number of times and verified that the number of failures was approximately equal to the theoretical number of failures.

To my mind, it seems that this is just the exact same problem that was addressed above, but instead of testing summary statistics on the output values we test the number of failures. And since the number of failures will vary randomly, we would need a sampling distribution for this. So really this approach requires more CPU clock cycles to do the same thing because we need to run the simulation a large number of times.

Summary

Automated testing of simulation code is different than testing business logic due to its stochastic nature and inability to be reduced to "rules"
We can formulate hypothesis tests to determine how often the simulation produces values that are farther than a given distance from what theory predicts
The hypothesis tests can be translated into test cases: accepting the null hypothesis means the test passes, whereas rejecting the null hypothesis means the test fails
Non-deterministic testing is useful when it is quick to implement and you expect to change the code often

A Simple Object-Space Telecentric System

Kyle M. Douglass — Mon, 11 Mar 2024 07:59:17 GMT

Object-space telecentricity

I have been working on a software package recently for optical systems design. The process of building the package has proceeded like this:

Think of a particular case that I want to model; for example an infinite conjugate afocal system
Implement it in the code
Discover that the code doesn't work
Create a test case that helps debug the code
Repeat

I am modeling a telecentric lens in the current iteration of this loop. To keep things simple, I am limiting myself to an object-space telecentric system. This was more challenging than I expected. In part, the reason is that I was trying to infer whether a system was or was not telecentric from the lens prescription data and a ray trace, which has two problems:

I need to do a floating point comparison between two numbers to say whether a system is telecentric. Either the chief ray angle in object-space has to be zero or the entrance pupil must be located at infinity. Floating point comparisons are notoriously difficult to get right, and if you're doing them then you might want to rethink what you're trying to model.
Numerous checks are needed before we can even trace any rays. For example, I should check first whether the user placed the object at infinity. This would form the image in the same plane as the aperture stop, which does not really make sense.

I find it interesting that Zemax addresses these problems by introducing object-space telecentricity as an extra boolean flag that forces the chief ray angle to be zero in the object-space. In other words, the user needs to know what they're doing and to specify that they want telecentricity from the beginning.

An object-space telecentric example

I adapted the following example from lens data presented in this video: https://www.youtube.com/watch?v=JfstTsuNAz0. Notably, the object distance was increased by nearly a factor of two from what was given in the video so that the image plane was at a finite distance from the lens. Paraxial ray trace results were computed by hand.

A simple object-space telecentric system comprising a planoconvex lens and a stop.
Surface	0	1	2	3	4
Comment	OBJ			STOP	IMG
$ R $		$ \infty $	-9.750
$ t $	29.4702	2	15.97699	17.323380
$ n $	1	1.610248	1	1
$ C $		0	-0.10256
$ -\Phi $		0	-0.06259
$ t/n $	29.4702	1.24204	15.97699	17.323380
$ y $	0	29.4702	30.712240	15.97699	0
$ nu $	1	1	-0.922279	-0.922279
$ \bar{y} $	1	1	1	0	-1.084270
$ n \bar{u} $	0	0	-0.06259	-0.06259

This system is shown below with lens semi-diameters of 5 mm. Note that the stop is at the paraxial focus of the lens. The rays in the sketch cross the axis before the stop because of spherical aberration.

Remarks

Marginal ray trace

At first the marginal ray trace was a bit confusing because the entrance pupil is at infinity. How can the marginal ray, which intersects the pupil at its edge, be traced when the pupil is at infinity? Then I remembered that I don't aim for the edge of the pupil when tracing the marginal ray. Instead, I launch a ray from the axis in the object plane at a random angle taking the surface with the smallest ray height as the aperture stop. (I chose a paraxial angle of 1 in the table above. Technically, this is called a pseudo-marginal ray. The real marginal ray is calculated from it by rescaling the surface intersection heights by the aperture stop semi-diameter.) Once you have the marginal ray in image space, just find its intersection with the axis to determine the image location.

Telecentric lens design

So how would an object-space telecentric design be implemented in software? First, I'd set an option that would force the chief ray angle to 0 in the object space. Then, I'd simply place a solve on the aperture stop that puts it at the location where the chief ray intersects the axis.

Fusion 360 Core Concepts

Kyle M. Douglass — Fri, 08 Mar 2024 14:16:22 GMT

I decided recently to learn Fusion 360 to help with some custom optomechanical designs that I need in the lab. The following are my notes about its core concepts.

Assemblies

An assembly is a group of parts in one design file.

In CAD, there are two ways to create assemblies:

Bottom-up
1. Create parts
2. Add parts to the assembly
Top-down (used by Fusion 360)
1. Start with an assembly
2. Add parts to it

Bodies vs. components

Bodies

A body is a 3D shape used to add or remove components.

There are two core types:

Solid bodies
Surface bodies (denoted by a yellow face)

Other types include T-Splines (created in the Form environment) used to create freeform shapes, and mesh bodies.

Bodies must be of the same type to interact with one another.

Components

A component is a part or "container" used within an assembly.

Components can contain

bodies
construction planes
sketches
canvases
origin planes
other components (a.k.a. subassemblies)

Joints

Joints are how components are forced to stay together.

Guidelines

Always start an assembly with a new component
Always rename components and bodies right after creation

References

Bodies vs Components

Phasor	\( \left( z - Z \right) \) positive	\( \left( z - Z \right) \) negative
\( e^{ j k r} \)	diverging	converging
\( e^{ -j k r} \)	converging	diverging

Surface	0	1	2	3	4
Comment	OBJ			STOP	IMG
\( R \)		\( \infty \)	-9.750
\( t \)	29.4702	2	15.97699	17.323380
\( n \)	1	1.610248	1	1
\( C \)		0	-0.10256
\( -\Phi \)		0	-0.06259
\( t/n \)	29.4702	1.24204	15.97699	17.323380
\( y \)	0	29.4702	30.712240	15.97699	0
\( nu \)	1	1	-0.922279	-0.922279
\( \bar{y} \)	1	1	1	0	-1.084270
\( n \bar{u} \)	0	0	-0.06259	-0.06259

Kyle M. Douglass (Posts about optics)

Ray-Surface Intersections with the Newton-Raphson Algorithm

Debugging Ray-Surface Intersections

Running Traces through Algorithms

A Failing Test Case

The Newton-Raphson Algorithm

Root Finding

Before I Go On, Some Vocabulary

Termination Criteria

Oscillations

Convergence Guarantees

The Importance of the Magnitude of \( f'(x) \)

Ray-Surface Intersections

Ray Parameterization

Surface Representations

Saggita for Rotationally Symmetric Conic Section Surfaces

Partial Derivatives of Rotationally Symmetric Conic Section Surfaces

Newton-Raphson for Ray-Surface Intersections

Geometrical Interpretation of Newton-Raphson Failures

Normal Vectors and Surface Representations

Back to Debugging

Discussion

Completing the Square and the Normal Form of Quadrics

Converting the Quadric to its Normal Form

Why is Camera Read Noise Gaussian Distributed?

The Source(s) of Read Noise

Read Noise is Gaussian because of the Central Limit Theorem

Sums of Discrete Random Variables

Example of a Continuity Correction

A Very Brief Summary of The Analytic Signal in Fourier Optics

The Analytic Signal Representation of a Monochromatic Wave

Monochromatic Scalar Waves

The Analytic Signal

Polychromatic Scalar Waves

The Narrowband Assumption

The Slowly Varying Envelope Assumption

Assumptions, not Approximations!

Narrowband Polychromatic Waves

Coherence

Monochromatic Light is Coherent

A Very Brief Summary of Fresnel and Fraunhofer Diffraction Integrals

Starting Point: the Huygens-Fresnel Principle

The Model

Approximations used in the Huygens-Fresnel Principle

The Fresnel Diffraction Integral

The Fresnel Approximation

The Diffraction Integral: Form 1

The Diffraction Integral: Form 2

Phasor Conventions

The Fraunhofer Diffraction Integral

The Fraunhofer Approximation

The Diffraction Integral

Solution to Homework Problem 4.16

Part a: Quadratic phase approximation to the incident wave

Part b: Diffraction pattern at the point \( P \)

Coordinate Systems for Modeling Microscope Objectives

The Model Components

Assumptions

The Aperture Stop and Back Focal Plane

The Back Principal Plane

The Front Principal Surface

The Front Focal Plane

Geometry and Coordinate Systems

The Aperture Stop Radius

The Back Principal Plane

The Far Field Coordinate System

The Angular Spectrum Coordinate System

Numerical Meshes

1D Mesh Example

Back Principal Plane Mesh Spacings

Sample Space Mesh Spacing

Effect of not Sampling the Origin

Structure of the Algorithm

Additional Remarks

The Mono16 Format and Flir Cameras

Automated Testing of Simulation Code via Hypothesis Testing

Missing a Theory of Testing for Scientific Code

Scientific Code is Different

Automated Testing of Simulation Results via Hypothesis Testing

Theoretical Values for Test Statistics