3DLF-Scan dataset: Multi-sensor 3D light-field and structured-light scans of 3D-printed Stanford figures

Abstract

This data article presents 3DLF-Scan, a multi-sensor dataset of 3D-printed canonical Stanford models (bunny, dragon, asian_dragon, armadillo, happy, lucy, thai_statue) captured under controlled tabletop conditions. Each object is recorded in a full 360° turntable sweep with two calibrated light-field cameras (apiCAM PRO and apiCAM CUBE, photonicSENS) and a structured-light Revopoint Miraco 3D scanner. For every light-field viewpoint, the dataset includes RGB images, raw/sparse depth, dense depth completion in metric units, per-view foreground masks, and metric point clouds. Camera-from-object poses are provided as 4 × 4 matrices obtained from a nominal 5° turntable step refined by depth-only ICP under a single-axis constraint. For each figure, a separate scanner-based reference reconstruction and per-sensor calibration files (intrinsics, undistortion maps, checkerboard images) are also included. All assets are organized per object and per modality using standard formats (PNG, NPY, PLY, JSON) and naming conventions compatible with common 3D vision toolchains. The dataset is intended for developing and benchmarking methods in multi-view 3D reconstruction, depth completion, volumetric fusion, and cross-sensor registration.

Specifications Table

Subject	Computer Sciences
Specific subject area	Multi-sensor 3D reconstruction and depth completion on tabletop objects.
Type of data	Images (PNG); arrays (NPY, NPZ); point clouds (PLY); JSON; TXT; figures (PNG/JPG).
Data collection	Two calibrated light-field camera photonicSENS units acquired 360° turntable sequences of each object (5° nominal steps). Per-view depth was computed by an LF pipeline (raw dense and sparse), then refined by a custom high-fidelity depth completion pipeline based on diffusion. Camera poses were initialized from turntable kinematics and refined with depth-only ICP. Additional scans were captured with a Revopoint Miraco structured-light device; raw streams were converted to metric depth, RGB, and PLY using custom converters. Intrinsics were estimated via checkerboard calibration with quality montages and undistortion maps.
Data source location	City/Town/Region: Málaga, Andalusia, Spain Country: Spain Institution: Universidad de Málaga, Institutos Universitarios
Data accessibility	Repository name: Mendeley Data DOI: 10.17632/ngvgpsvd8b.1 Direct URL to data: https://data.mendeley.com/datasets/ngvgpsvd8b/1 Instructions for accessing these data: The dataset is openly available under the CC BY 4.0 license. All files can be downloaded without registration; editors and reviewers can access the data anonymously via the direct URL.
Related research article	None.

1. Value of the Data

• •360° multi-sensor captures of canonical 3D models.

  The dataset provides full 360° turntable sequences of well-known Stanford figures acquired with two light-field cameras and a structured-light scanner. This enables systematic benchmarking of 3D Gaussian splatting [1], structure-from-motion (SfM) [2], multi-view stereo, TSDF fusion [3], and sparse-to-dense depth completion on real, controllable tabletop scenes.

• •Cross-sensor, pose-aware sequences for reconstruction and registration.

  Each 360° sequence includes per-view RGB, raw/sparse depth, dense depth, metric point clouds, and 4 × 4 camera-from-object poses, plus a separate high-resolution scanner point cloud. This allows researchers to study cross-sensor alignment, scale consistency, pose refinement, and object-centric fusion without relying on synthetic data.

• •Turntable ICP pose tracks with realistic residual errors.

  Camera trajectories are initialized assuming a 5° turntable step and refined via depth-only ICP under a single-axis constraint, exposing realistic residual drift, sweep direction, and coverage. These pose tracks can be reused for evaluating pose-estimation, bundle-adjustment, and pose-graph refinement algorithms.

• •Straightforward integration in common toolchains.

  Data are stored in standard formats (PNG, NPY, PLY, JSON) with naming conventions aligned to OpenCV, Open3D, and COLMAP. This simplifies using the dataset for training and evaluating SfM pipelines, COLMAP-based reconstruction, depth completion networks, and TSDF/voxel-grid methods.

