One capture.
Digital
intelligence.

Inside the P3D package

P3D is a packaged digital asset: captured appearance, media and machine-readable context stay together. The archive-style structure uses a manifest to describe the product and link its visual, textual and optional spatial layers. A consumer opens one asset and extracts the information needed for its task.

What is included

A concrete package example

The supplied image-stack export contains manifest.json and 360 PNG files under images/. Richer exports add the applicable media and spatial payloads. A package’s manifest is the guide to its actual content.

Use cases: one asset, multiple possibilities

These uses share a common requirement: preserve appearance and meaning together. Free navigation, relighting, physics and geometric interaction are separate rendering or modeling requirements; a view-based asset supplies captured viewpoints and can feed a richer reconstruction workflow when required.

File compression and AI-ready delivery

The product family offers four size profiles: Ultra 200 MB, High 80 MB, Medium 40 MB and Lite 4 MB. They provide a 50-fold range in delivered file size, allowing a rich source asset and compact distribution copies to serve different deployment needs.

Where the efficiency comes from

Image-led assets avoid making dense geometry part of every distribution copy. Resolution, frame count, encoding and included data layers determine the payload. The media is already encoded before archive packaging, so most of the space saving comes from the representation and profile choices rather than repeatedly ZIP-compressing an image.

¹ Decimal units. Storage totals equal nominal file size × 10,000 and exclude replicas, backups and indexes. Lower-resolution profiles do not imply unchanged pixel detail or identical spatial payloads. The reported 4K capability belongs to high-definition capture and appropriate exports, not automatically to every 4 MB file.

Why compact, structured assets help AI workflows

Compact deployment copies reduce the bytes moved and stored for those copies. The manifest keeps the product identity connected to extracted views and textual attributes. AI pipelines can ingest the relevant images and fields rather than first generating and rendering a dense model for an image-based task.

Turnaround time and output options

The automated scanning workflow captures a product with repeatable viewpoints and a controlled sequence. Capture runs from as low as 1 minute to about 7 minutes for a detailed scan, with an average of approximately 6 minutes. Processing takes 7 minutes. These timings replace the earlier 10-minute processing figure.

A shorter capture cycle

Against the 10–20-minute conventional capture reference used by the product team, the 6-minute average is 40–70% shorter, or 1.67–3.33× the capture throughput before processing and handling. This comparison describes that capture reference; it is not a universal timing claim for every scanning system.

Why the processing path is shorter

P3D’s core delivery asset is an indexed image and media representation. Preparing it does not require a complete dense point cloud, watertight mesh, retopology or baked texture atlas. The processing effort is directed toward usable visual frames, indexing, associated information and packaging. Optional depth and sparse spatial data enrich the asset without making dense reconstruction mandatory.

Resolution, profiles and file types

P3D supports 4K high-definition capture for detailed appearance. The distribution profile selects an appropriate payload footprint. The reference export supplied for this paper contains 1080 × 608 PNG frames, and its resolution metadata records 1080; the embedded pixels establish the actual resolution of that sample.

Container versus extracted outputs

The P3D file is the source package. A consuming tool may extract images, transcode sequences to a video, build a dataset record or pass optional spatial information to another application. JPEG/WebP previews, rendered video and reconstructed 3D derivatives are downstream outputs; their availability depends on the exporter or application, not solely on the .p3d extension.

From visual files to digital training records

P3D’s contribution to digital training is the association of evidence: what an object looks like, what it is, what is written on it and how its views relate. A dataset pipeline can extract imagery and structured fields from one object-level record instead of reconciling independently named files and spreadsheets.

Why the architecture changes dataset production

The reusable unit becomes an object with its evidence, rather than a single anonymous image. Additional tasks start from the same captured record: extraction, indexing, annotation and augmentation can preserve the product identity throughout. This reduces repeated source-data assembly and makes provenance easier to carry into downstream datasets.

Multiple views remain observations of the same object. Dataset splits must preserve object identity to avoid training/test leakage. Model accuracy, convergence time and the number of training examples required are properties of a specific experiment, not automatic consequences of the container.

One source for GenAI and content production

P3D turns a scan into a reusable content source. High-definition product views preserve real details; metadata and text provide factual context; optional masks and spatial fields provide additional conditioning. Marketing and creative teams can start successive outputs from the same asset instead of arranging a new shoot for each format.

Capture once; distribute the work

