This article demonstrates a stray light analysis workflow for a head up display (HUD). This article is part one of a three-part series.
Stray light analysis for head up display: part 2
Stray light analysis for head up display: part 3

Authored By Michael Cheng

Downloads

Article Attachments

Introduction

In Part 1, the specular straylight path of the picture generation unit (PGU) and sunlight are analyzed. A scene and a simple camera are added to visualize the image of the scene and the PGU received by an eye camera. To simulate efficiently straylight from the sun, a method of reverse ray-tracing from the eye camera to the sun is discussed.

In Part 2, an API Analysis tool is introduced to visualize straylight caused by the sun. This is done using a reverse ray-tracing process.

In the final part, a CAD model of the mechanical housing is imported into the system. The straylight process is repeated to analyze the straylight paths caused by scattering from the mechanical housing.

Note, while this article can be read independently, it’s suggested to read the article, Which tools to use when working on a Head-up-Display?. The straylight analysis is done on the system presented in that article.

Preparation

Before starting ray-tracing, a cover glass and absorbers are added to isolate the HUD system from the environment. This is mainly because one of the main straylight sources is from sunlight. Absorbers are needed to block all direct paths of sunlight apart from the windshield. Similarly, a cover glass is added because, by experience, it contributes to a large portion of straylight in a HUD system.

The system in Figure 1 is saved in attached “Step 0 - preparation.zar”. It is a modified version from the sample file “HUD_Step3_NONSEQ_after_tidying_up.zar” of the article Which tools to use when working on a Head-up-Display?.
Note that if users have a CAD model of a car, it can be also used here for a more realistic simulation. In any case, the tricks introduced in this article should be true and useful.

Figure 1 The HUD system prepared for straylight analysis.

Source: Picture Generation Unit

The system in this section can be found in the attached file “v2_Step1-1_PGU_light.ZAR”. In this section the PGU is made up of 4 objects as shown in Figure 2.

• Objects #32 and #33 are the image source of the PGU.
• Object #25 absorbs light that comes from the back side of the PGU.
• Object #24 reflects light coming from the front side of the PGU with 5% reflectance.

Note that on Object #33, the Object Properties > Type > Ignore Object is set to 24.

This means that rays coming from object #33 won’t see object #24. It avoids rays from the PGU source being blocked.

Figure 2 Adding 4 objects to define the PGU source.

