IES Files, Decoded: What’s Inside a Photometric File and How to Use It

Every lighting layout you’ve ever calculated started with a photometric file. Open one in a text editor and you’ll see rows of numbers that mean nothing without context. But that small ASCII file is the link between a lab measurement and your design — and if it’s wrong, your layout is wrong. This guide walks through the .ies file format line by line, explains how the data gets captured, and shows you what to check before you trust a file in your calculations.

What Is an IES File?

An IES file (sometimes called an .ies photometric file) is a plain-text ASCII file that contains the measured luminous intensity distribution of a luminaire. The format is defined by ANSI/IES LM-63, a standard maintained by the Illuminating Engineering Society. The current active edition is LM-63-2019, reaffirmed in 2025, though many files in circulation still follow the 2002 or earlier versions.

The file encodes how much light a fixture emits in every measured direction — a three-dimensional intensity map captured by a goniophotometer and distilled into a structured text document. Lighting design software such as AGi32, DIALux, Relux, and Revit import these files to simulate how a fixture will perform in a real space.

An IES file is not a rendering. It does not contain color information, spectral data, or visual appearance. It is strictly a record of luminous intensity by angle, paired with metadata about the fixture, lamp, and test conditions.

The Anatomy of an IES File

When you open an .ies file in a text editor, the data follows a specific sequence. Every field must appear in order. Here’s what you’ll find, block by block.

Block 1: Format Identifier

The first line declares which version of LM-63 the file follows. For a current file, this reads:

IESNA:LM-63-2002 or IES:LM-63-2019

Older files from the 1991 revision begin with IESNA91. Files from the original 1986 standard have no identifier line at all — they jump straight into label lines. Most modern software handles each variant, but the absence of an identifier can occasionally cause import issues.

Block 2: Keyword Lines

These are metadata lines that begin with bracketed keywords. LM-63-2002 and later require four mandatory keywords:

• [TEST] — The test report number from the photometric laboratory.
• [TESTLAB] — The name of the testing laboratory.
• [ISSUEDATE] — The date the photometric data was issued.
• [MANUFAC] — The luminaire manufacturer.

Additional optional keywords can include [LUMCAT] (luminaire catalog number), [LUMINAIRE] (description), [LAMPCAT] (lamp catalog number), [LAMP] (lamp description), and others. These fields are what you see in the descriptive header when you load a file into AGi32’s Photometric Toolbox or DIALux’s luminaire import dialog.

Block 3: TILT Statement

This line declares whether the file includes tilt multiplier data. When a lamp burns at an angle, heat and gas convection inside the bulb can shift its light output. A tilt multiplier corrects for this variation at different mounting positions.

• TILT=NONE — No tilt data (most common for fixed-mount fixtures).
• TILT=INCLUDE — Tilt multiplier data follows in the next lines.
• TILT= — Tilt data is in a separate file (this option was removed in LM-63-2019).

If TILT=INCLUDE is specified, the next four lines contain: the lamp-to-luminaire geometry identifier, the number of angle/multiplier pairs, the angles, and the multiplying factors. For the vast majority of architectural and commercial fixtures, this is simply TILT=NONE.

Block 4: Lamp and Luminaire Data (Line 1 of 2)

This is where the numerical data begins. The first data line after the TILT statement contains 10 values, separated by spaces or commas:

1. Number of lamps — How many lamps were in the fixture during the test.
2. Lumens per lamp — The rated initial lumens of each lamp. A value of -1 indicates absolute photometry, meaning the candela values represent the actual measured output of the complete luminaire and are not scaled relative to lamp ratings.
3. Candela multiplier — A scaling factor applied to all candela values. Typically 0.
4. Number of vertical angles — How many vertical measurement points are in the file.
5. Number of horizontal angles — How many horizontal measurement planes are in the file.
6. Photometric type — Defines the coordinate system. 1 = Type C (most common in North America, used for architectural, commercial, and area lighting), 2 = Type B (used for some floodlights and adjustable fixtures), 3 = Type A (rarely encountered).
7. Units type — 1 = Feet, 2 = Meters. Refers to the luminous opening dimensions.
8. Width — The width of the luminous opening.
9. Length — The length of the luminous opening.
10. Height — The height of the luminous opening.