2. Background

Research on depth completion and multi-view 3D reconstruction benefits from real, controllable tabletop scenes that permit dense capture, accurate pose estimation, and cross-sensor comparison. We assembled this dataset to (i) stress-test high-fidelity sparse-to-dense depth completion on light-field imagery, (ii) provide pose-aware, 360° turntable sequences for multi-view and SfM/MVS algorithms, and (iii) supply calibration artifacts for reproducible pipelines in common 3D toolchains.

The same 3D-printed Stanford models [4,5] (bunny, dragon, asian_dragon, armadillo, happy, lucy, thai_statue) are observed with two complementary modalities [7]: calibrated light-field cameras apiCAM PRO and apiCAM CUBE (PHOTONIC SENSORS & ALGORITHMS, Valencia, Spain). and a structured-light Revopoint Miraco scanner (Revopoint 3D Technologies Inc., Shenzhen, China). This combination offers view-dense RGB-D streams and high-quality reference geometry in metric units, enabling scale-consistent evaluation across reconstruction, registration, and depth-completion methods. Using canonical Stanford figures facilitates comparability across studies and simplifies replicating the scene setup with new hardware. Canonical models from the Stanford 3D Scanning Repository are widely used in graphics and vision as reference geometries, which makes them suitable for reusable benchmarking.

3. Data Description

The dataset [7] is organized around seven 3D-printed canonical objects (“figures”) (Fig. 1): bunny, dragon, asian_dragon, armadillo, happy, lucy, thai_statue.

Fig. 1.

3D-printed canonical objects used in the 3DLF-Scan dataset. Example RGB views of all seven Stanford-derived models printed in dark matte resin and placed on the motorised turntable.

All figures are observed in 360° turntable sequences with two modalities:

• •Light-field cameras (apiCAM PRO and apiCAM CUBE)
• •Revopoint structured-light scanner

At the repository root, data are grouped as described in Table 1.

Table 1.

Top-level folder structure of the 3DLF-Scan dataset and corresponding contents.

Folder	Content
pro/	Light-field sequences from apiCAM PRO
cube/	Light-field sequences from apiCAM CUBE
revopoint/	Structured-light turntable scans and derived depth/PCD
calib_pro/, calib_cube/	Camera calibration data for apiCAM PRO and apiCAM CUBE

In addition to the folders listed in Table 1, the repository root also contains one STL mesh per figure: armadillo.stl, asian_dragon.stl, bunny.stl, dragon.stl, happy.stl, lucy.stl, thai_statue.stl.

These files are the canonical meshes downloaded from the Stanford 3D Scanning Repository [4,5] and were used as the source geometry for 3D printing the physical models. They are provided as ground-truth reference shapes in their original coordinate systems and are not rigidly aligned to any of the camera or scanner frames in this dataset.

Below, we describe the structure and file contents of each part.

3.1. Light-field camera data

Each light-field root (pro/, cube/) contains one subfolder per figure:

• •pro/bunny/, pro/dragon/, …, pro/thai_statue/
• •cube/bunny/, cube/dragon/, …, cube/thai_statue/

Within each {camera}/{figure}/ directory (for both PRO and CUBE), data are organized in modality-specific subfolders (Table 2). An example of the main per-view modalities (RGB, dense depth, sparse depth visualization, and HiFi-DC output) is shown in Fig. 2.

Table 2.

Per-figure subfolder structure for light-field cameras.

