---
title: OASIS 2 Dataset Overview
url: https://www.emergentmind.com/topics/oasis-2-dataset
type: topic
---

# OASIS 2 Dataset Overview

Searching arXiv for the cited OASIS papers and any related versioning/context.
{"query":"OASIS single image 3D in the wild 2007.13215 OASIS 2 ontology 2306.17514","max_results":10}
I’ll look up the exact arXiv records to ground the article in the current literature.
The expression **“OASIS 2 Dataset”** is domain-dependent rather than singular. In computer vision, the relevant resource is **OASIS — Open Annotations of Single-Image Surfaces**, introduced as a large-scale dataset for single-image 3D in the wild; the associated paper and project site do **not** define a distinct dataset or version named “OASIS 2,” and the public release is simply called **OASIS** [2007.13215]. In ontology engineering, by contrast, **OASIS 2** denotes **Ontology for Agents, Systems and Integration of Services, version 2**, a foundational OWL 2 ontology whose downloadable OWL/RDF files, and related example ABox distributions, are sometimes treated as a “dataset” [2306.17514]. The term therefore names either a non-existent second version of the CVPR 2020 vision dataset, or an actual ontology distribution in the semantic-web literature.

## 1. Terminological scope and versioning

The two uses of the name differ in both object type and scholarly context. In the vision literature, OASIS is a dataset of annotated images for monocular 3D reconstruction. In the ontology literature, OASIS 2 is an OWL 2 ontology for agent behaviours, plans, processes, and procedures.

| Term | Referent | Versioning status |
|---|---|---|
| OASIS | Open Annotations of Single-Image Surfaces | Publicly released dataset; minor post–camera-ready quality fixes affecting \(<10\%\) of images |
| “OASIS 2” in vision | Purported second version of OASIS | Not defined by the authors |
| OASIS 2 | Ontology for Agents, Systems and Integration of Services, version 2 | Actual ontology distribution in OWL/RDF form |

For the CVPR 2020 resource, the first public release is associated with **“OASIS: A Large-Scale Dataset for Single Image 3D in the Wild”** [2007.13215]. The paper states that the publicly released dataset is an improved version relative to the camera-ready, with small post–camera-ready quality fixes affecting fewer than \(10\%\) of images, but it does not introduce any **“OASIS 2” nomenclature**. A common misunderstanding is therefore to read “OASIS 2 Dataset” as a formal second release of the vision benchmark; the source material does not support that interpretation.

In the ontology paper, **“A behaviouristic approach to representing processes and procedures in the OASIS 2 ontology”**, the phrase **OASIS 2** refers to the ontology itself and its OWL/RDF distribution, with related ABox/example distributions available separately [2306.17514]. In that setting, “dataset” typically means the ontology files that can be downloaded and loaded into a reasoner or triplestore.

## 2. OASIS as a single-image 3D dataset

OASIS is defined as a dataset for **single-image 3D in the wild** consisting of annotations of detailed 3D geometry for **140,000 images** [2007.13215]. The images are random **Creative Commons Flickr images with known focal length (from EXIF)**. The domain is explicitly heterogeneous: indoor, outdoor, natural, and man-made scenes are all represented, and focal lengths vary widely, with most between \(1\times\) and \(10\times\) the image width.

The dataset is organized around per-image annotations designed to enable **pixel-wise surface reconstruction**. Annotators provide **occlusion boundaries** with near/far ordering, and distinguish **smooth occlusions** from **sharp occlusions**. They also mark **fold boundaries**, defined as surface-normal discontinuities where surfaces remain physically connected. For smooth surfaces, they indicate whether a surface is **planar or curved**; they supply one normal per planar surface and multiple normals on curved surfaces where needed. For planar surfaces, they may additionally label **relative normals** as **parallel, orthogonal, or neither**, with automatic adjustment of normals to enforce those relations.

The scene geometry represented by these annotations is intentionally nontrivial. Most annotated regions, more than \(90\%\), contain **occlusion boundaries**, and nearly half contain **both occlusion and fold boundaries**. Most regions, more than \(70\%\), include **curved surfaces**, not only planes. Many regions also comprise multiple disconnected pieces and complex continuity or smoothness. This suggests that OASIS was constructed to stress the failure modes of planar, indoor-only, or sensor-constrained datasets rather than to regularize them away.

