This article was published in the September 2013 issue of LEDs Magazine.
Visit the Table of Contents and view the E-zine version in your browser. You can download a PDF of the magazine from within the browser E-zine.
Computer-aided design (CAD) technology has been applied in many technology segments and is increasingly important in the optical space. Optical simulation can speed product development and ensure that new products provide optimal illumination. However, the available optical CAD software tools are largely proprietary, including the file formats used to store light-source ray files. An ongoing Illuminating Engineering Society (IES) effort is seeking to standardize ray files to ease the burden on light-source suppliers, including LED manufacturers, and make optical CAD tools more broadly applicable.
In the past few decades, especially since the early 1990s, computer technologies improved rapidly in both storage capacity and processing speed. The optical design of illumination systems, namely non-imaging optics, has benefited greatly from these advances. Both proprietary and commercially distributed optical design and analysis software were quickly developed and adopted by the optical design community, beginning initially with automotive lighting applications and later extending to general lighting applications. For an example of the use of optical software, see "Accurately model LED sources for optimal SSL product designs" from the December 2012 issue of LEDs Magazine.
All of these non-imaging optics software tools have been developed and designed differently. Each tool has its own unique, proprietary ray-tracing algorithm and CAD interface, and places different emphases on different types of applications. The implementation of non-imaging design, analysis, and simulation software was a huge step in driving improvements to lighting design lead-time reduction, accuracy, and user interface friendliness.
In order to bring the light-source characteristics into optical system design simulations, these powerful software tools all employ ray-tracing based approaches to simulation, and use ray files as the light-source models. The ray files are electronic datasets generated by the light-source manufacturers, either by simulation or by using near-field goniometer measurements.
The various ray-tracing methods provide users with optical analyses for a range of illumination characteristics including luminous intensity distribution, zonal lumen calculation, illuminance and its uniformity, tooling error induced tolerances, iso-candela on-screen simulations, road simulations (both steady and dynamic), glare analyses, and many others. In today's practice, for LEDs or any other light sources, ray files are the only viable way to model a light source accurately if near-field information is needed in conducting non-imaging optics design and simulation.
Currently all non-imaging optics design and simulation software requires a unique light-source ray file format as input. For LED light sources, the LED manufacturers must provide users with multiple proprietary formats of ray files for each LED package, generated to fit into the particular format required by the different optics software tools. If an LED manufacturer produces many types of LEDs, then all of the LEDs need to have corresponding ray files for each supported tool.
The lighting community is using several types of non-imaging optics software, even within one design team, so ray files for each type of software must be available for every LED used in the design. Of course, generating vast quantities of ray files is time consuming, increases risk of error, and is inefficient as an ongoing practice — and most of the burden lies on the shoulders of the LED manufacturers.
The standard effort
With the rapid development and adoption of LEDs for general lighting, an increasingly broader variety of LED packages are produced for use in many different specific applications. While the far-field illumination characteristics (such as luminous intensity distribution) of light sources have been standardized by IES, the light-source designated ray file format used in non-imaging optics software has wide variation that can create inconvenience, inconsistency, and inefficiency for LED manufacturers and LED users alike.
The first effort to regulate and standardize ray file formats began in late 2011 during the SPIE Optics + Photonics Conference. With extended discussions between LED manufacturers, non-imaging optics software developers, near-field photometry measurement equipment vendors, and lighting optical design engineers, the consensus became clear: the most effective approach would be to establish a single standardized ray file format. The participants believed that a standard ray file format could be adopted for both general- and automotive-lighting applications. By early 2012, the IES Computer Committee had agreed to take on this project, and a subcommittee of ray file format experts was formed in the Spring of 2012.
Again, ray files describe light-source emission characteristics by a large number of rays with individual start location, direction, flux, and optional spectral and/or polarization data. Because all ray files store essentially the same data, the concept of standardization is to have the ray file format be the "same" so that it can be accepted by all ray-tracing software — which is easier said than done.
An initial complication is the sheer size of each file. A ray file for a light source that characterizes an LED can contain millions of rays and can total more than 250 MBytes of data. Furthermore, the new standardized ray file format must not only be suitable for new ray files but also allow simple conversion of all existing ray files.
With dedicated experts and diligent efforts, this new standard, named IES TM-25, was drafted within a year, and it went through the IES Computer Committee ballot. The scope and task of TM-25 is described as "recommendations for a standard ray file format to describe the emission properties of light sources. The ray file format will contain information necessary to interface between ray tracing or other optical design, simulation, analysis and metrology software used in lighting applications."
In addition to providing more inclusive definitions, the TM-25 standard first provides high-level ray file format information such as file type and extension, overall file structure, ray order and sampling, units and data type used in the file, as well as section or block breakdown. This gives the ray file generators the basis for how to construct the general layout of the ray file.
Next, the document provides detailed descriptions of the requirements for the header section and ray file section. The header provides software users, such as optical engineers, with descriptive information about the light source used for the ray-tracing process. Besides the overall physical characteristics including luminous flux, radiant flux, spectrum data, etc., it also provides background information such as the method of ray file creation and the number of rays to be used.
The ray file section provides the geographic and mathematical descriptions of the rays including each ray's position and direction, and the strength or energy carried by each ray. While we all know that light is an electromagnetic wave, its non-imaging optics behavior can be simulated by assuming the light is a ray and each ray carries a certain amount of energy. Because color or chromaticity behavior has become more important in general lighting design, TM-25 also provides spectrum-related specifications in the ray file section.
This standard is extremely technical and tedious and is not meant for lighting designers or specifiers but for light-source manufacturers, software developers, near-field photometry measurement equipment manufacturers, and lighting optical design engineers. The development of TM-25 is an excellent example of successful cross-industry collaboration. In developing this standard, I have personally experienced the mutual willingness and dedication among the participants.
The TM-25 working group members came from each of the aforementioned sectors. The uniqueness or differentiation in each software model is very important for the purpose of competition, and as such, to find common ground and to standardize some part of the software can be challenging. From starting the draft to the committee ballot, TM-25 took less than one year to develop, faster than many of the other IES standards that have been developed. That should give us some confidence that cross-industry standardization is not only feasible but can be achieved in a timely fashion. The solid-state lighting (SSL) industry encompasses many disciplines, intersecting different talents and areas of expertise such that the technological diversity is beyond any of traditional lighting practices.