The Analyze Lab & the Workbench.
Everything the research desk gives you — from a single drag-and-drop forensic analysis to a persistent case file submitted for the permanent archive. This guide walks every panel, every control, and what the numbers actually mean.
The Analyze Lab
Upload a photo or video of an aerial phenomenon and get a full forensic report: a dozen independent pipelines plus a frontier multimodal AI review, in one pass. One free analysis for everyone; unlimited with Research ($5/mo).
Uploading
The report, panel by panel
The report leads with what we think it is — the AI reading, the detections and the motion timeline, with the Evidence Chat right there to interrogate them — then the tools, then two grouped sections: Environmental Analysis (the sky, air traffic, weather and scene around the capture) and Forensics (is the file what it claims to be), before filing.
A frontier multimodal model reviews one frame alongside our pipelines and gives a candidate-by-candidate reading with likelihoods. Advisory — it never changes the pipeline verdicts.
YOLO detections across sampled frames, and a motion-event timeline showing exactly when something moved — those events become one-tap starting points for the object tracker.
The brightest flashing light in frame, measured frame-by-frame: flash period, on-duration, and timing steadiness. Aviation and tower obstruction lights flash at regulated rates (red tower beacons: 20–40/min), so a steady measured period is a strong mundane hint — reported as consistency with a light class, never an identification.
Ask questions about this analysis in plain language — the assistant holds the full report as context, and you can push any Viewing-Lab frame into the conversation. The transcript rides along if you file the sighting.
A classifier trained on our own aircraft datasets names the closest type — or returns Unknown, the headline outcome, with the rejection evidence and the strongest counter-evidence from the other pipelines pulled in beside it. Think you know what it is? The “help identify” form feeds future classifier versions.
Everything demonstrably around the capture, in one place: Skyline & Celestial Layout, air traffic, weather history, mundane matches, scene context, optics, and clouds.
From the capture place & time: planets, bright stars, the Moon, satellite passes, meteor showers, aurora conditions — with altitude/azimuth you can cite. If the media lacks GPS or a timestamp, one shared Resolve place & time form re-runs the whole report with your answers.
Aircraft near the capture point with bearing, distance, altitude, speed — the fastest mundane explanation there is, or a meaningful absence.
Archived conditions at the capture hour (cloud cover, visibility, precipitation) plus a cloud-genus classifier on outdoor shots — lenticular clouds explain a lot of saucers.
A dedicated pass for birds, kites, balloons, drones; indoor/outdoor + place type (an indoor “sky” is a red flag, as is a TV or phone screen in frame); and a lens-flare / bokeh geometry check for artifacts that mimic craft.
Is the file what it claims to be. Provenance forensics reads the container structure, capture keys, encoder fingerprints and timeline against what an iPhone or Android camera actually writes versus what CapCut, ffmpeg and NLEs write — verdict: camera-original / exported / stitched with every piece of evidence, one combined authenticity score, and the phone's own data (Takeout JSON, .AAE, XMP, GPS logs) cross-checked against the file. File-only: consistency with a device family, not proof of one specific phone.
The frame & audio pass folded into Forensics (shown alone when Forensics is off): metadata & editing-software tags, duplicate-frame runs, abrupt scene cuts, audio splice jumps — heuristic provenance, not deepfake detection.
The parsed track (points, duration, distance, speed, altitude), the device's interpolated position at the capture moment, and a green/amber verdict on whether the track agrees with the media's own GPS. Disagreement is a finding.
Forensics — raw capture, export, or stitched?
In plain terms: every phone camera leaves a very specific set of fingerprints inside the file it records — not in the picture, but in how the file is built. Editing apps, converters and social platforms build files differently and leave their own fingerprints. Forensics reads those fingerprints and tells you whether a file looks like it came straight out of a phone's camera in one take, was exported or converted afterwards, or was assembled from several clips — and shows you every clue it used, so you can disagree.
Technically: a structural analysis of the container (MP4/MOV atoms), the codec bitstream, the capture metadata and the sample timeline, compared against reference profiles of what iPhone / Android camera apps write versus what libavformat-based tools (ffmpeg, CapCut, HandBrake, web converters) and NLEs write. Each observation is an evidence item with a direction (camera / edited / stitched) and a weight; the verdict is the weighted balance. No pixels are judged — this is complementary to the frame/audio pass and to the AI review.
Turn it on with Add Forensics before a run, or Run Forensics from a finished report. Attaching phone data turns it on automatically.
| What you see | In plain terms | Technically |
|---|---|---|
| Combined score | One 0–100 number for “does this file behave like raw, untouched footage?” High = consistent with a raw capture; low = clear signs of handling after capture. | 0.6 × provenance score + 0.4 × the frame/audio authenticity stage (duplicate-frame runs, abrupt histogram cuts, audio RMS jumps). Provenance score = 60 + Σcamera − Σedited − Σstitched weights, clamped. |
| Verdict | Camera-original: looks like it came straight off the phone. Exported: someone ran it through an app or converter (not necessarily faked — messaging apps do this). Stitched: cut together or edited on a timeline. Indeterminate: not enough structure left to say. | Class from the weight balance: stitched ≥ 20 → stitched; edited ≥ 18 and > camera → exported; camera ≥ 25 with ≤ 10 against → camera-original; with a high / medium / low confidence from the margin. |
| Evidence list | Every clue, green for “camera”, amber for “edited”, red for “stitched”, with how much it counted. Read these, not just the number. | Each item: id, direction, weight (4–30), finding, raw detail (in the JSON export). Neutral observations are listed separately and carry no weight. |
| Device profile | The file says “I am an iPhone 13 on iOS 16.2” — so we check whether it still carries everything an iPhone actually writes. Missing pieces mean it was rebuilt by something else on the way to you. | Per-family expectations. Apple: qt brand, Core Media handlers, com.apple.quicktime.* capture keys (make/model/software/creationdate/ISO6709/lens), ≥1 mebx timed-metadata track, iOS-version Software. Android: ISO brand, MediaMuxer VideoHandle/SoundHandle handlers, com.android.version, ©xyz location, Samsung sefd. |
| Container & encoder | How the file is packaged and which encoder wrote the video. A phone's hardware encoder is silent; ffmpeg, CapCut, HandBrake and friends sign their work. | Pure-Python atom walk: ftyp brand + compatible brands, top-level atom order, moov placement (faststart = re-muxed), track handler names, sample-entry vendor/compressor, udta/keys. ffprobe for codec/profile/level/pix_fmt/vendor_id/encoder tags. A 2 MB scan of mdat for x264/x265/Lavc/HandBrake SEI strings. |
| Timeline | Cameras keep a very steady rhythm (a keyframe every second, audio and video the same length). Editors start a fresh keyframe at every cut and often leave audio and video slightly different lengths. | stts sample-duration runs (distinct deltas, regularity), stss keyframe cadence (mean, min/max, coefficient of variation), elst edit lists, A/V track duration gap, and splice candidates — abrupt scene cuts from the frame pass that coincide (±0.25 s) with a keyframe. |
| Photos | The same idea for stills: does it carry the camera's own notes (exposure, lens, maker data), or was it saved by an editor, screenshotted, or stripped? | Make/Model, manufacturer MakerNotes count, exposure tags (ExposureTime/FNumber/ISO…), iOS-version Software, XMP history / Photoshop IRB, JFIF-without-EXIF, PNG, HEIC-from-Apple, UserComment “Screenshot”. |
| Phone-side data | If you attach what the phone itself recorded, we check it against the file: was the phone where the file says, at that time? Does the photo library agree about when and on what device it was taken? Is the uploaded file byte-for-byte the copy in your export, or was it edited in Photos? | Bundle (zip or files) expanded and classified. GPS/sensor tracks → telemetry correlation (position at capture vs file GPS, ≤150 m; capture inside the track window). Google Takeout JSON → photoTakenTime / geoData / deviceType vs file. Apple .AAE → adjustment record (edited in Photos). XMP → edit history. Same-named media in the bundle → SHA-256 compared with the upload. |
| Frame & audio pass | The older authenticity check, folded in: frozen frames, hard cuts, audio jumps, and editing-software names in the metadata. | ~5 fps grayscale MSE duplicate runs, Bhattacharyya histogram distance ≥ 0.5 for cuts, librosa RMS ratio ≥ 3× for audio jumps, editor-name match (CapCut, Lavf/Lavc, x264, Premiere, Resolve, TikTok, Instagram…; iOS-version strings exempt). |
- Whether the file is consistent with an unmodified capture from the device family it claims (iPhone-class, Android-class).
- Whether it was re-encoded, converted or re-muxed after capture — and often by what.
- Whether it shows the marks of timeline editing or multi-clip assembly, and roughly where the splices are.
- With phone data: whether the device's own records agree with the file about where, when and on what it was recorded, and whether your upload is the library original.
- Prove a file came from one specific phone. That needs the device (sensor-noise references or its Photos database) — the domain of device-forensics tools, not a file upload.
- Tell “exported” from “faked”: WhatsApp, iMessage-compress, AirDrop-convert and Photos all re-export without changing what was filmed.
- Catch a lossless re-wrap that preserved every marker, or a forger who rebuilt every marker by hand.
- Judge the picture itself — that is the frame/audio pass, the mundane-object checks and the AI review.
The Viewing Lab & enhanced renders
- Filters — frame differencing, background modeling, gain/gamma, with a wipe to compare against the original.
- Zoom & pan — get close to small objects; the report's motion events are marked on the seek bar so you jump straight to the action.
- Ask about this frame — sends the exact frame you're looking at into Evidence Chat.
Enhanced renders are the heavy, server-side versions — frame-accurate mp4s you can replay and download: true background subtraction (moving things in color on black), temporal median (everything static vanishes; transients glow), and a track & stabilize crop that follows the main moving object. Roughly a minute of render per minute of footage; results attach to the case when you file.
AI clarity is the fourth render, for footage too grainy or low-res to read: a temporal denoise pass followed by a neural 4× super-resolution network, either on the full frame (10 s window, pick the start time) or following the object (15 s window, tracked from the box you drew in Speed & direction). A grain-removal slider blends between texture-preserving and heavy-noise weights, and a night boost (auto on dark clips) averages each frame with its aligned neighbours — a software long exposure that recovers real signal from dark footage — then lifts the exposure. It runs a network per frame on CPU, so expect several minutes; a progress bar tracks it. It is an interpretation, not evidence — the network reconstructs plausible detail — and every render is labeled as such.
Speed & direction
AI interpretation — Clarity & Reconstruction
- Clarify frame — for grainy or compressed media, a Pro-tier image model renders a sharpened, denoised interpretation of the frame you pick. You get two independent renders beside the original on purpose: where the two disagree, the model is guessing.
- Reconstruct as video — generates a short clip of the sighting, seeded by the clarified frame and driven by the measured motion from your kinematics track. Useful for showing others what the witness experienced.
Filing a sighting
When the analysis is yours — you shot it, you were there — File it → sends the complete evidence bundle into the review queue: your narrative, when & where, the full forensic report, the Evidence-Chat transcript, the media itself, your telemetry file, any enhanced renders, the kinematics track, and up to 8 additional photos/videos from the same incident (files you multi-selected at upload are already staged).
You get a submission number immediately. Review is human-gated: nothing enters the master archive without a person approving it. Cleared cases become permanent records with their own case number — on the public map's Community cases layer, in the database, in AI search, and citable. Your contact email is never published; pending cases are never shown publicly.
The Workbench
Your persistent research workspace. Where Analyze is one file, one report, one sitting — the Workbench is a case file you build over time: multiple pieces of footage, your own field notes, and a submission path to the review desk. Research subscription required; you get 5 GB of evidence storage.
Building a case
A reviewer routes approved material where it earns a place: the case database, the public map, the story/film pipeline, or the classifier training set — and can also return a case with notes. Incorporation into the master archive is always human-approved, never automatic.
Which tool, when
| Analyze | Workbench | |
|---|---|---|
| Shape | One sitting: upload → report → optionally file | Persistent case files you build over time |
| Media per case | 1 analyzed + up to 8 attached at filing | Unlimited within your 5 GB, each analyzable |
| Reports persist? | For the session (and forever if you file) | Saved on every media row, always |
| Best for | "What is this clip?" — fast forensic answers, witnesses filing a sighting | Ongoing investigations, multi-angle incidents, researchers curating a library |
| Path to the archive | File this sighting → review queue | Submit case → review desk → routed to database / map / story / training |
| Access | 1 free analysis, then Research | Research |
Limits & formats
≤ 500 MB per file · images PNG / JPG / WebP / BMP / TIFF · video MP4 / MOV / WebM / MKV / M4V / AVI. Long videos are fine — big files queue and the progress bar keeps reporting.
One file, several, or a zip (≤ 400 MB) · tracks: GPX, DJI SRT, CSV/TSV sensor logs (columns matched by name), JSON / GeoJSON, KML · records: Google Takeout JSON, Apple .AAE, XMP, plist · media copies inside a bundle are byte-compared to the upload. If your device's format doesn't parse, send us a sample.
Every report exports as Web (HTML), PDF, Markdown, or raw JSON — full report or any single section.
Free: one full analysis, the sample, public archive. Research ($5/mo): unlimited analyses, Workbench + 5 GB, enhanced renders, object tracking, AI interpretation, semantic search, proximity atlas — and it keeps the public archive free.
- The authenticity and Forensics scores are structural provenance, not deepfake detection. Forensics shows consistency with a device family, never proof that one particular phone recorded the file; “exported” is not “faked”.
- “Unknown” means not a confident match to anything we know — read it alongside the mundane checks, the sky, and the traffic before it means more.
- Every speed figure is conditional on a distance anchor; the UI never prints an unconditional number.
- AI Clarity/Reconstruction outputs and the AI clarity render are generative interpretations — never evidence.
- Nothing enters the master archive without human review.