INDUSTRY INSIGHTS | Photometric data files must be dependable

The Lighting Industry Association (LIA) and 42 Partners Limited collaborate on photometric testing best practices. 42 Partners works on post-processing of photometry, providing services such as photometric data file production, conversion, and editing, in addition to others. 42 Partners also coordinates training on photometric software with the LIA. So naturally, a lot of photometric data in the form of LDT and IES files pass across our collective desks. Unfortunately, many of these files raise problems that can negatively impact design decisions.

Lighting designers use advanced software tools — including Relux and Dialux — to produce incredibly detailed lighting designs with near-photorealistic renderings of the lighting effects. They rely upon the glare tables and glare calculations delivered by the programs, yet they often base them on bad input data.

How does this happen? One issue is that program developers have made it possible to import and use any valid data file. They provide the disclaimer that they accept no responsibility for the quality and accuracy of the data used in their calculations. It is entirely possible that loosened controls on data were an unintended consequence of past poorly formatted files being rejected by the software, with subsequent attempts to revise the applications leaving gaps in calculation reliability.

We can only conclude that most users believe that if the data imports into Relux and Dialux, it must be accurate. However, nothing could be further from the truth. Following is a summary of common problems we see in photometric data files used for lighting design.

Uplight that should not be there

Most contemporary goniophotometers collect data in absolute calibrated intensities, with the lumen output calculated by summing the intensities over the spherical data collection field. Any goniophotometer will measure some stray light during the test because it is impossible to render the surfaces of the test area and the gonio itself completely nonreflective. A well-run laboratory will minimize this stray light, but there will always be some. A properly run lab will also carry out a few extra readings to establish the extent of this stray light. With these extra readings, it is possible to process the raw gonio data to remove the stray light.

We have seen uncorrected photometric data for sealed-back, downlight only, high- and low-bay luminaires with 4% to 6% uplight — that is, at least 4% to 6% over declared lumen output. There will also be stray light in the downward intensities, so the ultimate lumen output error will be higher than the nonexistent uplight percentage.

Does it matter if there is a slight percentage of uplight or stray light that goes unremarked? It does, and here’s why:

• Stray light incorrectly increases lumen output; thus, all luminaire efficacy calculations (lumens per watt) required by the U.K. Building Regulations will produce values that are too high.
• Including nonexistent uplight in glare calculations when calculating the RUG (or UGR) table will produce values in the standard glare table that are too low.

Incorrect or missing dimensions

We see a lot of photometric data files with missing or incorrect dimensions. LDT files describe two sets of dimensions — physical and luminous.

The first set of dimensions represents the physical size of the luminaire. If physical dimensions are wrong, then the entire luminaire layout plan is worthless. In design plans, we are placing luminaires in close proximity to other services, sprinklers, AC ducting and vents, signage, and so forth. If the luminaire size is incorrect, then you can’t tell if your layout will work.

The second set of dimensions indicates the size of the luminous portion of the luminaire. The main value dependent on these dimensions is the RUG (UGR) table. If the luminous size is inaccurate, then the values in the standard glare table are incorrect.

We often see data for luminaires with some light emitted horizontally and upwards where the luminous height in the file is zero in all four planes. This is physically impossible and should yield a false glare table. However, lighting design software does not “sense check” the data; it performs the calculations and produces values in the standard glare table that are incorrect.

Glare is often misunderstood; since it’s a topic present on nearly all specifications, a properly calculated glare table is especially important.

There is another wrinkle here: IES files only describe the luminous dimensions. There is no way for an IES file to provide physical dimensions. There are several complications that can arise from this:

• If the file is correct, the dimensions in the IES file are the luminous dimensions. The physical size of the luminaire is usually larger than the luminous size, so your layout will not tell you if your luminaire bangs into the AC ducts. An IES file for a luminaire with no luminous height will have a height/thickness of zero and will not be visible in your layout from certain points of view. This could pose a problem for suspended or surface downlights.
• If the file is wrong and the dimensions are the luminaire’s physical size, the luminous size is usually smaller than the physical size, so the values in the standard glare table will be incorrect. Increasing the luminous area gives lower values in the glare table — which could be the intent from an unscrupulous manufacturer.

Lighting design programs offer a workaround for this problem by providing a facility to edit the dimensions of luminaires. This is an extra step for the lighting planner that can be avoided by using correctly formatted LDT files instead of IES files.

No symmetry or incorrect symmetry

A photometric data file for use in lighting design is supposed to represent the average performance of an average luminaire of that type (except for emergency lighting products, where there are legal constraints).

Most photometric data files we see have no symmetry applied to them. If a manufacturer is developing a luminaire, they would want the test data from the prototypes to show “warts and all” so they could tell whether it has been manufactured correctly. If the luminaire is meant to have some symmetry and the test data does not, either the test setup was incorrect or the test sample was wrong. Either way, they would want to know.

