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.