A note on LED fixtures: The IES file format predates the widespread adoption of LED, so its “lamp” fields weren’t designed with integrated light sources in mind. For LED luminaires, manufacturers handle this in one of two ways. Some enter 1 lamp with the total lumens of the fixture. Others use absolute photometry (lumens per lamp = -1), which bypasses the lamp-scaling model entirely and reports the luminaire’s actual measured output directly — the more accurate and increasingly preferred approach for LED products.

A note on circular luminous openings: For round fixtures such as downlights, the LM-63 standard uses a negative value for the width (representing the diameter) to indicate a circular luminous opening. If you open an IES file for a 6-inch round downlight and see -0.5 in the width field, the file is not corrupted — it’s telling the software the opening is a circle with a 6-inch diameter. Manually changing this to a positive number will cause the software to interpret the opening as rectangular, which can affect luminance calculations and near-field accuracy.

Block 5: Lamp and Luminaire Data (Line 2 of 2)

The second numerical data line contains three values:

1. Ballast factor — The ratio of actual lamp lumens to rated lamp lumens under the test ballast. For LED fixtures tested using absolute photometry, this is typically 0.
2. Ballast-lamp photometric factor — A factor accounting for the ballast-lamp combination’s effect on light output. Again, typically 0 for absolute photometry.
3. Input watts — The total electrical input power of the luminaire during the test.

Both the ballast factor and ballast-lamp photometric factor are legacy fields from the fluorescent and HID era. They remain in the file format because the text parser expects them in this position; omitting them would break the field sequence. For any LED luminaire tested under LM-79 absolute photometry, both are typically set to 1.0.

Block 6: Vertical Angles

A list of the vertical angles at which measurements were taken, starting from 0° (nadir for a Type C downlight). For a full-distribution Type C fixture, this typically runs from 0° to 180° in increments of 2.5° or 5°. A fixture that only emits downward might range from 0° to 90°.

Block 7: Horizontal Angles

A list of the horizontal angles (C-planes) at which measurements were taken. The range and number of horizontal angles encode the fixture’s symmetry:

• 0° only — The fixture has full rotational symmetry (e.g., a round downlight). A single vertical slice represents the entire distribution.
• 0° to 90° — Quadrilateral symmetry. The fixture is symmetric across two perpendicular planes (common for rectilinear troffers).
• 0° to 180° — Bilateral symmetry. The fixture is symmetric across one plane (common for linear fixtures).
• 0° to 360° — No symmetry assumed. The full distribution is measured (common for asymmetric optics, wall washers, and adjustable fixtures).

Block 8: Candela Values

The remainder of the file is the measured intensity data — the actual photometric web. Candela values are listed sequentially: all vertical angles at the first horizontal angle, then all vertical angles at the second horizontal angle, and so on through the last horizontal angle.

If a file has 37 vertical angles (0° to 180° in 5° increments) and 5 horizontal angles (0° to 90° in quadrilateral symmetry with 22.5° steps), the candela block will contain 37 × 5 = 185 values.

This is the data that your software uses to build the three-dimensional intensity distribution, calculate illuminance on surfaces, and generate isolines, candela plots, and spacing criteria.

How the Data Gets Captured: Goniophotometry

The numbers in an IES file originate from a goniophotometer — a precision instrument that measures luminous intensity as a function of angle. Understanding what happens in the lab helps you interpret the file and recognize when something looks wrong.

The Type C Goniophotometer

The Type C configuration is the standard for architectural and commercial lighting in North America, as defined by CIE 70:1987 and referenced in ANSI/IES LM-79.

In a Type C system, the luminaire is mounted at the center of a darkroom. Depending on the mechanical design, either the fixture rotates on two axes while a detector remains stationary, or a mirror system redirects emitted light to a fixed detector as it traverses the angular grid. The detector — a calibrated photometer with a V(λ)-corrected sensor matched to human visual sensitivity — records illuminance at each angular position. Using the inverse square law (I = E × d²), the system calculates luminous intensity in candela at every point on the measurement grid.

The vertical axis (gamma, γ) sweeps from nadir (0°) through the horizontal plane (90°) to zenith (180°). The horizontal axis (C-planes) rotates around the vertical centerline, typically from 0° to 360° depending on fixture symmetry. The result is a spherical map of intensity that becomes the candela block in the IES file.

Absolute vs. Relative Photometry

