Know your data

FelixRohrbach

Have you ever struggled to get reliable results from your Reality Mapping projects? In many of the support cases we see, the root cause is not the imagery itself but how the data was added to the project. Often it comes down to a misinterpreted sensor parameter or incorrect orientation information set when the camera session was created. When that happens, Reality Studio cannot find enough matches between overlapping images, and processing fails or produces distorted results.

In Reality Studio, data is organized into capture sessions. A capture session represents the data collected during a single acquisition, such as a flight, and can include imagery from one or more cameras together with sensor data such as lidar. When set up correctly, this structure allows Reality Studio to interpret how the data was captured and to turn it into high-quality mapping results. Validating your input before you start any time-intense processing is an essential step, because a wrong sensor definition typically causes gaps, artefacts or distortions in your Reality products.

The following sections describe practical checks you can use to confirm that a camera session's initial geometry is plausible before you continue processing.

What is a camera session?

A camera session describes the initial geometry for a set of images collected with a single physical camera within a capture session. It combines the image files, the camera's position and orientation (exterior orientation), and a camera definition that models the optics of the sensor.

Each camera session relies on the following inputs:

Images: The image files captured by the camera system. They must be accessible on disk and correctly referenced.
Exterior orientation data: The camera positions and rotations for each image, typically read from image metadata or supplied through an orientation file. These values are usually logged by a GNSS/INS system.
Camera calibration: The interior parameters that model the camera sensor and lens. This information is normally available in the calibration report.
Coordinate system: The horizontal and vertical spatial reference of the orientation data.
Axis conventions: The rotation convention and angular units used to interpret the orientation values.

Together, these inputs define where each image was captured, the direction the camera was facing, and how a point in the real world is projected onto the camera sensor. Reality Studio uses this information as the starting point for alignment and reconstruction.

Many configuration errors come down to a mismatch between what Reality Studio expects and what the data represents. If you are working with imagery captured by large-format frame sensors, the data typically has gone through a separate post-processing workflow provided by the camera vendor. These workflows allow to set output specifications, which are important to be considered when creating your capture session.

A few points are worth confirming up front:

Obtain the calibration certificate for the cameras used. Do not rely on marketing brochures or assume parameters based on the sensor model. Many sensors have variants with different configurations, and only the certificate reflects the actual geometry of the unit that captured your data.

Know the distortion state of your imagery. Some manufacturers correct lens distortion during pre-processing and deliver distortion-free images. Others leave it in, in which case you need the distortion parameters for a distortion model supported by Reality Studio.

Check for post-processing steps that affect orientation. Some operations modify the imagery without updating the exterior orientation. A common example is rotating images to "horizon-up", where EO angles must be corrected manually to match the new image orientation.

When in doubt, ask the data provider for the calibration protocol and a description of any post-processing applied.

Validation Checks

Use the checks below to confirm that your camera session was created correctly. If you find problems, troubleshoot with a small subset of images first. Smaller test sessions make it easier to isolate settings issues and verify fixes quickly.

Camera Position in Globe View

For the camera session you just created, visualize the camera frustums from the project tree and check the following:

Do cameras appear in the correct geographic location?
Does the spatial distribution match the capture pattern?
Do the frustums of the cameras point in the expected direction?
Does the orientation of the frustum (long side vs short side) fit the orientation of the camera?

Common issues to look out for:

Cameras are far above or below the terrain, or they appear in the wrong location. This usually points to an incorrect vertical coordinate reference system.
Cameras point upward or sideways, or the flight pattern looks mirrored or rotated. This usually points to the incorrect selection of exterior orientation attributes or a wrong selection of rotation convention.

Image Footprints

After you confirm camera positions, review the image footprints. Footprints show the ground area covered by each image. Turn on footprint visibility in the project tree, then check the following:

Do the footprints cover the area intended to be captured with this flight?
Is the overlap between images (both along and across flight direction) reasonable?
Is the orientation of the footprints on ground as expected from the camera configuration?
Does the image content shown in the camera session inspector make sense for the area of the highlighted footprint?

Tip: Select an image in the camera session inspector to highlight its footprint on the globe.

Common sources of errors can be:

Footprints are much smaller or larger than expected. This can indicate incorrect camera parameters (for example focal length or sensor size) or a coordinate system mismatch.
Footprints are flipped or rotated. This can indicate a problem with axis orientation, rotation order, or angular units.
If footprints are flipped/rotated: check the fields of the exterior orientation used and ensure that units are set correctly.

Example: Inappropriate camera setup can lead to unexpectedly large footprints of individual images. As a result an image will overlap with more following frames than anticipated. After correcting the parameter, the footprints show an image overlap as expected from the flight planning parameter.

Incorrect footprint extentCorrect footprint extent

Example: In a typical nadir camera configuration, the orientation of the camera has a larger extent across flight direction. Visualizing footprints allows to verify the correct definition of camera orientation parameter.

Incorrect camera orientationCorrect camera orientation

Dynamic Ortho

Camera positions and footprints confirm coverage and viewing direction. A dynamic ortho adds another check by projecting each image onto a reference surface, so you can verify that pixels land in the right place.

You can compute a dynamic ortho for the full camera session, or create a dedicated capture session to start with a smaller subset to get faster feedback while you troubleshoot.

Once the dynamic ortho is available, you can visualize it and verify the following points:

Do adjacent images roughly line up with each other? Minor offsets can be normal before alignment.
Do recognizable features, such as roads or rivers, match the basemap well enough to confirm the overall location?
Do you see distortion that cannot be explained by terrain relief?

If footprints look reasonable but the projected imagery does not align, the issue is often in the camera definition rather than the exterior orientation.

Confirm that the image coordinate axis definition matches the camera and metadata conventions.
Review distortion parameters. If needed, temporarily disable them to understand their impact.

Example: An incorrect camera setup will also show itself in the dynamic ortho. When visualizing the ortho on the globe, it becomes apparent that features do not line up with the background map in Reality Studio.

Features do not align with the background mapFeatures align with the background map

Example: Similarly a dynamic ortho will reveal misoriented repeating pattern if the camera orientation has been defined wrongly. Choosing the correct orientation will ensure a well-aligned result in the dynamic ortho.

Incorrect camera orientationCorrect camera orientation

Example: The dynamic ortho can also help to identify smaller misalignment issues. In this example a staggering effect can be noted in the imagery along the edges of a footprint. This indicates a mismatch of orientation angle units. After selecting the correct option, the staggering effect disappears and image content aligns nicely.

Dynamic ortho with staggering effectWell aligned dynamic ortho

Summary

These validation checks help you confirm three things: the camera positions are correct (frustums), the viewing geometry is plausible (footprints), and image pixels project to the right location (dynamic ortho).

Once the session looks plausible, you can continue with your Reality mapping workflow. At this stage, images do not need to be perfectly aligned. They need to be close enough for Reality Studio to find matches between overlapping images. Alignment then refines camera geometry and supports accurate 3D reconstruction.

Stay connected

To learn more about Reality Studio, you can visit our product page, check the resources, or the technical documentation.

If you have any questions or ideas, we’d love to hear from you! Visit the Esri Community page and let us know what you think.

If you’re interested in any of our Reality solutions, please check out our webpage and contact us for more information.