Subfolder	Typical file pattern	Description
rgb/	{figure}_{id}_rgb.png	Per-view RGB images of the 3D-printed model in turntable order. 8-bit PNG, one file per view.
rgb_bright/	{figure}_{id}_rgb_bright.png	Optional exposure-corrected / brightened RGB images derived from rgb/, useful for visualization and methods sensitive to low light.
depth/	{figure}_{id}_depth.png	Dense depth maps exported from the camera depth algorithm. Grayscale PNG (high bit-depth), one per view.
depth_sparse/	{figure}_{id}_depthSparse.png	Visualizations of the sparse or high-confidence depth input (mask-like overlay), in PNG format.
depth_npy/	{figure}_{id}_depth.npy	Per-pixel sparse depth values stored as NumPy arrays (float32, shape H × W). Invalid pixels are set to 0 or NaN. Depth values are in millimetres in the camera coordinate frame.
depth_hifi/	{figure}_{id}_depth_hifi.npy	Dense “high-fidelity” depth-completion results for each view. NumPy arrays (float32, H × W), in millimetres.
depth_hifi_vis/	{figure}_{id}_depth_hifi_vis.png	Colorized visualizations of depth_hifi maps (fixed colormap), in PNG format.
masks_rgb/	{figure}_{id}_mask_rgb.png	Binary foreground masks in image space, derived from RGB and depth (1 = object + turntable, 0 = background). Useful for cropping, loss masking, and segmentation baselines.
masks_depth/	{figure}_{id}_mask_depth.png	Binary masks in depth space indicating valid depth support (1 = valid depth, 0 = invalid/unknown). Aligned with depth_npy / depth_hifi.
pcd/	{figure}_{id}_pcd.ply, poses_metric.json	Per-view point clouds reconstructed from depth and intrinsics. PLY with XYZ (and optionally RGB) in millimetres, plus poses_metric.json storing camera-from-object poses and turntable geometry.

Fig. 2.

Per-modality sample for one object. Example view of the lucy figure from the apiCAM PRO sequence: (A) RGB frame (rgb/lucy_0_rgb.png); (B) dense depth map exported by the light-field camera pipeline and visualized with a depth colormap (depth/lucy_0_depth.png); (C) visualization of sparse / high-confidence depth samples on a black background (depth_sparse/lucy_0_depthSparse.png); (D) high-fidelity dense depth completion produced by the HiFi-DC model and visualized with the same type of colormap (depth_hifi_vis/lucy_0_depth_hifi_vis.png).

The RGB images in the rgb and rgb_bright subsets may exhibit blur due to the plenoptic (microlens-array) acquisition and RGB reconstruction, which trade effective spatial sampling for angular information used in depth estimation and are more sensitive to small defocus and exposure-related smoothing; the magnitude of this effect depends on the optical configuration and targeted depth range, so different optics (tuned for different working distances) can produce different perceived blur levels.

The view index {id} is a zero-based integer (0, 1, 2, …) following the physical turntable rotation, covering almost a full 360° sweep for each object.

3.1.1. Per-figure pose metadata

Inside each pcd/ directory (e.g., pro/lucy/pcd/ or cube/lucy/pcd/), a file named poses_metric.json stores the metric camera poses and turntable geometry:

Global fields:

• •``units'': string, set to ``mm'' for all geometric quantities.
• •``frame'': name of the object coordinate frame (e.g., ``object@turntable_icp'').
• •``method'': description of the pose–estimation procedure (e.g., ``turntable_icp_depthonly_locked_dir'').
• •``step_deg_prior'': nominal turntable step in degrees (e.g., 5.0).
• •``steps_median_used'': median effective step estimated from ICP refinement.
• •``coverage_signed_deg'', ``coverage_abs_deg'': angular coverage of the 360° sweep.
• •``global_dir'': sweep direction (``+'' or ``-'').
• •``axis_u_camera'': 3-element array with the unit rotation axis in camera coordinates.
• •``axis_point_c_mm_camera'': 3-element array giving a point on the turntable axis, in millimetres in the camera frame.

Per-view extrinsics:

• •``T_CO'': mapping from RGB filenames (e.g., ``lucy_0_rgb.png'') to 4 × 4 homogeneous matrices.
• •
  Each matrix is stored as a nested 4 × 4 list representing the rigid transform (camera-from-object):

  $$T_{C\leftarrow O}=\left[Rt01\right]$$
• •The same camera coordinate convention is used for PLY point clouds and for all depth values expressed in millimeters.

3.2. Camera calibration data

