Testing on EMIT scene (Jan 29, 2025) without Analytical Line:

4C case (Red= Using skyview; Purple=set to 1). Sky view~0.86 for this example at this pixel:

1C case (Red= Using skyview; Purple=set to 1). Sky view~0.86 for this example at this pixel:

Tests compared to C based topo-calc code (n_angles=72, n_cores=14)

comparison on same personal laptop against topo-calc code.

• EMIT-like (dem dimension: 3012x2640 pix, 60 m spatial resolution)
  • Times: both roughly 55-60 seconds on 14 cores..
  • Difference: RMSD: 0.0014 (n~7.95 million pixels)

Differences in skyview (topo-calc vs. skyview.py) were mostly on the edges, which is fine as this should generally be applied with a buffered DEM around the image in order for the horizons to be accurate. Measurable differences on the edges (~0.01) occurred mostly within 1km of the borders. This is mostly due I think to the greedy alg approach i applied in skyview.py. But also there is missing information bc the half of the hemisphere is missing so it is hard to tell for sure what is happening on the edge pixels. But TLDR; just use a DEM with a sufficient buffer around target image (~1km).

For reference, here is the extent of the EMIT shown in red:

Per conversation with Niklas, I am also bringing in logic to ensure cos_i respects bounds 0-1 within check_coszen_and_cos_i() . Mathematically cos ranges -1 to 1. But from a radiative transfer standpoint, it must be capped from 0-1.

EMIT scene (Jan 29, 2025) with Analytical Line:

1C case (Red= Using skyview; Purple=set to 1). Sky view~0.86 for this example at this pixel:

Summary ALAlg incorporation:

• skyview gets extracted similar to rdn.. The resulting "subs" file gets passed to initial solve.
• Then, the atmosphere is interpolated
• Finally, full sky view map provided directly to new Geom class in closing analytical solution.

Note: There are odd peaks in the spectra around H2O features that exist for all my runs here.. I think this is likely a user error and unrelated to any of the skyview codes contained within this PR.

@brentwilder I ran a very quick test (single pixel inversion with the 1c model, sky view factor assumed to be 1) and couldn't observe any difference in retrieved reflectance between dev and your sky-view-factor branches. Will run a more comprehensive test soon, but it points to an issue with your LUT, rather than with the code updates. That is, your above assumption "user error" is probably right.

@pgbrodrick on the conversation of computing skyview from LOC files:

I computed a test case for Copernicus DSM if we only had extent of EMIT image (A), and compared this with the larger, buffered one from above (B).

If you zoom in, you can see case (A) here often has positive bias (blue) along the edges. This is due to horizon calcs not having this information on the edges. I used same logic from topo-calc on the edges, where this point is its own horizon when difference in indices are zero (https://github.com/USDA-ARS-NWRC/topocalc/blob/main/topocalc/core_c/hor1d.c#L225) . But it gets more difficult than just the pure edge case, as you can see error may leak in further into the image depending on terrain.

Tested with a brand new image today and was able to find no effect on the h2o absorption features (emit20250327t212148). Still not sure what my error was before on the previous image. But the Skyview additions seem to be working as expected.

Small snippet on Lake Mary in Sierras:

Thanks for double-checking, @brentwilder! Great that it works on your end now too. From my perspective, we’re good to go. @pgbrodrick Feel free to merge this in.