IES vs LDT Photometric Files

IES vs LDT: how the two photometric file formats differ, why both matter for lighting product data, and how to normalize them for matching and enrichment.

published enrichmentdistributors

When a lighting distributor onboards supplier feeds from North American and European manufacturers, the same physical fixture arrives with two different photometric files — one IES, one LDT — and catalog systems that cannot parse either end up with broken attribute matching, duplicate SKUs, and design-software rejections from buyers who cannot get the file format they need. The IES vs LDT question is not academic: it determines whether a photometric attribute is usable or invisible in your product data.

Claro’s enrichment pipeline parses both formats, extracts normalized photometric attributes — lumen output, wattage, beam angle, test report number — into a shared schema, and links each file back to the correct canonical product record with full data provenance. When the same SKU carries a conflicting lumen claim across its IES and LDT versions, Claro flags the discrepancy and writes the resolved, trusted value back into your PIM or ERP rather than silently picking one.

What IES and LDT files actually are

A photometric file is a structured text file that records how a luminaire distributes light in space: luminous intensity values across a grid of vertical and horizontal angles, plus metadata such as total lumen output, input wattage, and the testing laboratory. Lighting designers load these files into planning tools like DIALux, AGi32, and Relux to simulate how a fixture will illuminate a room, aisle, or street before anything is physically installed.

The IES vs LDT split comes down to geography and origin. IES files follow the IESNA LM-63 specification published by the Illuminating Engineering Society; they dominate in the Americas and have gone through several revisions (LM-63-1995, -2002, -2019) that changed how keywords, tilt data, and lamp metadata are written. LDT files follow the EULUMDAT format developed in Germany; they are the de facto standard across Europe. Both are plain-text files that encode an intensity distribution, but they order fields differently, use different angle conventions, and carry slightly different metadata. A file in one format cannot simply be renamed into the other — it must be parsed and converted at the field level.

Why it breaks lighting product data

For a distributor or marketplace selling lighting products, the photometric file is not a footnote — it is the attribute that buyers and design engineers actually depend on before specifying a fixture. The problem is that the same physical product often arrives as an IES file from the North American supplier feed and as an LDT file from the European one. Many catalogs carry both, neither, or a mismatched pair attached to the wrong SKU. Treating IES and LDT as interchangeable text strings breaks both matching and enrichment.

In industrial distribution, a lighting manufacturer ships a high-bay luminaire under one MPN in the US and a near-identical variant in the EU; identity resolution must recognize these as the same product family while preserving format-specific photometric files for each region. In MRO, a maintenance catalog inherits fixtures from a dozen acquired suppliers, each attaching photometric files with inconsistent naming conventions, so deduplication needs to read inside the file — lumen output, beam angle, test lab number — rather than trust the filename. The same discipline that applies to unit of measure normalization — parse the value inside the format, validate it, then normalize — applies here.

Without photometric normalization With Claro enrichment
IES and LDT treated as interchangeable strings Both formats parsed; intensity values extracted into shared schema
Same fixture listed as 2-3 separate SKUs by format One canonical product record linked to both photometric files
Conflicting lumen claims across IES and LDT versions Discrepancies flagged; resolved value written back to PIM/ERP
Filenames used to infer fixture identity Embedded metadata (lumen output, wattage, test ID) drives matching
Design-software rejects wrong format Buyers can access whichever regional format they need

Key differences between IES and LDT

Both formats encode the same underlying measurement — luminous intensity as a function of angle — but they differ in structure, conventions, and metadata scope.

Attribute IES (LM-63) LDT (EULUMDAT)
Origin Illuminating Engineering Society, North America German lighting industry, Europe
Active standard IESNA LM-63-2019 (plus older -1995, -2002) EULUMDAT (no formal version history)
Angle convention C-gamma planes C-gamma planes (same concept, different ordering)
Metadata fields Keyword-value pairs (LUMCAT, LUMINAIRE, LAMP, etc.) Fixed positional fields with lamp and luminaire metadata
Preferred design tool AGi32, many North American tools DIALux (historically), European tools
Typical file size A few KB to ~50 KB A few KB to ~50 KB
Conversion Requires field remapping and angle-convention translation Requires field remapping and angle-convention translation

How Claro normalizes photometric attributes

Data normalization across photometric files follows the same parse-validate-trace workflow that applies to any supplier-specific format. Claro reads both IES and LDT files, extracts a normalized attribute set — luminaire description, lumen output, input wattage, color temperature, beam angle, and test lab reference — and stores each extracted value with a pointer back to the source file and the line it came from. This is the same provenance model that makes enriched attributes auditable and reversible.

When two photometric files for what appears to be the same SKU disagree — for example, an IES claiming 12,000 lm against an LDT claiming 9,400 lm — the system surfaces the conflict rather than silently picking one value. A product data manager can review the discrepancy, confirm which measurement is current, and approve the write-back to the catalog. The extract-specs-from-pdfs playbook covers the same parse-validate-trace pattern applied to spec sheets and datasheets.

FAQ

Can I convert an LDT file to an IES file?

Yes. Because both formats encode the same underlying intensity distribution, a EULUMDAT (LDT) file can be converted to IES LM-63 and vice versa. The conversion has to remap angle conventions and metadata fields rather than copy text, so use a dedicated converter and validate the result, since rounding or unit assumptions can shift values.

Is IES or LDT more accurate?

Neither format is inherently more accurate — accuracy depends on the laboratory measurement, not the file type. IES (LM-63) and LDT (EULUMDAT) simply package the same measured photometry using different layouts and conventions. A well-measured LDT beats a sloppy IES and vice versa.

Why does the same fixture have both an IES and an LDT file?

Manufacturers selling into both North American and European markets publish both formats because regional lighting-design software and customers expect their local standard. In a catalog this means one canonical product can legitimately carry two photometric files, which is why matching should link both to a single record rather than treating them as separate SKUs.

What software reads IES and LDT files?

Lighting calculation tools such as DIALux, Relux, and AGi32 read these files to simulate illumination. DIALux historically favors LDT, while many North American workflows expect IES, which is another reason distributors need both formats available and correctly mapped to each SKU.

How do I know which photometric file belongs to which product?

Do not trust the filename alone. Parse the file to read its embedded metadata — luminaire description, lumen output, wattage, and test report number — and match those values against the product record. A validator or an enrichment pipeline that extracts and reconciles these attributes is the reliable way to catch mismatched or stale files.

Claro

See how Claro handles this in production

This concept is one piece of keeping a catalog trusted. See how Claro resolves identity, enriches missing attributes, and validates every update before it reaches your PIM or ERP.

Learn more