The distributed outputs include RGB images, per-pixel dense depth maps, per-pixel dense normal maps, binary maps for fold and occlusion boundaries with occlusion near/far side labels, planar instance masks and planar parameters, and per-image focal length. The paper does **not** enumerate specific file formats such as PNG, EXR, or NPZ, does **not** specify exact dataset size on disk, and does **not** explicitly specify image resolution; those implementation details are deferred to the project site.

## 3. Annotation workflow and geometric reconstruction

The annotation pipeline is built around an interactive workflow rather than direct dense labeling. Annotators first select a **polygonal region** that is required to cover **two randomly pre-selected locations**. They then mark occlusion and fold lines, annotate normals with a **draggable 3D arrow**, decide planarity for smooth surfaces, and specify parallel or orthogonal relations for planar pairs. An **interactive 3D preview window** shows the reconstructed surface mesh, and annotators iterate until satisfied [2007.13215].

Quality control is multi-stage. Workers complete training on **occlusions, folds, normals, and UI usage**, and must pass a **qualification quiz**. Each collected mesh is then subjected to a separate **quality verification task** in which workers judge whether the reconstructed mesh reflects the image well; only meshes deemed high-quality are accepted. The workforce is mixed: **11% annotations via Amazon Mechanical Turk; the remainder via two annotation companies**. The reported average time per image is approximately **305 seconds**, indicating a deliberately high annotation effort.

Dense geometry is not hand-labeled directly but **derived** from the sparse structural annotations. **Dense normals** are obtained by propagating annotated normals with a **smoothness objective**, stopping at fold and occlusion boundaries, and solving via **least squares (LU factorization)** with boundary-aware neighborhood constraints, followed by per-pixel normalization. **Dense depth** is then recovered by integrating normals, with known focal length, per continuous surface to obtain depth up to **per-surface scale**. Inter-surface ordering is enforced by a constrained optimization that finds a scale \(X_S\) for each surface \(S\) so that near/far ordering along sampled occlusion pairs is satisfied; a small epsilon separation and minimum scale eta are used.

This reconstruction strategy imposes a particular scale semantics. Depth is **metric only up to a per-surface scale**; ordering across surfaces is enforced by scaling, but **absolute global scale across the whole image is not guaranteed**. Normal coordinates are effectively **camera-centric**, and the integration pipeline treats them in the camera frame. The authors also clip or snap the **z-component of normals to be no smaller than 0.3** during normal integration to avoid excessive depth stretch. A second common misconception is therefore to treat OASIS depth as globally scaled metric ground truth; the paper explicitly cautions against that interpretation.

## 4. Tasks, metrics, and empirical profile

OASIS provides official splits of **train 110K, val 10K, test 20K**, applied consistently across tasks [2007.13215]. The supported tasks are **single-image depth estimation**, **surface normal estimation**, **joint boundary detection and classification**, and **instance segmentation of planes** with plane parameter regression.

The depth protocol is built around **Locally Scale-Invariant RMSE (LSIV\_RMSE)** on 3D point clouds after backprojection with predicted focal length and **per-surface scaling and z-translation alignment**. **WKDR** is reported for depth ordering. The evaluation guidance is explicit: models should predict focal length, or use a validation-selected focal length if focal length is not produced; LSIV\_RMSE alone is **insensitive to cross-surface ordering**, so ordering should be evaluated separately via WKDR. The paper also lists common depth metrics such as **AbsRel**, **SqRel**, **RMSE**, **RMSE\(_{\log}\)**, thresholded \(\delta\) accuracies, and scale-invariant depth error, while emphasizing LSIV\_RMSE and WKDR for OASIS.

For **depth estimation**, representative results are: **ResNetD trained on ImageNet + OASIS: LSIV\_RMSE \(\approx 0.37\); WKDR \(\approx 32.62\%\)**. The same architecture trained only on OASIS yields **LSIV\_RMSE \(\approx 0.47\); WKDR \(\approx 39.73\%\)**, and an Hourglass model trained on OASIS yields **LSIV\_RMSE \(\approx 0.45\); WKDR \(\approx 39.01\%\)**. Off-the-shelf **FCRN** and **Hourglass** models trained on other datasets are reported at approximately **0.67 LSIV\_RMSE**, with WKDR around **38–40%**, and are **not better than a plane baseline**. Approximate human performance is **LSIV\_RMSE \(\approx 0.24\); WKDR \(\approx 19\%\)**.

