|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass00/P3-04/
Дата изменения: Mon Jun 4 20:38:03 2001 Дата индексирования: Tue Oct 2 04:54:23 2012 Кодировка: Поисковые слова: ngc 891 |
GIPSY, the Groningen Image Processing SYstem (Allen et al. 1985; Van der Hulst et al. 1992), has its roots in the early seventies. Since then it has constantly evolved. Stimulated by close contact with its users, the exploration of many new ideas in image analysis and user interaction has been possible. GIPSY's user group is modest in size but is still growing and has extended beyond those interested in the analysis of spectral line synthesis data.
The system is organized as a set of independent application programs, `tasks', which are controlled by the user interface program Hermes (Allen & Terlouw 1981).
Event-driven tasks are fundamentally different from procedural tasks. Procedural tasks are in control of the order in which their different parts are executed and consequently of the required order of their inputs. An event-driven task, by contrast, is programmed so that it ideally can handle any input at any moment. In this way the user, not the task, is in control.
To support the event-driven operation of tasks, some features had to be added, but the original scheme was kept intact. Hermes was modified so that it sends a message to the task whenever there is a change in its set of inputs. The task, in turn, must be prepared to receive this message. For this purpose an event-dispatching routine was written. When a task is to be notified of changes related to particular keywords, it can register one or more functions with the event-dispatcher for every such keyword. Whenever a change occurs for any of these keywords, the dispatcher will call all functions registered for that keyword. Each function can then obtain the associated value in the usual way.
GIPSY's graphical user interface has been implemented as a collection of `elements', each consisting of an X Toolkit widget, such as a button, a menu, a text input field, a plot canvas, etc., and code which connects the widget to the event mechanism. Most elements are associated with a user input keyword. The widget always reflects the keyword's value, regardless of how it was set. When the widget is manipulated by the user, e.g., by typing text into an input field, the keyword will be updated. This update then causes an event that can be received and handled by the application code. Implemented in this way, there is a strict separation between form and meaning. A benefit of this is that the application programmer need not know anything about the details of the GUI, but only has to deal with a uniform, abstract, event mechanism. It also allows the separate development of application code and user interface.
In earlier versions of GIPSY, the PGPLOT library (by T.J.Pearson, California Institute of Technology) was only used for vector graphics. Image display was done by GIPSY's image display server GIDS. In the current version PGPLOT's image capability has become an important utility.
GIPSY's graphical user interface contains a PGPLOT device driver supporting up to 16 independent plot windows. The color maps for these windows can be partially or completely shared, or can be separate. Because PGPLOT's procedural cursor interaction cannot be used in the event-driven environment, a special mouse interface routine is provided instead.
Associated with each window, off-screen images can be stored which can quickly be brought back to the screen. These can be used for backup purposes, e.g., when it is too time consuming to regenerate the window while the application regularly needs to overwrite parts of it. They can also be used to implement movie loops, etc.
For images with a small number of pixels, which usually have a `blocky' appearance when displayed, interpolation between pixels has been implemented. This feature is available both in the display windows described above and in GIPSY's PostScript driver. To prevent the PostScript output from becoming excessively large, in this case the interpolation was implemented as an algorithm written in the PostScript language.
The developments described above allowed us to write more user-friendly programs. The graphical interface is used to facilitate input for applications, especially those where it is important to understand the relations between variables used for fine tuning. Examples are the fitting parameters in the GIPSY tasks GAUFIT2D and XGAUFIT. The first fits the parameters of a two-dimensional Gaussian distribution to data in an image and uses a robust moments calculation to find initial estimates for a least-squares fit. The second task fits the parameters of a one-dimensional Gaussian distribution to profiles, usually used to derive a velocity field from data in an H I data cube. It also measures deviations from the Gaussian shape using higher order terms of the so called Gauss-Hermite series. (Van der Marel & Franx 1993)
Another example is program RENDER which renders 2-D and 3-D GIPSY data and displays 2-D slices at any angle. It is based on the subroutine library PGXTAL by D.S.Sivia. The sky coordinate transformation task SKYTOOL is an example of matured functionality with a new interface. It is based on intensively used and tested transformation routines. One can enter a position in any of the GUI fields, either formatted or in degrees, and the program will immediately update the other fields with the corresponding coordinates.
Inspired by the new applications, users proposed new functionality which could not be implemented before. One example is INSPECTOR. This task displays slices through a three-dimensional GIPSY data set (channel maps) and overlays radial H I velocities (i.e., `tilted ring' circular velocities) on velocities in position-velocity diagrams extracted from the data and allows the user to adjust the tilted ring parameters interactively in order to get a better fit. A full description of how to derive rotation curves with INSPECTOR and its advantages and disadvantages compared to other methods is given in Swaters (1999). A second example is SLICEVIEW. This is a multi-purpose inspection tool for GIPSY data sets. It has an easy to use movie facility for the display of subsets, e.g., channel maps. It also has a flexible way of creating images of slices through a 3-D data set. Slice types are a straight line, an ellipse or a cubic spline with control points positioned by the mouse.
Evolution, rather than redesign, has been the main mechanism by which GIPSY has been able to keep up with modern requirements. This has enabled our focus to remain on the development of applications that implement new ideas in data analysis.
Allen, R.J. & Terlouw, J.P. 1981, in Proceedings of the Workshop on IUE Data Reduction, ed. W.Weis. (Vienna Observatory), 193
Allen, R.J., Ekers, R.D. & Terlouw, J.P. 1985, in Data Analysis in Astronomy, ed. V.diGesù, L.Scarsi, P.Crane, J.H.Friedman & S.Levialdi, (Plenum Press, N.Y.), 271
Swaters, R.A. 1999, Ph.D. thesis Rijksuniversiteit Groningen
Van der Hulst, J.M., Terlouw, J.P., Begeman, K., Zwitser, W. & Roelfsema, P.R. 1992, in ASP Conf. Ser., Vol. 25, Astronomical Data Analysis Software and Systems I, ed. D. M. Worrall, C. Biemesderfer, & J. Barnes (San Francisco: ASP), 131
Van der Marel, R.P. & Franx, M. 1993, ApJ, 407, 525