For LED luminaires, ANSI/IES LM-79 mandates absolute photometry: the complete luminaire — driver, heat sink, optics, and LEDs — is tested as a single integrated unit. The candela values in the file represent the actual measured output. This is indicated by a lumens-per-lamp value of -1 in the data.

Older files for fixtures with replaceable lamps may use relative photometry, where the fixture was tested with a reference lamp and the results are scaled based on the rated lumens of the intended lamp. When you see a positive lumens-per-lamp value, the software multiplies the candela data by a ratio of rated lumens to reference lumens.

Stabilization Matters

Before any measurement begins, the luminaire must reach thermal equilibrium. LED output is temperature-dependent — testing before stabilization produces inflated or unstable data. LM-79 stabilization is typically assessed by monitoring light output and electrical power over a 30-minute window, using readings taken at 15-minute intervals, with variation of less than 0.5% required before data collection begins. This stabilization process can take 30 minutes or more depending on the fixture’s thermal characteristics.

Common Errors That Corrupt IES Files

A corrupted or poorly constructed IES file can silently produce incorrect calculation results. Here are the errors that most frequently cause problems, based on documented issues flagged by AGi32’s Photometric Toolbox and common field experience.

Zeroed-Out Critical Fields

The most common corrupting errors involve fields set to zero that should never be zero:

• Candela multiplier = 0 — Multiplies every candela value by zero, producing a file that shows no light output.
• Ballast factor = 0 — Same effect: the software scales all output to zero.
• Number of lamps = 0 — Invalidates the lumen calculation.
• Lamp lumens = 0 — When not using absolute photometry (lumens per lamp = -1), a zero here breaks the scaling.
• Input watts = 0 — While this won’t zero out the light, it makes efficacy calculations meaningless and can flag errors in some software.

Lumen Value Populated Instead of -1

A related error specific to LED fixtures: some photometric labs or quick-export software will place the total fixture lumens (e.g., 5000) in the lumens-per-lamp field instead of the required -1 for absolute photometry. This can lead to unintended scaling or misinterpretation of the output data, depending on how the file was generated and how the design software handles the value — producing results that look plausible but may not reflect actual performance. If you’re reviewing a file for an LED luminaire and see a positive lumen value in this field, treat it as suspect and confirm with the manufacturer or lab whether the file was generated using absolute or relative photometry.

Photometric Type Mismatch

If the photometric type field says Type C (value 1) but the vertical and horizontal angles follow a Type B convention (or vice versa), the software will misinterpret the entire distribution. The fixture may appear to throw light in the wrong direction. AGi32’s Photometric Toolbox checks for this mismatch and can suggest an alternate type based on the angles present in the file.

Mismatched Angle Counts

If the declared number of vertical or horizontal angles doesn’t match the actual count of angles listed, the candela values will be assigned to the wrong angular positions. The result is a distribution that looks nothing like the fixture’s actual performance. This is particularly insidious because the file may still import without an explicit error — the software simply reads the data in the wrong sequence.

Inconsistent Nadir Values

For a Type C fixture with multiple horizontal planes, the candela value at 0° vertical (nadir) should be identical across all planes — it’s the same physical direction regardless of which C-plane you’re measuring in. If these values differ significantly, it suggests a measurement error or a file assembly problem.

Negative Candela Values

Luminous intensity cannot be negative. Negative values typically indicate a data processing error during file generation. Most software will clamp these to zero, but the presence of negative values is a red flag that the entire file may be unreliable.

Excessive Line Length or Formatting Errors

LM-63 specifies a maximum line length of 132 characters per line. While many modern programs tolerate longer lines, some older software may truncate data without notifying the user. Other formatting issues include missing delimiters (spaces or commas between values), stray characters, or carriage return/line feed inconsistencies between Windows and Unix-generated files.

How to Verify a File Before You Use It

Don’t assume a file is good just because it imports without an error dialog. Here is a practical verification workflow.

Step 1: Open in a Text Editor First

Before importing into your design software, open the .ies file in Notepad, TextEdit, or any plain-text editor. Check:

• Does the file begin with a proper format identifier?
• Are the required keywords present ([TEST], [TESTLAB], [ISSUEDATE], [MANUFAC])?
• Does the catalog number match the fixture you’re specifying?
• Is the TILT line present?
• Do the numerical data lines contain reasonable values (non-zero watts, non-zero lumens or -1 for absolute, multiplier of 1.0)?

