The Tina system has been written and developed with the benefit of many years of hard
learned experience in computer vision and image processing algorithm development.
It is intended to provide a platform for research and development of vision
and image processing
research software without the application programmer having to start from
scratch (see the software requirements analysis below).
In doing so the user may inherit as much or as little of the existing
Tina modules, graphics, code and programming style as they wish. Of course the
more a program conforms to the Tina way of doing things and the
representation of image, image feature and geometrical data then the more
fully will it be able to interact with with other modules (written or future
developments). This chapter gives an overview of the philosophy behind Tina,
following chapters cover tips on programming style, and how to begin writing
applications. Though the first 4 chapters are recommended reading (prior to
starting to use Tina), the later chapters are largely technical and should be regarded
as reference material.

Considerable effort has been made to integrate into the environment as much general
purpose flexibility as possible with regard to user programming.
It is intended that a researcher using the system will expend a maximum of effort
in developing the software of his algorithm, rather than spending
his time developing basic support infrastructure.
Developing debugging and testing new software
is efficient provided that the user follows some simple rules for the
set up of his programming environment. These programming tips are given
below and in the basic tinaTool development directory. This directory also contains
a Makefile and instructions on how to view and modify existing
routies and some example "skeleton" software, as an example of
how to include new software (add buttons and parameters and access graphics).
Additionally, tools developed using Tina Windows (Tw) have a built in
history mechanism which can be saved at the end of a processing session. This
avoids the need for tedious tool manipulations that often precede useful work.

As Tina is the product of a research environment
it is likely to undergo whatever changes are found to be necessary
in the light of continued research efficiency. As such it is impossible
to produce and maintain a definitive set of documentation and over time
much of the software
is likely to change. We apologise in advance for any discrpancies that
may have crept into the software since the last rewrite of this documentation.

It is recommended that users acquaint
themselves with the software relating to the algorithms they intend
to use. This is the only way to make sure that the data delivered is what they
actually require and computed in the way that they would want.
Utilities such as doxygen, lxr and simple search utilities (ntw)
are provided for rapid searching of the software to facilitate this
but researchers should expect to spend at least a few days on this task.
The Tina environment makes vision research more efficient, but
it doesn't make the research any easier.

Unfortunately, it is impossible to protect the programmer
from the task of following what is often a difficult learning curve, but
our belief is that access to such software is still preferable to spending
three years or more re-inventing such methods
once again, rather than building upon what has already been achieved.
This idea also extends to coding practices and we try to avoid
techniques which produce undue levels of obscuration (such as object orientation
and function overloading).
Our avoidance of unnecessary complexity has evolved out of experience (and code sharing)
in a research environment over an extended period (15 years). We accept that
sometimes this results in practice which is not entirely endorsed by trained
software engineers.
However, the aim is to develop software (which we know works) with a complexity level justified
by the task, which permits future maintenence and modification by
non-expert programmers (see below). Some parts of Tina were necessarily written by very talented
programmers, non-expert programmers will probably be able to identify these sections
(such as the generic graphics wrappers) very quickly, for all the wrong reasons.
The hope is that most vision researcher, will not need to modify these parts of the
library and will make use of the functionality already provided.

Although the exact design of the top level modules are by no means fixed
the modular nature of the top level will
maximise the longevity of applications designed within it and minimise the
effort involved in their update to future, more powerful, versions.
Furthermore the underlying image processing, maths and graphics libraries are
now in a sufficiently fixed state of repair that major changes are becoming
increasingly unlikely. No commitment has been made, at this time, to maintain
backward compatibility as this is seen as likely to cause unwanted expansion of the
libraries with old (and therefore inferior) versions of algorithms. If we make a change
to the library it is because we think it is necessary and compatability can normally be
regained by a simple change to the argument list of a few functions or the list of headers.

Several yeasrs ago, this software was converted to the ANSI standard, and
recently (in Tina5) we have modified the header file system in
order to obtain forward compatability with C++ standards.
However, there is currently no intention to convert this software itself to C++.
Contrary to naive expectation C++ is not simply an extension of the C language, it
encompasses a completely different style to programming and development which we decided
not to adopt for reasons of maintenance and productivity
1.1.
C++ is perhaps better suited for people who know exactly what their program should
do when it is finished and this is rarely the case for a research software engineer.
Although it is true that C++ has some useful features,
upon reading this manual you will discover that many of the
advantages expected from programming in C++ are already obtained from
the design of the Tina software.
As far as object oriented programming is concerned, our preferred language is Java,
and to this end we have recently investigated the use of swig wrappers.
We would not however, consider re-coding in Java, as we belive C has more utility.