Vis-O-Matic image analysis tools

SunSync 360

Solar geometry and true-north registration for 360° imagery

Load 360° imagery

Equirectangular (2:1) frames are the primary case. Partial/cropped equirectangular strips and fisheye frames are supported if you declare their geometry below.

Drop images or a folder here
or click to choose  ·  JPEG / PNG / WebP  ·  nothing is uploaded

Frame geometry

Detected from GPano XMP and aspect ratio where possible. Override if your frames are cropped or non-standard.

degrees, +90 = zenith
−90 = nadir
degrees covered left→right
Import from Mapillary (for imagery with no EXIF)

Mapillary stores the heading, position and capture time it computed for every uploaded image. If your local copies have lost their metadata — cropped exports, screenshots, re-saved PNGs — pull the originals back instead of guessing.

You need a free access token from mapillary.com → Dashboard → Developers → register an application. The token stays in this page and is sent only to Mapillary's own API.

Mapillary's computed_compass_angle comes from its own structure-from-motion pass. It is usually good but it is not ground truth — SunSync will still solve from the sun where it can and will report both, so you can see whether they agree.

Time and place

The sun's computed position is only as good as the clock and the timezone. Neither is recorded reliably by most 360 cameras.

seconds added to EXIF time
degrees — frames excluded from solving
A degeneracy worth knowing about. A constant clock error and a constant heading error both shift the sun's apparent azimuth, and nothing in a single high-sun frame can tell them apart. Low-sun frames break the tie, because near sunrise and sunset the elevation changes fast enough that a clock error shows up in the elevation residual. If you have an evening or morning set from the same camera, register that one first and use its clock correction here.

Solve camera heading

Yaw offset is the angle you must add to a frame's horizontal position to get a true compass bearing.

± degrees around predicted elevation
degrees — removes the sky gradient
degrees of elevation error
top elevation
bottom elevation
Frames
computed sun position detected sun in frame horizon scattering-angle contours learned sun colour

Scattering-angle analysis

Once the heading is known, every pixel has an angular distance from the sun. That is the quantity scattering theory makes predictions about, and unlike a frame position it is comparable across dates, sites and cameras.

degrees
degrees of the sun
degrees
degrees, almucantar/principal

Solar-window matching

Two captures are only physically comparable if the sun was in a similar place. This finds the frames and the datasets where that is true.

degrees
degrees

Geometry sidecar

One row per frame, joinable on filename stem — the key the Batch Image Analyzer already uses for its compare tool. Nothing is resampled and the imagery is untouched.

Rotated image re-export

Writes new files with the frame rolled so that column 0 is true north.

Prefer the sidecar where you can. Re-exporting resamples every pixel and moves the stitch seam to a new part of the sky — a real colour-fidelity cost you would have to declare. With integer-pixel snapping on, a yaw roll is an exact lossless shift (0.125° steps on a 2880-wide frame), which removes almost all of that objection. Only turn snapping off if you need sub-pixel alignment more than you need untouched pixels.

Using the sidecar in the Batch Image Analyzer

The Analyzer needs three small additions to consume this file. They are described in the design memo; in short:

  1. Load geometry sidecar — join on filename stem and report the match rate, exactly the way runCompare() already reports onlyA/onlyB.
  2. Azimuth offset — one additive term in the x→bearing mapping, applied in the column-profile, grid and Moran's-I sampling paths. The existing 360° wrap logic already handles the rest.
  3. Scattering-angle spatial mode — alongside the current Cartesian and polar modes, with Θ annuli as the aggregation unit.

Until those land, the CSV is still directly useful: it tells you which frames share a heading, which are gated, and which datasets are solar-comparable.

How SunSync 360 works

An equirectangular 360° frame has a horizontal axis that looks like a compass but usually isn't one: almost no consumer 360 camera writes its heading into the file. SunSync 360 recovers that heading by finding the sun in the frame and comparing it with where the sun astronomically had to be, given the GPS position and timestamp already in the EXIF.

The check that makes it trustworthy: solar elevation does not depend on heading at all. So the gap between the sun's measured elevation in the frame and its computed elevation is a free, independent confidence score for every frame. Small residual → the detection found the sun. Large residual → it found a bright cloud, and the frame is gated out rather than silently mis-registered.

Second opinion: where the sun can't be trusted or isn't visible, the tool cross-correlates the static terrain band below the horizon between frames. That gives a relative heading, which one sun-anchored frame converts to absolute.

  1. Load — drop in a folder of 360° images. EXIF, GPS and projection are read automatically; anything missing can be typed in.
  2. Geometry — check the timezone and clock, review computed sun positions and air mass.
  3. Register — run detection, inspect the yaw-versus-time trace, accept a consensus or keep per-frame headings.
  4. Viewer — see the sun markers, true-north ticks and scattering-angle contours drawn on the imagery.
  5. Analyse — scattering-angle annuli, phase curves, and solar-window matching across datasets.
  6. Export — a geometry sidecar CSV for the Batch Image Analyzer, and optionally rotated images.

Nothing leaves your machine. Files are read in the browser; no upload, no server.