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.
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.
Related
Tool
Photometric File Validator
Check that an IES or LDT file parses cleanly and the photometric values are internally consistent.
Tool
LDT to IES Converter
Convert a EULUMDAT file to IES LM-63 without losing intensity data or metadata.
Glossary
Unit of Measure
Why lumens, watts, and dimensions need a normalized unit model before records can be compared.
Glossary
Data Normalization
Turning supplier-specific formats into one consistent, matchable schema.
Playbook
Extract Specs From PDFs
The same parse-validate-trace workflow applied to spec sheets and datasheets.
Glossary
Data Provenance
Tracking where each attribute value came from so enriched records stay auditable and reversible.
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