The production gain is the reuse of captured evidence, not a claim that every generated result is automatically correct. Product identity, geometry, branding and visible text still require output review. Photographed reference views improve the input supplied to a generation system; they do not by themselves guarantee a physically accurate generated scene.

Compute the representation the task needs

For product presentation and image-based AI, a dense 3D reconstruction is often an intermediate expense rather than the required output. P3D preserves the captured surface appearance and associated context in 2.5D. It moves dense geometric work off the critical path for tasks that consume images, sequences and product information.

4K appearance and spatial detail are different properties

4K capture preserves fine visual details such as print, finish, color boundaries, texture appearance and visible surface relief. In an image-led asset, this appearance is already photographed rather than recreated by material authoring. A 4K image is not itself a 4K depth map or a measured topographic model. Metric size, depth precision and surface accuracy depend on the optional spatial layer, camera calibration and capture geometry.

Sparse spatial data gives selected geometric anchors while keeping the mandatory asset lightweight. Full model training, reconstruction or complex inference still has its own compute requirements; the efficiency benefit is avoiding that work for every basic viewing or content task.

A product digital twin with visual and factual context

For catalog and product-information workflows, P3D serves as the visual and contextual digital counterpart of a physical item. It links the product’s appearance to identity, descriptions, specifications and capture information. Optional sparse geometry adds a spatial layer for future enrichment.

A catalog digital twin is an appearance-and-information record. Engineering simulation, live operational synchronization and certified measurement need additional validated models, measurements or system connections.

Keep a lightweight spatial foundation

P3D supports an optional sparse point-cloud layer and associated camera-angle information. This retains selected information about shape, scale, surface structure and depth for later spatial processing. The core 2.5D viewing workflow stays usable without reconstructing every surface into a dense 3D model.

The lightweight benefit comes from carrying a selective spatial representation and invoking further processing only when needed. Rich images remain available for future algorithms while the asset avoids the mandatory storage and preparation of a complete dense model.

A capture architecture beyond the dedicated scanner

The automated scanner provides repeatable capture and reduces the amount of manual viewpoint planning required from an operator. A technician follows the capture workflow rather than building a 3D model, repairing topology or authoring materials. Product placement, lighting and visual quality checks remain practical operator responsibilities.

The image-based architecture also extends to sources such as mobile phones, conventional cameras, video cameras and extracted video feeds. A dedicated station emphasizes consistency and automation; field sources emphasize availability and coverage. They feed the same general pattern: prepare usable imagery, associate context and package a reusable record.

The 1–7-minute scan range and 7-minute processing figure describe the product scanning workflow. Capture conditions, missing viewpoints and sensor-specific preparation determine the workflow for other sources.

Earth observation: a spatial intelligence extension

Connect what a scene looks like, where it is and what its sensors measure. A proposed Earth-observation extension would associate high-resolution drone imagery with satellite observations, hyperspectral bands, depth and field-sensor readings. The aim is one traceable observation record for extraction, analysis and AI model training across locations, viewing angles and acquisition conditions.

Fuse drone imagery with sensor evidence

Drone RGB imagery supplies fine visual detail and overlapping views. Hyperspectral observations add wavelength-dependent measurements; thermal cameras, LiDAR/depth sensors, GNSS/IMU telemetry and time-stamped field sensors add complementary evidence. Align these inputs by location, capture time and viewing geometry before extracting object boundaries, surface features, elevation, material signatures or change indicators. Which outputs are reliable depends on sensor calibration and validation for the task.

Normalize the view, spectrum and location

Standardization must address three different sources of variation. Viewing frame: correct lens distortion, orthorectify against terrain where needed and record camera pose, field of view and sun–sensor angles. Spectrum: calibrate sensor values to comparable physical units, document wavelengths and band responses, and apply illumination or atmospheric corrections appropriate to the acquisition. Localization: co-register observations to a defined coordinate system, elevation datum, time window and spatial grid.

Hyperspectral measurements can support spectral interpretation and consistent optical products, while geometric correction controls viewpoint and localization. These are complementary operations: adding spectral bands alone does not normalize camera geometry. Preserve native measurements, correction parameters and quality flags alongside every display or analysis derivative. See USGS UAS calibration guidance.

Convert high-resolution observations into usable data

Create georeferenced image tiles, orthomosaics, aligned spectral patches and extracted feature layers at the resolution required by the task. High-resolution RGB can supply spatial detail while spectral measurements supply additional channels, with each layer’s native resolution recorded. Any learned super-resolution or cross-sensor sharpening must be labeled as a derived estimate and checked against independent reference data; resampling alone does not create measured detail.

