Skip to content

Fast Dimension Lines

Status: Implemented fast Detection path; type-specific local arc search remains later work

Authority: Current contract (2026-08-12)

Last reviewed: 2026-08-14

Question

How does the Fast Dimension Lines path find possible dimensions?

Short answer

The path builds one page-wide straight-line centreline pass. OCR does not limit that first line search. Later stages use OCR and arrowheads to label lines and form clue bundles. The result is a possible-dimension list, not confirmed dimensions.

Input mask and page scope

The path starts from the allowed Detection page raster. It builds an ink mask from dark pixels on that page. Accepted table, title-block, and accepted-note regions are removed from the mask. Cached OCR boxes are also removed as text gaps. The first Hough pass then scans all remaining compatible page lines. Selected-input scope does not limit that page pass.

Skeletonization and directional segments

Skeletonization reduces remaining ink to a one-pixel centreline image. Directional segment extraction then runs probabilistic Hough on that centreline. The pass finds short straight segments across the page. A merge step joins collinear aligned fragments into longer carriers. A configured Hough gap can bridge holes left by OCR boxes. That gap recovers interrupted carriers without treating text as geometry.

When OCR and arrowheads enter

OCR and arrowhead caches must exist before preview. Cold preparation populates missing OCR and arrowhead caches. Warm reuse reads those caches again without a full rerun. OCR boxes carve gaps in the ink mask before line extraction. OCR is not rerun inside the line pass. After line merge, nearby OCR and arrow tips label carriers mechanically. Those labels do not assign view ownership or dimension type.

Selected-input scoping

The page-wide line pass is cached for the page and input set. Switching the selected input does not rerun that page pass. Preview then filters lines, OCR, and arrows into the selected input bbox. Exclusion interiors stay out of the local clue list.

Accepted exclusions

Accepted table and title-block truth from table review can exclude regions. Accepted notes from Detected Sheet review can also exclude regions. Exclusions remove ink before line extraction. Exclusions are not the same as rejecting a possible dimension later.

Local clue grouping

Local grouping starts after the page pass and the selected-input filter.

  1. Dimension-like OCR seeds nearby carriers.
  2. Opposing arrow tips can pair on a shared carrier.
  3. Orphan opposing arrow pairs can still form partial bundles.
  4. Perpendicular lines near carrier ends become witness-line clues.
  5. A witness far end can touch another nearby line as a feature-contact clue.
  6. Each bundle is marked complete, ambiguous, or partial.

A feature contact is a probable geometry touch only. It is not measured-feature ownership.

Exact output

The path outputs possible-dimension clue bundles. Each bundle groups text, carrier, arrow, witness, and contact clues when present. The Detection UI must keep saying 0 confirmed dimensions. Confirmed membership, type, units, view ownership, and feature ownership belong to Understand.

Cold preparation versus warm reuse

Cold preparation populates OCR and arrowhead caches for the selected input. That prerequisite action does not run the generic detected-sheet assembler. Warm reuse returns existing OCR, arrowhead, and page-line caches when fingerprints match. Measure cold preparation, warm reuse, line extraction, arrow search, association, and full runtime separately. Do not claim the redesign is faster until those stages are measured.

Implemented versus planned

Implemented now:

  • page-wide centreline Hough
  • OCR-gap recovery
  • accepted table, title-block, and note exclusions
  • OCR and arrow labelling
  • selected-input filtering
  • opposing-arrow pairing
  • witness intersections
  • probable geometry contacts
  • possible-dimension list with complete, ambiguous, and partial status
  • exact cache reuse and per-stage runtime fields

Planned primary route later:

  • trustworthy native PDF paths, otherwise a clean vector-derived page mask
  • convert traced bands to centrelines before the page-wide line pass
  • keep local OCR-seeded and arrow-seeded search inside a view
  • keep interrupted carrier recovery, arrow ends, witnesses, and ray-cast contacts
  • add local arc or circle search only for diameter, radius, and angle cases

Do not treat the planned vector-derived primary path as the current default.

Why this replaced the first approach

The original dimension assembly path became complex and slow. It mixed mechanical association with early meaning. Fast Dimension Lines keeps Detection mechanical. It preserves incomplete evidence instead of hiding it.

Open Questions

  • Which cold and warm stage split becomes the accepted speed benchmark for this path?

Sources