Photometric data released to clients or users should be the average/mean data of the production run of that luminaire which requires symmetry to be applied. Not only does this give the necessary average performance, but it will also show the product in the best possible light (no pun intended) as the design will show the expected symmetry.

It seems this distinction between development data and product data has been lost. Many labs are only issuing non-symmetric files and leaving the manufacturer to apply any symmetry.

Too much/not enough detail

Photometric tests should be performed using data steps small enough to record the full details of the luminaire distribution, including any unexpected anomalies. Routine tests would be in 1° steps in elevation and 5° steps in azimuth with the ability to reduce this step size when required. This is test data; it is not suitable to be released for use with lighting design software.

Lighting design programs calculate the average effect of a luminaire over a small area, then repeat the calculation for the next small area. The size of the area is determined by many parameters but is typically in the range of 0.2m² to 10m². Visual representations and maximum and minimum values are obtained by using the results from each of these areas, while the main calculations are based on the combined effect of all these small areas in the lighting scheme. Each area requires the calculation of an average intensity from the luminaire at various angles. The more detailed the file, the longer it takes to calculate the average.

The released data for lighting design purposes should have the correct data steps appropriate to the distribution. Consider the following examples.

A dense opal downlight luminaire that has an almost perfect lambertian distribution (output is proportional to the cosine of the angle) can be described with 19 data steps (0° to 90° in 5° steps; each elevation angle is relevant to all azimuth angles). This is a small calculation load for the program.

If a test data file is provided with, say, 0° to 180° in 1° steps in elevation and 5° steps in azimuth, the program must calculate not from 19 data steps but from 13,032 data steps — which increases the calculation load on the program and slows scheme calculation down without having any effect on the accuracy of the calculation. Providing extra detail is not harmful, but it is wasteful and unnecessary and will slow the light planner down.

On the other hand, trying to design with a symmetric 10° FWHM (full width half maximum) spotlight with 5° elevation data steps is wrong, misleading, and potentially very inaccurate. There would only be three data points that are significant — 0°, 5°, and 10° — with no detail about what happens between each point. This luminaire would require data in 0.5° or possibly 0.1° elevation steps to describe the beam shape correctly.

Many LED streetlights have sharply delineated peak intensities in elevation over a relatively small azimuth spread. The old CIE Streetlight data format expected variable intensity steps in both azimuth and elevation, with maximum detail being 2.5° in elevation and 5° in azimuth over the peak width, relaxing to 15° in both directions well away from the peak.

We have seen LED streetlights that require even smaller steps in both planes. Missing the peak intensity due to wide data steps in streetlighting is poor practice that results in incorrect values for threshold increment (TI) as well as longitudinal and overall uniformity.

The same requirements for detail apply to narrow-beam floodlights and some extreme emergency luminaires that have a very narrow peak and a sharp run back above and below the peak. Remember that designers have statutory responsibilities under safety legislation when designing emergency lighting installations and can be held criminally responsible for unsafe designs. Missing peaks and troughs in the data will also result in lumen output errors and therefore incorrect results for luminaire efficacy calculations (lumens per watt) required by the Building Regulations.

A polar curve showing straight lines is a rather good indication that the data steps are too wide to correctly describe the luminaire. If a detailed file shows a very jagged polar curve, the lighting designer may decide not to use that luminaire in a scheme, because the visual effect when installed may result in stripes on the floor that are not demonstrated in the average calculations of the lighting design program.

Filename and catalogue number

It is a relatively simple matter to ensure the filename and catalogue number match in some way. This makes it easy for designers to find a particular product data file from a list. We see a surprising number of files where the filename has no relationship to the catalogue number, and in some cases a catalogue number and filename that are supposed to match are different, so the lighting planner cannot be sure which data to use. Manufacturers and laboratories should make it easy for designers to find and verify the data and to which product it belongs.

Exceedingly long filenames and catalogue numbers are unnecessary. Exporting LDT files from a particular website produces catalogue numbers of 300 characters and more. The LDT file format specifies a maximum of 78 characters for luminaire name and luminaire number; the subsequent ELX format specifies a maximum of 24 characters. The default maximum expected length for lighting design programs is now 40 characters. While lighting design programs may tolerate more characters, they often do not have enough room on the screen to display everything.

The LDT file format specifies a maximum of 8 characters for the filename; the subsequent ELX format specifies a maximum of 12 characters. Although both limits are currently ignored by lighting design programs, there are still several applications that stick to the Microsoft Windows path length and line length limit of 256 characters. Editing these for consistency and clarity takes additional time away from actual lighting design planning.

We understand that the files downloaded go into Relux and Dialux and produce answers. Still, as suppliers and servicers to designers and users, manufacturers and test laboratories should ensure that the data presented is in the optimal format to help their clients make effective and efficient use of their products.

Follow our LinkedIn page for our latest news updates, contributed articles, and commentary, and our Facebook page for events announcements and more. You can also find us on the X platform.