Validate IES and LDT Photometric Files Before PIM Upload

A practical workflow for checking IES and EULUMDAT/LDT photometric files before attaching them to luminaire records in a PIM or ERP.

An IES or LDT file should not be uploaded to a PIM just because it has the right extension. Before it becomes a trusted luminaire asset, confirm that the file parses, that its declared angle grid matches the actual candela table, that metadata points to the right SKU or MPN, and that parsed values do not conflict with the datasheet or supplier feed. The goal is not to turn Claro into specialist lighting-design software; the goal is to stop corrupt, stale, or misassigned technical assets from polluting the product record your catalog, ecommerce filters, and downstream design workflows depend on.

For a lighting manufacturer launching a new high-bay range, the common failure is simple: files arrive in a zip named by project, not by SKU. A distributor then attaches HB-120W-old.ldt to the current 150 W product because the family name looks close. The file may still open in a lighting tool, but the product record now carries the wrong flux, beam distribution, and provenance. This playbook gives catalog, PIM, and ecommerce teams a repeatable validation path before write-back.

What IES and LDT validation means

IES LM-63 and EULUMDAT/LDT both encode a luminaire’s photometric distribution as metadata plus a table of luminous intensity values across defined angles. IES is the Illuminating Engineering Society format used heavily in North American workflows; LDT is the EULUMDAT format widely encountered in European lighting catalogs. See IES vs LDT Photometric Files for the format comparison.

Validation has three layers:

Layer	Question	Example checks
Structural	Can the file be parsed as the format it claims to be?	Header/version line, required numeric fields, angle counts, complete candela matrix
Semantic	Do the values make sense together?	C-plane order, gamma-angle coverage, symmetry declaration, no missing or negative intensity values unless explicitly expected by a parser rule
Catalog	Does the asset belong to this product record?	Manufacturer, catalog number, MPN, wattage, lumen output, dimensions, revision date, source provenance

Structural validation catches files that will break on import. Semantic validation catches files that parse but are internally suspicious. Catalog validation catches the most expensive problem: a technically valid file attached to the wrong product.

The validation checklist before PIM upload

1

Detect the actual format

Do not trust the file extension. Identify whether the contents follow IES LM-63 or EULUMDAT/LDT conventions, then reject mislabeled files or route them through a controlled conversion workflow. A renamed .ldt file is not an IES file.
2

Parse the file and compare declared counts to actual rows

Confirm that angle counts declared in the header match the number of C-planes, gamma angles, horizontal angles, vertical angles, and candela values actually present. A file that declares 37 vertical angles but contains 36 values may still look like text, but it should not become a product asset.
3

Check C-plane and gamma-angle integrity

Ensure angle lists are numeric, ordered consistently, and compatible with the declared photometric type or symmetry. Watch for duplicated angles, skipped planes, or mixed conventions after conversion from one format to another.
4

Review symmetry declarations

A symmetric luminaire may encode fewer planes than an asymmetric one. That is normal only when the symmetry declaration and angle grid agree. If the declaration says symmetric but the values imply a broader distribution, quarantine the file for lighting or product-data review.
5

Flag anomalous intensity values

Check for missing, non-numeric, negative, zero-only, or extreme candela values. A zero value can be valid at a particular angle; a full distribution of zeros, NaN, or impossible spikes is a data-quality exception, not a publishable asset.
6

Reconcile luminous flux, wattage, dimensions, and units

Compare parsed lumen output, input wattage, luminous-opening dimensions, and unit fields against the datasheet and supplier feed. Differences are not automatically wrong because test conditions and product variants differ, but they should be visible before the asset is approved.
7

Match the asset to the canonical SKU or MPN

Use manufacturer, catalog number, MPN, family, wattage, CCT, beam angle, dimensions, and file revision date. The match should resolve to one canonical record, not just to a product family. Claro’s catalog matching and supplier onboarding patterns apply here: identify the product before enriching it.
8

Capture provenance and write back approved results

Store file name, hash, supplier, source URL or package, upload date, parsed values, validation status, and reviewer decision. When approved, write the asset link and trusted attributes back into the PIM or ERP with provenance intact. See data provenance for the field-level pattern.

Batch-validation output your team can actually use

A useful batch report should separate deterministic failures from review questions. Do not produce one giant “valid/invalid” column.

Output field	Purpose	Example value
asset_id	Stable reference for the file	supplier_zip_2026_07/HB150_4000K.ies
detected_format	Prevents extension-based mistakes	IES LM-63
parse_status	Shows whether the file can be read	pass
matrix_check	Compares declared and actual angle counts	fail: 181 expected, 180 found
candidate_sku	Best product-record match	HB150-840-WIDE
match_confidence	Routes ambiguous records	0.82, review required
conflicts	Summarizes datasheet disagreements	IES 18,200 lm vs PDF 17,600 lm
recommended_action	Turns validation into workflow	quarantine, request current file
provenance	Keeps source evidence attached	supplier portal URL, file hash, received date

