#### NOTE
This is a **Hugging Face dataset**. For large datasets, ensure `huggingface_hub>=1.1.3` to avoid rate limits. Learn more in the <a href="https://docs.voxel51.com/integrations/huggingface.html#loading-datasets-from-the-hub" target="_blank">Hugging Face integration docs</a>.

<a href="https://huggingface.co/datasets/Voxel51/ariel_scans" target="_blank">![Hugging Face](https://img.shields.io/badge/%F0%9F%A4%97%20Hugging%20Face-Dataset-yellow)</a>

# Dataset Card for Ariel Scans

![image/png](https://huggingface.co/datasets/Voxel51/ariel_scans/resolve/main/ariel_scans_.gif)

This is a [FiftyOne](https://github.com/voxel51/fiftyone) dataset with 6546 samples.

## Installation

If you haven’t already, install FiftyOne:

```bash
pip install -U fiftyone
```

## Usage

```python
import fiftyone as fo
from fiftyone.utils.huggingface import load_from_hub

# Load the dataset
# Note: other available arguments include 'max_samples', etc
dataset = load_from_hub("Voxel51/ariel_scans")

# Launch the App
session = fo.launch_app(dataset)
```

# Ariel Scans: The Great Desert Plane Hunt

> A turbine RC plane went down in the desert. Its builder flew a mapping grid over the
> search area, came home with thousands of nearly-identical sand tiles, and posted a
> $50 bounty on Reddit to anyone who could find it. This is that haystack — now with a
> few embeddings, a homemade computer-vision plugin, and ten saved views pointed
> squarely at the needle.

## Dataset Details

### Dataset Description

<!-- Provide a longer summary of what this dataset is. -->

`Ariel_Scans` is an aerial search-and-rescue dataset for exactly one missing object: a
self-built turbine RC plane that crashed somewhere in the desert. The original pilot ran
an automated mapping grid (the kind you’d use for drone photogrammetry) over the suspected
crash zone, producing a wall of overhead imagery where every frame looks heartbreakingly
like the last: scrub, sand, the occasional shadow, and — somewhere in there — a small dark
carbon-fiber airframe lying flat on the ground.

The Reddit post mentioned “about 3,000 high-res images.” The grid actually came back with
**6,546**, because the mapping rig captured two sensors at once: a high-resolution RGB
camera and a low-resolution thermal/IR camera. So it’s really ~3,274 RGB frames and ~3,272
thermal frames, paired tile-for-tile across the same ground.

This release ships the raw survey **plus** the full FiftyOne analysis layer built to crack
it: CLIP embeddings, a similarity index, a 2D UMAP map, candidate detections from the
`plane_finder` plugin (a classic dark-blob / elongated-shape / smooth-interior detector),
per-detection geometry features, patch embeddings, uniqueness scores, and ten saved views
that triage 6,546 frames down to a handful worth a human’s eyeballs.

- **Curated by:** Harpreet Sahota (Developer Advocate, Voxel51), on behalf of one optimistic Redditor
- **Funded by:** A $50 PayPal/CashApp/Zelle bounty and an unreasonable amount of curiosity
- **Shared by:** Harpreet Sahota / Voxel51
- **Language(s) (NLP):** en (the field names and this card; the imagery does not speak)
- **License:** Imagery courtesy of the original poster; please treat it as the OP’s and use it in the good-natured spirit of “help me find my plane.” Code and annotations: MIT.

### Dataset Sources

<!-- Provide the basic links for the dataset. -->
- **Repository:** `harpreetsahota204/ariel_scans` on the Hugging Face Hub
- **Paper:** None. This is, scientifically speaking, a guy who lost his plane.
- **Demo:** The accompanying notebook, `Finding_a_Needle_in_the_Desert.ipynb`, and the [`plane_finder` plugin](https://github.com/harpreetsahota204/plane_finder)

## Uses

<!-- Address questions around how the dataset is intended to be used. -->

### Direct Use

<!-- This section describes suitable use cases for the dataset. -->
- **Find the plane.** This is the canonical task. Open `candidates_by_score` or
  `top_shortlist` in the FiftyOne App and start scrolling from the top.
- A teaching dataset for **needle-in-a-haystack visual search**: embeddings, similarity
  search, uniqueness/anomaly ranking, and 2D embedding visualizations on imagery that is
  punishingly self-similar.
- A worked example of turning a **classical OpenCV detector into a FiftyOne plugin** and
  using its output to drive dataset views.
- Benchmarking **small-object / low-contrast detection** in aerial imagery, including the
  RGB-vs-thermal sensor split.
- A friendly sandbox for **patch embeddings** (`to_patches` + per-crop embeddings,
  similarity, and uniqueness).

### Out-of-Scope Use

<!-- This section addresses misuse, malicious use, and uses that the dataset will not work well for. -->
- It is **not** a general-purpose aircraft, drone, or object-detection benchmark. There is
  essentially one object of interest, it may appear in only a handful of frames, and the
  “labels” here are *unverified machine-generated candidates*, not ground truth.
- Not a surveillance or people-finding dataset — it’s empty desert by design. Please don’t
  repurpose the workflow to track individuals.
- Don’t treat `plane_candidates` as gold annotations. Most of them are bushes, rocks, and
  shadows that happen to be dark and vaguely plane-shaped. That’s the whole problem.

## Dataset Structure

<!-- This section provides a description of the dataset fields, and additional information about the dataset structure such as criteria used to create the splits, relationships between data points, etc. -->

A FiftyOne image dataset of **6,546 samples** and **no train/test split** (when you’re
looking for your plane, every frame is the test set).

**Sensor mix (de-facto split):**

| Sensor       | Resolution   | Count   |
|--------------|--------------|---------|
| RGB          | 4624 × 3472  | ~3,274  |
| Thermal / IR | 640 × 512    | ~3,272  |

**Sample fields:**

- `filepath`, `metadata` — standard image metadata (width, height, channels, size, mime).
- `clip_embeddings` — CLIP (`open-clip-torch`) embedding of the whole frame.
- `dark_mask` — a `Heatmap` from the plugin’s calibration operator showing what counts as “dark.”
- `plane_candidates` — `Detections` of plane-like blobs. Each detection carries geometry
  features used for scoring: `confidence`, `solidity`, `rect_fill`, `rect_aspect`, `area`,
  `interior_std`, `interior_mean`, `rect_angle`, `bbox_diag`, plus `patch_embeddings` and
  `patch_uniqueness` (see below). Across the dataset there are **132,531** candidate
  detections; **3,947** frames have at least one.
- `max_plane_candidates_score` — the best candidate score per frame, for ranking.
- `uniqueness` — frame-level visual uniqueness (anomaly-ish) score.

**Saved views (the actual product):**

- `candidates_by_score` — every frame with a candidate, ranked by best score.
- `top_shortlist` — the top 100. Start here.
- `high_confidence` — only the strong boxes (`confidence > 0.6`).
- `carbon_like` — elongated **and** smooth-surfaced candidates (the airframe signature).
- `best_geometry` — solid, box-filling, elongated, sensibly sized.
- `review_band` — the mid-scoring “maybe” pile, so nothing borderline slips through.
- `thermal_frames` — the small IR frames, which behave differently under the detector.
- `unusual_candidates` — candidate frames ranked by how visually unusual they are.
- `plane_patches` — one crop per candidate detection (read-only patches view).
- `unusual_patches` — those crops ranked by per-crop unusualness; the real airframe should
  stand apart from the endless bush/shadow patches.

**Brain runs:** `clip_sim`, `clip_viz`, `patch_sim`, `patch_viz`, `uniqueness`.

## Dataset Creation

### Curation Rationale

<!-- Motivation for the creation of this dataset. -->

Someone on the internet lost something they built with their own hands and offered fifty
bucks for help finding it. That is a wholesome problem, and it also happens to be a perfect
illustration of why visual-AI tooling exists: a human cannot reliably scan 6,546 look-alike
desert tiles, but embeddings + a cheap detector + good views can shrink that to a coffee’s
worth of reviewing. The dataset was curated to (a) actually help find the plane and (b)
serve as a charming, end-to-end teaching example.

### Source Data

<!-- This section describes the source data (e.g. news text and headlines, social media posts, translated sentences, ...). -->

#### Data Collection and Processing

<!-- This section describes the data collection and processing process such as data selection criteria, filtering and normalization methods, tools and libraries used, etc. -->

The raw imagery was captured by the original pilot flying an **automated aerial mapping
grid** (overlapping nadir passes) over the suspected crash area with a dual RGB + thermal
payload. Processing in this release was done with FiftyOne:

1. Loaded the images from disk and computed metadata.
2. Computed CLIP embeddings, a similarity index (`clip_sim`), and a UMAP visualization (`clip_viz`).
3. Ran the `plane_finder` plugin (dark thresholding → morphological closing → contour
   analysis → geometry scoring) to write `plane_candidates` and `max_plane_candidates_score`.
4. Computed frame-level `uniqueness`.
5. Computed patch embeddings on each candidate crop, indexed them (`patch_sim`, `patch_viz`),
   and derived a per-crop `patch_uniqueness` (mean cosine distance to nearest neighbors).
6. Built and saved the ten review views above.

#### Who are the source data producers?

<!-- This section describes the people or systems who originally created the data. It should also include self-reported demographic or identity information for the source data creators if this information is available. -->

One RC-aircraft hobbyist who builds their own turbine planes, owns or borrowed a mapping
drone, and has a healthy tolerance for desert sun. Identity intentionally left as the
anonymous Reddit handle that started it all.

### Annotations

<!-- If the dataset contains annotations which are not part of the initial data collection, use this section to describe them. -->

#### Annotation process

<!-- This section describes the annotation process such as annotation tools used in the process, the amount of data annotated, annotation guidelines provided to the annotators, interannotator statistics, annotation validation, etc. -->

There are no hand-drawn annotations. The `plane_candidates` “annotations” are
**machine-generated candidate detections** produced entirely by the `plane_finder` plugin —
an unsupervised, rule-based OpenCV detector. No human drew a box; the algorithm flagged
anything dark, elongated, and smooth, then scored it. Consider every box a *hypothesis*,
not a label.

#### Who are the annotators?

<!-- This section describes the people or systems who created the annotations. -->

A ~200 lines of OpenCV and the `plane_finder` FiftyOne plugin. It has never seen a plane,
has no opinions, and will confidently box a shadow.

#### Personal and Sensitive Information

<!-- State whether the dataset contains data that might be considered personal, sensitive, or private (e.g., data that reveals addresses, uniquely identifiable names or aliases, racial or ethnic origins, sexual orientations, religious beliefs, political opinions, financial or health data, etc.). -->

It’s overhead imagery of empty desert. No people, faces, license plates, or homes were the
subject of the survey. Precise GPS/EXIF geolocation may be embedded in the original files;
if you’d rather not advertise the exact patch of desert, strip EXIF before redistributing.

## Bias, Risks, and Limitations

<!-- This section is meant to convey both technical and sociotechnical limitations. -->
- **Massive class imbalance of one.** There may be only a handful of frames (or zero!)
  containing the actual plane among 6,546. Precision/recall metrics are nearly meaningless
  without verified ground truth.
- **The detector is dumb on purpose.** It keys on “dark + elongated + smooth,” which also
  describes bushes, tire tracks, rocks, and — famously — shadows.
- **The `0000` trap.** The original poster warned that one image (renamed `0000`) contains
  a shadow on the top-left that looks *exactly* like the plane; they drove out and checked
  in person. It is a known, confirmed false positive and a great sanity check for any model.
- **Sensor domain gap.** RGB and thermal frames have wildly different resolution, contrast,
  and noise characteristics; a threshold tuned on one will misbehave on the other.
- **No guarantee of success.** The plane might be under a bush, buried in sand, or simply
  outside the flown grid. The data can only narrow the search, not promise a happy ending.

### Recommendations

<!-- This section is meant to convey recommendations with respect to the bias, risk, and technical limitations. -->

Users should treat `plane_candidates` as triage hints, not truth. Start from
`top_shortlist` and `carbon_like`, keep the RGB and `thermal_frames` reviews separate,
lean on `patch_sim` to pull look-alikes once you spot a promising crop, and use `0000` as
your “can my eye/model tell the difference?” calibration sample. And if you find it: the OP
still owes someone $50.

## Citation

<!-- If there is a paper or blog post introducing the dataset, the APA and Bibtex information for that should go in this section. -->

**BibTeX:**

```bibtex
@misc{lostturbineplane,
  author       = {{u/ReturnAdventurous179}},
  title        = {{[Need Help] Searching 3{,}000 aerial images to locate a downed turbine RC plane}},
  howpublished = {Reddit post},
  year         = {2025},
  note         = {``I built the plane myself and it would be sick to find it.
                  I'll paypal/cashapp/zelle etc \$50 bucks to whoever finds it lol.''
                  Warning: image ``0000'' is a shadow that looks EXACTLY like the plane.},
  url          = {https://www.reddit.com/r/computervision/comments/1u76ln1/need_help_searching_3000_aerial_images_to_locate}
}
```

## Glossary

<!-- If relevant, include terms and calculations in this section that can help readers understand the dataset or dataset card. -->
- **Candidate** — a machine-flagged blob that *might* be the plane. Usually isn’t.
- **`solidity`** — contour area ÷ convex-hull area. ~1.0 means a clean, solid shape (good);
  low means ragged or hollow (vegetation).
- **`rect_fill`** — how much of the candidate’s minimum-area rectangle the blob actually
  fills. High = compact, rectangular, airframe-like.
- **`rect_aspect`** — length-to-width ratio of that rectangle. A plane on the ground is
  elongated, so higher is more interesting.
- **`bbox_diag`** — bounding-box diagonal in pixels; a rough size gate.
- **`interior_std` / `interior_mean`** — pixel statistics inside the blob. Low std =
  smooth, uniform surface (raw carbon fiber), which is what we want.
- **`max_plane_candidates_score`** — the best candidate score in a frame; the primary ranking signal.
- **`uniqueness`** — frame-level visual distinctiveness; the plane should be an anomaly in a sea of sameness.
- **`patch_uniqueness`** — the same idea, computed per candidate crop from patch embeddings.
- **`dark_mask`** — the calibration heatmap showing which pixels the detector considers “dark.”

## More Information

The full story, code, and review workflow live in the companion notebook
(`Finding_a_Needle_in_the_Desert.ipynb`) and blog post, and the detector ships as the
open-source [`plane_finder`](https://github.com/harpreetsahota204/plane_finder) FiftyOne
plugin. If you actually locate the aircraft, please tell the OP, collect your $50, and post
the coordinates so the rest of us can sleep.

## Dataset Card Authors

Harpreet Sahota (Voxel51), with narrative contributions from an anonymous Reddit pilot and
a great deal of sand.

## Dataset Card Contact

Harpreet Sahota — [@harpreetsahota204](https://github.com/harpreetsahota204) on GitHub, or
via the Voxel51 community Discord.