An eye camera is set up to receive the image as shown in Figure 3. The eye camera consists of a Paraxial Lens (object #27) with a focal length of 22 mm and a Detector Rectangle (#30) 22.245 mm behind the Paraxial Lens. It assumes that the human eye is looking at a virtual image on a 2000 mm distant plane. The Annulus object (#28) limits the aperture of the Paraxial Lens to an aperture of 20 mm in diameter. This is not realistic for a real human eye but is more efficient in terms of simulation. Less rays are required to achieve high signal-to-noise-ratio.

Figure 3 The Eye camera is set up to simulate what a human eye sees; the HUD image, environment, and the straylight.

The result from ray-tracing is shown in Figure 4. Note two different detectors (#29 and #30) are set up here. They have different sizes in order to check both the HUD image and the overall field of view.

Figure 4 The PGU image received by the eye camera.

The ghost image can be seen clearly in Figure 4. This is a well-known issue in HUD systems. The ghost image comes from a double reflection on the windshield as shown in Figure 5. Usually, this ghost image is minimized by changing the wedge angle of the windshield glass.

Figure 5 Light path of ghost image of PGU source.

Source: Sunlight (Reverse Tracing)

Note that in this section, the # Analysis rays of the PGU source (Object 32) are temporarily set to zero.

Adding objects for simulating the sunlight source

In this section, more objects are added to analyze the effect of straylight from the sun. To simulate sunlight, the most efficient way is to reverse trace rays from the eye camera and analyze the light paths that can finally reach the sun. The sun is represented by a Detector Polar.

The final system in this section can be found in the attached file “v2_Step1-2_sunlight.ZAR”. It’s suggested to open this file and read the following explanations. In this system, two objects are added:

1. A Source DLL (# 35, Lambertian_Overfill.dll) is added behind the detector of the eye camera as shown in Figure 7. The rays launched from this source are virtual and only meaningful when they hit a real source (sun), which is, in this case, the Detector Polar. Note that the parameters of this Source DLL are designed to make the source the same size as the eye camera detector (#30, Eye detector (Big)) and target the camera aperture, which has a diameter of 20 mm. The rays will only launch from a specified rectangle towards a target circle as shown in Figure 6.
2. A Detector Polar (#26), representing the sun, is added to receive reversely traced rays from the eye camera as shown in Figure 7. By analyzing the rays that start from a Source DLL (#35) and hit the Detector Polar (#26), it gives all the possible light paths from the sun to the eye camera.

Figure 6 Parameters of a Source DLL (Lambertian_Overfil.dll).

Figure 7 A Detector Polar and a Source DLL are added for analyzing sunlight.

The ray paths shown in the Layout in Figure 7 are not yet useful. All the ray paths from the eye camera are drawn. However, we are only interested in those ghost paths that can finally hit the detector polar. For this reason, a filter is used: “G0 & H26 & (H5 | H8 | H14 | H24)”. The result is shown in Figure 8. Each term in the filter has the following meaning:

• G0 – This isolates the ghost light paths. Any light that reflects on a refractive surface will be considered as a ghost light.
• H26 – This considers only the light paths that hit the Detector Polar (#26), representing sunlight.
• (H5 | H8 | H14 | H24) – This considers only light paths that at least have hit one of the HUD components, which includes the first mirror (#5), the second mirror (#8), the PGU (#24), and the cover glass (#14).

Figure 8 Use a filter string to filter out ghost paths from the eye camera to the detector polar.

Ray Tracing

The information in the layout is not yet useful as there are too many paths mixed together. To classify and sort rays by path, a large number of rays need to be traced and saved as a Zemax Ray Database file (ZRD file) as shown in Figure 9. The same filter string as discussed above can be used to decrease the size of the saved ZRD file.

Figure 9 Reverse ray-tracing and saving ZRD. Filter string is used to save disk space.

Checking ZRD data in Detector Viewer

After tracing rays and before analyzing paths, it’s useful to first check the ZRD result on a Detector Viewer for the eye detector (#30) and the sun detector (#26) as shown in Figure 10. The image on both detectors shows the information of possible straylight paths. Note the result shown with this ZRD data has already been filtered by the filter string, as in Figure 9. So, the result only includes ghost power from the eye detector (#30) to the detector polar (#26). Also, it should be mentioned here that these images do not show the power density of the straylight. It only shows where the eye camera may see straylight, or which angle of sun can cause straylight. A brighter pixel on these images doesn’t necessarily tell how strong the straylight effect is. This will be analyzed in the later parts of this series of articles.

Nevertheless, it’s still possible to extract some information from the result here. On the eye detector (#30), there are mainly two blocks of bright area. By comparing to the Layout, it can be seen that straylight comes from windshield (upper block) and the cover glass (lower block). Furthermore, the straylight from the windshield is actually the image of the HUD box itself. In other words, a quick observation shows there are mainly two types of straylight paths:

• “Sun -> Cover glass -> Eye camera”.
• “Sun -> HUD -> Eye camera”.

Figure 10 Image of reverse ray-tracing of sun on the eye detector and detector polar.

On the other hand, the result in the detector polar (#26) shows the angles that can cause straylight. If a pixel on the detector polar is non-zero, it means that if the sun is at this angle, there is a path that the sunlight can go through to reach the eye camera, although it’s unknown how strong it could be.

Path Analysis: Sorting and Analyzing the Ray Paths

In addition to the results on the detectors, the other useful trick for a first level analysis is to use the Path Analysis tool to classify ray paths by the order of objects in which rays pass through, as shown in Figure 11.

After running the path analysis, it’s possible to use the “_#” filter string to only show the result of a specific path in the Layout and Detector Viewers, as shown in Figure 12. Note that for Detector Viewers, a ZRD file is required to use a filter string. For Layouts, it can be used with or without a ZRD file.

• If a ZRD file is not used, the filter string needs to be complete, as shown in Figure 12 (B). This is because the ray data in the ZRD file has already been filtered during the ray-tracing process and thus it can ignore some filter strings.
• On the other hand, if ZRD data is used in Layouts, it’s suggested to add a filter string keyword “{#xxx}”, which limits the number of displayed rays as shown in Figure 12 ©.

Figure 12 Filter string “_1” can filter out path #1 as shown in the path analysis.
(A) Detector Viewers must read ZRD data to use filter strings.
(B) For Layouts, it’s possible not to use ZRD data, but then the filter string needs to be fully given instead of only “_#”.
(C) If ZRD data is read, the filter string {#xxx}, where xxx is number of rays to show in Layout, can be used to avoid showing too many rays in Layouts.

Discussion of each path

Below, the straylight from each path is discussed using the results in Layouts and Detector Viewers. At this stage, it’s still unknown whether the path caused strong glare at the eye camera. However, it’s still useful to know what kind of path the straylight goes through.

Path #1

This is the most problematic straylight path that is described in many literature sources. In this path, the sunlight is reflected by the planar cover glass. Usually, a solution is to make the cover glass a curved surface so that the collimated sunlight is diverged before reaching the eye box. Since the cover glass is thin, it doesn’t introduce much aberration to the normal light path that transfers the image.

Figure 13 Path #1 of the straylight analysis for the reverse system.

Path #2

In this path, the sunlight is reflected by the cover glass and then the wind shield. In theory, this means the intensity of light can be decreased to about (5%)^2 = 0.25%. However, since the sunlight is very bright, it can still be a big problem for the driver.

Figure 14 Path #2 of the straylight analysis for the reverse system.

Path #3

In this path, the beam is reflected by the windshield and the two mirrors. Reflectance is about 5% for the windshield and 95% for the two mirrors, which means the glare from the sunlight can be strong. However, the beam diverges in this path, which might mitigate the glare power. It’s not easy to know at this stage whether the stray light is a big problem in this path. In the next part, it will be explained how to check the image received by the eye camera.

Figure 15 Path #3 of the straylight analysis for the reverse system.

Path #4

In this path, rays are reflected by the edge of the HUD second mirror and then reflected by the windshield. This one can usually be solved by making the edge scattering or painting it with a black color to absorb light.

Figure 16 Path #4 of the straylight analysis for the reverse system.

Path #5

In this path, the beam is reflected by the first mirror, the windshield, and then the cover glass. The final radiance may not be strong as the beams undergoes two reflections on glass plates. However, this requires more investigation. It will be done in later parts of this series of articles. Since the beam path includes a reflection on the cover glass, a curved cover glass might mitigate or even remove this straylight problem.

Figure 17 Path #5 of the straylight analysis for the reverse system.

Path #6

This is another well-known straylight path. In this path, the straylight path and the designed imaging path share a large common part. The beam is reflected twice on glass plates, LCD on PGU and the windshield. However, the beam is not diverged during its path from the sunlight to the eye box. This means the straylight from the sun can be well-collimated when arriving in the eye box and be a strong glare. Similarly, this requires more analysis in a forward ray-tracing stage.

Figure 18 Path #6 of the straylight analysis for the reverse system.

All paths together

In Figure 19, the straylight from all paths are shown together. The Path #6 pattern is very weak, so it is shown in another Log-5 plot.

Figure 19 All straylight paths detected by the Detector Polar.

Conclusion

This article has demonstrated how to find and study straylight paths in a HUD system using a reverse ray-tracing process and filter strings.

Next Article: Stray light analysis for head up display: part 2 where we’ll use an API Analysis tool to visualize the straylight caused by the sun.