Reference
JSON schemas and metadata sidecars¶
SpectralBridge writes structured JSON files next to major processing artefacts so correction choices, wavelengths, QA summaries, and provenance remain inspectable after the raster work is done.
Reproducibility
Metadata sidecars record how a product was generated instead of forcing users to infer processing history from filenames alone.
Validation
QA JSON files carry machine-readable checks that complement the PNG and PDF artefacts.
Stage transparency
Each major stage can leave a structured record of what was assumed, fitted, or applied.
Export metadata
ENVI export sidecars¶
The export stage records metadata needed to interpret the ENVI cube and the downstream parquet products derived from it.
- wavelength arrays and band names
- reflectance scaling details
- mask and CRS context
- basic provenance for the exported raster
Correction metadata
Topographic and BRDF sidecars¶
Topographic metadata
Topographic sidecars summarize the slope, aspect, solar geometry, and correction parameters used for the terrain-sensitive part of the workflow.
BRDF metadata
BRDF sidecars preserve coefficient summaries, fit diagnostics, kernel settings, and any NDVI-binning context used while building the correction model.
The streamlined BRDF model JSON remains the most direct structured record of the fitted coefficient surfaces and kernel configuration for a flight line.
Harmonization metadata
Sensor translation sidecars¶
Convolution and harmonization sidecars document how corrected hyperspectral reflectance was translated into target sensor products.
- sensor response assumptions
- wavelength alignment checks
- brightness adjustment coefficients when used
- bandpass integration context and summary metrics
QA metadata
QA JSON sidecars¶
Every QA JSON file acts as the machine-readable counterpart to the PNG and optional PDF reports.
Scene-level summaries
Reflectance, masking, correction, geometry, and harmonization summaries live here for dashboards and automated review.
Provenance and workflow context
QA payloads also carry package version, created time, and other details that make a run auditable later.
How to use them
Why these files matter downstream¶
These JSON files are useful when you need to:
- reproduce a published processing run
- compare runs across software versions
- debug a suspicious corrected or harmonized output
- drive dashboards or automated quality gates from structured metadata
The raster and parquet outputs are still the main analysis products, but the JSON sidecars are the best explanation of how those products were created.
Where to go next