O. M. Smirnov
Institute of Astronomy of the Russian Academy of Sciences
48 Pyatnitskaya Str., Moscow 109017 Russia
N. E. Piskunov
Joint Institute for Laboratory Astrophysics
University of Colorado, Boulder, CO 80309-0440
The PCIPS image processing system (Smirnov & Piskunov 1994) has been in development since 1991; the current version is 2.01. PCIPS is a PC-based platform for all kinds of astronomical image processing and data-analysis. Key features of the system include: (1) an intuitive graphical user interface (GUI), (2) all functionality is provided by external application modules, which are easily added to the system as they are developed, (3) there is an application program interface (API) for development of custom applications, and (4) the code runs on practically any Intel-based PC.
As of now, several application packages have been developed under PCIPS. These include: (1) basic image processing operations (mathematics, statistics, filtering, fitting, geometric transforms, export and import of standard data formats, etc.), (2) PCDAOPHOT II, a GUI-equipped version of the DAOPHOT II (Stetson 1991) stellar photometry package (finding objects, aperture photometry, PSF construction, simultaneous PSF fits), (3) CCD/Echelle processing package (flat fielding, cosmic ray hit detection, finding and extracting spectral orders), (4) a spectral analysis package (dispersion curve fitting, continuum normalization, multiple line profile fits), (5) a Fourier analysis package (FFTs, power spectra, filtering in the Fourier domain), and (6) DASHA, a globular cluster/field photometry package (Smirnov & Ipatov 1995).
All of these very different packages have a consistent and powerful GUI that is common to all PCIPS applications. This paper reviews some issues that arose when developing the GUI.
Several design goals were formulated at the initial stage of development. First and foremost was expandability: the system would not be limited to a set of built-in image processing operations. All image processing functionality was to be provided by external modules (called applications), loadable on demand. The upshot of this decision is that the user interface for the applications became the interface of the whole system, since there is not much the user would do in PCIPS apart from running applications. Thus the second design goal emerged---making the user interface consistent across all applications, both existing ones, and those yet to be written. A third goal was making the interface as simple and easy to use as possible (substituting development time and CPU load for astronomer, or end user, time), while still providing enough features to support a great variety of applications.
A simple solution such as a single (usually huge) form with all the possible parameters, to be filled out by the user when starting an application, was unacceptable. A lot of applications (or, to be exact, their users) would benefit from a truly interactive operation. Finally, a fourth goal was to provide future compatibility with a visual programming metaphor (Smirnov & Piskunov 1993) to be implemented in an advanced version of PCIPS, which requires elements of the user interface to be modular and connectable by pipes.
A PCIPS application interacts with the system using a set of AIS (Application Interface Services, the application program interface, or API, of PCIPS) calls. It never communicates with the user directly. Instead, PCIPS translates AIS calls into user interface objects, maintains them, and reports the results back to the application. At the core, AIS is object-oriented. However, we did not want to implement a true object-oriented (OO) application interface in C++, for the sake of compatibility with non-OO languages such as C and FORTRAN. The application programmer works with the more conventional concept of handles, while inside PCIPS the handles are converted into true objects.
A big advantage of isolating the user from the application in this manner becomes apparent when we consider the visual programming metaphor, in which individual applications are connected by pipes that move data between them. With AIS, it does not matter to an application whether a parameters was actually requested from the user, or arrived via a pipe from another application. Therefore, all existing packages need little or no modification to adapt to the new metaphor.
A completely revised version of PCIPS is currently in development, targeted at UNIX/X11, Windows NT and DOS/Windows95. Some features of the new system are: (1) an unconventional object-oriented database, supporting all sorts of data objects and relations between them. It has a fully extendible data interface, and new data classes will be easily derivable from existing basic classes (i.e., images, arrays, tables, lists, etc.); (2) more visualization capabilities, implemented as properties of each data class (and thus easily extendible as well); (3) an overhauled API, with a separate, truly object-oriented C++ version, with support for more user interface objects and features; and (4) use of the visual programming metaphor.
PCIPS is a commercially distributed product. For details, contact Oleg Smirnov (e-mail: email@example.com). We welcome any comments and questions both regarding the current version of PCIPS, and the one in development. We are maintaining an e-mail distribution list for the PCIPS Electronic Bulletin (Peb), ask Oleg Smirnov if you want to sign up. Also, visit our anonymous ftp host, pcips.inasan.rssi.ru (188.8.131.52). The directory /pcips contains everything related to the system. A trial version can be picked up from /pcips/trial.