Help
Frequently asked questions¶
Short answers to the questions that come up most often when running SpectralBridge, reading its outputs, or deciding which products to trust.
Outputs are the API
The merged parquet and QA artefacts are the main interface for downstream analysis.
Reruns are expected
The NEON pipeline is designed to validate and reuse good outputs instead of recomputing everything.
QA is part of the contract
PNG, JSON, and optional PDF summaries exist so reflectance changes remain inspectable after processing.
Concepts
What problem is SpectralBridge solving?¶
Cross-sensor comparability
SpectralBridge helps make reflectance from NEON, drones, and target sensor frames more comparable by correcting geometry-driven artifacts and standardizing downstream outputs.
Analysis-ready structure
The workflow is built to produce stable ENVI, parquet, merged parquet, and QA products that can be reused across notebooks, scripts, and batch runs.
Inputs
What inputs do I need?¶
NEON pipeline
The canonical NEON path starts from NEON .h5 directional reflectance files and can download them for you.
Drone pipeline
The drone workflow accepts either existing HDF5 inputs or supported TIFF-backed packages that are bridged into the working HDF5 contract before QA and polygon extraction continue.
Common questions
Why do some values look surprising?¶
Why does NEON use scaled reflectance?
NEON HDF5 products store scaled values for compactness. SpectralBridge converts them back to floating-point reflectance during export.
Why do some pixels exceed 1.0 reflectance?
Topographic or BRDF correction can amplify noisy regions or difficult geometry. QA outputs flag these conditions so they can be reviewed rather than silently hidden.
Why do some bands look noisy?
Low-SNR wavelength regions, edge effects, clouds, shadow, or unstable correction support can all increase visible noise in specific bands.
Do I need both topo and BRDF correction?
Usually yes for the NEON workflow. They address different sources of reflectance variability and are treated as a coupled correction stage in the main pipeline.
Performance
Why can the pipeline take a long time?¶
NEON and drone products are large, and several stages are intentionally chunked and restart-safe instead of optimized around whole-scene shortcuts.
- ENVI export and correction touch large raster volumes
- sensor translation and parquet extraction are designed to preserve provenance and chunking
- merge and QA stages validate outputs rather than assuming they are always good
If you need a lighter first run, reduce worker counts and prefer the thread engine while validating a workflow.
Outputs
Can I analyze results without reopening ENVI cubes?¶
Yes. In most cases, the merged parquet is the intended downstream analysis surface.
Use merged parquet
For NEON runs, start with <flight_id>_merged_pixel_extraction.parquet. It is the authoritative tabular product for analysis.
Use polygon parquet
For polygon workflows, use the polygon-specific extracted and merged parquets instead of re-reading the rasters.
Support