Non-Uniformity Analysis for a Spatial Light Modulator February 25, 2002 1. Introduction and Purpose There is an inherent reflectivity non-uniformity in spatial light modulators, hereafter referred to as SLM, that renders them unusable in certain printing applications. These non-uniformities can be caused by the manufacturing process or by stresses introduced by the physical mounting arrangement. Two of these artifacts, low frequency and high frequency non-uniformity, need to be qualified as to their degree. Above some pre-determined limit, the SLM needs to be rejected for printing applications. Of course, there is the possibility of digital correction of the image non-uniformity, but this comes at a cost in terms of additional processing overhead as well as quantization artifacts if the correction required is excessive. Figure 1 shows a typical uncorrected image displaying both low frequency and high frequency artifacts. The purpose of this project is to produce a QC / QA tool that could be used by the manufacturer of the SLM, to verify the acceptability of the device for an application prior to its being built into an apparatus. The evaluation of monochrome images in each of red, green, and blue is required as the non-uniformity image is wavelength dependent. The low frequency non-uniformity is characterized by slowly varying reflectance over a large SLM area, whereas the high frequency non-uniformity can be seen by looking closely at a small area and noting the characteristic brush-mark appearance which is an artifact of the rubbing process used during manufacture. Figure 2 shows the low frequency content of the same image from Figure 1, whereas, Figure 3 shows the high frequency content. Ideally, both of these images would be perfectly uniform. 1
Figure 1: Uncorrected Image 2
Figure 2: Low Frequency Image 3
Figure 3: High Frequency Image 4
By low pass filtering the original image, then only the low frequency non-uniformities are seen and can be quantified. By high pass filtering, only the high frequency non-uniformity remains and can be characterized. 2. Approach The approach to this effort was driven by several factors. Primarily, there was a requirement to produce a GUI application that used the IDL programming environment. Secondary was to make the application actually useful. This project succeeded at both. Due to the time constraints, as well as the uncertainty of the actual requirements for the application, the approach was to lay the foundation for an extensible tool. Initially, this tool would have minimal functionality, but would allow an easy way to add or modify testing as the requirements were settled down. Consideration was given to the use of the application. The application should be simple to use, provide a repeatable procedure, and remove the subjectivity out of making a pass/fail decision. In addition, a few additional features would be added to allow a more detailed look at the actual data that drove the decision. The reflectivity images used in making the decision could be viewed during the testing, and the data derived from processing these images, can be viewed and stored for post-processing if desired. 3. High Level Requirements The user first selects from the Image menu, either an image to open for analysis, or requests to acquire an image from a camera/scanner. There is also an option to exit the application from this menu. If the open image option is selected, the user is prompted for the image to be opened. Only.tif images are allowed. Once the image is opened, some basic image information is displayed as text to the user: filename, number of rows, number of columns, mean pixel value, standard deviation, minimum pixel value, and maximum pixel value. Once opened, an option to allow the user to view the image is provided. This, along with the afore mentioned text information, will provide a way or the user to verify that the 5
proper image is being analyzed. After an image is opened, and, optionally displayed, the next step would be to perform low frequency and/or high frequency testing. If acquire new image option is selected, the user is prompted to ensure that the input acquistion device is ready, and to provide a filename to store the image as. Then the user initiates the scan. The user will also be provided with a data menu which allows either saving or viewing of analysis data. In the case of saving, the user is prompted to enter a filename to save the analysis data as. For viewing, the user is prompted to select an analysis data file to view. There will also be a help facility provided. The operation of the Analyzer application will be provided to aid the user in proper use. An about dialog box will provide the user with data about the current version of the Analyzer application. Once an image has been opened, low and/or high frequency testing can commence. For low frequency testing, the user must first low frequency filter the image. This removes the high spatial frequency structure in the image that is not important for the low frequency testing. The user can select from various low frequency filters, as well as select the kernel size to be used. Additional filters can easily be added in the future. Once a low frequency filter type and kernel size have been selected, the user commands the original image to be filtered and, optionally, the low frequency image can be viewed. Along with the low frequency filtered image, the low frequency filtering operation also produces similar statistics as were computed for the original image. These new computed statistics will then be used in the low frequency evaluation of the image. For low frequency image evaluation, it has been determined that two types of image artifacts are important to test for in printing applications: non-uniformity and gradient. Non-uniformity is tested by comparing the global low frequency image statistics against pre-defined limits. For gradient testing, moderately steep edges over large image areas are important and must also be compared against pre-defined limits. For both of these low frequency tests, the used can select various acceptance limits prior to performing the test. The application will then produce a text message indicating pass or fail of the low frequency test. 6
For high frequency image evaluation, a similar user interaction is required. In this case, only the high frequency non-uniformity test is required. After performing the tests, against the selected limits, the user can save the analysis data and also display the results if desired. If saved, the analysis data is stored as a formatted text file that can be opened with other applications (e.g. Microsoft Excel). For invalid operations by the user, the application should warn or coerce the user for the proper action. 4. Design and GUI Layout Figure 3 shows the design solution for the IDL GUI which meets the requirements for the project. It was attempted to make the GUI flexible enough to allow an experienced operator to have access to more detailed data than the standard operator would. This is seen in some of the controls to display images and view analysis data. It would also be a simple matter to initiate a more automated process, where as soon as an image was opened, or a new image acquired, the entire ensemble of steps would be executed and the results written to a file. This will be considered for a final production version of the application. The actual IDL design was built upon familiar constructs due to the time constraints. Pointers were used to reference the various images that were needed between the various event handlers. Using separate functions for the various tasks would be a better architecture for the next version as well. This would allow an even easier method to maintain and add new functionality. A global data structure was used in the top level base to hold all references to widgets, and additional data needed by the various event handlers. This technique was used in the past and performed well here. 5. Testing 7
Figure 4: Main Application GUI 8
The application was tested for proper operation. All controls were tested to ensure proper operation and that warning messages were presented to the user if improper steps were commanded. In addition, a sample SLM reflectance image acquired using a high resolution monochrome digital camera was tested (uncorrected.tif). Opening, viewing, computation of statistics and low pass filtering was performed and worked as expected. This image was evaluated using Adobe Photoshop and the results agreed with those attained with the Analyzer application. It appeared that the pointers used to reference the original and filtered images were not being lost, so that there were no apparent memory leaks. The data files produced by the application were opened in Unix and the correct data was observed to be stored. Files were tested to ensure that they had been properly closed after access. The formatted text files produced need verification that they are properly formatted for use with Microsoft Excel. This needs to be tested, since the long-term intent will be to further analyze and document the current and archived test data using a tool such at this. 6. Results and Conclusions The scope of this project was kept very well defined and limited based upon the requirements and the time constraints. Time constraints did not allow the high frequency filtering to be operational at the time of this writing, but will be easily implemented using the low frequency filtering source code as a model. In addition, the actual tests on the filtered data cannot be d until algorithms have been developed. Since the algorithm development is beyond the scope of the course work requirements, and given the time constraints, it is not currently operational. Following is a list of the status of the major functions of the application: FUNCTION Overall GUI Image open STATUS 9
Image acquire Application exit Application help Application about Display Original Image Save analysis data View analysis data Low Frequency Filter Low Frequency Test High Frequency Filter High Frequency Test not operational partial not operational not operational not operational Changes to the requirements may also occur to this application as actual users are asked to evaluate it. At this stage the Analyzer application is an engineering model. 10