Standardize many variables for AI model training

Large datasets vary across sensors, sites, seasons, altitude, illumination and viewing angle. A shared schema would record these independent variables explicitly and create consistent image–sensor–label samples. Use a fixed channel order, documented band mapping and units, consistent patch footprints, acquisition timestamps, missing-data masks, label versions and processing lineage. Fit statistical scaling on the training split and reuse those parameters for validation and testing. Split by location, flight or time where appropriate to reduce leakage from neighboring or overlapping observations.

The proposed package would carry selected training-ready derivatives and references to native scientific assets, rather than forcing all sensor measurements into an RGB image. This supports multimodal model inputs while keeping sensor differences and uncertainty visible. Standardization prepares data for training; model accuracy still requires task-specific evaluation.

Preserve scientific assets and distribute what is needed

GeoTIFF and Cloud Optimized GeoTIFF can retain georeferenced raster assets; STAC can catalog related observations. Spectral band definitions, viewing geometry and asset identifiers should remain interoperable with those standards. The STAC Electro-Optical extension documents band metadata and recommends recording instrument and viewing context.^{4, 5, 6}

Processing near a drone or ground station can prioritize regions, previews or extracted features for sharing while retaining access to full-resolution originals. Storage and transmission savings depend on that selection policy and the actual payloads. This is a proposed P3D application architecture; the supplied product sample demonstrates the product-imagery package, not a validated geospatial fusion or AI-training system.

Viewing options and deployment

Interaction follows the captured view envelope. Horizontal and vertical view coverage determines available angles; frame interpolation is a viewer/processing capability, not a substitute for observing missing surfaces. The supplied comparison sample has 36 horizontal indices and 10 vertical indices. Its preview supports selection across the full 360-view grid; these are indexed views, not a claim of calibrated camera poses.

Separate portable data from the rendering layer

P3D stores the representation and relationships. A viewer decides how to decode, cache and present those views; an AI pipeline decides how to extract and transform them. This lets the same source asset support different applications without requiring every consumer to render a full 3D model.

More catalog value.
Less reconstruction work.

P3D is designed around what a catalog team needs next: product views, interactive presentation, factual context and reusable content inputs. Its advantage is a shorter path from capture to those outputs, while a geometric model remains useful when the brief needs free viewpoints, relighting, AR or measurement.

Reading the numbers: Measured = inspected supplied file. Specification = owner-reported workflow. Published benchmark = another dataset and system. Calculated scenario = explicit inputs, not a measured speedup. File formats do not prescribe scanning times or production prices.

01 / Compare the complete product-content asset

Compare the full handover: the PDP image source, video exports, interactive representation, product information and retained originals. A mesh-only figure is just one component of a textured 3D workflow.

P3D and loose-image figures below are measured from the same supplied product. For other exports, T means the actual encoded texture-file total, V the actual video-file total and R the retained camera-RAW archive. These totals are recorded at export rather than inferred from a file extension.

The P3D total already includes its PNG views and manifest; do not add those components to it again. Videos, published PDP selections, RAW masters and geometric derivatives are counted only when separately exported or retained. A visual catalog twin and a geometric model provide different interaction capabilities.

02 / Capture time and processing are separate budgets

The specified 6-minute capture is 40–70% shorter than the owner’s conventional 10–20-minute capture reference. This is a capture-only comparison. Setup, handling, content generation, review and publication sit outside the 13-minute source cycle.

These published results show where reconstruction compute is spent. They use different datasets, outputs and hardware from P3D; no cross-method speedup percentage is inferred from them.

03 / What is actually in the supplied file?

360 product views, structured product information and a reusable view index — together in one 54.44 MB P3D. The file is an organised source for PDP images, interactive product exploration, visual digital twins and later content production.

Product metadata sections

The manifest provides the following product-information sections. Cataloging completes the relevant fields for each product and keeps that information associated with its views.

3D file-size budgets: compare the complete asset

4.40 MB is the example mesh geometry only — not a complete high-detail product asset. Textures supply surface appearance; retained product photographs supply the source for later content. Those files, their processing and any video exports belong in the total.

A low-polygon mesh can use high-resolution textures; polygon count and texture resolution are separate choices. A simple mesh does not automatically contain detailed product imagery. High-detail appearance requires sufficient image/texture data, coverage and preparation. UV mapping, baking, cleanup and delivery optimization contribute processing time; modern compression changes the final encoded size.^{[3], [10]}