For **surface normals**, the reported metrics are mean and median angular error and the percentage of pixels within **11.25°**, **22.5°**, and **30°**. An Hourglass model trained on OASIS achieves **mean angular error \(\approx 23.91^\circ\)**, **median \(\approx 18.16^\circ\)**, with **31.23% / 59.45% / 71.77%** within the three thresholds, and relative-normal **AUC\(_o\) \(\approx 0.59\)** and **AUC\(_p\) \(\approx 0.58\)**. Approximate human performance is **mean \(\approx 17.27^\circ\)**, **median \(\approx 12.92^\circ\)**, with **44.36% / 76.16% / 85.24%** within thresholds, and **AUC\(_o\) \(\approx 0.88\)** and **AUC\(_p\) \(\approx 0.65\)**. The paper also reports that an Hourglass model trained on OASIS generalizes better to **DIODE** and **ETH3D** than models trained on **NYU** or **SNOW**.

For **fold/occlusion boundary detection**, the metrics are **ODS**, **OIS**, and **AP**, with a detection required both to localize the boundary and to classify it correctly as **occlusion** or **fold**. An Hourglass model trained on OASIS yields **ODS \(\approx 0.581\)**, **OIS \(\approx 0.639\)**, **AP \(\approx 0.530\)**; **HED** trained on OASIS yields **ODS \(\approx 0.547\)**, **OIS \(\approx 0.606\)**, **AP \(\approx 0.488\)**; approximate human performance is **ODS \(\approx 0.810\)**. For **planar instance segmentation**, **PlanarReconstruction** trained on **ScanNet only** gives **AP \(\approx 0.076\)**, **AP50 \(\approx 0.161\)**, **AP75 \(\approx 0.064\)**; trained on **OASIS**, **AP \(\approx 0.125\)**, **AP50 \(\approx 0.249\)**, **AP75 \(\approx 0.110\)**; trained on **ScanNet + OASIS**, **AP \(\approx 0.137\)**, **AP50 \(\approx 0.262\)**, **AP75 \(\approx 0.126\)**; approximate human performance is **AP \(\approx 0.461\)**, **AP50 \(\approx 0.542\)**, **AP75 \(\approx 0.476\)**.

These results support several bounded conclusions already stated by the authors. Training directly on OASIS and predicting focal length improves metric reconstruction in the wild; ImageNet pretraining helps; relative normal relations remain difficult; joint fold-versus-occlusion boundary detection is challenging; and sizable human–machine gaps remain across tasks. The paper also notes that standard normal metrics may **underweight foreground geometry**, which suggests that current evaluation may not fully capture perceptual quality in complex scenes.

## 5. OASIS 2 as an OWL 2 ontology distribution

In the ontology literature, **OASIS 2** is a **foundational OWL 2 ontology** for modeling **agents**, their **mental states and capabilities**, and their **interactions**, including **plans** and **action executions** [2306.17514]. Its behavioristic orientation is explicit: it emphasizes what agents can do, how those abilities are described, and how they are executed. In this context, the “dataset” is the downloadable ontology distribution, including the ontology files and, in related resources, example ABox individuals.

The pre-extension core model includes classes such as **Agent**, **Behaviour**, **GoalDescription**, **TaskDescription**, **TaskOperator**, **Action**, **TaskOperatorArgument**, **TaskObject**, **TaskInputParameter**, **TaskOutputParameter**, **TemplateThing**, **BehaviourThing**, **PlanningThing**, **ExecutionThing**, and **PlanExecution**. The intended semantics are specific. A **Behaviour** is a mental state describing agent capabilities and collects goals; a **GoalDescription** is a container of tasks an agent can achieve; a **TaskDescription** models atomic operations; **TaskOperator** refers to the action to be performed; and the various task-object and task-parameter classes specify recipients, inputs, and outputs. Template, behaviour, planning, and execution markers distinguish abstract templates, concrete behaviours of real agents, planned actions, and already performed actions.