Calibration for the two light-field cameras is stored in separate folders:

• •calib_pro/ – apiCAM PRO calibration
• •calib_cube/ – apiCAM CUBE calibration

Each calibration folder has a common internal structure (Table 3).

Table 3.

Contents of calibration folders for apiCAM PRO and apiCAM CUBE.

Subfolder	Description
chessboard_images/	Raw or lightly processed calibration images of a planar checkerboard target, captured from multiple viewpoints. Filenames typically encode frame index or timestamp.
intrinsics/corners_montage.png	Montage image showing detected checkerboard corners across all calibration images.
intrinsics/rgb_optic.json	Camera intrinsic and distortion model. Includes fields such as ``model'' (``brown5''), ``width'', ``height'', ``fx'', ``fy'', ``cx'', ``cy'', radial/tangential distortion coefficients (``k1'', ``k2'', ``p1'', ``p2'', ``k3''), reprojection error (``rms_reproj_px''), calibration date, and camera serial number.
intrinsics/undistort_maps_optic.npz	NumPy archive containing precomputed undistortion maps (pixel-wise mapping from distorted to rectified image coordinates) compatible with OpenCV-style remapping.
intrinsics/undistorted_sample.png	Example undistorted RGB image obtained by applying the intrinsics and undistortion maps.

3.3. Revopoint Miraco structured-light data

The structured-light scans are stored under a separate root, for example:

• •revopoint/armadillo/
• •revopoint/asian_dragon/
• •revopoint/bunny/
• •revopoint/dragon/
• •revopoint/happy/
• •revopoint/lucy/
• •revopoint/thai_statue/

Each revopoint/{figure}/ directory contains per-view outputs derived from the original Revopoint Miraco capture (.dph, .img) and, when available, pose files from the vendor software. An example cross-sensor comparison between a light-field point cloud and a Revopoint point cloud for the same object is shown in Fig. 3.

Subfolder	Typical file pattern	Description
rgb/	{figure}_{idx:03d}.png	Color images associated with each depth frame, resized or cropped to match the depth resolution.
depth_npy/	{figure}_{idx:03d}_depth.npy	Dense depth maps as NumPy arrays (float32, H × W). Depth values are stored in millimetres, after rescaling from the original Revopoint units. Invalid/occluded pixels are set to zero or NaN.
depth_vis/	{figure}_{idx:03d}_depth_vis.png	Colorized depth visualizations using a fixed colormap and truncation range.
pcd/	{figure}_{idx:03d}_pcd.ply	Per-view point clouds reconstructed from depth_npy using a pinhole camera model with approximate intrinsics. Stored as PLY with XYZ (metres) and no color (or RGB if added).

Fig. 3.

Cross-sensor sample for one object. Example of the lucy figure from two sensor modalities, rendered from approximately the same viewpoint. (A) Single-view point cloud reconstructed from the apiCAM PRO light-field capture (pro/lucy/pcd/lucy_0_pcd.ply), with points expressed in millimetres in the camera frame. (B) Single-view point cloud reconstructed from the Revopoint Miraco structured-light scan (revopoint/lucy/pcd/lucy_009_pcd.ply), with points expressed in metres in the scanner frame.

In addition to the per-view files listed above, each revopoint/{figure}/pcd/ directory also contains fused reconstructions exported from the Revopoint software:

• •fuse.ply – a global fused point cloud / mesh of the whole object in the scanner frame (XYZ in metres, no color).
• •fuse_mesh_rgb.ply – a fused mesh with per-vertex RGB colors.
• •fuse_mesh_tex.ply and fuse_mesh_tex.jpg – a textured mesh and its corresponding texture atlas, suitable for textured-mesh rendering in standard 3D viewers.

These fused artefacts provide an additional high-density reference geometry for each object, complementary to the per-view RGB–depth frames.

3.4. Per-object statistics and sensor parameters

A summary of the number of views per object and modality is provided in Table 4. The main sensor resolutions and nominal depth accuracy for each device are reported in Table 5 for quick reference.

