A software null is a phase map, representing a nominal expected interferogram. It may be subtracted from the measured interferogram to improve test accuracy. A software null can be represented by a rectangular grid of values or by Zernike polynomials.
A software null may be used to compensate the known design residual and/or as-built residual of a CGH or conventional null. Software nulls may also be used alone in the testing of mild aspheres.
Because the interferogram bitmap scale and image position are generally unknown when designing a software null, it is necessary that the interferometry software be able to scale and register the software null to the measured interferogram. Durango Interferometry Software does this.
Software nulls are generated by raytracing a double-pass, as-built lens model that includes the measured CGH substrate flatness, transmitted wavefront distortion (TWD) and thickness. Flatness is modeled as identical Zernike surface deformations on the CGH front and back surfaces. TWD is modeled as an additional Zernike surface deformation on the back surface. These Zernike surface deformations are represented as Code V .INT files. Departure from the design thickness will contribute spherical aberration in the case of a spherical wavefront.
The software null is defined at the Exit Pupil of the raytrace model. This is a next-to-last surface, made to be concentric with the point source or perpendicular to the collimated source. The axial position of the Exit Pupil (which determines its radius of curvature) is chosen to be a best image of the test optic. This is appropriate if the interferometer is focused onto the test optic. In practice, if the software null correction is small then the position of the Exit Pupil is not critical. Ideally, the Exit Pupil would be the interferometer camera, but we lack sufficient information to raytrace the interferometer. If we are given your Fizeau sphere prescription, we can readily incorporate this into the raytrace model (making the Exit Pupil a plano surface). We do assume that the interferometer optics image the Exit Pupil onto its camera without distortion.
The software null is represented by a square grid of OPD values in the form of a Code V .INT file of wavefront type. The number of grid points is typically 500×500, but any density is possible. The software null is generated by tracing rays to each grid point and noting the optical path difference from the source. By using a grid representation (rather than Zernikes) we are able to define the software null over only those grid points that represent rays passing through the CGH null aperture. Ray blocking at the test optic aperture is ignored, allowing the software null to overfill the test optic.
The raytrace model typically defines two or more fiducials. These are identifiable features on the CGH null. The locations of these fiducials are recorded in the leading comment lines of the CodeV .INT file. These fiducials are to be used to achieve proper scaling and registration of the software null to your interferogram.
A null test configuration typically includes several compensators or alignment degrees of freedom. Viewed from a CGH-centric perspective, the location of the interferometer focus provides 3 compensators and the location of a rotationally symmetric test asphere provides 5 compensators. We generally instruct the user to first align the CGH to the interferometer, using an Alignment CGH and/or retro-alignment features integral to the CGH null. Subsequently, the test asphere is aligned to best null the interferogram.
Prior to generating a software null, we simulate this alignment process with our as-built raytrace models. This assures that the software null correction is as small as possible and that it corresponds to the interferogram that you will achieve using best practice.
The software null is a good representation of the error you will incur by not applying a software null. This error is often small enough that users may justifiably elect to omit the software null subtraction.