| ... | ... | @@ -46,5 +46,5 @@ Defines the number of available pixels of the used screen real estate. For insta |
|
|
|
## Camera
|
|
|
|
The [TUIO](http://tuio.org/) protocol transmits the position of objects on the table as normalised coordinates, i.e. instead of being expressed in pixels they are ranging from **0**, i.e. fully left/top to **1**, fully right/bottom. The rigid construction of the [Multitaction](https://www.multitaction.com/) tables ensures that the camera coordinate system and the screen coordinate system are locked, i.e. the won't shift or scale with respect to each other. On the other hand, for *Do-It-Yourself* tables with build in projector and camera, both coordinate systems are always slightly misaligned and out of scale. TULIP incorporates a calibration function to correct those misalignments and stores the corrective factors in the **`camera`** section of the calibration file. Usually, you don't have to edit those values yourself.
|
|
|
|
## Table
|
|
|
|
This section defines a number of table related dimensions. The **`width`** and **`height`** properties define the table's screen dimensions expressed in **millimetres**. Another set of strictly table related properties are **`movementThreshold`** and **`rotationThreshold`**. Tangible tables rely on optical recognition of fiducial markers on the table. This process is by its very nature *noisy*, meaning that detected positions and orientations are not stable for stationary objects, but show slight variations over time, a phenomenon commonly known as *jitter*. Depending on the table you're using, the camera system already provides filters to minimise the amount of jitter. Settings those filters always is a compromise between responsiveness and jitter free.
|
|
|
|
This section defines a number of table related dimensions. The **`width`** and **`height`** properties define the table's screen dimensions expressed in **millimetres**. Another set of strictly table related properties are **`movementThreshold`** and **`rotationThreshold`**. Tangible tables rely on optical recognition of fiducial markers on the table. This process is by its very nature *noisy*, meaning that detected positions and orientations are not stable for stationary objects, but show slight variations over time, a phenomenon commonly known as *jitter*. Depending on the table you're using, the camera system already provides filters to minimise the amount of jitter. Settings those filters always is a compromise between responsiveness and stability though. The values of the **`movementThreshold`** and **`rotationThreshold`** properties define the permissible variations in **position** and **angles** before the respective changes are considered to be caused by the translation, respectively the rotation, of the corresponding object.
|
|
|
|
|