Table 4.

Per-object view statistics in the 3DLF-Scan dataset.

Figure	Number of LF views per camera (apiCAM PRO / apiCAM CUBE)	Number of Revopoint Miraco frames
armadillo	73 / 73	151
asian_dragon	73 / 73	103
bunny	73 / 73	92
dragon	73 / 73	95
happy	73 / 73	121
lucy	73 / 73	137
thai_statue	73 / 73	103

Note: 73 light-field views correspond to 72 nominal 5° steps plus one additional frame near 0° used for consistency checking.

Table 5.

Sensor resolutions and nominal depth accuracy.

Device	RGB resolution [pixels]	Depth resolution [pixels]	Nominal depth accuracy (manufacturer / reported)
apiCAM PRO (light-field)	1749 × 1155	1749 × 1155	Up to 0.64 mm
apiCAM CUBE (light-field)	1353 × 987	1353 × 987	Up to 0.85 mm
Revopoint Miraco (structured-light)	800 × 600	800 × 600	Up to 0.02 mm

3.5. File formats and value conventions

Across the dataset, the following conventions are used:

• •
  RGB images (*.png)

  • ○
    8-bit sRGB PNG, one file per view.
  • ○
    Dimensions follow the native resolution of each device; exact width and height are recorded in rgb_optic.json (for PRO/CUBE) or can be read from the PNG headers (for Revopoint).
• •
  Depth maps (*.png, *_depth.npy, *_depth_hifi.npy)

  • ○
    PNG depth maps are stored as grayscale images with high bit-depth (e.g., 16-bit); units follow the camera’s export format.
  • ○
    NumPy depth maps (*_depth.npy, *_depth_hifi.npy) use float32 arrays of shape H × W.
  • ○
    All NumPy depth values are expressed in millimetres, with invalid pixels encoded as 0 or NaN.