Step 2: Use Your Software’s Integrity Check

AGi32’s Photometric Toolbox runs an automatic integrity check on import and flags errors and warnings with specific descriptions. DIALux displays file information in its luminaire import dialog. Use these tools — don’t skip past the warnings.

Specific checks AGi32 performs include: LM-63-2002 keyword compliance, non-zero lumen and watt values, valid photometric type (1 or 2), valid units type (1 or 2), matching angle counts, and nadir consistency.

Step 3: Verify Against the Spec Sheet

Compare the IES file data to the manufacturer’s published specification sheet:

• Total lumens: Does the calculated lumen output from the file match the spec sheet? A significant discrepancy (more than 5–10%) warrants investigation.
• Input watts: Does the watt value in the file match the published wattage?
• Distribution: Does the candela plot from the file match the distribution shown on the spec sheet (narrow, medium, wide, asymmetric, etc.)?
• Catalog number: Does the [LUMCAT] keyword in the file match exactly? Watch for generic or placeholder catalog numbers that suggest the file may be for a different configuration.

Step 4: Sanity-Check the Distribution

After importing, look at the candela distribution plot in your software. Ask:

• Shape vs. fixture type: Does the shape make sense for this fixture type? A recessed downlight should show a concentrated downward pattern, not a batwing or omnidirectional spread.
• Peak intensity angle: Is the peak intensity at a reasonable angle? For a standard downlight, peak should be near 0° (nadir). For a wall washer, peak should be offset.
• High-angle intensity: Is there unexpected intensity at high angles (above 75°–80°)? This could indicate a measurement artifact or a file intended for a different optic.

Step 5: Cross-Reference the Test Date

The [ISSUEDATE] keyword tells you when the file was generated. Photometric data for LED fixtures should correspond to the current product revision. If the test date predates a known product update (new optic, new LED board, revised driver), the file may not represent the fixture you’re specifying. Request an updated file from the manufacturer.

IES vs. EULUMDAT (LDT): A Brief Comparison

If you work with European manufacturers or international projects, you’ll encounter EULUMDAT files (.ldt extension). Both formats encode the same fundamental data — luminous intensity by angle — but differ in structure:

• IES (LM-63): ASCII text, keyword-based header, predominantly used in North America.
• EULUMDAT (.ldt): ASCII text, fixed-field structure with predefined line positions for lamp data, flux, and dimensions. Predominantly used in Europe.

Both are supported by AGi32, DIALux, and Relux. The photometric data itself is equivalent — the difference is in file organization and metadata conventions. One functional distinction worth noting: EULUMDAT files include fixed fields for color temperature (CCT) and Color Rendering Index (CRI), while standard IES LM-63 files are entirely color-blind — they contain no color information whatsoever. If color data is important to your workflow, an LDT file carries it natively; with an IES file, you’ll need to reference the spec sheet or request supplemental data. Files can be converted between formats using software tools, though metadata fields (including color data) don’t always map one-to-one.

It’s worth noting that IES has signaled that LM-63 will eventually be replaced by ANSI/IES TM-33, an XML-based format designed to carry richer data including spectral information and more detailed luminaire geometry. That transition is still underway, and .ies files remain the dominant format in practice.

What to Request from Manufacturers

When requesting photometric data, be specific:

• The exact configuration: Optic code, lumen package, CCT, and driver type. A file for a medium flood optic won’t help if you’re specifying a spot.
• Absolute photometry: For LED fixtures, confirm the file was generated using absolute photometry per LM-79.
• Current revision: Ask whether the file reflects the current production version of the fixture.
• LM-63-2002 or later compliance: This ensures the file includes the required keywords and follows current formatting standards.
• Luminous opening dimensions: Verify that the luminous opening in the file accurately represents the fixture’s actual emitting area, as this affects near-field calculations and luminance estimates.

Bringing It All Together

An IES file is a small text document with an outsized impact on your design. Every lux value on your calculation grid, every isoline on your site plan, and every spacing decision in your layout traces back to the data in that file. Understanding what’s inside — and verifying that it’s accurate — is one of the simplest ways to protect the integrity of your work.

At LiteSource, we make lighting simple — so photometric data becomes a tool you can trust, not a black box you hope is right.