Cesium Guide
Cesium Guide
Version 4
CESIUM’S GUIDE
INTRODUCTION
This document explains how to use and set up Cesium, Chyron’s application for converting
tracking data from any providers into regular and normalized 3D virtual camera parameters.
Documentation history:
Based on the original doc created by Yann Brosse for Hybrid-mc and modified 29 September 2011
by Rémi Lévêque.
Disclaimer: Our products are subject to continual development and improvement. Therefore, while the information in this
document was complete and accurate when it was written, additions or modifications to the products may cause changes
to the technical and functional specifications. No rights can be derived from this document.
Table of Content
INTRODUCTION 2
Documentation history: 2
Help and Support 2
Table of Content 3
Overview 5
Global Operation 5
Basics 6
Driver 6
Rig 6
Geometry vs Optical 7
Targets 7
Quick Reference for standard Calibration Steps: 8
Target Creation 13
Use Case 25
Mo-Sys StarTracker 25
Chyron’s Tracking 25
Setting up Rigs 25
Degrees of Freedom 25
Rig’s hierarchical geometry steps 26
Appendices: 27
TroubleShooting 27
Sighting: 27
Overview
This document is a guide for using Cesium software.
Cesium is Chyron’s application for managing tracking data from any providers and converting them
into regular and normalized 3D camera parameters (coordinates and optical ones).
Cesium’s purpose is to provide geometrical and optical data to a partner 3D software for accurate
matching between a real camera and its virtual equivalent.
Global Operation
Cesium runs on a host computer connected to one or several camera tracking systems, these
providing real-time data of their own format, while cameras are moving.
From the data received, Cesium will compute instantly a set of parameters characterizing the
virtual camera that is best fitted to the actual real camera, including focal angle, and make that set
continuously available to any 3D application, such as Fresh, Prime, Krypton, a.s.o.
This last can run either on the same computer or on any distant machine connected to it over
Ethernet.
Many camera tracking systems are supported by Cesium, obviously - but not only, those provided
by Chyron.
To understand briefly the overall structure and concepts involved, you may want to look at Basics.
For an overall GUI overview, you may want to look at Interface.
To set up a usual calibration, you may want to look at Setup with existing Files.
To simply apply from usual cases, you may want to look at Use Case.
To tune or build a more advanced calibration, you may want to look at Setting up Rigs.
Basics
Cesium coordinates system orientation is right-handed, and Y-up.
Convenient references may be:
1.
○ X pointing to the right
○ Y up
○ Z going backward the view
2.
○ X pointing to the left
○ Y up
○ Z going toward the view
In the rest of the document, the abbreviation CS stands for Coordinate System.
Driver
A driver enables Cesium to communicate with a tracking data provider.
It manages connections, protocols, as data reception and eventual normalisation.
Rig
A Rig is the structure model that converts data from a driver into standardized 3D coordinates and
optical info.
As such, It is modeled with a series of basic mechanical (hierarchically organized/evaluated) and
optical transformation steps.
Each of them depending on the tracking data system it relates to.
Geometry vs Optical
Cesium’s main task, into providing properly re-assembling the virtual 3D camera parameters, is
mainly splitted into:
● determining the position and orientation of the camera’s geometric/optical center in a space
referenced by a fixed coordinate system specified by the user.
● determining all relevant parameters for the optics.
Briefly:
● the first task processes the camera coordinate system resulting from the composition of a
hierarchy of transformations, part of them static, others variable.
This step applies to the center of the resulting picture.
● the second one is to deduce, eventually from tables characterizing the lens, the proper
values for the field of view (FOV), and for the nodal point shift (NPS).
This step handles the rest of the picture surrounding its center.
For more detailed explanations of these steps and principles, see chapter Setting up Rigs.
Targets
Targets are used for helping matching real and virtual.
This is more a helper than a needed tool as such, still should be treated as a quite helpful one, and
should not be neglected when working with several cameras.
It consists of a set of real properly surveyed points expected to have their equivalent
build/displayed in the virtual world (partner 3D software - obviously out of the same .tgt file).
A good calibration should have the virtual ones moving with very few inconsistencies from the real.
Targets are stored and managed in a dedicated text (usually .tgt) file, as a set of points expressed
within the coordinate system (CS) mentioned above.
You can build a set following Target Creation chapter.
A target system should be related to a specific physical studio.
Some of these steps would be better proceeded with using helpers (Optical Center reticule,
Targets) displayed as overlays from the 3D partner rendering software (Fresh, Prime, a.s.o.) using
mixing/compositing, either internally or with an external Chroma keyer/Mixer.
It can still be (re)installed using Cesium installer which should look like
Cesium_<version#>_Windows_10_Pro.exe (for Windows).
Cesium_<version#>_.deb (for Ubuntu).
Running
On Windows computers Cesium can be run either directly, as for any Windows program (using
Start menu, search Cortana, a.s.o.)
With this tool, you can set Cesium to permanently restart after closing.
N.B: in that case, closing Launchpad will also close Cesium.
Interface
When run from the very first time or from the Start Menu, Cesium may load empty:
Otherwise, especially when using --load-last command line option (for instance from the
Launchpad),
Cesium should load with the last session used (mainly Drivers and Rig sections already filled in).
Exemple:
File
Typical file menu for loading and saving files, with a Recent sub-menu for loading last (10) loaded
files.
The Open Sketch… sub-menu stands for loading predefined generic configuration files.
Convenient when starting a setup from known configurations, see next chapter Setup with existing
Files.
Tools
Targets…
Sub-menu for managing and adjusting Targets files (see Targets above).
Explained later on.
.
Send Targets to Krypton
Load StyleSheet
Driver
Add…
Delete…
To delete a driver from the already loaded ones from the current session.
Once loaded, drivers are shown in the Drivers section of Cesium’s main interface as 3 widgets for
each:
● A driver button that will open the dialog specific to the loaded one (with its name - see
later).
● On/Off button to have it activated (or not).
● Delay input box for adjusting data transmission delays.
Rig
Add…
Once loaded, Rigs are shown in the Rigs section of Cesium’s main interface as 1 widget:
● A Rig button that will open the dialog specific to the loaded one (with its name - see later).
Delete…
To delete a rig from the already loaded ones from the current session.
Help
Show Help
Tab 2:
Alpha values for Chyron’s robotics.
Languages
About
Self explanatory.
Target Creation
As stated earlier (Targets), while this is not a strictly necessary step, it is still recommended to be
done, especially for helping further re-calibrations or when working with multiple angles of
views/cameras.
Once loaded, the Drivers and Rigs sections should be filled in accordingly.
Checking Connection
With a driver loaded, pressing its corresponding button will open a dialog box that
shows how communication occurs:
You should see in the first panel data changing, especially the (fps) rate according to your
environment (50/60 Hz).
And obviously other specific values (Pan, Tilt, Zoom, etc.).
Depending on the tracking system, connections may be done via serial interface or ethernet.
N.B: Recent systems tend to provide ethernet, while serial corresponds to rather old technologies.
The connection mode is visible and configurable at the bottom of the previously mentioned dialog
box:
Adjusting Driver
Values can be displayed as (first dropdown list):
● Raw: straight from the provider.
● Cooked: as converted according to the Edit… dialog button (see below).
● Coeff: showing values according to the Edit… dialog button (see below).
Each incoming raw data may be “cooked” with mathematical transformations, accessible through
the Edit… button.
The Encoder Params dropdown list allows to select which specific incoming one.
Rig/Driver connection
Once the driver is properly adjusted, let’s open its corresponding Rig by pressing the related Rig
The relation/synchronisation with the Driver is confirmed (or setup) using the top right button
This step is for guaranteeing concordance between real and virtual geometrical transformations.
Thus it is important to concentrate only on the center of the picture. It is not necessarily an issue if
the surroundings don't match well at first, which will be the role of next step (Picture matching).
Thus Optical Center procedure below should be addressed first.
Geometrical/Mechanical
On the top most panel (named Mechanical), you should see the list of different geometrical steps
(or CS) used for setting up the specific data from the Driver.
Since loaded from a predefined setup file, you shouldn’t need to modify much of these.
Each of these steps, when selected, will display its parameters on the top right most panel.
N.B: Insert, Append, Delete, Active buttons are meant to be used while setting up new Rigs, as
discussed in chapter Setting up Rigs and shouldn’t be necessary here.
You may still want to Insert and/or Append a Fixed Transformation for temporary quick fix or overall
offsets (see just below).
In that case it may also be convenient to be able to activate them or not with Active (toggle button).
Depending on the transformation type, the right panel will display different contextual options/info:
Fixed Transformation
This is meant for adding custom offsets in X,Y, Z Translation and/or Rotations.
Translation values are in meters.
Rotation values are in degrees.
This one is used for setting up the offset of the camera (optical center) from its mechanical center
(known as “Goto Lens”), for instance. Or any other mechanical fixed offset from transformation
centers.
Also convenient for adjusting or moving the whole rig.
Most of the time, predefined rigs come with at least one of these transformations at first, named
Initialisation.
⚠ Because of possible rotations, the place of such transformations in the stack are important.
A fixed transformation at first is not the same as at the end.
To move the whole world, you should apply the related Fixed Transformation at first.
A transformation that comes from an incoming tracking device and should be mapped accordingly.
Don’t forget to put the proper coefficients, for the driver adjustments to get according cooked
values.
Pan/Tilt Transform
Similar to the previous one, dedicated to the combination of Pan and Tilt rotation together.
Jib Transform
Similar to the previous one, with managing arm length (Translation offset).
Unknown Transform
Similar to the Fixed Transformation (meaning it will create a similar step in the stack of operations),
except that the values are supposed to be automatically calculated during the Sight process (see
next step).
The checkboxes indicate which coordinates should NOT be automatically calculated by the Sight
procedure.
Show Sights (wrongly named Shight) (toggle) button displays a new Sights panel for dealing with
the Targets (as explained before) and managing matching real/virtual.
With this tool, it is possible to adjust and fine tune the geometric calibration process:
This procedure assumes that a relevant target file, with appropriately modified 3Dcoordinates, is
loaded into Cesium.
It consists in collecting the pan and tilt values under which targets are seen from the camera: more
precisely, the pan and tilt values collected are those for which each target, in a subset of the
available targets, coincides with the center of the reticule, i.e. the optical center (see below).
As expressed earlier, it assumes optical center determination has been performed prior.
Finally, Cesium uses these pan and tilt angular values to compute precisely all remaining unknown
parameters in the CS hierarchy.
This procedure requests having a real/virtual output composition (mixing) visualisation. Preferably
3D overlaid on top of real, with Optical Center (as a reticule) and the targets equivalents in the 3D
software shown.
Repeat the following sequence of steps (recommended to be done with 2 persons, one
manipulating the camera, the other the UI):
● select a target. Move the camera to aim at this target so that it and the optical center
coincide. You may use maximum zoom for better precision.
● press the Insert.. button, a dialog pops up (1) for entering target’s label ID (number), which
displays as a dropdown list. You may still type it in. Cesium defaults with one label that
should be the right target ID (generally wrong in the beginning of the session).
N.B: As a tooltip mentions it (2), the values are locked when pressing the Insert… button,
meaning if the camera moves after opening the Insert… dialog, it won’t be taken in account.
● Errors estimation (3) and average (4) are displayed in the panel, expressed in millidegrees.
● the same target may be selected multiple times from different camera positions.
● A checkbox (5) allows to bypass specific targets during the calculation (if, for instance, its
error is too high).
Every time a new target is inserted in the list of sights, Cesium tries to determine the correct
initialization CS (provided the 'Automatically refine when inserting/deleting sight' is checked in the
Preference window). So, in general, after a few (4 or 5, in various directions) different targets have
been taken this way, the viewer should display the CG targets roughly in the same position as the
real targets.
The process may be stopped when no obvious changes occur.
The buttons Solve and Refine allow to run new calculations for Unknown Transform/CS. Use the
Solve button when you are very far from the desired solution, the Refine one, when you are quite
close to it. If you are not using the 'Automatically refine when inserting/deleting sight', you will need
to manually run the calculations.
If you change values in the Rig, you may need to rerun the calculations as well.
The right side of this panel will show the status of each step.
On the Lens panel you may load the lens calibration file according to the actual lens used
using the Open Lens… button.
⚠ It is needed, otherwise virtual visualisation will mostly show a blank screen.
For both Zoom and Focus, you may map/connect them to the proper incoming data using
the Map… button.
⚠ Prior to the following, a proper back focus setup should be applied to the camera.
To have the system learn maximum and minimum values according to the physical rings,
the following steps should be proceeded at least once:
● Move the ring to the maximum (Widest for Zoom/Infinite for Focus) and press the
corresponding button.
● Move the ring to the minimum (Tele for Zoom/Closest for Focus) and press the
corresponding button.
While this should be proceeded only once, it may be needed to re-apply if enlarging
matching looks wrong.
Picture matching
A proper picture-wise matching depends on the receptor topology and where the actual
optical center is located.
This steps request having a real/virtual output composition (mixing) visualisation. Preferably
3D overlaid on top of real.
N.B: This step should be needed only once, as long as the video paths are not modified.
⚠Check that a proper back-focus procedure has been applied prior.
6. Repeat steps 3 to 5 until it is stable, meaning the spot is always centered by the
cross whether zoomed in or out.
Receptor Size
The first parameter is the width of the receptor, the second parameter the height. Note that
these parameters are expressed in millimeters.
This parameter compensates for the optical distortions a real lens most always has. A good
start value is 40% of the receptor size width.
Use Case
Mo-Sys StarTracker
Chyron’s Tracking
Setting up Rigs
A few considerations:
Degrees of Freedom
(as used in Cesium).
The number of degrees of freedom in a rig is the number of different independent actions one can
apply on its components during shooting, counting only those which affect the geometrical
rendering of the image related to the corresponding camera.
For instance, on a lens, while one can act separately on zoom, focus and iris rings, only zoom and
focus are taken into account, since the iris doesn't affect the topology of the image (only its colors).
To be noted: on most lenses, both zoom and focus are altering viewing angle. However, as long as
one can physically act independently on the zoom and focus rings, it’ll be treated as separate
degrees of freedom.
Similarly, one can generally act in many ways on a pan/tilt head (panning, tilting, changing the
amount of friction, changing the amount of counter-balancing springs, changing the balance of the
camera by sliding it forward/backward on the head, etc...). Only pan and tilt are taken into account
in the number of degrees of freedom, as for the head. Friction and counter-balancing springs are
not taken into account for two reasons : it is highly uncommon to act on them during shooting, and
they don't directly affect the geometry of the image. Changing the balance, which is performing a
traveling on the camera and thus is really affecting image's geometry, is not counted, because
no-one would dare doing it during shooting.
Cesium handles a hierarchy of coordinate systems describing the articulated geometry of the rig.
To illustrate, we present hereafter the way one can modelize, with some simplifying assumptions,
in Cesium, a pan/tilt head on a fixed pedestal.
We assume that some fixed coordinate system (CS), taken as the World CS (all CS considered in
the following are right-handed), for which the Y axis is vertical, with positive direction upward, has
been chosen.
1. Define first the Init CS with
● Y axis being the pan axis, with positive direction toward the camera plate (generally
upward)
● X and Z axis being in the plane of the tilt axis.
Observe that the Init CS is only defined up to a vertical axis rotation.
2. Define the Pan CS as being simply deduced from the Init CS through a rotation along the Y
axis by an angle equal to the value given by the pan encoder.
3. Define the Tilt CS deduced from the Pan CS through a rotation along the X axis (taken as
the tilt axis) by an angle equal to the value given by the tilt encoder, up to a fixed angular
offset.
4. Define the Camera CS as being the Tilt CS translated in such a way that the Z axis is the
optical axis of the camera, oriented toward the viewed scene, with its origin in the plane
where the lens is applied to the camera mount.
Clearly, this model assumes some nice properties of the pan/tilt head and of the camera
geometries, such as : the tilt axis is orthogonal to the pan axis the optical axis of the camera is in a
plane orthogonal to the tilt axis, etc...
The fixed angular offset, mentioned in 3., is only necessary to correct the value given by the tilt
encoder so that the resulting angle is null whenever the camera plate is orthogonal to the pan axis.
The full computation of the resulting Camera CS implies the knowledge of some (incompletely
specified) first coordinate system, namely Init. In the case of the pan/tilt head on a static pedestal,
this unknown CS contains the information on the position and orientation of the pedestal, which
can be freely chosen in the space by the user. In a few situations, it may be fine enough to operate
a rough determination of the relevant values in Init, as explained below (Empirical initialization). But
Cesium provides also a simple, fast and accurate procedure for the automatic determination of the
Init CS, a technique called: Procedural initialization, for the most demanding cases.
Appendices:
Cesium calibration Checklist
● Tripod level
● Check the back focus. Adjustment of the back focus implies adjustment of the optical center.
● Genlock. The Cobalt must be genlocked with blackburst. All Platinums need genlock too.
● Homing.
● Check that data comes from the Cobalt panel to Cesium (Driver. Rate = 50 fps or 60 fps)
● Pan /Tilt Coefficient Map... buttons in Pan and Tilt sections Alpha value (Facteur Cesium):
● Tilt 0 (+ Horizontal 0 & Pan 0 for the Jib) Tilt angle must be 0° when horizontal. Map... button in
Tilt section. Beta value.
● Goto Lens: Translations (meters). Silver =>Tx = +/- 0.2 m. Titanium => Tx = 0 m.
● Optical center.
● Targets: error <= 100 mdeg is perfect for PTZF robotic head. If no targets, in Initialisation section,
Ty = hight of the head from ground. Rx = 0 and Rz = 0.
● Receptor Size: ratio adjust. Check again the optical center if you need to change these values.
TroubleShooting
Sighting:
Possible unsuccesses:
● The Solve routine does not give valuable Unknown Transforms. Check the Relevant ones
(usually named as Initialization). Replace them with plausible values. Click on Refine.
● The average error stays big, even after a lot of targets have been inserted.
Check among the following potential sources of error.
Common causes of unsuccess are:
● The coordinate system used for the target is not right-handed; check for it and refer to the
Target Handling section in this manual.
● One or many targets used in the computation have wrong 3D coordinates.
For major errors, this is sometimes easily detected by drawing a sketch representing the
world CS and the 3D targets and checking whether the suspected target could possibly
have such values as coordinates.
This cannot detect minor errors. The only possible way at this point is to use a different set
of targets. One after the other, select one target in the board, activate/deactivate
checkboxes to enable or disable targets for calculation.
Try Solve or Refine. It often happens that wrong targets can be detected by this method.
● Bad coefficients for pan and/or tilt. Check alpha values for Pan and Tilt levels in the CS
hierarchy. Pay attention to the sign of alpha. After modification of these parameters, start
the procedure again from scratch.
● Bad Tilt0 value. Open the Tilt level; if this is not already the case, set Beta = Tilt0 and place
the camera in the tilt rest position: click on Refresh. The value displayed should be
approximately 0. Do not forget to put the original value in Beta.
● Other errors in the CS hierarchy. Check every level, compare with this manual template.
● Hardware problems on the rig; check the values delivered by the pan and tilt encoders.