This structure lets clean assets move forward while a short exception queue goes to the right reviewer.

What can be automated and what needs review

Check	Deterministic automation	Contextual or human review
File parses as IES or LDT	Yes	No, unless the parser detects a vendor-specific extension
Declared angle counts match candela values	Yes	No
Metadata manufacturer and catalog number match the SKU	Partly	Yes when naming is inconsistent or multiple variants share a family
Photometric values conflict with datasheet values	Partly	Yes, because test conditions, product generations, and regional variants may differ
File is from an obsolete generation	Partly, using revision dates and MPN patterns	Yes when supplier naming is ambiguous
Beam shape looks plausible for the marketed product	No	Yes, especially for specialty optics or custom luminaires

Claro’s role is strongest around the product-data layer: matching each technical asset to the correct canonical record, extracting and validating associated attributes from supplier files and PDFs, surfacing conflicts with source evidence, routing exceptions, and writing approved records back into the systems you already use. If you need photometric engineering certification, keep that specialist review in the workflow rather than replacing it with a catalog rule.

Authoritative references for this workflow

This playbook treats format claims cautiously. The IES format is governed by ANSI/IES LM-63, the IES standard file format for electronic transfer of photometric data. EULUMDAT/LDT is a line-oriented photometric exchange format widely used in European lighting workflows. Because format standards define file structure rather than product identity, the catalog workflow still needs product matching, provenance, and review before a parsed value is trusted.

For Claro, that means the same operational sequence used in product enrichment, catalog matching, and product deduplication: identify the product record first, normalize only explicit source values, keep evidence attached, route exceptions, and write back approved fields.

Common failure modes

Right format, wrong product. The file opens cleanly, but it belongs to a sibling SKU with different wattage or optics.
Stale product generation. The filename reuses an old family code after LED package, driver, or lens changes.
Incomplete intensity table. Counts in the header do not match the number of candela values.
Metadata drift. Manufacturer, test lab, catalog number, or issue date does not match the current datasheet.
Unit confusion. Dimensions, luminous-opening fields, or LDT intensity scaling are interpreted with the wrong unit assumptions.
Conversion residue. A converted file carries rounded or remapped values that should be revalidated before publication.

Glossary

IES vs LDT Photometric Files

Understand the two formats before validating or converting lighting assets.

Tool

EULUMDAT / IES Photometric Validator

Check whether a photometric file parses and exposes key values before upload.

Tool

LDT to IES Converter

Convert EULUMDAT files for channels that require IES, then revalidate the output.

Playbook

Extract Specs From PDFs With Traceability

Reconcile photometric assets against datasheets with source links intact.

Playbook

Onboard a New Supplier Range

Apply the same match, validate, review, and write-back pattern to a full supplier launch.

Guide

Fill Missing Attributes With Provenance

Keep every enriched lighting attribute tied to source evidence.

FAQ

What should I check before uploading an IES or LDT file to a PIM?

Confirm that the file parses, the declared angle counts match the candela matrix, C-plane and gamma-angle values are ordered consistently, dimensions and units are present, metadata points to the correct luminaire, and the file can be matched to the intended SKU or manufacturer part number. Treat the parsed values as candidate evidence until they are reconciled with datasheets and approved for write-back.

Can photometric file validation be fully automated?

Structural checks such as parseability, angle counts, numeric candela values, duplicate file hashes, and SKU-to-file naming rules can be automated deterministically. Current-generation checks, visual beam-shape review, obsolete product detection, and conflict resolution against datasheets usually need contextual or human review.

What is the difference between validating an IES file and validating an LDT file?

Both checks ask whether the file describes a complete intensity distribution, but the layouts differ. IES LM-63 uses a keyword/header section followed by angle arrays and candela values. EULUMDAT/LDT is a line-oriented format with its own symmetry, geometry, lamp, and intensity-table conventions. Do not validate one by renaming it as the other.

How do I know whether a photometric file belongs to the right SKU?

Match on manufacturer name, catalog number, MPN, product family, lumen output, wattage, CCT, beam angle, dimensions, and revision date across the photometric file, datasheet, supplier feed, and product record. If those signals conflict, quarantine the asset for review instead of attaching it to the record automatically.

Should I write parsed photometric values directly into the PIM?

Only after normalization, provenance capture, and review of conflicts. Store the raw file, parsed candidate values, source filename or hash, validation result, and reviewer decision so later updates can be compared safely against the previous asset version.

See how Claro supports product enrichment workflows