The Ocean Geometry Library provides geometry functionalities e.g., projective algorithms, optimization approaches or support for advanced transformations. More...

Data Structures
class	Ocean::Geometry::AbsoluteTransformation
	This class provides functions determining the absolute transformation between two point sets. More...

class	Ocean::Geometry::CameraCalibration
	This class implements functions to calibrate a camera, to determine the profile of a camera. More...

class	Ocean::Geometry::Delaunay
	This class implements Delaunay triangulation functions. More...

class	Ocean::Geometry::EpipolarGeometry
	This class implements epipolar geometry functions. More...

class	Ocean::Geometry::Error
	This class implements to functions to determine the error or accuracy of geometric functions and their parameter. More...

class	Ocean::Geometry::Estimator
	This class implements robust estimator functions. More...

class	Ocean::Geometry::Grid
	This class implements the basic data of an planar grid. More...

class	Ocean::Geometry::Homography
	This class implements functions necessary for computations with homographies. More...

class	Ocean::Geometry::Jacobian
	This class implements function to calculate the jacobian matrices for geometry functions. More...

class	Ocean::Geometry::JLinkage
	This class implements several J-linkage functions for pose/homography determination. More...

class	Ocean::Geometry::TLinkage
	This class implements L-linkage functions for pose/homography determination. More...

class	Ocean::Geometry::MultipleViewGeometry
	This class implements epipolar geometry functions for multiple views. More...

class	Ocean::Geometry::AutoCalibration
	This class implements self-calibration for multiple views. More...

class	Ocean::Geometry::NonLinearOptimization
	This class implements the basic functions for least square or robust optimization algorithms for non linear functions. More...

class	Ocean::Geometry::NonLinearOptimizationCamera
	This class implements least square or robust optimization algorithms for camera profiles. More...

class	Ocean::Geometry::NonLinearOptimizationHomography
	This class implements non linear optimization algorithms for homographies. More...

class	Ocean::Geometry::NonLinearOptimizationLine
	This class implements least square or robust optimization algorithms optimizing lines. More...

class	Ocean::Geometry::NonLinearOptimizationObjectPoint
	This class implements least square or robust optimization algorithms optimizing the locations of 3D object points (sometimes in combination with e.g., 3-DOF camera orientations or 6-DOF camera poses). More...

class	Ocean::Geometry::NonLinearOptimizationOrientation
	This class implements least square or robust optimization algorithms for orientations. More...

class	Ocean::Geometry::NonLinearOptimizationPlane
	This class implements least square or robust optimization algorithms for 3D planes. More...

class	Ocean::Geometry::NonLinearOptimizationPose
	This class implements non linear optimization algorithms for camera poses. More...

class	Ocean::Geometry::NonLinearOptimizationTransformation
	This class implements non linear optimization algorithms for coordinate transformations. More...

class	Ocean::Geometry::NonLinearUniversalOptimizationDense< tModelSize, tResultDimension, tExternalModelSize >
	This class implements an optimization for universal dense problems with one model (optimization problem). More...

class	Ocean::Geometry::NonLinearUniversalOptimizationSparse
	This class implements optimizations for universal sparse problems. More...

class	Ocean::Geometry::Normalization
	This class implements functions to normalize geometric data. More...

class	Ocean::Geometry::OctreeT< T >
	Forward declaration. More...

class	Ocean::Geometry::P3P
	This class provides functions determining the camera's pose by a set of three 3D object and 2D image point correspondences. More...

class	Ocean::Geometry::P4P
	This class provides functions determining the camera's pose by a set of four 3D object and 2D image points. More...

class	Ocean::Geometry::PerspectivePose
	This class is the base class for all perspective pose classes. More...

class	Ocean::Geometry::PnP
	This class provides functions determining the camera's pose based on at least five 3D object and corresponding 2D image points. More...

class	Ocean::Geometry::Quadric
	This class implements the base for all quadric object. More...

class	Ocean::Geometry::Cone
	This class implements a cone quadric. More...

class	Ocean::Geometry::Sphere
	This class implements a sphere quadric. More...

class	Ocean::Geometry::RANSAC
	This class implements several RANSAC functions for pose determination. More...

class	Ocean::Geometry::SpatialDistribution
	This class implements spatial distribution function for 2D geometric data. More...

class	Ocean::Geometry::StereoscopicGeometry
	This class implements function for stereoscopic geometry. More...

class	Ocean::Geometry::Utilities
	This class implements utilities function for the tracking library. More...

class	Ocean::Geometry::VanishingProjection
	This class implements functions for vanishing projections. More...

Typedefs
typedef Vector2	Ocean::Geometry::ImagePoint
	Definition of a 2D image point. More...

typedef Vector3	Ocean::Geometry::ObjectPoint
	Definition of a 3D object point. More...

typedef std::vector< ImagePoint >	Ocean::Geometry::ImagePoints
	Definition of a vector holding 2D image points. More...

typedef std::vector< ObjectPoint >	Ocean::Geometry::ObjectPoints
	Definition of a vector holding 3D object points. More...

typedef std::vector< ObjectPoints >	Ocean::Geometry::ObjectPointGroups
	Definition of a vector holding object points, so we have groups of object points. More...

typedef std::vector< ImagePoints >	Ocean::Geometry::ImagePointGroups
	Definition of a vector holding image points, so we have groups of image points. More...

typedef OctreeT< Scalar >	Ocean::Geometry::Octree
	Definition of an Octree using Scalar as data type. More...

typedef OctreeT< double >	Ocean::Geometry::OctreeD
	Definition of an Octree using double as data type. More...

typedef OctreeT< float >	Ocean::Geometry::OctreeF
	Definition of an Octree using float as data type. More...

Detailed Description

The Ocean Geometry Library provides geometry functionalities e.g., projective algorithms, optimization approaches or support for advanced transformations.

The library is platform independent.

In general, the Geometry library is an direct extension to the Math library offering a wide variety of mathematic functions mostly related with geometric tasks.
The entire framework is using a right-handed coordinate system (as long as not explicitly documented differently).
Please be aware that often coordinate systems are defined in different ways depending on the area of expertise or traditional decisions.
In Computer Graphics, most coordinate systems are defined/interpreted in a way that the observer/camera is looking into the negative z-space.
In such a case, the x-axis points to the right of the camera, and the y-axis is identical to the up vector of the camera (as long as the camera is located in the origin of the coordinate system).
In the following, such a coordinate system is depicted:

    ^
  Y |
    |
    |
    O --------->
   /        X
  / Z
 v

Therefore, each 3D object point lying in front of the camera has a negative z-value (as long as the camera is located in the origin of the coordinate system).
On the contrary, each object point lying behind the camera then has a positive z-value.
By default, the Ocean framework uses this kind of representation/interpretation for !any! coordinate system and for any algorithm as long as not explicitly stated/documented differently.

In Computer Vision, often a slightly different representation/interpretation is used.
Computer Vision algorithms or/and equations are mostly defined in relation to a coordinate system in which the observer/camera is looking into the positive z-space.
While the x-axis is still pointing to the right of the camera, the y-axis is equivalent to the down vector of the camera.
In the following, such a coordinate system is depicted:

     ^
  Z /
   /
  O --------->
  |        X
  |
  | Y
  v

In such a coordinate system, 3D object points lying in front of the camera have a positive z-value (as long as the camera is located in the origin of the coordinate system).
The reason (at least one of several other) for this coordinate system is that an image/frame quite often is defined to have the origin in the upper left corner of the image/frame (while the x-axis is pointing horizontally to the right and the y-axis is pointing vertically to the bottom of the image/frame).

Obviously, both coordinate systems can simply be transformed from one to the other and vice versa (by simply rotating around the x-axis).
However, it is crucial to understand that mixing up both coordinate systems can result in totally different results (sometimes not directly noticeable - depending on the situation etc.).
As the Ocean framework offers Computer Graphics as well as Computer Vision functionalities it was important to define one coordinate system as default coordinate system.
Without specific reasons, the Computer Graphics coordinate system (camera is looking into the negative z-space) is the default coordinate system while the Computer Vision coordinate system (camera is looking into the positive z-space) is the non-default case.
Therefore, the Computer Vision coordinate system is called the 'flipped' coordinate system as (compared to the default coordinate system) the Computer Vision coordinate system is flipped around the x-axis by 180 degrees.

Whenever a coordinate system is defined, e.g., for a camera pose the name of this parameter contains the information in which coordinate system the transformation is defined.
The parameter name for a default camera pose (defined in the default coordinate system) can be e.g., "cameraPose", 'extrinsicMatrix', 'pose', 'transformation', and so on.
While the camera pose defined in the flipped coordinate system (the Computer Vision coordinate system) can be e.g., 'cameraPoseFlipped', 'flippedPose', 'flippedTransformation', 'cameraPoseF', 'transformationF', and so on.
Either the prefix or suffix 'flipped/Flipped' or 'f/F' is used to identify a transformation defined in the flipped coordinate system.
Similar to this naming convention every function expecting (or returning) a transformation defined in the flipped coordinate system will contain the suffix 'F' like e.g., determineCameraPoseF(), projectPointF().
As long as this naming convention is preserved within the entire Framework no issues regarding mixed coordinate system can happen and a lot of time can be saved for debugging.
The framework has a lot of helper functions allowing to transform coordinate systems from one interpretation to the other.
Further, for reasons of convenience often a function is implemented twice (one function holds the actual implementation e.g., for the Computer Vision coordinate system, while the other function is implemented for the Computer Graphic coordinate system and simply transforms input and output).
For better understanding take a look on NonLinearOptimizationPose::optimizePose() and NonLinearOptimizationPose::optimizePoseIF().

Another decision has been made that a camera pose (the coordinate system respectively), in general, can be located at any position and can have any orientation compared to the world coordinate system.
That means that camera poses must not necessarily be located in the origin of the world coordinate system which offers a lot of flexibilities.
In this framework, a camera pose (the extrinsic camera matrix) transforms 3D object points, defined in the coordinate system of the camera, into 3D object points defined in the world coordinate system.
In Computer Graphics, the well known Model-View-Matrix is often defined in the opposite way (the matrix is simply inverted) - here 3D object points defined in the world coordinate system would be transformed into the camera coordinate system.
However, as a wide variety of functions in this framework also expect the inverted camera pose as input, another naming convention exists adding an 'inverted/Inverted' or 'i/I' to any parameter name of function name if the inverted matrix/transformation is expected.
For better understanding take a look on PinholeCamera::projectToImage() and PinholeCamera::projectToImageIF().

As coordinate systems (and their transformations between each) are very often the reason for bugs, errors and time consuming debugging sessions it is highly recommended to follow the above described rules and to document which kind of transformation is expected in every function.
In this framework, the documentation often provides equations showing which kind of transformations are expected or returned e.g., like:

Pw = wTc * Pc,     or      wP = wTc * cP

For a transformation wTc (e.g., a 3x3 or 4x4 square matrix) transforming a point 'Pc/cP' defined in the coordinate system of the camera (c) into the coordinate system of the world (w) - as long as points are multiplied on the right side of the transformation.
Due to the notation of the subscripts 'w' and 'c' it's obvious how the transformation is to be interpreted and in which coordinate system a point must be defined so that the transformation can be applied.