\section{The Data Format}

% The present user manual assumes the user is already familiar with the
% \sic\ command monitor, and also with the \greg\ graphic program.
% If not, read the documentation entitled ``An Introduction to \gildas ''
% to get started.

\subsection{Description}

\gildas\ has two slightly different data types : Images and Tables.  Images
are data sets of up to 4 dimensions, with a header specifying the World
coordinate system, the type of projection used, spectroscopic information,
etc... Tables are essentially like 2-D images (a 2-D image can be treated
as a Table in fact), but the only relevant information in this case is the
number of lines and columns in the table. The header is described in more
details in the programmer's guide.

\gildas\ was originally based on the mapping memory concept, in which an
image, resident on the disk, is considered as part of the virtual memory
space of the user. Memory mapping has the great advantage of separating the
Algorithms from the Input/Output system. The portable Unix version, though
no longer using memory mapping, still preserves a complete separation
between I/O statements and Algorithms. Algorithms are just standard
subroutines operating on arrays storing the images.

\subsection{Drawbacks}
\begin{center}
  ``Nobody is perfect''\\
  (attributed to the nameless God)
\end{center}

\gildas\ was designed to be fast and use little disk space. The consequence
is that it is not as comprehensive as larger packages. In particular, it
does not handle any ``history'' like AIPS does. You should then take care
of what a particular image is really. All vital information is in principle
correctly transmitted : axis types, coordinate conversion formula,
projection information. Extrema may need to be recomputed.

Other drawbacks comes from the virtual memory concept itself. The maximum
virtual memory a process can have is often limited by the operating system
configuration. With modern computers, a reasonable limit of say typically
256 Mbytes corresponds to data cubes of 256 by 256 by 256 (as you typically
access several data cubes at the same time...). Few instruments are capable
of producing larger data sets however, and large computers would be
required to handle these data in any case. These limitations can be partly
removed by proper programming of the applications (i.e. reading subsets
whenever possible).

\gildas\ does not clean up things as for example AIPS does when you exit.
Command files for the tasks are in principle deleted after task completion.
But it is up to the user to delete scratch files and log files which are no
longer needed. However \gildas\ never creates data or work files without
having requested a file name, so you know which files have been created.

Finally, \gildas\ contains an increasing number of algorithms. It is always
assumed that the user understands the basics of image processing when using
these algorithms. They may not apply to your special cases.  Although they
are usually tested, some of them may still be in the development phase. A
message in the {\tt HELP} or in the parameter file will signal these
programs.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gildas-intro"
%%% End:
