Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass97/fitzpatrickm.html
Дата изменения: Fri May 15 22:17:27 1998 Дата индексирования: Tue Oct 2 03:46:19 2012 Кодировка: Поисковые слова: iapetus |
Next: Recent Developments in Experimental AIPS
Up: Data Analysis Applications
Previous: The Future of Data Reduction at UKIRT
Table of Contents -- Index -- PS reprint -- PDF reprint
Michael Fitzpatrick
IRAF Group,
NOAO
, PO Box 26732, Tucson, AZ 85726
For more than a decade IRAF has relied on the use of a display
server as the primary means for image display. IRAF client tasks connect
to the server and send or read data using a modified IIS
Model 70 protocol, originally via named fifo pipes but more recently using
Unix domain or inet sockets. The advantage to this approach was that IRAF
client tasks can make use of an image display without duplicating the code
needed for actually displaying the image in each task. The longtime
disadvantage however was that the IIS protocol used was arcane and
undocumented, making the display server largely unavailable to applications
or programmers outside of the IRAF project. Earlier attempts to solve this
problem, such as the SAO-IIS library (Wright and Conrad, 1994), have shown
there was a need in the community for such an interface but never managed
to provide all the features and generality necessary to be widely used.
The CDL is meant to provide an easy-to-use, fully featured application interface which can be easily evolved for future display servers, communications schemes, or display functionality. It is independent of IRAF itself (as are the display servers) so client tasks can be written for any discipline or application. CDL client programs can connect to the server using named pipes (fifos), Unix domain sockets or inet (Internet TCP/IP) sockets. The default connection scheme is the same as with IRAF (domain sockets then fifos) but client programs can specify any connection desired. With the C interface it is possible to open multiple connections to one or more servers, allowing clients to display both locally and to a remote server which can be anywhere on the Internet.
The CDL runs on all Unix platforms and is compatible with the XImtool, SAOimage, SAOtng and the IPAC Skyview display servers. The distribution includes all sources, full documentation and example tasks in both C and FORTRAN. An experimental SPP interface is available which lets IRAF developers (or occasional programmers) quickly prototype new applications without worrying about the details of image display. A ``Virtual XImtool" dummy display server is also available which can be used as a ``proxy server", taking input from one client and re-broadcasting it to a number of other servers, effectively creating a `tee' for display programs.
![]() |
The CDL currently uses a modified IIS Model 70 protocol to communicate with IRAF display servers such as XImtool. This protocol is isolated from the rest of the library by a generic communications interface (providing I/O functions for the cursor, image rasters, WCS, frame configuration and erasure, etc) which can be rewritten to use a different protocol without affecting the rest of the library. Servers which provide much more functionality through the client interface can still be used with only small modifications needed to extend the CDL.
![]() |
Image sizes are growing to the point of straining the modern machines used to do the reductions and have long since past the point where they can be displayed at full resolution on a typical monitor. The CDL, like most software, could benefit from some memory optimization to better handle these large images. New display servers are currently in development meaning the communications protocol will likely need to be extended if not changed entirely; we expect that the CDL will be made compatible with the new IRAF message bus architecture and the next generation display servers.
The graphics markers available provide all the primitives needed to to do graphics of any complexity however it is up to the client program to still create the overlay. For simply marking a few positions this is a straightforward task, but more powerful applications could be developed more easily by providing high-level routines for axis labeling or improving the speed required to draw many markers by doing the overlays in memory prior to display. Users with suggestions or questions are encouraged to contact the author at iraf@noao.edu.
Next: Recent Developments in Experimental AIPS
Up: Data Analysis Applications
Previous: The Future of Data Reduction at UKIRT
Table of Contents -- Index -- PS reprint -- PDF reprint