The mesh ledger is a transparent component example, not a measured competing export. T, V and R are filled from actual delivered files; no arbitrary texture, video or RAW size is presented as a benchmark. Shared source files are counted once. Meshes also add geometric functionality beyond P3D’s captured-view presentation.

04 / Keep one reusable product source

A retained P3D keeps the product’s views and information together for later catalog updates, image selection, interactive presentation and content generation. For this supplied asset, one product source is 54.44 MB; 1,000 equivalent sources would occupy 54.44 GB before backup copies and separately saved outputs.

05 / Zoom quality is a sampling budget

Older, simplified 3D exports may blur on zoom because of low-resolution textures, sparse geometry, poor UV allocation or incomplete capture. Age or file extension alone does not determine detail. A 2048² texture has 4.19 million texels shared over the mapped surface; a 4096² texture has 16.78 million. Neither number is directly equivalent to a photographed view’s pixel count.

Modern glTF supports detailed PBR assets and compressed KTX2 textures; compression can reduce transfer size and GPU memory. P3D retains the photographed finish at captured viewpoints, but zoom cannot recover pixels absent from its embedded images. Its 4K capability is separate from this 1080 × 608 sample.^[10]

06 / Rendering libraries and compute requirements

07 / Quantify your own time and cost

Use your current workflow as the baseline. The defaults below are a planning scenario, not research measurements, service prices or a guaranteed saving. Both routes charge the same hourly rates; every capture/processing minute is assumed attended. Processing compute is billed as one machine at the entered hourly rate, not as measured GPU utilization.

08 / Where P3D makes the strongest case

A matched comparison should scan the same products, hold visible detail and output requirements constant, log active operator time and wall time separately, and record machine model, peak RAM/VRAM, GPU time, kWh, retained bytes and quality. No such cross-format trial was supplied; universal cost, compute or quality superiority is not asserted.

Closing: capture once, build digital intelligence

P3D’s efficiency comes from choosing an image-led representation for the many tasks that need appearance and context, then retaining optional spatial information for tasks that need more. The product is captured once, its evidence stays connected to its identity, and downstream workflows extract the information they use.

For commerce, the same record supplies catalog and interactive product content. For AI, it organizes visual and textual inputs around an object. For inspection, archives and immersive media, it preserves an inspectable source. The proposed Earth-observation extension applies that packaging principle to related sensor data and spatial derivatives.

Evidence, calculations and references

This edition presents HyperD / Perfit / Is Going Online product specifications and architecture as supplied by the product owner on 21 October 2026: 1–7-minute capture range, approximately 6-minute average capture, 7-minute processing, 4K capture capability, four nominal MB profiles, metadata/text/media packaging and optional sparse spatial data. It is a technical product white paper, not an independent certification or a controlled cross-vendor benchmark.

Arithmetic in the graphics: average sequential source TAT = 6 + 7 = 13 minutes; detailed TAT = 7 + 7 = 14 minutes; Lite size reduction = (200 − 4) / 200 = 98%; Ultra-to-Lite size ratio = 200 / 4 = 50:1. Capture comparison = (reference − 6) / reference for the owner’s 10–20-minute reference. No measured AI accuracy gain, GPU-energy saving, sales uplift or universal end-to-end content speedup is claimed.

The satellite section describes a proposed extension and its technical requirements. The comparison source IGO_2026_0675_017_P3D_001.p3d was inspected directly and remains unchanged. It is a 54,436,585-byte high-size example with 360 PNGs at 1080 × 608 and a 14,088-byte manifest (2,212 bytes stored). The 4,164,696-byte web preview is a resized, lossy derivative, not an official size profile or equal-quality benchmark. Product-size profiles are nominal values, not maximum-size guarantees. Pixel resolution, geometry accuracy and scientific measurement fidelity are separate properties.

Comparison research · checked 22 October 2026

The comparison keeps independent file measurements, owner timings, historical published benchmarks and editable cost assumptions separate. P3D sample metadata audit: 67 top-level product-attribute keys, 4 non-empty values; text-dump links do not count as embedded media. Pixel-memory calculations use RGBA8 and exclude runtime overhead. Storage uses decimal GB; decoded memory uses binary MiB/GiB. No cross-format product quality score or GPU energy measurement is available.