Selected properties structure this capability-and-execution model. **hasBehaviour** links an agent to a behaviour; **consistsOfGoalDescription** and **consistsOfTaskDescription** compose behaviours into goals and tasks; **dependsOn** organizes inter-goal and inter-task dependency; **refersExactlyTo**, **refersAsNewTo**, and **refersAsInstanceOf** connect descriptions to concrete or template-level entities; **overloadsBehaviour** and related overload properties connect concrete behaviours to templates; **drawnBy** subproperties trace executions back to the elements they were drawn from; **submittedTo** subproperties link planned descriptions to the behaviours responsible for realization; and **hasExecution** subproperties connect plans to their executions.

The 2023 extension adds explicit representations of **processes** and **procedures**. Motivated by **ISO 9001-2015**, the paper distinguishes a **process** as a set of correlated or interactive activities that transform inputs into outputs, and a **procedure** as a description of how to carry out all or part of a process. New classes include **Process**, **Procedure**, and **ProcedureState** with two categories: **TerminatingProcedureState**, containing **InitialProcedureState** and **FinalProcedureState**, and **NonTerminatingProcedureState**. The paper states the representative axiom **Procedure \(\sqsubseteq\) Activity**, and introduces ordering and composition properties such as **procedureConsistsOfProcedureState**, **procedureConsistsOfInitialProcedureState**, **procedureConsistsOfFinalProcedureState**, **hasNext**, **hasNextNonTerminatingProcedureState**, **hasFinalProcedureState**, and **hasNextProcedure**.

Each procedure state is linked to the planned behaviour that describes how to perform it by **isDescribedBy**, and may be connected to an **Event** by **triggersEvent**. The ontology also models **roles** and **behaviour provisioning**: **Role** can provide behaviours via **providesBehaviour**; agents acquire those behaviours by **playRole**; **RoleType** provides domain-specific classification; and **DeprecatedThing** marks deprecated roles. The result is an ontology that integrates **capabilities**, **plans**, **ordered procedure steps**, **executions**, **roles**, and **events** within a single agent-centric formalization.

## 6. Access, usage patterns, and interpretive cautions

The two resources are accessed and used differently. The vision dataset is available from the OASIS project site, and its use is conditioned by the fact that the images derive from **Flickr CC**; licensing and redistribution therefore follow source constraints, and the latest terms should be checked on the project page [2007.13215]. The ontology distribution is available from the **OASIS 2 v2 ontologies** repository, with separate links for the **OASIS-Abox ontology** and **Ether-OASIS**; the paper is **CC BY 4.0**, but it does **not explicitly state the ontology’s license**, so the repository should be consulted for licensing details [2306.17514].

The ontology paper does **not** advertise a public **SPARQL endpoint**. Typical usage is to load the OWL files into a reasoner or triplestore, for example **Protégé** with **HermiT**, **Pellet**, or **FaCT++**. The intended reasoning tasks include checking consistency of processes and procedures, role-based behaviour provisioning, and tracing plan-to-execution links through the **drawnBy** family of properties. The paper’s case study is a **resource lock process** with three procedure states—**request lock**, **modify resource**, and **release lock**—each linked by **isDescribedBy** to a planned behaviour, and realized through corresponding plan executions connected by **hasPlanExecution** and **planExecutionDrawnBy**.

For the vision dataset, the principal methodological caution is to **align predictions per-surface and report ordering separately**. The paper explicitly states that OASIS depth should not be treated as **globally scaled metric ground truth**, that LSIV\_RMSE is invariant to per-surface scale and translation in \(z\), and that **WKDR reporting is important** because LSIV\_RMSE does not enforce ordering between disconnected surfaces. For the ontology, the principal interpretive caution is terminological: “dataset” refers to the **OWL files** and possibly associated **ABox examples**, not to a benchmark with empirical performance metrics. The 2023 ontology paper itself presents **no empirical performance metrics**; its evaluation is by formalization, competency questions, example RDF/Turtle fragments, and standard OWL 2 reasoning practice.

Taken together, the two literatures show that **“OASIS 2 Dataset”** is not a single canonical object. In single-image 3D, the authoritative dataset is **OASIS**, not “OASIS 2.” In knowledge representation, **OASIS 2** is an actual ontology distribution for agent behaviours, processes, procedures, and executions. Any precise use of the term therefore depends on whether the intended referent is a **computer-vision dataset** or an **OWL 2 ontology package**.

Source: https://www.emergentmind.com/topics/oasis-2-dataset