Field guide — one line per page

The OPT load file format — Opticon image cross-reference

An OPT describes images, one line per page rather than per document. A single missing character in it will silently merge two documents, and the volume will import without complaint.

What it is

An OPT is the image cross-reference: seven comma-separated fields per line, one line per page rather than per document. It is commonly called an Opticon file, after the image viewer whose convention it follows. In order, the fields are the image key (the Bates number of that page), the volume label, the path to that page's image file, the document-break flag, two fields that are reserved and in practice always empty, and the page count.

The document-break flag is the load-bearing one. It holds Y on the first page of each document and is empty on every continuation page; nothing else in the file says where one document ends and the next begins. The page count appears on the break line and describes the whole document. So a three-page document is three lines with Y on the first only:

ACME0000001,VOL001,IMAGES\001\ACME0000001.tif,Y,,,3
ACME0000002,VOL001,IMAGES\001\ACME0000002.tif,,,,
ACME0000003,VOL001,IMAGES\001\ACME0000003.tif,,,,

A dropped Y silently merges two documents; a stray one silently splits one in half. Neither stops the volume importing. The validator flags both shapes it can see from the file alone: a continuation row that appears before any document break at all, and a declared page count that disagrees with the number of rows that actually follow.

The two failure modes that import cleanly

Both of the OPT's characteristic errors are silent. A dropped Y merges two documents into one; a stray Y splits one document in half. Neither stops the volume importing, and neither produces an error anywhere — the platform simply believes the document boundaries it was given. You find out at review, when a document has the wrong number of pages, or at production, when the wrong pages carry a confidentiality endorsement.

The checker flags both shapes that are visible from the file alone: a continuation row that appears before any document break at all, and a declared page count that disagrees with the number of rows that actually follow it. Per-row structure is checked too — fewer than seven fields, an empty image key or path, an unrecognized boundary flag, and a non-numeric offset where a number is required.

What only shows up against the DAT

The most useful OPT findings are not in the OPT. Load the DAT and the OPT together and they are checked against each other, which catches the class of error that no single file reveals.

Document counts from each file are put side by side: DAT rows against OPT document breaks. When they disagree, at least one file is describing a different set of documents than the other — often a volume that was regenerated after one file had already been written. Membership is then checked in both directions: DAT documents with no matching document break in the OPT, and OPT documents with no matching row in the DAT.

Finally, every OPT continuation page is tested against the set of begin-to-end ranges declared in the DAT. A page whose number falls outside every declared range is either an image that does not belong in the volume, or a DAT range that is wrong. Both are worth knowing before the volume goes out, and neither is visible from either file on its own.

Encoding

An OPT is checked for encoding like every other file: byte-order marks honored, UTF-8 verified rather than assumed, and anything that is not valid UTF-8 read as Windows-1252 and labeled. Paths are the part that matters here — a custodian folder with an accented character in its name is exactly where a mis-decoded path silently stops resolving to a real file.