• •
  Point clouds (*.ply)

  • ○
    Stored in ASCII or binary PLY format depending on the generating script.
  • ○
    PRO/CUBE PLY point clouds (pro/*/pcd/*.ply, cube/*/pcd/*.ply) use XYZ coordinates in millimetres in the camera frame.
  • ○
    Revopoint PLY point clouds (revopoint/*/pcd/*.ply) use XYZ coordinates in metres in the camera frame.
• •
  Poses (poses_metric.json)

  • ○
    All translations and axis points are in millimetres.
  • ○
    4 × 4 matrices correspond to rigid transforms from object frame to camera frame.
  • ○
    Keys are image filenames, so each pose is traceable to the corresponding RGB/depth/PCD view.
• •
  Calibration (rgb_optic.json, undistort_maps_optic.npz)

  • ○
    Intrinsics are compatible with OpenCV (focal length in pixels, principal point in pixels, distortion coefficients for the Brown-Conrady model).
  • ○
    Undistortion maps are NumPy arrays suitable for OpenCV’s remap function or equivalent.

4. Experimental Design, Materials and Methods

4.1. Overview

The dataset combines two complementary acquisition pipelines applied to the same set of 3D-printed canonical objects [4,5] (Stanford bunny, dragon, asian_dragon, armadillo, happy, lucy, thai_statue):

• •Light-field pipeline using two photonicSENS cameras (apiCAM PRO and apiCAM CUBE) to obtain per-view RGB, raw/sparse depth, dense completed depth, and per-view metric point clouds with 4 × 4 camera-from-object poses.
• •Structured-light pipeline using a Revopoint 3D scanner to obtain additional RGB–depth sequences and point clouds in metric units (see the Revopoint acquisition subsection).

Both pipelines use the same physical turntable setup; view coverage and step size are described in the corresponding acquisition protocols. The acquisition setup and sensor hardware are shown in Fig. 4.

Fig. 4.

Acquisition setup and sensor hardware for 3DLF-Scan. (A-B) Light-field capture inside a small light tent: the object is centred on the motorised turntable while a photonicSENS light-field camera (apiCAM PRO or apiCAM CUBE) is rigidly mounted in front of the opening. (C) The two light-field cameras used in the dataset, apiCAM CUBE (left) and apiCAM PRO (right). (D) Structured-light capture with the Revopoint Miraco scanner facing the same turntable for 360° scans in stationary mode.

4.2. 3D-printed objects and physical setup

The canonical Stanford figures were 3D-printed on a Phrozen desktop resin printer using a durable RPG-grade photopolymer resin designed for tabletop miniatures. After printing, the models were cleaned and UV-cured according to the printer and resin manufacturer instructions. No paint, primer, or varnish was applied prior to scanning to preserve a uniform, slightly matte surface.

For all acquisitions:

• •Each model was placed on the same motorized turntable and approximately centered on the rotation axis by visual alignment.
• •The camera or scanner was rigidly mounted (tripod/stand) at a fixed distance and height relative to the turntable.
• •Background consisted of a uniform white light-tent interior (white backdrop and diffuser), providing consistent diffuse illumination and facilitating object segmentation.
• •Illumination was provided by diffuse room lighting and/or soft auxiliary lighting without strong specular highlights.
• •Viewpoint sampling and step size are described in the corresponding acquisition protocols.

The precise camera-to-object geometry for light-field sequences is encoded in the extrinsic matrices stored in pcd/poses_metric.json for each figure.

4.3. Light-field camera hardware (apiCAM PRO and apiCAM CUBE)

Two light-field cameras from photonicSENS were employed:

• •apiCAM PRO
• •apiCAM CUBE

Both devices internally capture a microlens-based light-field but expose a standard monocular RGB stream and an associated depth output through the vendor software/SDK. For the dataset, only the per-view RGB images and associated depth outputs are stored; low-level light-field processing internal to the devices is treated as a black box.

Each per-camera calibration folder (calib_pro/, calib_cube/) contains the intrinsics and distortion parameters actually used to unproject depth and to generate metric point clouds.

4.4. Light-field capture protocol

For each object and each camera (PRO and CUBE), the acquisition followed the same protocol:

• 1.The camera was rigidly mounted facing the turntable at a fixed working distance.
• 2.The turntable was driven in single-step mode.
• 3.
  At each step, the following were stored:

  • ○
    A monocular RGB frame: rgb/{figure}_{id}_rgb.png
  • ○
    A per-pixel depth output and auxiliary sparse depth (see below)
• 4.The sweep continued until the turntable completed essentially one full revolution (≈360°). The resulting pose/viewpoint coverage is illustrated in Fig. 5.
• 5.File indices {id} are zero-based integers (0, 1, 2, …) indicating turntable order.

Fig. 5.

Pose coverage.

All acquisitions for a given camera were performed without changing the camera’s pose or lens settings between objects.

Light-field camera calibration (intrinsics and undistortion)

Each light-field camera was calibrated separately using a printed planar chessboard:

• •Calibration datasets are stored under calib_pro/ and calib_cube/.
• •
  Each calibration folder contains:

  • ○
    chessboard_images/ — raw calibration images of the chessboard at multiple distances and orientations.
  • ○
    intrinsics/rgb_optic.json — calibration result with fields:

    • •
      model: ``brown5” (5-parameter Brown distortion model)
    • •
      width, height: calibrated image resolution
    • •
      fx, fy: focal lengths in pixels
    • •
      cx, cy: principal point in pixels
    • •
      distortion: coefficients k1, k2, p1, p2, k3
    • •
      rms_reproj_px: reprojection error in pixels
    • •
      calib_date, serial, notes
    • ○
      intrinsics/undistort_maps_optic.npz — precomputed OpenCV-style undistortion maps for efficient rectification.
    • ○
      intrinsics/corners_montage.png — visual montage of detected chessboard corners for quality control.
    • ○
      intrinsics/undistorted_sample.png — example undistorted calibration image.

Calibrations were performed with standard OpenCV routines using multiple chessboard poses at the working distance range used in the object scans. For all downstream processing (depth completion, point-cloud generation), RGB frames were undistorted using undistort_maps_optic.npz and the corresponding intrinsics file for the relevant camera.

4.5. Per-view depth outputs from the light-field pipeline

For each figure project, the manufacturer’s light-field processing pipeline was used to export:

• •
  A dense depth map in PNG format:

  • ○
    depth/{figure}_{id}_depth.png
• •
  A sparse depth visualization in PNG format:

  • ○
    depth_sparse/{figure}_{id}_depthSparse.png
• •
  A numerical sparse depth map in NumPy format (float32):

  • ○
    depth_npy/{figure}_{id}_depth.npy

Depth values are provided according to the dataset’s conventions described in File formats and value conventions. Metric depth is stored in depth_npy/ as float32 arrays (invalid pixels encoded as 0 or NaN), while the PNG files in depth/ and depth_sparse/ are vendor-exported representations intended primarily for visualization and inspection.

No additional filtering beyond the vendor’s internal processing was applied at this stage; the only operations were format conversion and, where needed, scaling to millimetres to match the coordinate frame used in pcd/.

4.6. Metric point-cloud reconstruction and turntable pose estimation

To express all views in a common object-centric frame, a turntable-constrained ICP procedure was applied:

• •An initial pose for frame k was defined as a pure rotation of angle k · 5° around an unknown turntable axis passing through an approximate object centre.
• •The turntable axis direction axis_u_camera and a point on the axis axis_point_c_mm_camera (in camera coordinates, mm) were estimated from the raw per-view point clouds using circle-fitting methods.
• •For each frame, the initial rotation around this axis was refined using depth-only ICP under a single-axis constraint.
• •The result is a 4 × 4 camera-from-object transform $T_{CO}$ per view.

Using $T_{CO}$, the 3D points expressed in camera frame can be transformed into the object frame, and vice versa. For convenience, a fused object-space point cloud is provided per figure:

• •pcd/{figure}_{id}_pcd.ply

These .ply files are stored in millimetres and were generated with Open3D or equivalent point-cloud libraries.

4.7. High-fidelity depth completion pipeline

High-fidelity depth maps were generated using HiFi-DC (High-Fidelity Depth Completion), a custom diffusion-based depth completion pipeline developed by the authors, based on Marigold-DC [6], with an additional surface-normal consistency regularization term. HiFi-DC outputs are provided as an additional representation for convenience alongside the raw sparse and dense depth data.

For the dataset:

• •A fixed inference configuration (number of diffusion steps, noise schedule, resolution) was used for all views and all objects.
• •
  Outputs are stored as single-channel float32 depth maps in millimetres:

  • ○
    depth_hifi/{figure}_{id}_depth_hifi.npy
• •
  For visual inspection, each dense depth map was converted to a colour heatmap with a depth-to-colour mapping consistent within each object and saved as:

  • ○
    depth_hifi_vis/{figure}_{id}_depth_hifi_vis.png

No additional post-processing (e.g., bilateral smoothing, mesh fitting, TSDF fusion) was applied to the depth_hifi maps; they are the raw HiFi-DC predictions at the exported resolution. A separate companion article will provide the full technical details of the HiFi-DC architecture and training procedure; this section only specifies the aspects needed to interpret the dataset.

4.8. Revopoint structured-light acquisition

In addition to the light-field captures, each printed object was acquired with a Revopoint structured-light 3D scanner:

• 1.The scanner was fixed on a stand, facing the same motorized turntable used for the light-field pipeline.
• 2.The object was placed at the manufacturer-recommended working distance.
• 3.The Revopoint software was run in a stationary scan mode with the turntable executing a full 360° rotation.
• 4.
  The resulting project was exported, and the internal cache folder was collected:

  • ○
    data/{figure}/cache/

Within each cache/ folder, the Revopoint software stores per-frame files:

• •frame_***_****.dph — raw depth data (binary).
• •frame_***_****.img — colour image, either as an encoded PNG/JPEG or raw RGB.

File names follow the Revopoint internal convention; the dataset provides them as exported by the software.

4.9. Conversion of Revopoint cache to RGB, depth, and point clouds

To integrate the Revopoint data into the dataset in a consistent format, a custom conversion script was used (Python, NumPy, PIL, and Open3D). For each object:

• 1.The script scans data/{figure}/cache/ for all frame_*_*.dph files and sorts them by name to obtain a frame order.
• 2.For each frame, the associated .img and .inf are located via the shared base name.
• 3.
  Image and depth dimensions are inferred from file sizes:

  • ○
    depth frames are treated as uint16 with shape (H, W);
  • ○
    RGB frames are treated either as encoded images (PNG/JPEG signature) or as raw uint8 buffers reshaped into (H, W, C).
• 4.
  If an .img file is encoded:

  • ○
    It is decoded with Pillow (PIL.Image) and converted to 3-channel RGB.
  • ○
    If its resolution differs from the depth map, it is resized to match (W, H) using bilinear interpolation.
• 5.The raw depth values in .dph are loaded as uint16 and converted to millimetres.
• 6.
  The following outputs are saved under revopoint/{figure}/:

  • ○
    rgb/{figure}_{k:03d}.png — per-frame RGB image.
  • ○
    depth_npy/{figure}_{k:03d}_depth.npy — float32 depth map in millimetres (scale factor 0.1 applied, no _mm suffix in the filename).
  • ○
    depth_vis/{figure}_{k:03d}_depth_vis.png — colourized visualization of the depth map, using a fixed colormap and percentile-based clipping.
• 7.For optional point-cloud export, a simple pinhole model is used.

4.10. Software stack and reproducibility

All conversions and derived products were generated with:

• •Python 3.x
• •NumPy for numerical operations and depth handling.
• •OpenCV for camera calibration, undistortion maps, and basic image operations.
• •Pillow (PIL) for image loading, decoding, and saving.
• •Open3D (or equivalent library) for point-cloud construction and PLY export.

The repository accompanying the dataset includes the calibration JSON files, undistortion maps, and all derived products described above.

Limitations

The dataset focuses on seven canonical Stanford Figs. 3D-printed at a single scale in a uniform, dark, slightly matte resin and acquired on a tabletop turntable under controlled, diffuse lighting with a homogeneous background. Consequently, variability in material properties, object scale, background complexity, and illumination is limited. This may restrict generalizability for methods targeting more diverse conditions (e.g., glossy/specular or transparent surfaces, strong shadows and highlights, cluttered backgrounds, or large photometric variation), and performance measured on this dataset may overestimate robustness in unconstrained environments. No dynamic scenes, articulated motion, or cluttered interactive settings are included.

For the light-field cameras, only the vendor-exposed RGB and depth values are available; raw microlens data and internal processing parameters are not provided. Sparse and dense depth maps may contain noise, holes, or failures around thin structures and self-occlusions. HiFi-DC dense depth maps are generated by a single completion model and may inherit any systematic biases of that model. For generalization studies, users are encouraged to consider the provided raw sparse/dense depth outputs in addition to the completed HiFi-DC maps.

Turntable poses obtained via constrained ICP are accurate but not exact ground truth; small residual errors, slight axis misalignment, or off-centre object placement may remain. For Revopoint scans, depth accuracy and intrinsics follow vendor specifications and simple conversion scripts, without independent metrology.

Ethics Statement

The authors have read and follow the ethical requirements for publication in Data in Brief. The current work does not involve human subjects, animal experiments, or any data collected from social media platforms.

CRediT Author Statement

Bohdan Vodianyk: Conceptualization; Methodology; Software; Validation; Formal analysis; Investigation; Data curation; Visualization; Writing – original draft; Writing – review & editing. Anton Popov: Conceptualization; Methodology; Validation; Supervision; Writing – review & editing. Enrique Nava-Baro: Resources; Supervision; Project administration; Funding acquisition; Writing – review & editing.

Data Availability

• Mendeley Data3DLF-Scan dataset: multi-sensor 3D light-field and structured-light scans of 3D-printed Stanford figures (Original data).