The IPRO LFP file format

Image load file · line-oriented command grammar · the IPRO lineage's answer to the OPT

What it is

An LFP is the image load file of the IPRO family. It carries the same information as an Opticon OPT — page keys, volume, paths, document boundaries — but instead of flat positional columns, each line begins with a two-letter command. That grammar lets one file carry images, natives, tags and text side by side, which is why vendor exports often arrive as a mixed LFP rather than separate files.

The commands you will actually meet

Command	Meaning
IM	Image/page reference — the record type that defines documents and pages
OF	Original/native file reference
IS, AN, FT	Page-level tags, annotations/redactions, full-text highlights
OI, OT	OCR text inline / path to a text file on disk
FD, IO	Field data loads (document-level metadata, info-only fields)
VN	Volume location

Anatomy of an IM record

IM,ABC0000001,D,1,@VOL001;IMAGES\001;ABC0000001.tif;1
IM,ABC0000002,,,@VOL001;IMAGES\001;ABC0000002.tif;1

Position	Field	Notes
1	Record type	IM for images
2	Image key	The page's Bates number; matches the image filename
3	Boundary flag	D marks the first page of a document — the analogue of the OPT's Y; empty on continuation pages
4	Box / pageset	Optional numeric grouping used by some shops; often absent
5	@ token	@volume;directory;filename[;extra] — semicolon-packed location; a trailing numeric segment is a file type/multi-page marker

The @ token is where paths hide. Splitting it wrong — treating the directory's own semicolons or the trailing file-type segment as part of the filename — produces an OPT whose paths point at files that do not exist. Conversely OPT→LFP means splitting a path into directory and filename and repacking: same image, different grammar.

Multi-page images

Unlike the one-file-per-page OPT, an LFP can point several page keys at one multi-page TIFF: consecutive IM records sharing a filename with different keys or offsets. The byte offset and page-type segments in the @ token are how the viewer finds the right sub-image. Converting such an LFP to OPT maps each record to its own row keyed by path — the OPT convention of one file per page — which is why lossless round trips hold for keys, volumes, paths and grouping, the fields both formats share.

Mixed files

Because IM shares the file with OF/IS/AN/…, a converter must partition: image records become OPT rows; everything else is set aside. Silently flattening an OF record into an image row gives you an OPT whose "page" is a Word file. A sane export reports what was skipped and why, so a combined imagebase/nativebase LFP still yields a valid image OPT.

Practical notes

• Encoding is typically ASCII or UTF-8; honor BOMs and verify before assuming.
• Line endings are CRLF; blank lines are not records.
• Boundary flags: treat D as a document break; blank means continuation — the same discipline as the OPT's Y, with the same two silent failure modes (dropped flag merges documents, stray flag splits one).

The converter reads IM records, keeps the rest aside with a count, and writes OPT/LFP/DAT/CSV from the parsed page model; the Bates checker audits the key sequence exactly as it does for OPT.