Hyperspectral systems / open source

Open Ore Mapper

Local-first surface mineral maps from hyperspectral cubes — classical matching, QA layers, and a public scoreboard.

Open Ore Mapper turns hyperspectral cubes into surface mineral candidate maps you can inspect, score, and ship from a laptop. The stack is classical spectral matching first: continuum-aware feature fits, open-set gates for weak matches, multi-layer QA, and a fixed public benchmark so progress is measurable.

The public home for the project is github.com/K-naman-T/open-ore-mapper.

The job to be done

Exploration and spectral consulting teams already sit on AVIRIS-, HyMap-, and EMIT-class cubes. They need a path that:

  1. Loads a real cube and a real mineral library
  2. Runs a documented classical pipeline without a training label set
  3. Returns class maps, confidence, and continuum QA (scale, RMS, unknown, matched-filter style scores)
  4. When a published expert map exists for the scene, scores map-to-map agreement so you can see where the stack holds and where it fails

That path is the product spine. Supervised models live as optional research when someone has painted ROIs; the default demo stays unlabeled-scene classical matching.

Cube to map

Cube + wavelengths + independent library CSV
  → QC and band filter
  → classical feature-fit fuse (sff_ls product preset)
  → class map + confidence + QA layers
  → optional score vs public expert map (panel + OA / κ)

sff_ls is the product default: continuum least-squares feature fit fused with classical soft scores and open-set reject. Presets (for example cuprite_product) lock thresholds so CLI, API, and validation scripts share the same behavior.

Libraries are first-class. The Cuprite product path uses an independent USGS spectral pack built into the repo — spectra drawn from public library material, not pure pixels lifted from the reference map used for scoring. That separation keeps the scoreboard honest: reference maps judge agreement; they do not supply the endmembers.

Cuprite as the public scoreboard

Cuprite, Nevada is the dumb-first-user run. AVIRIS scene plus a Tetracorder-class reference mineral map for comparison. The pipeline writes:

Cuprite validation panel: true-color, overlay, reference, solid map, agreement

AVIRIS true-color underlay

Class mask on true-color

Candidate mineral map from the product fuse

On the independent USGS product path, full-scene map-to-map overall agreement vs the reference sits around 0.53 (κ around 0.46, reject around 0.10). Multi-seed Track A with a fixed library lands near 0.56±0.03. Those numbers are agreement with a published interpretation under a defined legend — the scoreboard we use to improve the stack.

Reproduce from a clone:

pip install -e '.[dev,api]'
python scripts/build_usgs_cuprite_library.py
OPEN_ORE_PRESET=cuprite_product OPEN_ORE_LIBRARY_MODE=independent \
  python scripts/run_cuprite_real_validation.py

What ships in the tree

| Surface | Role | |---------|------| | CLI open-ore-mapper predict | Cube → maps with --product-preset | | FastAPI | Upload, predict, QC with the same open-set thresholds | | QA export | Multi-layer rasters for continuum and confidence review | | Track A multi-seed | Spatial hold-outs, fixed independent library | | Path B | Scenes without a reference map: match strength and coverage only | | React + MapLibre UI | Globe shell and scorecard wired to the same agreement language | | Optional ML extras | RF / boosting / 1D-CNN under .[ml] for labeled experiments |

Docker Compose and a Makefile cover the backend path for local demos.

Where we are taking it

The build stays on the classical unlabeled path and the services around it:

The longer product bet is local candidate mapping that operators and consultants can run, score, and put next to their own field notes — with the public Cuprite scoreboard as the ongoing integrity check.

Links

Back to portfolioBlogDiscuss similar work