From 0face28c5897d5761f80ad0e7e435300fa958b4b Mon Sep 17 00:00:00 2001 From: Ole Streicher Date: Fri, 10 Mar 2023 11:31:43 +0100 Subject: [PATCH 1/2] Re-add IRAF release notes As the rest of doc/, they are now in RestructuredText --- doc/README | 1 + doc/releases/index.rst | 14 + doc/releases/v210revs.rst | 3616 +++++++++++++++++++++++++++++++++++++ doc/releases/v211revs.rst | 1336 ++++++++++++++ doc/releases/v212revs.rst | 1313 ++++++++++++++ doc/releases/v214revs.rst | 181 ++ doc/releases/v215revs.rst | 445 +++++ doc/releases/v216revs.rst | 718 ++++++++ doc/releases/v217revs.rst | 334 ++++ doc/releases/v28revs.rst | 1463 +++++++++++++++ doc/releases/v29revs.rst | 875 +++++++++ 11 files changed, 10296 insertions(+) create mode 100644 doc/releases/index.rst create mode 100644 doc/releases/v210revs.rst create mode 100644 doc/releases/v211revs.rst create mode 100644 doc/releases/v212revs.rst create mode 100644 doc/releases/v214revs.rst create mode 100644 doc/releases/v215revs.rst create mode 100644 doc/releases/v216revs.rst create mode 100644 doc/releases/v217revs.rst create mode 100644 doc/releases/v28revs.rst create mode 100644 doc/releases/v29revs.rst diff --git a/doc/README b/doc/README index 3adf7bb6d..77fcef3be 100644 --- a/doc/README +++ b/doc/README @@ -10,3 +10,4 @@ system as a whole. paspconf.sty, iraf92f3.eps, iraf92.tex IRAF in the Nineties (paper) (1992) + releases IRAF release notes \ No newline at end of file diff --git a/doc/releases/index.rst b/doc/releases/index.rst new file mode 100644 index 000000000..c6bd2100b --- /dev/null +++ b/doc/releases/index.rst @@ -0,0 +1,14 @@ +IRAF Release Notes +================== + +.. toctree:: :maxdepth: 1 + + v28revs + v29revs + v210revs + v211revs + v212revs + v214revs + v215revs + v216revs + v217revs diff --git a/doc/releases/v210revs.rst b/doc/releases/v210revs.rst new file mode 100644 index 000000000..b18b6ad6e --- /dev/null +++ b/doc/releases/v210revs.rst @@ -0,0 +1,3616 @@ +IRAF Version 2.10 Revisions Summary +=================================== + +:Authors: IRAF Group +:Date: July 1992 +:Abstract: A summary of the revisions made to the IRAF for the version 2.10 release + are presented. V2.10 is a major IRAF release, meaning that there were + significant additions to both the system and applications software, and + the release will eventually be made available on all supported systems. + This document deals with only the changes to the IRAF core system and + NOAO packages. The many layered packages available for IRAF follow + independent release schedules and are documented separately. This + revisions summary is divided into three main sections: system revisions, + IRAF and NOAO applications revisions, and revisions to the IRAF + programming environment. + +Introduction +------------ + +This document summarizes the changes made to IRAF in version 2.10. V2.10 +is a major release of IRAF, meaning that there were significant changes +to both the system and applications software, and the release will +eventually be made available on all supported platforms. + +By IRAF version 2.10 we refer only to the core IRAF system and NOAO +packages. Numerous external or “layered” packages are also available for +IRAF, for example the NSO package (solar astronomy), the ICE package +(data acquisition), the STSDAS package from STScI (HST data reduction +and analysis), the TABLES package from STScI (tabular data), the XRAY +package from SAO (X-ray data analysis), and so on. These packages are +layered upon the IRAF core system, and once installed, are +indistinguishable from the rest of IRAF. Layered packages are developed +and maintained separately from the core IRAF release and follow +independent release schedules, hence we will not discuss them further +here. Contact the IRAF project or any of the outside groups supporting +IRAF layered packages for additional information on what is available. + +This document is intended only as an overview of what is new in version +2.10 IRAF. More detailed documentation will be found in the systems and +applications notes files (files ``sysnotes.v210.Z`` and +``pkgnotes.v210.Z`` in the network archive), in the online help pages, +and in any reference papers or user’s manuals distributed with the +software. The IRAF Newsletter is a good source of information for new +IRAF software. + +The reader is assumed to already be familiar with the basic concepts and +operation of the IRAF system. In particular, familiarity with V2.9 IRAF +is assumed. + +IRAF System Revisions +--------------------- + +Starting up V2.10 IRAF +~~~~~~~~~~~~~~~~~~~~~~ + +Before attempting to start V2.10 IRAF each user should run the *mkiraf* +command in their IRAF login directory. This will create a new +``login.cl`` file and ``uparm`` (user parameter) directory. *mkiraf* +should be allowed to delete any existing parameter files, as there have +been many changes to task parameter sets in the new version of IRAF. + +LOGIN.CL changes +^^^^^^^^^^^^^^^^ + +The ``login.cl`` file is read by the CL during startup to perform some +runtime initialization and to customize IRAF for each user. A standard +``login.cl`` file is created and initialized by the *mkiraf* command +when the user’s IRAF login directory is configured. For V2.10 IRAF the +``login.cl`` file has undergone the following changes. + +- The IRAF version number is now checked automatically whenever you + login, and a warning message will be printed if your ``login.cl`` + file is out of date. If you see this message it means that important + changes have been made to the ``login.cl`` file and you need to rerun + *mkiraf* to update this file. + +- Most of core IRAF system packages are now loaded automatically at + login time by the ``login.cl`` file. If you use a personal + ``loginuser.cl`` file and you previously loaded any core system + packages in this file, you should edit the file and remove those + entries. + +- A “quiet” login option is now provided. If a file named ``.hushiraf`` + exists in the login directory when you start up the CL, printing of + the usual login messages will be disabled (the only output seen will + be the “cl>” prompt). + +- On UNIX/IRAF systems the login script now looks at the host system + environment variable ``TERM`` and checks for the common terminal + types “sun” and “xterm”, configuring the IRAF *stty* accordingly if + either terminal type is seen (note that the default number of lines + set for an xterm terminal window may need to be modified). The logic + used to do this is not foolproof however, and is provided only as an + example illustrating how to make use of the host system terminal + definitions. You may need to customize this portion of the script, or + override it in your ``loginuser.cl`` file. + +- The CL hidden parameter ``showtype`` is now set to “yes” by default. + This will cause a character to be printed after the name of each + package or named pset in CL package menus to allow these objects to + be easily distinguished from ordinary tasks. Packages are marked with + a trailing period (“.”) and psets with an ampersand (“@”). This + feature can be disabled with a “showtype=no” statement. + +- The V2.10 login script contains a call to a new internal (non-user) + IRAF task *mtclean*. Be sure to leave this alone, it is required for + the correct operation of the new magtape i/o system. + +The USER package defined in the template ``login.cl`` has been +extensively revised, adding many new tasks. These are mainly used to +make common UNIX commands available from within the IRAF environment. +Type “?user” in the CL to see what is available, e.g.: + +:: + + cl> ?user + adb cp fc lpq mv rlogin spell top + bc csh find ls nbugs rsh sps touch + buglog date finger mail nm rtar strings vi + cal df ftp make od ruptime su w + cat diff generic man ps rusers sync wc + cls du grep mkpkg pwd rwho telnet wtar + comm emacs less mon rcp sh tip xc + +Note that since the USER package is defined in the user’s login file it +is easily customized to add new tasks. Refer to the existing package for +examples illustrating how to do this. + +Compatibility Issues +^^^^^^^^^^^^^^^^^^^^ + +Version 2.10 IRAF requires the new ``login.cl`` file; if the CL does not +start up correctly, it may be because the user has not done a *mkiraf*, +or because they have some construct in their ``loginuser.cl`` file which +is incompatible with V2.10 IRAF. The V2.10 login file is usable with +V2.9 IRAF, however this is not recommended. + +There have been many task **parameter changes** between V2.9 and V2.10. +If “parameter not found” messages are seen, most likely the user has an +old ``uparm`` directory, or has been switching back and forth between +IRAF versions. An *unlearn* or *mkiraf* should fix the problem. + +The V2.10 IRAF **networking system** is not fully compatible with +earlier versions of IRAF. This can cause problems when, e.g., a newly +installed V2.10 system is used to communicate with an older version of +IRAF on another system. The best solution is to update to V2.10 on all +systems, but if this is not convenient it is possible to configure the +networking system to avoid the problems. See the discussion of the new +networking system given below. + +Accessing a **remote magtape device** via IRAF networking will not work +between V2.10 and older versions of IRAF (the remote procedure calls +have changed). To remotely access magtape devices you will need to +install V2.10 IRAF on both the client and server nodes. + +In most respects installing V2.10 IRAF will be very similar to +installing earlier versions of IRAF. The main difference is the +**tapecap file** required to use the new magtape system. The old +``dev$devices`` file is no longer used. See the discussion of the new +magtape system given below for more details. + +Due to name changes in certain low level system routines (made to avoid +name clashes when linking with host level libraries) the V2.10 libraries +are incompatible with older versions of IRAF. Any IRAF programs or +external packages **relinked** under V2.10 will have to be fully +recompiled or the linker will complain about unresolved externals. Note +that so long as the old program is not relinked there should be no +problem, even if the program uses the IRAF shared image, since the V2.9 +shared image is included in V2.10 (this applies to Sun/IRAF systems +only). + +Starting with V2.10, many IRAF applications now fully support +generalized **world coordinates** (WCS). While in principle this should +not pose any compatibility problems, the image headers do contain more +information in V2.10 than previously, and there can be problems if, for +example, an input image contains an illegal WCS. Previous versions of +IRAF would ignore this but in V2.10 such an image could result in an +error or warning message. If WCS related problems are encountered it is +probably best to contact the IRAF group for help. + +CL Enhancements +~~~~~~~~~~~~~~~ + +Formatted scans and prints, scan from a pipe +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +New in the V2.10 CL (command language) are formatted scan and print +routines, and the ability to scan from a pipe or other form of +redirected input. These new facilities will prove most useful in CL +scripts. + +The old unformatted scan and print routines are the following. These are +still available and are the simplest routines to use where they are +adequate. + +:: + + scan (arglist) # scan standard input + fscan (list, arglist) # scan a list + print (expr, exprlist) # print to standard output + fprint (param, exprlist) # print to a string buffer + +For example, + +:: + + list = "filename" + while (fscan (list, x, y) != EOF) + print ("x=", x, "y=", y) + +In the above, *arglist* is a comma delimited list of output arguments +(parameter or parameter field names) and *exprlist* is a comma delimited +list of expressions to be printed. *list* is the name of a +list-structured parameter to be scanned, and *param* is the name of a +parameter, the value field of which is to receive the output string. The +unformatted scan routines will automatically convert output data values +to match the types of the output arguments. + +The new formatted routines are as follows. These take an extra *format* +argument which tells how to parse the input string in the case of the +*scanf* routines, or how to format the output in the case of the +*printf* routines. + +:: + + scanf (format, arglist) # formatted scan from stdin + fscanf (list, format, arglist) # formatted scan from a list + printf (format, exprlist) # formatted print to standard output + +Currently there is no *fprintf* routine. For the *printf* routine the +*format* argument is similar to that for the SPP/VOS *printf* (which is +similar to the C *printf*). The *format* argument for the *scanf* +routines is the same as the VOS LIBC *scanf*, which is patterned after +the C *scanf* (in fact the UNIX manual page for *scanf* can be used as a +guide to the CL *scanf* with only minor deviations). + +The following examples illustrate the new routines. + +:: + + cl> printf ("%d foo %7.3f\n", 5, 12.123) | scanf ("%d foo %g", i, x) + cl> printf ("new values are i=%d, x=%g\n", i, x) + new values are i=5, x=12.123 + +or, + +:: + + while (fscanf (list, " %*d size=%d name=%s", i, s1) != EOF) + printf ("size=%05o, name=`%s'\n", i, s1) + +Note in the first example the use of *scanf* to scan from a pipe. There +are actually two different versions of *scan* and *scanf* in V2.10 IRAF, +an intrinsic function version and a procedure version. When called as an +intrinsic function, a *scan* routine returns as its function value the +number of operands successfully scanned, or EOF. When called as a +procedure, the function value of a *scan* routine is discarded. + +Here is another example illustrating scan from a pipe, in this case +using an unformatted scan since the *hselect* output is in a simple +tabular format (*hselect* prints selected fields of the image header). + +:: + + cl> hselect dev$pix naxis,naxis1,naxis2 yes | scan (i, j, k) + cl> printf ("naxis=%d, axlen=[%d,%d]\n", i, j, k) + naxis=2, axlen=[512,512] + +When using the formatted scan routines, care must be taken to ensure +that the data types implied by the *format* argument match the actual +data types of the output parameters. The *scanf* routines are +implemented using an internal call to the C (LIBC) *scanf*, with the +output parameter value fields referenced directly via a pointer. If the +data type is incorrect the output value may be meaningless. + +Unlearning package parameters +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The *unlearn* task now works for package parameters as well as task +parameters. In a command such as “unlearn pkgname” the package +parameters for the named package will be unlearned, as well as the +parameters for all the tasks in the package. This works whether or not +the package is loaded. + +Loading packages at login time +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A bug has been fixed which affected packages with package parameters +loaded at login time. It is now permissible to load any package at login +time regardless of whether it has package parameters (V2.9 users will +recognize this bug as one which prevented loading CCDRED in the login +script). + +Environment variables +^^^^^^^^^^^^^^^^^^^^^ + +The environment variables ``imtype``, ``cmbuflen``, and +``min_lenuserarea`` are now defined at login time. Previously, explicit +values for these variables were not defined, and the system would use +the builtin internal defaults. Explicit definitions were added so that +the user can query the current value, e.g. + +:: + + cl> show cmbuflen + 128000 + +A *show* or *set* with no arguments will print the full environment +list. New values for these and other common environment variables may be +set in the user ``login.cl`` file. + +System Management Related Changes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Install script +^^^^^^^^^^^^^^ + +The UNIX/IRAF install script underwent minor changes to make it more +robust. Problems are still possible if the IRAF root pathname is set to +different values in the various system dependent files modified by the +script. The system as shipped from NOAO has the same initial root +pathname set in all such files, but problems can occur if the files are +manually edited during or after installation. To avoid problems always +use the install script to make system changes such as installing at a +different root directory. + +Caching of termcap entries +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +User caching of termcap or graphcap entries with the old ``mkttydata`` +task is no longer recommended. The most common entries (e.g. sun, xterm, +vt100) are already cached. Modern workstations are so fast that there is +no longer much point in caching termcap entries; it is sufficient to +merely place local additions near the top of the file. Most programs +that repeatedly access the terminal cache the entries internally during +execution. Custom caching of termcap or graphcap device entries requires +that the system be relinked, and the risk inherent in relinking the +system (hence giving up the prebuilt, pretested binaries) is not worth +the small performance gain achieved. + +Sorting of UNIX directories +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The UNIX-based versions of IRAF now sort UNIX directories whenever a +directory is accessed to expand a file or image template. This will fix +the problem sometimes seen in earlier versions of IRAF, in which an +image template could appear to be expanded in a seemingly random +fashion. + +UMASK support +^^^^^^^^^^^^^ + +The UNIX-based versions of IRAF now support the host level *umask* file +creation mask correctly. If files or directories created by V2.10 IRAF +do not have the desired permissions, it is because you do not have umask +set correctly at the UNIX level (most people set umask to 022). + +Networking Enhancements +~~~~~~~~~~~~~~~~~~~~~~~ + +New networking driver +^^^^^^^^^^^^^^^^^^^^^ + +The UNIX/IRAF networking driver has been completely rewritten for +version 2.10 IRAF, with the goals of eliminating redundant password +prompts, improving efficiency, and enhancing system security. For the +most part the changes will be transparent to the user. Once the IRAF +system manager has configured the ``dev$hosts`` file for the local site +the networking system should function automatically; in the default +configuration a password prompt should be seen only when connecting to a +server for which *rhosts* (“trusted” hosts) permission is not granted. + +The following information is provided mainly for IRAF system managers. +In normal use the user does not need to understand how the networking +system functions. + +How it works +'''''''''''' + +The IRAF networking system is an RPC (remote procedure call) mechanism +for the IRAF kernel; all kernel procedures may execute either locally or +remotely, and the client and server nodes do not even need to run the +same operating system. IRAF applications may be distributed, and may +access resources which reside anywhere on the network. IRAF networking +is layered upon standard low level networking protocols such as TCP/IP +and DECNET. + +The IRAF networking system defines one or more *connection protocols* +which are used by a client to connect to the IRAF kernel server on a +remote machine. The old networking driver supported only one connection +protocol, the *rexec* protocol, which requires a login name and +password. The new driver adds support for an *rsh* based protocol. This +is the default connection protocol for V2.10 IRAF; automatic fallback to +the rexec protocol is provided in the event that the rsh connect fails. +The rsh connection protocol bootstraps off the suid-root *rsh* command +found in most BSD derived UNIX systems (most System V systems provide +the equivalent command *remsh*). + +The connection protocol is used to start the *in.irafksd* IRAF +networking daemon on the remote server node. This daemon executes with +the same uid and permissions as the account which initiated the +connection, and there is one such daemon per user per server node. Once +the daemon has been started via the rsh or rexec connection protocol, +new client connections are made very quickly, by merely forking the +daemon to create the IRAF kernel server process, and setting up a direct +socket connection between the IRAF client process and the server. The +daemon process runs indefinitely, shutting down if idle for longer than +a certain interval (the current default is one hour). When connecting to +the daemon a client must supply an authentication key to gain access to +the daemon. If authentication fails the daemon shuts down and it is +necessary to reestablish the connection. + +The .irafhosts file +''''''''''''''''''' + +The new networking driver retains the old *irafhosts* file, used to +store information telling how to connect to various IRAF hosts (the +irafhosts file is the file ``.irafhosts`` in the user’s login +directory). The networking system will automatically create this file +for the user if the file is not found; if an old-style file is found, it +will be edited by the system to make it compatible with the new +networking system. While it is no longer necessary for the irafhosts +file to contain password information to avoid password prompts, the file +is used to store the user authentication key, hence the file should be +read protected. The networking system will automatically read protect +the file if it is not already protected. + +To avoid authentication failures when clients on different nodes attempt +to connect to the same server, the same authentication code should be +used on all server nodes. Unfortunately there is no way that the +networking system can do this automatically (without going to some much +more complicated authentication scheme, such as a key server), so users +who make heavy use of the networking system should install a copy of +their irafhosts file in their login directory on all server nodes. If +this is not done the networking system will still work, but will be less +efficient than it could be, when simultaneously accessing the same +server from IRAF sessions running on multiple client nodes. + +The truly paranoid may not be happy with even the unique user +authentication code used in the current networking system. If this is +the case the *port* parameter (see below) may be set to zero to force +rsh to be used for every connection (in effect the in.irafksd daemon has +to be restarted for every connection). This imposes an overhead of as +much as several seconds on every server connect. Alternatively, +``KSAUTH`` can be defined in the user environment at login time, setting +the value string to some random integer value selected at login time. If +defined in the user environment, ``KSAUTH`` will override the value of +*auth* given in the irafhosts file. This approach would at least allow +efficient connects for a single login process tree. + +The irafhosts file consists of two sections. The first section defines +several networking parameters: ``port``, ``auth``, ``hiport``, and +``timeout``. The second section is a list of server nodes, with login +and password information describing how to connect to each node. + +:: + + port = default + auth = 1234567890 + hiport = default + timeout = default + + ursa : ? + * : + +The example above illustrates a typical irafhosts file. Typically a +unique authentication code is allocated automatically by the system when +the file is first created, and the other parameters retain their default +values as shown (i.e., the string “default”). In the example the host +list consists of an entry for the node “ursa”, and an entry for +everything else. The format of a host entry is “*host-name : login-name +password*”. If *login-name* is the reserved string “” the user name on +the client node is used for login authentication on the remote node. +Setting the password to “” as well causes the rsh connect protocol to be +used; anything else causes the rexec protocol to be used. If the rexec +protocol is used the password field may be set to the actual password or +to the string “?”, in which case the system will prompt for the password +whenever a connection attempt is made. The “*” entry should always be +the last entry in the list, since it matches all nodes. The default host +list contains only the ”*” entry. + +Additional information on the irafhosts file is provided in the comments +in the file ``dev$irafhosts``, and in the system notes file. + +Compatibility +''''''''''''' + +By default the new networking system will try to use the rsh protocol to +connect to the server node. If the server is running an older version of +IRAF the connection attempt will hang and eventually time out. If this +occurs the networking system will fall back on the rexec protocol and +issue a password prompt, but by then the user will probably have +interrupted the connect. The best way to avoid this problem is to update +the server node to V2.10, but if this is not possible, an explicit entry +for the node can be made in the irafhosts file, setting the password +field so that the rexec protocol will be used. + +An older, e.g. V2.9 client connecting to a V2.10 server should not be a +problem. In this case the V2.10 server will see an attempt to connect +with the rexec protocol, which should be processed as in the past. + +Aside from the problem of making a connection the pre-V2.10 and V2.10 +networking systems are compatible, *except* for the magtape i/o calls. +Since the magtape driver calling sequences were changed in V2.10, remote +magtape access between V2.10 and older systems is not supported. + +The hosts file +^^^^^^^^^^^^^^ + +The file ``dev$hosts`` is used to interface new host machines to the +IRAF networking system. This file defines, for each host, the primary +host name, any aliases, and the command to be executed remotely to start +up the IRAF kernel server on a remote node. + +The format and role of the hosts file is unchanged in V2.10. Two changes +were made which affect the use of this file. + +- A user can now have a private copy of the hosts file. To enable this + feature, the variable ``irafhnt`` (IRAF host name table) should be + defined in the user’s IRAF or host level environment, with the string + value giving the file pathname of the user’s private host name table + file. + +- The maximum number of entries in the host name table has been + increased from 64 to 128. In the current implementation these entries + are statically buffered, so it is necessary to keep the maximum + number of entries to a reasonable value. + +The hosts file must be configured to enable IRAF networking. IRAF +networking is disabled if there is no entry for the local host in this +file. The *netstatus* command may be used to examine the state of the +host name table after it has been loaded by the networking system. + +There is another file ``dev$uhosts`` which often confuses people. This +file is not used by UNIX/IRAF and can be ignored; it is there for +VMS/IRAF and other IRAF implementations which do not provide the +equivalent of the UNIX system routine *gethostbyname*. On host machines +which implement name server facilities IRAF will use the name server, +allowing any machine on the internet to be accessed via IRAF networking, +so long as there is an entry in the system wide or user IRAF hosts file. + +Magtape System Enhancements +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The magtape subsystem underwent a major revision in V2.10. The VOS level +MTIO interface was extensively revised, and the host-level IRAF magtape +driver ZFIOMT is completely new. A new device configuration facility +called *tapecap* was introduced. Together with the new “programmable” +magtape driver, this makes it possible to interface almost any removable +media mass storage device to the magtape subsystem. The DATAIO +applications, in particular the FITS programs, underwent minor, but +important revisions. + +A full specification of the new magtape subsystem, particularly the +tapecap facility, is beyond the scope of this document. Our intention +here is merely to introduce the new facilities. A reference paper is +planned, time permitting, which will fully document the new magtape +system and tapecap. + +Basic usage +^^^^^^^^^^^ + +In most respects basic usage of the magtape system is unchanged from +previous releases. Many new capabilities have been added, but these are +upwards compatible with earlier releases. + +Logical device names +'''''''''''''''''''' + +Magtape devices are still referred to in IRAF applications much as they +have been in the past. Whether or not the logical device names are the +same before and after the V2.10 upgrade depends upon how the IRAF system +manager configures the tapecap file. The new magtape system is much more +flexible than previously regarding device names, but to avoid user +confusion it is recommended that the old names be supported as aliases +regardless of whatever the full device name may be. + +As in earlier versions of IRAF, a simple magtape reference might be + +:: + + cl> mtexamine mta + +where “mta” is the device name. To examine only file 3 on the tape one +might enter + +:: + + cl> mtex mta[3] + +If the device is on the remote node “ursa” the command would be + +:: + + cl> mtex ursa!mta[3] + +If the device is a 9 track tape supporting multiple densities we might +specify the density explicitly, e.g. + +:: + + cl> mtex mta1600[3] + +Device names can be more complex. For example, + +:: + + cl> mtex mtwd + +might refer to a WangDAT drive, and + +:: + + cl> mtex mtwdc + +to the same drive, but with data compression enabled. + +Devices can have multiple names, possibly with slightly different +behavior or characteristics. Device names such as “mta” are usually only +host specific aliases for the lower level, host independent device +names. The names “mta” and “mtb” might be aliases for the actual device +names “mthp0” and “mtxt1”. This can be useful in networked systems where +IRAF and the tapecap file reside on a server node, but the user is +running IRAF on their workstation with a local tape drive attached. In +this case there may be no entry for the local drive in the installed +tapecap file, but the user can still access the local drive using the +lower level, host independent device entry (it is also possible to have +a private tapecap file as we shall see later). + +To see what logical devices are known to the magtape system you can +enter the following command (the task *gdevices* was intended for +graphics devices but can be pressed into service to list a tapecap file +as well). Just because a device is listed does not mean that the +physical device actually exists on a particular host system. + +:: + + cl> gdev devices='^mt' graphcap=dev$tapecap + +In IRAF V2.10 it is possible to include tapecap parameters in the device +specification to do clever things, as in the following example. + +:: + + cl> mtex "mta[:so=lepus:se:nb]" + +This is discussed further below in the section describing the tapecap +facility. + +Device allocation +''''''''''''''''' + +Device allocation operates much the same in V2.10 as in earlier versions +of IRAF. The main change is that it is no longer necessary to allocate a +device in order to be able to access it. It is strongly recommended +however that you always allocate a device before accessing it in IRAF. +If the device is not allocated anyone can access the drive, e.g., +changing the tape position, and this can cause data to be lost or +improperly read back. The only reason to access the drive without +allocating it is if there is some problem with device allocation on your +system. + +A device is allocated with the *allocate* command, e.g. + +:: + + cl> alloc mta + +A device is deallocated with *deallocate*. If the tape has already been +unmounted use the *rewind=no* option to avoid accessing the drive. By +default the tape will be rewound when it is deallocated. Deallocating +and reallocating a drive initializes the magtape system, i.e., all +cached knowledge of the status of the drive is discarded. + +Device status +''''''''''''' + +The device status can be examined at any time that the magtape device is +idle (not being actively accessed by an IRAF task) using the *devstatus* +task. + +:: + + cl> devs mtc + # Magtape unit mtc status Thu 12:54:02 04-Jun-92 user v14 + file = 4 + record = 1 + nfiles = 0 + tapeused = 405 + pflags = 0 + +Of particular interest are the *tapeused* and *nfiles* fields. *nfiles* +refers to the total number of files on the tape (if a file is appended +to the tape it will be file *nfiles*\ +1). If *nfiles* is given as zero +that means that the magtape system does not yet know how many files are +on the tape (it has not seen the end of tape). + +*tapeused* reports the amount of tape used in units of kilobytes. This +is intended to refer to the amount of tape used up to and including the +end of tape (EOT). However, the magtape system only knows about data +that it has seen, i.e. physically read or written, so whether or not +*tapeused* is accurate depends upon how you have accessed the tape. + +For example, if you started out with a fresh tape and appended a number +of files the number should be accurate. If you just completed a full +scan of the tape with *mtexamine* the number should be accurate, since +all the data was read. If you just put on a new tape and did a scan of +the FITS headers with “rfits make-”, the number may or may not be +accurate, depending upon the device and how file skipping forward was +done. In most cases only the header area of each file will have been +read and *tapeused* will not reflect the full contents of the tape. If +however, “rfits make-” is done immediately after writing to a new tape, +the number will be accurate, since all the data was written before the +tape was rescanned to print the FITS headers. + +Be advised that by default an explicit *rewind* will clear the *nfiles* +and *tapeused* fields, since by default *rewind* initializes the magtape +system. See the discussion of *rewind* below. + +In summary *tapeused* can be useful for monitoring how much space is +left on a tape, but you have to know what you are doing. When writing to +a new tape the number will be accurate so long as you avoid doing an +explicit *rewind*. A simple procedure which will always work when +mounting a non-empty tape and appending files to it, is to do an +*mtexamine* of the tape and then append the new files. This can be time +consuming for large tapes but does provide a safe and device-independent +method for getting the maximum amount of data on a tape. + +File positioning +'''''''''''''''' + +File positioning when accessing magtape files in IRAF is straightforward +in the sense that you can simply specify the file number to read an +existing file, or “append” (as in wfits new-) to append a file to an +existing tape. Most tasks accept range lists to access existing files, +e.g. + +:: + + cl> mtexamine mta file="3,5,9-11" + +It is even possible to position a tape to a specific record within a +file. Opening a tape with file zero (as in “mta[0]”) disables file +positioning, allowing the tape to be positioned with host level +utilities to workaround media problems. + +There can be problems with this simple scheme however, with modern tape +devices such as DAT and Exabyte which have capacities in the gigabyte +range and which may be used to store thousands of files. It is beyond +the scope of a revisions summary to go into this in detail here, but a +simple example will help illustrate the problem. + +Assume we have a tape mounted on device “mtwd” containing 900 files. We +want to append image “pix” as a FITS file. The obvious thing to do is +enter the following command. + +:: + + cl> wfits pix mtwd new- + +This will certainly work. The only problem is that if the tape is +freshly mounted the magtape system will not know how many files there +are on the tape, and it will have to skip forward one file at a time to +count the files and determine where EOT is. In the worst case of a tape +containing several thousand files this could literally take hours. + +If we know apriori the number of files on the tape, e.g., 900 in our +example, the following command would be much faster (something like +10-40 seconds on most DAT drives, assuming a decent host level driver). + +:: + + cl> wfits pix mtwd[901] + +Of course, if there were actually 930 files on the tape, the last 30 +files would be overwritten. + +There is a useful trick which works in some cases if we don’t care +exactly how many files are on the tape (whether this works depends upon +the specific device and the host driver). Assume that we know there are +several hundred files on the tape, but less than 1000. We enter the +following command to append a file to the tape. + +:: + + cl> wfits pix mtwd[1000] + +If this works, after the operation the magtape system will think there +are 1000 files on the tape. A subsequent “wfits new-” would be very fast +regardless of the tape position, since so long as the magtape system +knows where the end of tape is relative to the current position, it can +get there very fast. + +If the trick doesn’t work for your particular device or driver you will +probably get a positioning error when attempting to position to a +nonexistent file beyond the EOT. + +More automated techniques for rapid positioning with very high capacity +tapes are still a matter for study. One promising technique would be to +formalize the above approach by supporting EOT-relative positioning. A +tape catalog based approach is also possible. The best approach may +simply be to not write so many small files on large tapes, by grouping +images or other data system files into a single large tape file (as with +UNIX *tar*). None of these approaches are implemented in V2.10. + +Rewind +'''''' + +In IRAF a magtape device is rewound with the *rewind* command, as in the +following example. + +:: + + cl> rewind mta + +By default this will not only rewind the tape but also initialize the +magtape system, in the sense that all cached information regarding the +named device is erased (e.g., *nfiles* and *tapeused* in the cached +device status). This is necessary when changing tapes without +deallocating the drive; always do an explicit rewind (or deallocate) of +the device before removing a tape or mounting a new one. Having *rewind* +initialize things is also useful if error recovery should fail following +an interrupt or program abort. + +In some cases it may be useful to be able to do a rewind without erasing +the cached device status. This is done by specifying the *init-* option +on the command line. + +New magtape driver +^^^^^^^^^^^^^^^^^^ + +The IRAF magtape driver is new for V2.10. The chief feature of the new +driver is that it is programmable, via the tapecap device entry, making +it possible to interface new devices or host drivers without having to +make any binary code changes to IRAF. All one has to do is add a device +entry in the tapecap file. + +Software structure +'''''''''''''''''' + +The IRAF magtape system has enough layers that it may be confusing +exactly what the magtape driver is and what role it plays. A brief +review of the software structure may help clarify things. + +Starting at the top we have applications, such as the DATAIO and MTLOCAL +tasks, which can access magtape files. These use the IRAF/VOS interfaces +FIO (file i/o) and MTIO (magtape i/o) to do i/o to tape devices. For the +most part i/o is done with FIO and is device independent, but a call to +the magtape system is required to open a magtape device. The tapecap +file is read by the GTY interface, which is called by MTIO. MTIO passes +the tapecap device entry as a string to ZFIOMT, the IRAF magtape device +driver, when a tape file is opened. All magtape positioning and i/o is +done by ZFIOMT driver under the control of the MTIO interface. Device +allocation is done prior to accessing the device by the CL and is +handled by the allocation routines in the ETC interface, with kernel +support (this is largely independent of the magtape system). + +All of the code listed above is part of the portable IRAF system (i.e., +is OS independent and shared by all host versions of IRAF) until we get +to the ZFIOMT driver. This is in the IRAF kernel and is host system +dependent. At present the only version of ZFIOMT is the UNIX version; +other versions, e.g., for VMS will follow as IRAF is updated to V2.10 on +these systems. The UNIX version of ZFIOMT uses only generic UNIX ioctls +and should compile on most UNIX systems without change. All of the +system and device dependence has been concentrated in the tapecap file. +The ioctls used to communicate with a UNIX tape device are fairly +standard, but the semantics are often poorly defined and are certainly +not standardized. + +Beneath the IRAF driver are the host level magtape device drivers. A +given host system may have more than one of these, typically one for +each class of magtape device. Some systems, notably Sun with their ST +(SCSI tape) driver, try to control more than one type of device with a +single host driver. The host driver may come with the OS or may be +supplied by a third party vendor. + +Beneath the host driver is the actual tape device. Often these days this +is a SCSI tape device such as a DAT or Exabyte. These devices are +intelligent peripherals; control of the physical tape hardware resides +in the tape unit. There is a small computer in each tape drive which +communicates with the host computer via the SCSI interface, passing +commands and data back and forth. The drive will buffer 256K to 512K of +data passed in bursts over the SCSI bus, and then copied to or from the +physical media at a much slower rate. These drives emulate variable size +records by blocking and deblocking within the drive unit, and writing +fixed size blocks to the media. Features such as error correction and +data compression are also handled within the drive. + +Although we usually speak of tape devices, the “magtape” device does not +have to be a tape device at all. The IRAF magtape system can also make +use of, e.g., a floppy disk, or anything that looks like a raw disk +partition. The problem with the latter devices is that they usually +don’t support files and file positioning, hence can only be used to +store one “file”. + +Driver features +''''''''''''''' + +A detailed description of the magtape driver is beyond the scope of this +document. Briefly, the driver supports two main classes of devices, +variable record size devices and fixed block devices. All file +positioning is handled by the driver, and while the driver has the +device open it is responsible for keeping track of the device position +(the saved device position is passed in at open time and saved by the +high level code at close time). A couple of dozen tapecap parameters are +defined which describe the characteristics of each device, such as +whether it supports variable records, the maximum record size, whether +it can backspace, and so on. A socket or file based status logging +feature is provided which allows detailed monitoring of the tape status +during execution (see below). + +In the simplest case the new magtape system, coupled with the UNIX +version of the magtape driver, will emulate simple UNIX commands such as +*tar* and *mt* insofar as the requests made to the host system and +magtape device are concerned. That is, if one writes a series of files +the only system requests made for each file will be open, write, and +close. When reading a series of files in sequence the only requests made +will be open, read, and close. Providing no file positioning is +attempted it is possible to get by with no file positioning requests +other than rewind. The driver provides extensive facilities for file +positioning, using tapecap parameters to work around any shortcomings of +the host system or device, but in case of trouble it is possible to +operate with only open, close, read, and write requests, which should +work for any device (unless it is truly broken). + +Tapecap +^^^^^^^ + +The tapecap file, or magtape device capabilities file, defines the +magtape devices known to the system and how to access these devices. +While large portions of this file depend only upon the host operating +system and device type and hence are fairly site independent, it will +typically be necessary to customize the tapecap file to configure the +IRAF magtape system for a site. In normal use the tapecap file is +invisible to the user, but users with special problems may wish to learn +more about tapecap to gain more control over the behavior of the magtape +system. + +Using tapecap +''''''''''''' + +The standard tapecap file is the file ``dev$tapecap``. A system +environment variable ``tapecap`` is defined which by default points to +this file. + +Users can customize or manipulate tapecap entries in either of two ways. +The user can have their own private copy of the tapecap file (much as is +currently done with the termcap and graphcap files), by resetting the +value of the ``tapecap`` environment variable to point to their local +copy of the file. For example, + +:: + + cl> reset tapecap = home$tapecap + +This may be necessary to customize a device entry, or add support for a +local device not supported by the system wide tapecap file. + +It is also possible to modify a tapecap device entry “on the fly”, by +overriding the values of specific tapecap parameters on the command line +when the device is accessed. For example, + +:: + + cl> mtex "mta[:so=/dev/tty]" + +would override the default value of the tapecap parameter “so” for +device mta (in this case enabling status output logging and directing +this output to the user terminal). + +Specifying tapecap parameters on the command line is useful for +experimentation but rapidly becomes tiresome if many commands are +entered. In this case it becomes simpler to redefine ``tapecap`` to +include the desired tapecap parameter overrides. + +:: + + cl> reset tapecap = ":so=/dev/tty" + +As we see, the ``tapecap`` environment variable can be used to either +specify the tapecap file name, or globally override specific tapecap +parameters (all device entries are affected). The full form of the value +string for ``tapecap`` is + +:: + + cl> reset tapecap = \fR[\fP*tapecap-file\fP\fR] [\fP`:' *capabilities-list\fP\fR]\fP + +Any number of colon-delimited tapecap capabilities or parameters may be +given. + +It is beyond the scope of this document to detail all the tapecap +parameters here. A reference paper for the magtape system is planned. +For the present, there is a summary of the tapecap parameters in the +ZFIOMT driver source file, ``os$zfiomt.c``. For examples of actual usage +refer to the tapecap file in the distributed system. + +Configuring tapecap +''''''''''''''''''' + +The tapecap file uses the standard “termcap” file format, originally +developed for BSD UNIX and adopted long ago for IRAF. Any UNIX system +will probably have a manual page defining the termcap file format, if +not this can be obtained from the IRAF group. + +The distributed tapecap file is divided into three sections: the host +machine specific device aliases (names like “mta” etc.), the site +logical devices, and the generic device entries. To customize the +tapecap file for a site you modify the first and second sections. To +configure the tapecap file for a particular host machine you uncomment +the entries for that host in the first section of the file. Sites which +don’t have a large network of hosts may prefer to combine the first two +sections to simplify things. Site specific changes should never be made +to the bottom, or generic, part of the tapecap file, as you will want to +update this portion of the file when new versions of IRAF are released. + +Don’t be intimidated by the apparent complexity of some of the tapecap +device entries. In most cases the generic device entry will already +exist for the device you need to interface, and all you need to do is +add a site entry which references the generic entry. In some cases the +generic entry itself may be sufficient (for example, in the distributed +SunOS version of tapecap, logical device “mtxb0” would provide access to +Exabyte unit 0 interfaced with the Sun ST driver, “mtxb1” would be the +same but unit 1, “mthp0” the HP 9 track tape on unit 0, and so on). + +For example to interface Exabyte unit 2, using the Sun ST driver, as +local device “mta”, the following entry would suffice. + +:: + + mta| :tc=mtst2-exb: + +If the generic device entry provided doesn’t quite work and minor +modifications are needed, these should be made to the *local* entry and +not the standard generic entry. This is easily done with termcap +parameter redefinitions. For example, in SunOS 4.1.2 (but not earlier +versions of SunOS) there is a bug in the Sun ST driver which +necessitates rewinding the tape after a tape scan is made to position to +EOT (!). The capabilities “:se:nb” can be added to the tapecap entry for +the device to workaround this bug, as in the following example. + +:: + + mta| :se:nb:tc=mtst2-exb: + +The parameters mean that the device spaces past EOT in a read (se) and +cannot backspace (nb). Neither of these things is actually true, but the +effect is that the tape is rewound and spaced forward to get back to the +desired file, working around the host level driver bug. Access will be +less efficient than it should be, but the interface will work properly +and the user does not have to be concerned with the problem. + +As a final example, suppose we need to write a new tapecap entry from +scratch because there is no generic entry for the device in the +distributed tapecap file. To simplify things we assume that no special +tapecap parameters are needed, i.e., that the standard UNIX defaults +builtin to the driver will work for the device. We are upgrading from an +old version of IRAF so we already have an old ``dev$devices`` file to +work with. For the purposes of our example we use an old HP 88780 1/2 +tape drive entry, but pretend that the device is something which is not +already supported. + +The old devices file entry was as follows. + +:: + + mta nrst20 nrst4 nrst12 nrst28 rst4 rst12 rst20 rst28 + mta.6250 nrst20 nrst4 nrst12 nrst28 rst4 rst12 rst20 rst28 + +The minimal tapecap entry required to duplicate this is the following. + +:: + + mta|mta6250|HP 88780 1/2 inch tape drive:\\\\ + :al=nrst4 nrst12 nrst20 nrst28 rst4 rst12 rst20 rst28:\\\\ + :dv=nrst20:lk=st4:tc=9tk-6250: + +Here, the “al” parameter lists the device files to be allocated, the +“dv” parameter is the device file to be used for i/o at the desired +density (6250bpi in this case), and “lk” is the root file name to be +used for the “.lok”, or device status file. The “tc=” picks up the +standard parameters for a 9 track 1/2 inch tape drive operating at 6250 +bpi. Two device aliases are defined, “mta” and “mta6250”. + +Supported devices +''''''''''''''''' + +The IRAF magtape system itself should support almost any magtape device +if properly configured. What devices are actually supported at a site +depends upon the tapecap file, and in particular upon the host system +(different host systems have different tapecap files). + +================================= ======================= +Device Driver +================================= ======================= +QIC-11 cartridge tape Sun st +QIC-24 cartridge tape Sun st +QIC-150 cartridge tape Sun st +Pertec compatible 1/2 inch drives Xylogics +HP 88780 1/2 inch drive Sun st +WangDAT 1300, 2000 ApUNIX +HP DAT ApUNIX +Exabyte 8200, 8500 ApUNIX, Sun st, Ciprico +DC2000 cartridge tape A/UX tc +FDHD floppy disk A/UX fd +================================= ======================= + +As an example, the tapecap file distributed in the V2.10.0 release of +Sun/IRAF supported the devices listed in the table above. New devices +are constantly being added. As V2.10 IRAF propagates to the various +platforms on which IRAF is supported, similar tapecap files will be +configured for those systems. + +Status output +^^^^^^^^^^^^^ + +The new magtape driver has a facility known as status output logging +which can be used to monitor interactively lengthy tape jobs while i/o +is in progress. The status output facility can also be useful for +debugging magtape problems. + +In its simplest form, the status output may be directed to a file, e.g., +an actual text file, or a terminal device. Status output is enabled by +setting the “so” option in tapecap. For example, + +:: + + cl> mtex "mta[:so=/tmp/mta.out]" + +would enable status output logging and direct the output text to the +file /tmp/mta.out. Likewise, + +:: + + cl> mtex "mta[:so=/dev/ttyp7]" + +would enable status output and direct the output to a pseudoterminal, +e.g., an xterm window. When this form of status output logging is used +one sees the raw, driver level status messages, as in the following +example. + +:: + + cl> mtex "mta[:so=/dev/tty]" + open device tc2n\n + devtype = Apple Tape 40SC + tapetype = DC2000 + tapesize = 38500 + density = na + blksize = 8192 + acmode = read + file = -1 + record = -1 + nfiles = 0 + tapeused = 0 + device tc2n opened on descriptor 4\n + rewinding... + done\n + position to file 1\n + file = 1 + record = 1 + reading...\n + recsize = 65536 + record = 9 + tapeused = 64 + *(etc.)\fP + +The UNIX version of the new magtape driver also has an option to direct +status output to a TCP/IP socket, which can be anywhere on the network. +For this option to be useful one must have a program which will listen +on the designated socket, accept the connection when the magtape driver +tries to open a connection, and then read and process the status +messages (which are still text, exactly as in the example above). + +Status output to a socket is enabled by giving a host name instead of a +file name in the “so” directive: + +:: + + cl> mtex "mta[3:so=lepus]" + +to examine file 3, directing status messages to a socket on node +“lepus”. + +An X11 client application called *xtapemon* has been developed to listen +on a socket, read messages from the tape driver, and provide a real-time +display of the status of the tape device. While not included in the +V2.10 IRAF distribution, this utility will be available later in 1992 as +part of the X11 support package currently under development. + +Error recovery +^^^^^^^^^^^^^^ + +Considerable effort went into “bullet proofing” the new magtape system +to make it recover gracefully from ctrl/c interrupts or other program +aborts. In practice it can be very difficult to reliably catch and +recover from interrupts in a multiprocess, distributed system such as +IRAF. No doubt there are still conditions under which an interrupt will +leave the magtape system in a bad state, but in most circumstances the +system should now be able to successfully recover gracefully from an +interrupt. + +If it is necessary to interrupt a tape operation, it is important to +understand that the host system will not deliver the interrupt signal to +the IRAF process until any pending i/o operation or other driver request +completes. For example, in a read operation the interrupt will not be +acted upon until the read operation completes, or in a tape positioning +operation such as a rewind or file skip forward, the interrupt will not +be acted upon until the tape gets to the requested position. For a +device such as a disk you rarely notice the delay to complete a driver +request, but for a magtape device these operations will take anywhere +from a few seconds to a few tens of seconds to complete. Type ctrl/c +once, and wait until the operation completes and the system responds. + +If a magtape operation is interrupted, the IRAF error recovery code will +mark the tape position as undefined (*devstatus* will report a file +number of -1). This will automatically cause a rewind and space forward +the next time the tape is accessed. The rewind is necessary to return +the tape to a known position. + +Device optimization +^^^^^^^^^^^^^^^^^^^ + +In addition to making it possible to characterize the behavior of a +magtape device to permit the device to be accessed reliably, the tapecap +facility is used to optimize i/o to the device. The parameter “fb” may +be specified for a device to define the “optimum” FITS blocking factor +for the device. Unless the user explicitly specifies the blocking +factor, this is the value that the V2.10 *wfits* task will use when +writing FITS files to a tape. Note that for cartridge devices a FITS +blocking factor of 22 is used for some devices; at first this may seem +non-standard FITS, but it is perfectly legal, since for a fixed block +size device the FITS blocking factor serves only to determine how the +program buffers the data (for a fixed block device you get exactly the +same tape regardless of the logical blocking factor). For non-FITS +device access the magtape system defines an optimum record size which is +used to do things like buffer data for cartridge tape devices to allow +streaming. + +Some devices, i.e., some DAT and Exabyte devices, are slow to switch +between read and skip mode, and for files smaller than a certain size, +when skipping forward to the next file, it will be faster to read the +remainder of the file than to close the file and do a file skip forward. +The “fe” parameter is provided for such devices, to define the “file +equivalent” in kilobytes of file data, which can be read in the time +that it takes to complete a short file positioning operation and resume +reading. Use of this device parameter in a tape scanning application +such as *rfits* can make a factor of 5-10 difference in the time +required to execute a tape scan of a tape containing many small files. + +On most cartridge tape devices backspacing, if permitted at all, is very +slow. On such devices it may be best to set the “nf” parameter to tell +the driver to rewind and space forward when backspacing to a file. + +MTIO interface changes +^^^^^^^^^^^^^^^^^^^^^^ + +A number of new routines were added to the MTIO (magtape i/o) +programming interface. These are documented in the summary of +programming environment revisions given below. Existing magtape +applications may benefit from being modified to make use of these new +routines. + +Graphics and Imaging Subsystem Enhancements +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +New graphics applications +^^^^^^^^^^^^^^^^^^^^^^^^^ + +New tasks for histogram plotting, radial profile plotting, and producing +lists of the available graphics devices have been added to the PLOT +package. All of the tasks in this package were revised to add support +for world coordinates. A related task for drawing world coordinate grid +overlays on images or plots was added to the IMAGES.TV package. See the +appropriate sections of *IRAF and NOAO package revisions* below for +further information on these changes. + +Graphics system changes +^^^^^^^^^^^^^^^^^^^^^^^ + +Encapsulated postscript SGI kernel +'''''''''''''''''''''''''''''''''' + +A new encapsulated postscript SGI kernel has been added. Graphics output +may be directed to any of the logical graphics devices *eps*, *epsl*, +*epshalf*, etc. to render a plot in encapsulated postscript, e.g., for +inclusion as a figure in a document. For example, + +:: + + cl> prow dev$pix 101 dev=eps; gflush + +will leave a “.eps” file containing the plot in the current directory. +The command “gdev dev=eps” will produce a list of the available EPS +logical graphics devices. + +Graphics output to the default printer +'''''''''''''''''''''''''''''''''''''' + +Graphics output (SGI postscript) can now be directed to the UNIX default +printer device by directing output to any of the logical devices “lpr”, +“lp”, or “lw”. + +:: + + cl> prow dev$pix 101 dev=lpr + +Output will be sent to the default device for the UNIX *lpr* command +(set by defining “PRINTER” in your UNIX environment). This makes it +possible to make immediate use the distributed IRAF graphcap without +having to add entries for specific local devices (although you may still +wish to do so). + +Tick spacing algorithm improved +''''''''''''''''''''''''''''''' + +The algorithm used to draw the minor ticks on IRAF plots was replaced by +an improved algorithm contributed by the STScI STSDAS group (Jonathan +Eisenhamer in particular). This was derived from similar code in Mongo. + +Graphics metacode buffer +'''''''''''''''''''''''' + +The default maximum size of the graphics metacode buffer in the CL, used +to buffer graphics output for cursor mode interaction, was increased +from 64K to 128K graphics metacode words (256Kb). The ``cmbuflen`` +environment variable may be used to change this value. + +IMTOOL changes +'''''''''''''' + +The *imtool* display server (SunView) was enhanced to add additional +builtin color tables, support for user color tables, and setup panel +control over the screen capture facilities. A version supporting +encapsulated postscript output is in testing. This will be the final +version of the SunView based version of imtool (the new display servers +are all X window system based). + +IMTOOLRC changes +'''''''''''''''' + +The ``imtoolrc`` file, used by display servers such as *imtool* and +*saoimage* to define the available image frame buffer configurations, +has been relocated to the DEV directory to make it easier for local site +managers to customize. The IRAF install script now uses a link to point +to this file, rather than copying it to /usr/local/lib. The maximum +number of frame buffer configurations was increased from 64 to 128. + +X11 support +''''''''''' + +The released version of V2.10 does not contain any changes insofar as +X11 support is concerned. Since our X11 support code is host level +stuff, with minimal ties to IRAF per se, it is being developed +independently of the V2.10 release and will be distributed and installed +as a separate product. + +Image Structures +~~~~~~~~~~~~~~~~ + +Image I/O (IMIO) +^^^^^^^^^^^^^^^^ + +The image i/o interface (IMIO) is that part of the IRAF system +responsible for imagefile access and management. The changes to IMIO for +V2.10 included the following. + +Null images +''''''''''' + +Null images are now supported for image output, much like the null files +long supported by the file i/o system. For example, + +:: + + cl> imcopy pix dev$null + +would copy the image “pix” to the null image. This exercises the +software but produces no actual output image. Unlike null files, null +images do not work for input since images have some minimal required +structure, whereas files can be zero length. + +Preallocating pixel file storage +'''''''''''''''''''''''''''''''' + +In the UNIX versions of IRAF, when a new image is created storage is not +physically allocated for the output image until the data is written. +This is because most UNIX systems do not provide any means to +preallocate file system storage. The UNIX/IRAF file creation primitive +*zfaloc*, used by IMIO to create pixel files, now provides an option +which can be used to force storage to be physically allocated at file +creation time. This feature is enabled by defining the environment +variable ``ZFALOC`` in the UNIX environment. For example, + +:: + + % setenv ZFALOC + +can be entered before starting IRAF to cause space for all pixel files +to be preallocated as images are created. If it is not desired to +preallocate all image storage (there is a significant runtime overhead +associated with preallocating large images) then a value string can be +given to specify which types of images to preallocate storage for. For +example, + +:: + + % setenv ZFALOC /scr5 + +would preallocate only those pixel files stored on the /scr5 disk, and + +:: + + % setenv ZFALOC "/scr5,zero" + +would preallocate only images on /scr5, or images containing the +substring “zero” in the image name. In general, the string value of +``ZFALOC`` may be the null string, which matches all images, or a list +of simple pattern substrings identifying the images to be matched. + +In most cases the default behavior of the system, which is to not +physically allocate storage until the data is written, is preferable +since it is more efficient. The preallocation option is provided for +users who, for example might have an application which spends a lot of +time computing an image, and they want to ensure that the disk space +will be available to finish writing out the image. + +Image templates now sorted +'''''''''''''''''''''''''' + +As mentioned earlier in the *System Management* section, UNIX/IRAF now +sorts UNIX directories. One result of this is that the sections of image +templates which are expanded via pattern matching against a directory +will now be sorted, or at least logically ordered (the final output list +will not necessarily be fully sorted if string substitution is being +performed - this is the reason the output list itself is not sorted). + +The dev$pix test image +'''''''''''''''''''''' + +Minor changes were made to clean up the image header of the standard +test image ``dev$pix``. A second test image ``dev$wpix`` has been added. +This is the same image, but with a different header containing a test +world coordinate system (actually the image is just a second image +header pointing to the ``dev$pix`` pixel file, now shared by both +images). + +Image kernels (IKI) +^^^^^^^^^^^^^^^^^^^ + +The IMIO image kernels are the data format specific part of the IRAF +image i/o subsystem. Each kernel supports a different image format. +Existing disk image formats range from the conventional image raster +formats (OIF and STF) to the photon image format (QPF and QPOE) and the +pixel mask image format (PLF and PMIO/PLIO). There also exist special +image kernels which allow IMIO to be used to access non-disk storage +devices such as image display frame buffers. + +New PLF image kernel +'''''''''''''''''''' + +A new image kernel, the PLF image kernel, has been added which allows +IRAF PMIO/PLIO pixel masks to be stored as images. This kernel first +appeared as a patch to version 2.9 IRAF but was actually developed +within V2.10. + +Pixel mask images may be created, deleted, read, written, etc. like +other IRAF images, but the image is stored in a special compressed +format designed specially for image masks. An image mask is an +N-dimensional raster-like object wherein typically there are regions of +constant value but arbitrary shape. Masks are used by applications +involving image decomposition. The image is decomposed into regions of +different types, the type of region being very dependent upon the type +of image analysis being performed. A special type of mask image is the +bad pixel mask, used to flag the bad pixels in an image. Other +applications use masks for data quality, to identify the region or +regions to be used for analysis, and so on. + +A PMIO image mask is a special case of a PLIO pixel list. Masks can +exist and be accessed independently of the image i/o system, but the PLF +image kernel allows a mask to be stored and accessed as an IRAF image. +Any IRAF application which operates upon images can operated upon a mask +image. For example, the *imcalc* (image calculator) program in the SAO +XRAY package can be used to combine images and masks, or compute new +masks by evaluating an algebraic expression over an image. + +Mask images have the reserved image extension “.pl”. Some of the +features of mask images are illustrated by the following example. + +:: + + cl> imcopy dev$pix pix.pl + dev$pix -> pix.pl + cl> imstat dev$pix,pix.pl + # IMAGE NPIX MEAN STDDEV MIN MAX + dev$pix 262144 108.3 131.3 -1. 19936. + pix.pl 262144 108.3 131.3 6. 19936. + +This is a sort of worst case test of the mask encoding algorithm, since +our test image is not a mask but a noisy image (and hence not very +compressible). Note that masks must be positive valued, hence the MIN +value is different for the two images. Storing ``dev$pix`` as a mask +does not result in any significant compression, but for a real mask very +high compression factors are possible. The compression algorithm used in +PLIO is simple and fast, combining 2D run length encoding and a +differencing technique in a data structure allowing random access of +multidimensional masks (masks are not limited to one or two dimensions). + +For further information on pixel lists and pixel masks, see the document +``plio$PLIO.hlp`` in the online system. This is also available as +``plio.txt.Z`` in the IRAF network archive. + +OIF image kernel changes +'''''''''''''''''''''''' + +The OIF image kernel is the kernel for the old IRAF image format - this +is still the default IRAF image format. Revisions to the OIF kernel for +V2.10 included the following items. + +- A valid image header is now written even if an application which + writes to a new image is aborted. Previously, the pixel file would be + written but the image header would be zero length until the image was + closed. If an image creation task aborts the image will likely be + incomplete in some way, e.g., part of the pixels may not have been + written to, or the header may be missing application specific + keywords. By valid image header we mean that the header will be valid + to IMIO, allowing the image to be accessed to try to recover the + data, or to delete the image. + +- The image header file of a new image is now written to and closed at + image create time, then reopened at image close time to update the + header. This frees one file descriptor, an important consideration + for applications which for some reason need to write to dozens of + output images simultaneously. + +- The OIF image kernel uses file protection to prevent inadvertent + deletion of the image header file. In UNIX/IRAF systems file delete + protection is simulated by creating a “..” prefixed hard link to the + file. This could cause problems with images if the user deleted the + image header file outside of IRAF, leaving the “..” prefixed link to + the file behind. A subsequent image create operation with the same + image name would fail due to the existence of the hidden “..” + prefixed file. It is unlikely that such a file (with a “..” prefix + and a “.imh” extension) could ever be anything but an old IRAF image + header file, so the system will now silently replace such files when + creating a new image. + +A couple of related system changes were made which, while not +implemented in the OIF kernel, do involve the OIF or “.imh” image +format. The default template ``login.cl`` now defines the environment +variable ``imtype`` and sets it to “imh”. The environment variable +``min_lenuserarea`` is also defined now at login time, with a default +value of 20000, allowing image headers with up to about 250 header +parameters. + +STF image kernel changes +'''''''''''''''''''''''' + +The STF image kernel is the kernel for the online HST (Hubble Space +Telescope) image format. This format allows multiple images to be +grouped together in a single “group format” image. There is a common +image header stored in a FITS-like format, as well as a small fixed +format binary header associated with each image in the group. + +- A check was added for a group index out of range. This yields a more + meaningful error message about no such group, rather than having IMIO + complain about a reference out of bounds on the pixel file. + +- Support was added for non-group STF images (GROUPS=F in the header). + At first glance a non-group group format image might seem a little + silly, but it turns out that a non-group STF image with a zero length + group parameter block is very close to “FITS on disk”, since the + header is FITS-like and the image matrix is simple. It is still not + true FITS since the header and pixels are stored in separate files + and the pixels are not encoded in a machine independent form, but on + UNIX hosts which are IEEE standard and not byte swapped, it comes + close enough to be useful for communicating with external + applications in some cases. + +A true FITS image kernel is planned for IRAF. This will probably appear +in one of the V2.10 patches, sometime during 1992. + +QPF image kernel changes +'''''''''''''''''''''''' + +The QPF image kernel is the interface between the QPOE (position ordered +event file) interface and IMIO, allowing QPOE event files to be accessed +as images by general IRAF applications. Photon “images” are unique in +that the image raster is generated at runtime as the image is accessed, +optionally passing the photon list through event attribute and spatial +filters, and sampling the photons to produce a raster image. For +example, + +:: + + cl> imcopy "snr[time=@snr.tf,bl=4]" snr.imh + +would filter the event list stored in the file “snr.qp” by the time +filter stored in file “snr.tf”, sample the image space blocking by a +factor of 4, and store the resultant image raster in the OIF image file +“snr.imh”. + +:: + + cl> display "snr[time=@snr.tf,bl=4]" 1 + +would display the same image raster without creating an intermediate +disk image. + +The changes to the QPF interface for V2.10 included the following. + +- A bug was fixed which would prevent very long filter expressions from + being correctly recorded in the IMIO image header. The current + version of IMIO stores applications header parameters in FITS format, + hence multiple FITS cards are required to store long filter + expressions. The bug would cause only one such card to be output. + +- A new facility was added which allows general expressions to be + computed for the input event list and stored as keywords in the + output image header. The header of the input QPOE file can contain + one or more parameters named *defattr1*, *defattr2*, and so on. If + present, the string value of each such parameter should be a + statement such as + +:: + + exptime = integral time:d + +which will cause a keyword named “exptime” to be added to the output +image header, the scalar value of the keyword being the value of the +expression on the right. Currently, only the integral function is +provided. This computes the included area of a range list field of the +event attribute expression, such as a time filter. In the example, +“time” is the name of the event attribute to be integrated, and the “:d” +means use a range list of type double for the computation. The data +types currently supported are integer, real and double. + +Other minor changes to QPF included improvements to the error recovery, +and other changes to support very large filters. + +World coordinate system support (MWCS) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +MWCS is the IRAF world coordinate system package, one of the major new +system interfaces developed for the new image structures project. A full +description of the MWCS interface is given in the file ``mwcs$MWCS.hlp`` +in the online system, and in the file ``mwcs.txt.Z`` in the IRAF network +archive. + +Applications support +'''''''''''''''''''' + +MWCS was first released in V2.9 IRAF and at the time the interface was +new and few applications were yet using it. In V2.10 IRAF most (but not +all) applications which deal with coordinates now use MWCS. These +include all of the system plotting tasks, and the spectral reduction +packages. Details of the MWCS support added to the system and science +applications in V2.10 are given in the *IRAF and NOAO package revisions* +section of this revisions summary. + +New function drivers +'''''''''''''''''''' + +Function drivers for the *arc*, *sin*, and *gls* nonlinear sky +projections were added, as well as a special function driver for the +*multispec* image format. The latter allows general programs which don’t +know anything about spectra to access and display spectra in world +coordinates, e.g., for plotting. + +WCS attributes +'''''''''''''' + +The maximum number of “attributes” per WCS was increased from 64 to 256, +mainly to support the multispec function driver, which makes heavy use +of attributes. A limit on the size of a single attribute value string +was removed, allowing arbitrarily large attribute values to be stored. + +Axis mapping +'''''''''''' + +Axis mapping is now fully implemented. Axis mapping is used when, for +example, you extract a 2 dimensional section from a 3 dimensional image +and write the result to a new image. Axis mapping allows the 2 +dimensions of the new image to be mapped backed into the original 3 +dimensional WCS, making it possible to get the full physical coordinates +(which are 3 dimensional) for any point in the extracted image. A new +header keyword ``WAXMAP*nn`` was added to store the axis map in image +headers. + +MWCS save format +'''''''''''''''' + +The newer IRAF image formats such as QPOE are capable of storing +arbitrarily complex objects such as a MWCS in an image header keyword. +In the case of a stored MWCS object, the MWCS interface is responsible +for encoding the object in its external storage format, and restoring it +to a MWCS descriptor when the MWCS is accessed. The code which does this +was revised to add a new version number for the stored V2.10 MWCS, to +make it possible to differentiate between the MWCS save formats used in +V2.9 and V2.10 and allow recovery of MWCS objects from data files +written under V2.9. + +Bug fixes +''''''''' + +Since MWCS is a new interface and V2.10 saw its first real use in +applications, a number of interface bugs were discovered and fixed. Most +of the bugs turned out to be in the part of MWCS which converts between +the internal MWCS WCS representation, and the FITS WCS representation, +used for those image formats that still use FITS-like headers. Bug fixes +included a problem with the treatment of CROTA2, a problem with the FITS +CD matrix, an axis mapping problem that caused “dimension mismatch” +errors, and a problem with support for the old-style CDELT/CROTA which +could result in a singular matrix during WCS inversion when compiling a +transformation. + +Event files (QPOE) +^^^^^^^^^^^^^^^^^^ + +The QPOE interface is the interface responsible for creating and +accessing *event files*, the main data format produced by event counting +detectors. We summarize here the main enhancements to QPOE made during +the preparation of V2.10. Some of these features appeared earlier in the +patches made to V2.9 IRAF but these revisions have never been formally +documented so we summarize both the old and new revisions here. See also +the discussion of the QPF image kernel given earlier. + +Blocking factors +'''''''''''''''' + +The builtin default blocking factor, when sampling the event list to +make an image raster, is one. This may be changed on a per-datafile +basis by defining the parameter *defblock* in the QPOE file header. + +Parameter defaults +'''''''''''''''''' + +Since parameters such as the blocking factor can be set at a number of +levels, a parameter defaulting scheme was defined to determine the +precedence of parameter overrides. The lowest level of precedence is the +builtin default. Next is any datafile specific value such as *defblock*. +A value such as *blockfactor* set in the QPDEFS file will override the +datafile default value if any. Specifying the parameter value in a +runtime filter expression or *qpseti* call is the highest order of +precedence and will override any other setting. + +Another way to think of this is the more recently the parameter was set, +the higher the precedence. The oldest value is the default builtin to +the code. Next is the datafile value, usually set when the datafile was +created. Next is the QPDEFS macro file, usually set by the user or for a +site. Last (highest precedence) is the value set by the user when the +data is accessed. + +Referencing the current datafile in macros +'''''''''''''''''''''''''''''''''''''''''' + +A special symbol ``$DFN`` is now recognized during macro expansion and +if present is replaced by the filename of the current QPOE file. This +allows macros to be written which automatically perform some operation +involving the datafile to which they applied, e.g., computing an +attribute list from aspect or data quality information stored in the +datafile header. + +Bitmask expressions +''''''''''''''''''' + +Bitmask expressions may now be negated, e.g., “%3B” is the mask 03 +octal, “!%3B” or “!(%3B)” is the complement of 03 octal. + +Large time filters +'''''''''''''''''' + +A number of changes and bug fixes were made to QPOE for V2.10 to support +large time filters. These are lists of “good time” intervals used to +filter the event list. These large time filters may contain several +hundred double precision time intervals spanning the exposure period. +Often a large time filter is combined with a complex spatial filter +(PLIO mask) to filter an event list consisting of from several hundred +thousand to several million events. QPOE can handle this efficiently +regardless of whether the data is temporarily or spatially sorted and +regardless of the complexity of the temporal or spatial filters. + +A number of minor bugs were fixed caused by the large filter expressions +overflowing various buffers. The default sizes of the program and data +buffers used to compile filter expressions were increased to allow all +but very large filters to be compiled without having to change the +defaults. If the buffers overflow more space can be allocated by setting +the ``progbuflen`` and ``databuflen`` parameters in QPDEFS (these +buffers are not dynamically resized at runtime for efficiency reasons). +During testing with large time filters it was discovered that a routine +used to test floating point equality was being used inefficiently, and +compilation of large time filters was taking a surprisingly long time. A +change was made which reduced the time to compile large filters by a +factor of 10 to 15. + +Default filters +''''''''''''''' + +QPOE now fully supports default event attribute and spatial filtering of +data at runtime. The idea is that the full data set (all events) is +stored in the QPOE file, along with default event attribute and spatial +filters. When the data is accessed these filters are, by default, +automatically applied. Any user specified event attribute or spatial +filters are “added” to the builtin default filters to produce the +combined filter used when the event list is accessed. The point of all +this is to make it easy for the user to modify or replace the default +filters and “reprocess” the raw event list. In effect the raw and +processed event list are available in the same file. + +The default filter and mask, if any, are stored in the datafile header +parameters ``deffilt`` and ``defmask``. If the datafile contains +multiple event lists a default filter or mask may be associated with +each list by adding a period and the name of the event list parameter, +e.g., “deffilt.foo” would be the default filter for the event list +“foo”. + +By default, if a default filter or mask exists for an event list it is +automatically applied when the event list is accessed. Use of the +default filter or mask can be disabled in QPDEFS with either of the +following statements: + +:: + + set nodeffilt + set nodefmask + +The default filter and mask can also be disabled in a filter expression +by adding a “!” before the expression, as in the following example. + +:: + + display "snr[!time=@times.lst,pha=(3,8:11)]" + +There are actually several variants on the “=” assignment operator used +in filter expressions such as that above. The operator “=” is equivalent +to “+=”, meaning the expression term on the right adds to any existing +filter specified for the event attribute on the left. The operator “:=” +on the other hand, means *replace* any existing filter by the new filter +expression. + +Alternate coordinate systems +'''''''''''''''''''''''''''' + +The event structure used to represent each event in an event list may +contain multiple coordinate systems if desired, for example, detector +and sky coordinates. One coordinate system should be defined as the +default when the event list is created, and if the event list is to be +indexed it must be sorted using the coordinate system specified as the +default. Any coordinate system may be used when the data is accessed +however; this can result in quite different views of the same data set. +For example, + +:: + + cl> display snr.qp 1 + +would display the QPOE file “snr.qp” in display frame 1, using all +defaults for the event list, blocking factor, filter, mask, and so on. +The default event coordinate system would probably be sky coordinates. +To display the same event list in detector coordinates, one could enter +the following command. + +:: + + cl> display "snr.qp[key=(dx,dy)]" 1 + +This assumes that the event structure fields “dx” and “dy” are defined +somewhere, either in the datafile header or in QPDEFS (otherwise the +actual field datatype-offset codes must be given). + +Currently if the QPOE datafile has a WCS associated with it this WCS can +only refer to one coordinate system, normally the default event +coordinate system. Additional WCS can be stored in the QPOE file, either +in the stored MWCS object or as separate MWCS objects, but at present +there is no mechanism for selecting which will be used (if the parameter +``qpwcs`` exists in the QPOE file header, this is assumed to be a stored +MWCS object and this is the WCS which will be used). + +System Specific Changes +~~~~~~~~~~~~~~~~~~~~~~~ + +Sun/IRAF +^^^^^^^^ + +Since V2.10 has only just been completed and at this stage has only been +released on Sun platforms, there are few system specific revisions to +report. For SunOS there were several system specific revisions worth +noting here. + +- The HSI binaries for the sparc architecture are now statically + linked. This makes them considerably larger, but avoids problems with + SunOS complaining about shared library version mismatches (note that + we refer here to to Sun shared libraries - this is not a problem with + the IRAF shared library facility since we control the version + numbers). + +- The HSI binaries for the Motorola architectures (f68881 and ffpa) are + *not* statically linked since they cannot be without running into + linker problems warning about f68881_used etc. To avoid or at least + minimize warnings about SunOS shared library versions the system was + linked on 4.1.1 instead of 4.1.2. SunOS 4.0.3 versions of the + Motorola HSI binaries are also available upon request. + +- The system as distributed was linked with the name server library, + ``-lresolv``. This means that if the local host is configured to use + the name server, IRAF will be able to access almost any host on the + Internet without an entry in the ``/etc/hosts`` file on the local + host. + +Additional system specific changes will be reported in the documentation +distributed with each release, as V2.10 is moved to the various +platforms for which IRAF is supported. + +IRAF and NOAO package revisions +------------------------------- + +The revisions for the various packages in the IRAF core system and in +the NOAO packages are summarized below. There have been many changes +with this release. Users are encouraged to refer to the help pages, +user’s guides provided with some packages, revisions notes, and more +recent issues of IRAF Newsletters for more details. Comprehensive notes +on systems and applications modifications are in the files +``pkgnotes.v210.Z`` and ``sysnotes.v210.Z`` in the directory +``iraf/v210`` in the network archive. This summary can be read online by +typing *news*. Revisions notes for the various packages can also be +accessed online as in the following example. + +:: + + cl> phelp dataio.revisions opt=sys + +One of the system changes that affects many tasks in the IMAGES, PLOT, +and LISTS packages as well as most tasks in the spectroscopic packages +in NOAO is the full implementation of the world coordinate system (WCS), +introduced in V2.9 but not fully integrated into the IRAF and NOAO tasks +at that time. There are currently three classes of coordinate systems: +the logical system is in pixel units of the current image section; the +physical system is in pixel units of the parent image (for a WCS +associated with a raster image); the world system can be any system +defined by the application, e.g. RA and DEC or wavelength. In general, +this should be transparent to the user since most defaults have been +chosen carefully so that tasks perform the same as in V2.9. The NOAO +spectroscopic tasks also use the WCS extensively, but again, this should +be transparent to the user, although it can cause some problems with +backward compatibility. Users will notice the biggest difference in the +image headers with additional keywords added by the interface. Two tasks +in the PROTO package may help the interested user understand more about +the WCS - see *wcsedit* and *wcsreset*. Technical notes on the WCS are +available in a paper in the ``iraf$sys/mwcs`` directory. Type the +following to read more about the MWCS interface. + +:: + + cl> phelp mwcs$MWCS.hlp fi+ + +Changes to the IRAF system packages +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +DATAIO package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- The output defaults for *wfits* have been modified. If the pixel type + on disk is real or double precision the output will be IEEE format + (FITS bitpix = -32 or -64, respectively). If the pixel type on disk + is short integer then the output will be integer format (bitpix = 16) + as before. These defaults can of course be changed by modifying the + parameters for *wfits*. + +- The *wfits* “blocking_factor” parameter can accept values up to and + including 10 for variable blocked devices, i.e. 1/2” tape drives, + Exabytes, and DATs. If the “blocking_factor” parameter is set to “0”, + as in the default, the value is read from the “fb” parameter in the + tapecap file (usually 10 for variable blocked devices). For fixed + blocked devices such as cartridge tape drives the default value for + the “fb” parameter in the tapecap file is 22 (used to determine a + buffer size) and the block size of the device is given by the “bs” + parameter. + +- All tasks were modified to accept tapecap parameters as part of the + magtape file name syntax. Tapecap parameters can now be appended to + the magtape file name to add to or override values in the tapecap + file. For example, ``"mta6250[:se]"`` is a valid magtape file name + (the “” are important when tapecap parameters are specified at + execution time). See the file ``os$zfiomt.c`` for more details about + the tapecap parameters. + +- The *rfits* task has been modified to permit a short last record, + i.e. a last record that has not been padded out to 2880 bytes. No + warning messages are issued. + +- *rfits* was modified to map ASCII control characters in the header to + blanks. + +- The sequence number appended to disk file names by *rfits* and + *wfits* was modified to 4 digits, i.e. 0001 - 9999. + +IMAGES package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- WCS (world coordinate system) support was added to all tasks in the + IMAGES package that could introduce a coordinate transformation. Some + tasks had already been modified for the V2.9 release. These tasks + (*blkavg*, *blkrep*, *geotran*, *imcopy*, *imlintran*, *imshift*, + *imslice*, *imstack*, *imtranspose*, *magnify*, *register*, *rotate*, + and *shiftlines*), upon execution, will update the image header to + reflect any transformation. + +- The *listpixels* task was modified to list the pixel coordinates in + either logical, physical, or world coordinates. A format parameter + was added to the task for formatting the output pixel coordinates + taking precedence over the WCS in the image header, if used. + +- A new *imcombine* task was added to the package. This new task + supports image masks and offsets, and has an assortment of new + combining algorithms. See the help pages for complete details on this + powerful new task. + +- The *imhistogram* task has a new “binwidth” parameter for setting + histogram resolution in intensity units. + +- The default values for the parameters “xscale” and “yscale” in the + *register* and *geotran* tasks were changed from INDEF to 1.0, to + preserve the scale of the reference image. + +IMAGES.TV package reorganization and modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- The TV package has been reorganized. The IIS dependent tasks have + been moved into a subpackage, TV.IIS. The *imedit*, *imexamine*, and + *tvmark* tasks that were previously in PROTO have been moved to TV. + +- A new task *wcslab* developed at STScI by Jonathan Eisenhamer was + added to the package. *wcslab* overlays a labeled world coordinate + grid on an image using WCS information stored in the header of the + image or in parameters of the task. + +- *imexamine* was modified to use WCS information in axis labels and + coordinate readback, if selected by the user. Two new parameters, + “xformat” and “yformat”, were added to specify the format of the WCS + if it is not present in the header of the image. + +- A new option was added to *imexamine* to allow for fitting 1D + gaussians to lines or columns. + +- *tvmark* had two cursor key changes. The “d” keystroke command that + marked an object with a dot was changed to “.”; the “u” keystroke + command that deleted a point was changed to “d”. + +LISTS package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- Two new parameters were added to the *rimcursor* task, “wxformat” and + “wyformat”. These parameters allow the user to specify the coordinate + formats for the output of the task and override any values stored in + the WCS in the image header. + +OBSOLETE package added +^^^^^^^^^^^^^^^^^^^^^^ + +- An new package called OBSOLETE was added. Tasks will be moved to this + package as they are replaced by newer tasks in the system. OBSOLETE + tasks will then be removed at the time of the next release. + +- *mkhistogram*, *imtitle*, *radplt*, and the old *imcombine* task have + been moved to the OBSOLETE package. Users should become familiar with + *phistogram*, *hedit*, *pradprof*, and the new *imcombine* and use + them instead since *mkhistogram*, *imtitle*, *radplt*, and + *oimcombine* will be retired with the next release. + +PLOT package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- A new task called *phistogram* was added to the PLOT package. This + task takes input from an image or from a list and allows full control + over the plotting parameters. This task replaces the + *obsolete.mkhistogram* task. + +- A new task *pradprof* was added to the PLOT package. This task plots + or lists the radial profile of a stellar object. This task replaces + the *obsolete.radplt* task. + +- A new task called *gdevices* was added to the package. *gdevices* + prints available information known about a particular class of + device. The default parameters are set up to print a list of the + available stdimage devices in the standard graphcap file. + +- WCS support was added to the tasks *graph*, *pcol(s)*, and *prow(s)*. + A new parameter called “wcs” was added to define the coordinate + system to be used on the axis, either logical, physical or world. Two + additional parameters, “xformat” and “yformat”, were also added to + allow the user to set the format for axis labels overriding any + values in the image header. The “xlabel” parameter values were + extended to include the special word “wcslabel” to select the WCS + label for the x axis from the image header. + +- WCS support was added to the task *implot*. A new parameter called + “wcs” was added to define the coordinate system for plotting, either + logical, physical, or world. Two new “:” commands were also added: + “:w” allows the user to set a new WCS type interactively; “:f” allows + the user to change the axis format, for instance, “:f %H” would + change the axis to read h:m:s, if the world coordinate RA had been + defined in the image header. The “space” key now prints out the + coordinate and pixel value information. + +- *graph* has a another new parameter “overplot” that allows the user + to overplot multiple plots with different axes. + +- The default parameters for “floor” and “ceiling” in *contour* and + *surface* were changed to INDEF. + +PROTO package reorganization and modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This package has been reorganized. The PROTO package now resides in the +core system. Tasks in the old PROTO package that were general image +processing tools were kept in this new PROTO package. Tasks that were +more data reduction specific were moved to the new NPROTO package in the +NOAO package. The current PROTO package now contains the tasks *binfil*, +*bscale*, *epix*, *fields*, *fixpix*, *hfix*, *imalign*, *imcentroid*, +*incntr*, *imfunction*, *imreplace*, *imscale*, *interp*, *irafil*, +*joinlines*, *suntoiraf*, *wcsedit*, and *wcsreset*. + +- The new task *hfix* was added to the package. This task allows the + user to extract the image headers into a text file, view or modify + this file with a specified command, and then update the image header + with the modified file. + +- A new task called *suntoiraf* was added to this package. This is a + host dependent task that will most likely be useful only on Sun’s. + This task converts a Sun raster file into an IRAF image. + +- Two new tasks dealing with the WCS were added to this package, + *wcsreset* and *wcsedit*. *wcsreset* resets the coordinate systems in + the image header to the logical coordinate system. *wcsedit* allows + the user to modify the existing WCS or to create a new WCS and then + update the image header. + +- A new version of *bscale* was added to the package. The task now + takes a list of input images and output images. + +- A new version of *imfunction* was added to the package. The task + supports many more functions, for example log10, alog10, ln, aln, + sqrt, square, cbrt, cube, abs, neg, cos, sin, tan, acos, asin, atan, + hcos, hsin, htan, and reciprocal. + +- *imreplace* was modified to support the “ushort” pixel type. + +- The task *join* has been renamed *joinlines*. + +Additions to XTOOLS and MATH +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Programmers may be interested in the following new additions to the +XTOOLS and MATH libraries. + +- The interactive non-linear least squares fitting package INLFIT, + developed by Pedro Gigoux at CTIO, was added to XTOOLS. + +- The 1D image interpolation routines in the MATH library were modified + to support sinc interpolation. + +Glossary of new tasks in the IRAF core system +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++-----------------------+-----------------+----------------------------+ +| Task | Package | Description | ++=======================+=================+============================+ +| gdevices | plot | List available imaging or | +| | | other graphics devices | ++-----------------------+-----------------+----------------------------+ +| hfix | proto | Fix image headers with a | +| | | user specified command | ++-----------------------+-----------------+----------------------------+ +| imcombine | images | Combine images | +| | | pixel-by-pixel using | +| | | various algorithms | ++-----------------------+-----------------+----------------------------+ +| phistogram | plot | Plot or print the | +| | | histogram of an image or | +| | | list | ++-----------------------+-----------------+----------------------------+ +| pradprof | plot | Plot or list the radial | +| | | profile of a stellar | +| | | object | ++-----------------------+-----------------+----------------------------+ +| suntoiraf | proto | Convert Sun rasters into | +| | | IRAF images | ++-----------------------+-----------------+----------------------------+ +| wcsedit | proto | Edit the image coordinate | +| | | system | ++-----------------------+-----------------+----------------------------+ +| wcslab | tv | Overlay a displayed image | +| | | with a world coordinate | +| | | grid | ++-----------------------+-----------------+----------------------------+ +| wcsreset | proto | Reset the image coordinate | +| | | system | ++-----------------------+-----------------+----------------------------+ + +Changes to the NOAO Packages +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +An updated version of the *observatory* task has been installed at the +NOAO level. The task sets observatory parameters from a database of +observatories or from the parameters in the task itself. Many packages +and tasks within the NOAO packages that need information about where the +data was observed use information supplied by the *observatory* task. + +ARTDATA package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A new version of the ARTDATA package was released with IRAF version +2.9.1. A summary of those changes plus modifications since that update +are listed below. A more comprehensive list of the changes included in +V2.9.1 are discussed in IRAF Newsletter Number 10. + +- A new task *mkechelle* has been added that creates artificial 2D + echelle images. + +- A new task *mkexamples* has been added. The task is intended to + generate a variety of artificial images to be used in testing or + demonstrations. + +- A new task *mkheader* adds or modifies image headers using a header + keyword data file. + +- The *mk1dspec* task was modified to create multispec and echelle + format images, line by line. + +- A parameter “header” was added to *mkobjects*, *mknoise*, *mk1dspec*, + and *mk2dspec* so that a header data file could be added to the + output image. Other header parameters are also added to the image + header such as gain, rdnoise, and exptime. + +- A “comments” parameter was added to various tasks to include/exclude + comments in the header of the output image that describe the data + parameters. + +ASTUTIL package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- A new task *gratings* has been added to the package. This task + computes grating parameters; five of the seven parameters must be + specified at one time. + +- A new task *setjd* has been added to the package. *setjd* computes + the geocentric, heliocentric, and integer local Julian dates from + information given in the headers of the input list of images. This + information is then listed or added to the image headers. + +- A few changes were made to *setairmass*. The default value for + “update” was changed to “yes”; an update field was added to the + “show” messages; a warning is printed if both “show” and “update” are + set to “no” indicating that nothing was done. + +DIGIPHOT package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A new version of the DIGIPHOT package was installed. Some changes were +made to the existing APPHOT package used for aperture photometry, and +those are mentioned below. But three new packages have also been +installed, DAOPHOT, PHOTCAL, and PTOOLS. + +DAOPHOT has been available for the past two years as an add-on package +known as TESTPHOT. It is now part of the distributed system. The IRAF +version of DAOPHOT, used to do photometry in crowded fields, has been a +collaborative effort with Peter Stetson and Dennis Crabtree of the DAO. +For the convenience of the many TESTPHOT users, changes to the package +since the last release of TESTPHOT are summarized below. + +PHOTCAL is the photometric calibration package for computing the +transformations of the instrumental magnitudes output from APPHOT and +DAOPHOT to the standard photometric system. This package has been a +collaborative effort with Pedro Gigoux at CTIO. + +PTOOLS is a package containing an assortment of tools for manipulating +the data files produced from APPHOT and DAOPHOT. If users are using +STSDAS TABLES format data files then they must first install the TABLES +layered package. This package can be obtained from either STScI or NOAO +(see ``iraf/contrib`` in the IRAF network archive). + +DIGIPHOT.APPHOT package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- The *apselect* task was replaced with the functionally equivalent + *txdump* task. *txdump* allows the user to select fields of data from + the output data files produced from APPHOT tasks and either simply + list the extracted data or save it in another file. + +- A new task called *pexamine* has been added to the package. + *pexamine* is a general purpose tool for interactively examining and + editing the data files produced from tasks in either APPHOT or + DAOPHOT. This task is intended to complement the batch oriented task + *txdump*. + +- All of the APPHOT tasks will now query to verify the “datamin” and + “datamax” values, if these values are used by the tasks. + +- The time of the observation, i.e. UT, can now be carried over into + the output data files, if a keyword in the image header contains this + information. + +- If there is bad data within the photometry aperture a value of INDEF + will be stored in the data file for that magnitude. + +DIGIPHOT.DAOPHOT (TESTPHOT) package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This is a new package but for the convenience of the many users of the +TESTPHOT add-on package, the changes to TESTPHOT between its last +release and its installation into the DIGIPHOT package as DAOPHOT are +summarized below. + +- The *append*, *convert*, *dump*, *renumber*, *select*, and *sort* + tasks were renamed to *pappend*, *pconvert*, *pdump*, *prenumber*, + *pselect*, and *psort*. + +- The “text” parameter was moved from *daopars* to the DAOPHOT package + parameters. + +- All the DAOPHOT routines were modified so that “psfrad”, “fitrad”, + and “matchrad” are defined in terms of scale. + +- The tasks *allstar*, *group*, *nstar*, *peak*, *psf*, and *substar* + were all modified to include “datamin” and “datamax” in their verify + routines. + +- Support was added for a time of observation parameter to all the + appropriate DAOPHOT tasks. If present, this time will be carried over + into the output data files. + +- All the DAOPHOT tasks except *psf* have been modified to accept lists + of input and output files. + +- The new *pexamine* task was added to this package. *pexamine* is a + general purpose tool for interactively examining and editing the data + files produced from tasks in either APPHOT or DAOPHOT. This task is + intended to complement the batch oriented task *txdump*. + +- Several changes were made to *psf*: the default PSF image header will + now hold up to 66 stars (but it is still dependent on the environment + variable ``min_lenuserarea``); a check was added so that the same + star can not be added to the PSF twice; potential PSF stars are now + rejected if their sky or magnitude values are INDEF; a check was + added so that stars with INDEF valued positions are treated as stars + that were not found. + +- *group* was modified so that the groups are output in y order instead + of in order of the size of the group. + +- Both *group* and *peak* were modified so that stars with INDEF + centers are not written to the output file. + +IMRED package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The spectroscopic packages within the IMRED package have undergone quite +a bit of work and reorganization. The spectroscopic packages are now +ARGUS, CTIOSLIT, ECHELLE, HYDRA, IIDS, IRS, KPNOCOUDE, KPNOSLIT, and +SPECRED. These packages are a collection of tasks from APEXTRACT and +ONEDSPEC that are appropriate for the specific applications. All these +packages use the new versions of the APEXTRACT and ONEDSPEC packages; +the changes for APEXTRACT and ONEDSPEC are summarized below. Earlier +versions of all these packages were released as the NEWIMRED add-on +package. The NEWIMRED package is now defunct and the distributed system +contains the latest versions of these packages. + +The spectroscopic packages now contain “DO” tasks that are scripts that +streamline the reduction process for the user. The “DO” tasks have been +modified for each particular application. + +The ARGUS package is for the reduction of data taken with the CTIO +*argus* instrument. Its corresponding script task is *doargus*. + +The CTIOSLIT package is similar to the ARGUS package except that is a +collection of spectroscopic tasks used for general CTIO slit reductions. +The *doslit* task allows for streamlined reductions. + +The ECHELLE package has the addition of the *doecslit* task for simplied +echelle reductions. The *dofoe* task has been added for the reduction of +Fiber Optic Echelle (FOE) spectra. + +The HYDRA package is used for the reduction of multifiber data taken at +KPNO. The *dohydra* task has been customized for streamlining *nessie* +and *hydra* reductions. + +The KPNOCOUDE package has been customized for the KPNO Coude. The +*doslit* task allows the user to go through the reduction process with +as few keystrokes as possible. The *do3fiber* task is specialized for +the 3 fiber (two arc and one object) instrument. + +The KPNOSLIT package can be used for general slit reductions at KPNO. +The *doslit* task in this package is similar to that in the other +packages. + +The SPECRED package is the old MSRED package, used for general +multispectral reductions. This is a generic package that can be used for +slit and multifiber/ aperture data. General *doslit* and *dofibers* +tasks are available. + +Several of the spectroscopic packages has a special task called +*msresp1d* for creating 1d aperture response corrections from flat and +throughput data. This task is specialized for multiaperture or +multifiber data. + +All of the “DO” tasks have reference manuals that are available in the +network archive in the ``iraf/docs`` directory. + +IMRED.CCDRED package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- A new task *ccdinstrument* was added to the package. The purpose of + this task is to help users create new CCD instrument translation + files to use with the package. + +- The *combine* task (as well as *darkcombine*, *flatcombine*, and + *zerocombine*) is the same task as the new *imcombine* task in + IMAGES. A few parameters were added for compatibility with the CCDRED + tasks. + +- A new parameter was added to *ccdproc* called “minreplace”. Pixel + values in flat fields below the value for “minreplace” are replaced + by the same value (after overscan, zero, and dark corrections). This + avoids dividing by zero problems. + +- The default computation and output “pixeltype” in the package + parameter for CCDRED are both real. Note that both can now be + specified separately. + +- The default parameters for *darkcombine* and *flatcombine* have been + changed. + +NOBSOLETE package added +^^^^^^^^^^^^^^^^^^^^^^^ + +This new package has been defined but currently no tasks reside in it. +This package will be used as a repository for tasks that have been +replaced by newer tasks in the NOAO packages. The NOBSOLETE tasks will +then be removed at the time of the next release. + +NPROTO package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The old PROTO package was divided into two separate packages, one called +PROTO that now resides in the IRAF core system and the other called +NPROTO that resides in the NOAO package. The current NPROTO tasks are +*binpairs*, *findgain*, *findthresh*, *iralign*, *irmatch1d*, +*irmatch2d*, *irmosaic*, *linpol*, and *slitpic*. The *imedit*, +*imexamine*, and *tvmark* tasks were moved to the IMAGES.TV package. The +*ndprep* task was moved to ONEDSPEC. All other tasks were moved to the +PROTO package at the core level. + +- Two new tasks called *findgain* and *findthresh* were added to this + package. *findgain* determines the gain and read noise of a CCD from + a pair of dome flats and from a pair of bias/zero frames using the + Janesick method. *findthresh* estimates the background noise level of + the CCD using a sky frame and the gain and readnoise of the CCD. + +- A new task called *linpol* has been added to the PROTO package. This + task calculates the pixel-by-pixel fractional linear polarization and + polarization angle for three or four images. The polarizer must be + set at even multiples of a 45 degree position angle. + +- The task *ndprep* used for CTIO 2DFRUTTI reductions was moved to the + ONEDSPEC package. + +- The task *toonedspec* was removed since its function can now be + performed by the *onedspec.scopy* task. + +ONEDSPEC package reductions +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +There have been significant changes to the ONEDSPEC package. A more +detailed revisions summary is available in the IRAF network archive as +file ``onedv210.ps.Z`` in the subdirectory ``iraf/docs``. + +The new package supports a variety of spectral image formats. The older +formats can still be read. In particular the one dimensional “onedspec” +and the two dimensional “multispec” format will still be acceptable as +input. Note that the image naming syntax for the “onedspec” format using +record number extensions is a separate issue and is still provided but +only in the IMRED.IIDS and IMRED.IRS packages. Any new spectra created +are either a one dimensional format using relatively simple keywords and +a two or three dimensional format which treats each line of the image as +a separate spectrum and uses a more complex world coordinate system and +keywords. For the sake of discussion the two formats are still called +“onedspec” and “multispec” though they are not equivalent to the earlier +formats. + +In addition, the one dimensional spectral tasks may also operate on two +dimensional images. This is done by using the “dispaxis” keyword in the +image header or a package dispaxis parameter if the keyword is missing +to define the dispersion axis. In addition there is a summing parameter +in the package to allow summing a number of lines or columns. If the +spectra are wavelength calibrated long slit spectra, the product of the +*longslit.transform* task, the wavelength information will also be +properly handled. Thus, one may use *splot* or *specplot* for plotting +such data without having to extract them to another format. If one wants +to extract one dimensional spectra by summing columns or lines, as +opposed to using the more complex APEXTRACT package, then one can simply +use *scopy* (this effectively replaces *proto.toonedspec*) + +Another major change to the package is that spectra no longer need to be +interpolated to a uniform sampling in wavelength. The dispersion +functions determined by *identify*/*reidentify* can now be carried along +with the spectra in the image headers and recognized throughout the +package and the IRAF core system. Thus the WCS has been fully +implemented in the ONEDSPEC tasks and although much is to be gained by +this it can cause problems with earlier IRAF systems as well as making +it difficult to import data into non-IRAF software. But it is now +possible to use *imcopy* with an image section on a spectrum, for +instance, and have the wavelength information retained correctly. + +A sinc interpolator is now available for those tasks doing geometric +corrections or interpolations. This option can be selected by setting +the “interp” parameter in the ONEDSPEC package parameters. + +Other changes are summarized: + +- The new task *deredden* corrects input spectra for interstellar + extinction, or reddening. + +- The new task *dopcor* corrects input spectra by removing a specified + doppler velocity. The opposite sign can be used to add a doppler + shift to a spectrum. + +- The new task *fitprofs* fits 1D gaussian profiles to spectral lines + or features in an image line or column. This is done noninteractively + and driven by an input list of feature positions. + +- The task *ndprep* was moved to this package from the PROTO package. + *ndprep* is used for CTIO *2DFRUTTI* reductions. + +- The new task *sapertures* adds or modifies beam numbers and aperture + titles for selected apertures based on an aperture identification + file. + +- The new task *sarith* does spectral arithmetic and includes unary + operators. The arithmetic can be performed on separate input spectra + or on apertures within a multispec format image. + +- The task *scombine* has been added to the package. This new task is + similar to the new *imcombine* task in the IMAGES package but is + specialized for spectral data. + +- The new task *scopy* copies subsets of apertures and does format + conversions between the different spectrum formats. + +- The new task *sfit* fits spectra and outputs the fits in various + ways. This includes a new feature to replace deviant points by the + fit. Apertures in multispec and echelle format are fit independently. + +- The tasks *addsets*, *batchred*, *bswitch*, *coincor*, *flatdiv*, + *flatfit*, *subsets* and *sums* were moved to the IIDS and IRS + packages. + +- The task *combine* was removed with the all new *scombine* suggested + in its place. + +- The tasks *rebin*, *sflip* and *shedit* were removed from the + package. Rebinning of spectra can now be done with *scopy* or + *dispcor*. *scopy* and *imcopy* can now be used in place of *sflip*. + And *hedit* is an alternative for *shedit*. + +- *bplot* and *slist* have been modified to support the multispec + format. + +- The task *continuum* now does independent fits for multispec and + echelle format spectra. + +- There is now only one *dispcor* task doing the work of the three + previous tasks *dispcor*, *msdispcor* and *ecdispcor*. Several of the + parameters for this task have been changed. The old “recformat” and + “records” parameters for supporting the old onedspec format have been + removed except in the IIDS/IRS packages. A “linearize” parameter has + been added for setting the interpolation to yes or no on output. The + “interpolation” parameter was removed since this information is now + read from the package parameter “interp”. The “ignoreaps” parameter + has been changed to “samedisp”. + +- *identify* and *reidentify* now treat multispec format spectra and + two dimensional images as a unit allowing easy movement between + different image lines or columns. The database is only updated upon + exiting the image. The “j”, “k”, and “o” keys have been added to the + interactive sessions to allow for scrolling through the different + lines in a two dimensional image. The database format now uses + aperture numbers rather than image sections for multispec format + spectra. + +- The task *specplot* has new parameters “apertures” and “bands” to + select spectra for plotting in the multispec format. + +- *splot* now allows deblending of any number of components and allows + simultaneous fitting of a linear background. Several cursor keys have + been redefined and colon commands have been added to fully support + the new multispec format and to add even more flexibility to the task + than before! Please see the help pages for details. + +- The *reidentify* task is essentially a new task. The important + changes are an interactive review option, the ability to add features + from a line list, using the same reference spectrum for all other + spectra in a 2D reference image rather than “tracing” (using the + results of the last reidentification as the initial guess for the + next one) across the image, and matching image + lines/columns/apertures from a 2D reference image to other 2D images + rather than “tracing” again. + +RV package added +^^^^^^^^^^^^^^^^ + +This is a new package installed with IRAF version 2.10. A version of +this package, RV0, has been available as an add-on for the past year or +so. The package contains one main task *fxcor* that performs a Fourier +cross-correlation on the input list of spectra. The package supports the +multispec format. + +TWODSPEC package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The old MULTISPEC package that has resided in the TWODSPEC package for +years has been disabled. The code is still there for browsing, however, +and the package can be resurrected easily if needed. + +The *observatory* task was moved to the NOAO package itself. The +*setairmass* task was moved to LONGSLIT. And the *setdisp* task is no +longer needed; task or package parameters are used in its place. + +Changes to the APEXTRACT and LONGSLIT packages are summarized below. + +TWODSPEC.APEXTRACT package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A new version, version 3, of the IRAF APEXTRACT package has been +completed. A detailed revisions summary is available in the IRAF network +archive (file ``apexv210.ps.Z`` in ``iraf/docs``). + +There were three goals for the new package: new and improved cleaning +and variance weighting (optimal extraction) algorithms, the addition of +recommended or desirable new tasks and algorithms (particularly to +support large numbers of spectra from fiber and aperture mask +instruments), and special support for the new image reduction scripts in +the various IMRED packages. + +The multispec format, the default image format for all spectroscopic +packages except IIDS and IRS, is either 2D or 3D (the 3D format is new +with this release). The 3D format is produced when the parameter +“extras” is set to yes in the extraction tasks. The basic 2D format, +which applies to the first plane of the 3D format, has each 1D aperture +spectra extracted in a line. Thus, the first coordinate is the pixel +coordinate along the spectra. The second coordinate refers to the +separate apertures. The third coordinate contains extra information +associated with the spectrum in the first plane. The extra planes are: + +- 1: Primary spectra which are variance and/or cosmic ray cleaned +- 2: Spectra which are not weighted or cleaned +- 3: Sky spectra when using background subtraction +- 4: Estimated sigma of the extracted spectra + +If background subtraction is not done then 4 moves down to plane 3. + +:: + + output.ms[*,*,1] = all primary spectra + output.ms[*,5,1] = 5th aperture spectrum which is cleaned + output.ms[*,5,2] = raw/uncleaned 5th aperture spectrum + output.ms[*,5,3] = sky for 5th spectrum + output.ms[*,5,4] = sigma of 5th spectrum + +The following summarizes the major new features and changes. + +- New techniques for cleaning and variance weighting extracted spectra + have been implemented. + +- Special features for automatically numbering and identifying large + numbers of apertures have been added. + +- There is no longer a limit to the number of apertures that can be + extracted. + +- The new task *apall* integrates all the parameters used for one + dimensional extraction of spectra. + +- The new task *apfit* provides various types of fitting for two + dimensional multiobject spectra. + +- The new task *apflatten* creates flat fields from fiber and slitlet + spectra. + +- The new task *apmask* creates mask images from aperture definitions + using the new pixel list image format. No tasks have yet been + written, however, to use this new mask image format. + +- The new tasks and algorithms, *aprecenter* and *apresize*, will + automatically recenter and resize aperture definitions. + +- The task *apio* is defunct. Its functionality has been replaced by + the APEXTRACT package parameters. + +- The task *apstrip* has been removed. + +- Minor changes have been made to the old “AP” tasks to accommodate + these new changes in the package; in some cases new parameters have + been added to the task and in other cases new cursor options have + been implemented. See the help pages for details. + +TWODSPEC.LONGSLIT package modifications +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- The “dispaxis” parameter was added to the package parameters. This + value is used unless DISPAXIS is in the image header. + +Glossary of new tasks in the NOAO packages +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++--------------+--------------------+---------------------------------+ +| Task | Package | Description | ++==============+====================+=================================+ +| addstar | daophot | Add artificial stars to an | +| | | image using the computed psf | ++--------------+--------------------+---------------------------------+ +| allstar | daophot | Group and fit psf to multiple | +| | | stars simultaneously | ++--------------+--------------------+---------------------------------+ +| apall | apextract | Extract 1D spectra (all | +| | | parameters in one task) | ++--------------+--------------------+---------------------------------+ +| apfit | apextract | Fit 2D spectra and output the | +| | | fit, difference, or ratio | ++--------------+--------------------+---------------------------------+ +| apflatten | apextract | Remove overall spectral and | +| | | profile shapes from flat fields | ++--------------+--------------------+---------------------------------+ +| apmask | apextract | Create and IRAF pixel list mask | +| | | of the apertures | ++--------------+--------------------+---------------------------------+ +| aprecenter | apextract | Recenter apertures | ++--------------+--------------------+---------------------------------+ +| apresize | apextract | Resize apertures | ++--------------+--------------------+---------------------------------+ +| c | ccdred | Review and edit instrument | +| cdinstrument | | translation files | ++--------------+--------------------+---------------------------------+ +| centerpars | daophot | Edit the centering algorithm | +| | | parameters | ++--------------+--------------------+---------------------------------+ +| chkconfig | photcal | Check the configuration file | +| | | for grammar and syntax errors | ++--------------+--------------------+---------------------------------+ +| continpars | rv | Edit continuum subtraction | +| | | parameters | ++--------------+--------------------+---------------------------------+ +| daofind | daophot | Find stars in an image using | +| | | the DAO algorithm | ++--------------+--------------------+---------------------------------+ +| daopars | daophot | Edit the daophot algorithms | +| | | parameter set | ++--------------+--------------------+---------------------------------+ +| datapars | daophot | Edit the data dependent | +| | | parameters | ++--------------+--------------------+---------------------------------+ +| deredden | onedspec | Apply interstellar extinction | +| | | correction | ++--------------+--------------------+---------------------------------+ +| do3fiber | kpnocoude | Process KPNO coude three fiber | +| | | spectra | ++--------------+--------------------+---------------------------------+ +| doargus | argus | Process ARGUS spectra | ++--------------+--------------------+---------------------------------+ +| doecslit | echelle | Process Echelle slit spectra | ++--------------+--------------------+---------------------------------+ +| dofibers | specred | Process fiber spectra | ++--------------+--------------------+---------------------------------+ +| dofoe | echelle | Process Fiber Optic Echelle | +| | | (FOE) spectra | ++--------------+--------------------+---------------------------------+ +| dohydra | hydra | Process HYDRA spectra | ++--------------+--------------------+---------------------------------+ +| dopcor | onedspec | Apply doppler corrections | ++--------------+--------------------+---------------------------------+ +| doslit | ctioslit | Process CTIO slit spectra | ++--------------+--------------------+---------------------------------+ +| doslit | kpnocoude | Process KPNO coude slit spectra | ++--------------+--------------------+---------------------------------+ +| doslit | kpnoslit | Process slit spectra | ++--------------+--------------------+---------------------------------+ +| doslit | specred | Process slit spectra | ++--------------+--------------------+---------------------------------+ +| evalfit | photcal | Compute the standard indices by | +| | | evaluating the fit | ++--------------+--------------------+---------------------------------+ +| filtpars | rv | Edit the filter function | +| | | parameters | ++--------------+--------------------+---------------------------------+ +| findgain | nproto | Estimate the gain and readnoise | +| | | of a CCD | ++--------------+--------------------+---------------------------------+ +| findthresh | nproto | Estimate a CCD’s sky noise from | +| | | the gain and readnoise | ++--------------+--------------------+---------------------------------+ +| fitparams | photcal | Compute the parameters of the | +| | | transformation equations | ++--------------+--------------------+---------------------------------+ +| fitprofs | onedspec | Fit gaussian profiles | ++--------------+--------------------+---------------------------------+ +| fitskypars | daophot | Edit the sky fitting algorithm | +| | | parameters | ++--------------+--------------------+---------------------------------+ +| fxcor | rv | Radial velocities via Fourier | +| | | cross correlation | ++--------------+--------------------+---------------------------------+ +| gratings | astutil | Compute and print grating | +| | | parameters | ++--------------+--------------------+---------------------------------+ +| group | daophot | Group stars based on positional | +| | | overlap and signal/noise | ++--------------+--------------------+---------------------------------+ +| grpselect | daophot | Select groups of a specified | +| | | size from a daophot database | ++--------------+--------------------+---------------------------------+ +| invertfit | photcal | Compute the standard indices by | +| | | inverting the fit | ++--------------+--------------------+---------------------------------+ +| istable | ptools | Is a file a table or text | +| | | database file ? | ++--------------+--------------------+---------------------------------+ +| linpol | nproto | Calculate polarization frames | +| | | and Stoke’s parameters | ++--------------+--------------------+---------------------------------+ +| keywpars | rv | Translate the image header | +| | | keywords used in RV package | ++--------------+--------------------+---------------------------------+ +| mkcatalog | photcal | Type in a standard star catalog | +| | | or observations file | ++--------------+--------------------+---------------------------------+ +| mkconfig | photcal | Prepare a configuration file | ++--------------+--------------------+---------------------------------+ +| mkechelle | artdata | Make artificial 1D and 2D | +| | | echelle spectra | ++--------------+--------------------+---------------------------------+ +| mkexamples | artdata | Make artificial data examples | ++--------------+--------------------+---------------------------------+ +| mkheader | artdata | Append/replace header | +| | | parameters | ++--------------+--------------------+---------------------------------+ +| mkimsets | photcal | Prepare an image set file for | +| | | input to (mk)(n)obsfile | ++--------------+--------------------+---------------------------------+ +| mk(n)obsfile | photcal | Prepare a single | +| | | (multi)-starfield observations | +| | | file from apphot/daophot output | ++--------------+--------------------+---------------------------------+ +| mkphotcors | photcal | Type in/check any photometric | +| | | corrections files required by | +| | | mk(n)obsfile | ++--------------+--------------------+---------------------------------+ +| msresp1d | argus | Create 1D response spectra from | +| | | flat field and sky spectra | ++--------------+--------------------+---------------------------------+ +| msresp1d | hydra | Create 1D response spectra from | +| | | flat field and sky spectra | ++--------------+--------------------+---------------------------------+ +| msresp1d | kpnocoude | Create fiber response spectra | +| | | from flat field and sky spectra | ++--------------+--------------------+---------------------------------+ +| msresp1d | specred | Create 1D response spectra from | +| | | flat field and sky spectra | ++--------------+--------------------+---------------------------------+ +| nstar | daophot | Fit the psf to groups of stars | +| | | simultaneously | ++--------------+--------------------+---------------------------------+ +| obsfile | photcal | Prepare a single | +| | | (multi)-starfield observations | +| | | file from a user-created text | +| | | file | ++--------------+--------------------+---------------------------------+ +| pappend | daophot | Concatenate a list of daophot | +| | | databases | ++--------------+--------------------+---------------------------------+ +| pappend | ptools | Concatenate a list of | +| | | apphot/daophot databases | ++--------------+--------------------+---------------------------------+ +| pconvert | daophot | Convert a text database to a | +| | | tables database | ++--------------+--------------------+---------------------------------+ +| pconvert | ptools | Convert from an apphot/daophot | +| | | text to tables database | ++--------------+--------------------+---------------------------------+ +| pdump | daophot | Print selected fields from a | +| | | list of daophot databases | ++--------------+--------------------+---------------------------------+ +| pdump | ptools | Print selected columns of a | +| | | list of daophot/apphot | +| | | databases | ++--------------+--------------------+---------------------------------+ +| peak | daophot | Fit the psf to single stars | ++--------------+--------------------+---------------------------------+ +| pexamine | apphot | Interactively examine or edit | +| | | an apphot output file | ++--------------+--------------------+---------------------------------+ +| pexamine | daophot | Interactively examine and edit | +| | | a daophot database | ++--------------+--------------------+---------------------------------+ +| pexamine | ptools | Interactively examine and edit | +| | | an apphot/daophot database | ++--------------+--------------------+---------------------------------+ +| phot | daophot | Compute sky values and initial | +| | | magnitudes for a list of stars | ++--------------+--------------------+---------------------------------+ +| photpars | daophot | Edit the photometry parameters | ++--------------+--------------------+---------------------------------+ +| prenumber | daophot | Renumber stars in a daophot | +| | | database | ++--------------+--------------------+---------------------------------+ +| prenumber | ptools | Renumber a list of | +| | | apphot/daophot databases | ++--------------+--------------------+---------------------------------+ +| pselect | daophot | Select records from a daophot | +| | | database | ++--------------+--------------------+---------------------------------+ +| pselect | ptools | Select records from a list of | +| | | apphot/daophot databases | ++--------------+--------------------+---------------------------------+ +| psf | daophot | Fit the point spread function | ++--------------+--------------------+---------------------------------+ +| psort | daophot | Sort a daophot database | ++--------------+--------------------+---------------------------------+ +| psort | ptools | Sort a list of apphot/daophot | +| | | databases | ++--------------+--------------------+---------------------------------+ +| sapertures | onedspec | Set or change aperture header | +| | | information | ++--------------+--------------------+---------------------------------+ +| sarith | onedspec | Spectrum arithmetic | ++--------------+--------------------+---------------------------------+ +| scombine | onedspec | Combine spectra having | +| | | different wavelength ranges | ++--------------+--------------------+---------------------------------+ +| scopy | onedspec | Select and copy apertures in | +| | | different spectral formats | ++--------------+--------------------+---------------------------------+ +| seepsf | daophot | Compute an image of the point | +| | | spread function | ++--------------+--------------------+---------------------------------+ +| setjd | astutil | Compute and set Julian dates in | +| | | images | ++--------------+--------------------+---------------------------------+ +| sfit | onedspec | Fit spectra and output fit, | +| | | ratio, or difference | ++--------------+--------------------+---------------------------------+ +| substar | daophot | Subtract the fitted stars from | +| | | the original image | ++--------------+--------------------+---------------------------------+ +| tbappend | ptools | Concatenate a list of | +| | | apphot/daophot tables databases | ++--------------+--------------------+---------------------------------+ +| tbdump | ptools | Print selected columns of a | +| | | list of tables databases | ++--------------+--------------------+---------------------------------+ +| tbrenumber | ptools | Renumber a list of | +| | | apphot/daophot tables databases | ++--------------+--------------------+---------------------------------+ +| tbselect | ptools | Select records from a list of | +| | | apphot/daophot tables databases | ++--------------+--------------------+---------------------------------+ +| tbsort | ptools | Sort a list of apphot/daophot | +| | | tables databases | ++--------------+--------------------+---------------------------------+ +| txappend | ptools | Concatenate a list of | +| | | apphot/daophot text databases | ++--------------+--------------------+---------------------------------+ +| txdump | apphot | Dump selected fields from an | +| | | apphot output file | ++--------------+--------------------+---------------------------------+ +| txdump | ptools | Print selected columns of a | +| | | list of apphot/daophot text | +| | | databases | ++--------------+--------------------+---------------------------------+ +| txrenumber | ptools | Renumber a list of | +| | | apphot/daophot text databases | ++--------------+--------------------+---------------------------------+ +| txselect | ptools | Select records from a list of | +| | | apphot/daophot text databases | ++--------------+--------------------+---------------------------------+ +| txsort | ptools | Sort a list of apphot/daophot | +| | | text databases | ++--------------+--------------------+---------------------------------+ + +Programming Environment Revisions +--------------------------------- + +.. _compatibility-issues-1: + +Compatibility Issues +~~~~~~~~~~~~~~~~~~~~ + +V2.10 IRAF requires that any local IRAF programs external to the V2.10 +system (such as layered packages or locally written tasks) be *fully +recompiled* if they are relinked against V2.10. The problem arises only +if the programs are relinked; external programs will continue to run +after V2.10 is installed, but linker errors will be seen if the programs +are relinked without being fully recompiled. This is because the +internal names of some important system routines were changed in V2.10 +to avoid name clashes with host system routines. For example, the SPP +procedure “rename” is now translated to “xfrnam” when the SPP code it +appears in is compiled. + +As always, actual interface changes affecting existing source code were +very few. The macro “E” in ```` was renamed to “BASE_E” to +minimize the chance of an accidental name collision. The calling +sequence for the *onentry* procedure (ETC) was changed, but since this +is a little used system procedure very few tasks should be affected. A +number of new procedures were added to MTIO and the syntax of a magtape +device has changed; old applications should be modified to use the MTIO +procedures to operate upon magtape device names. + +These and other revisions affecting the programming environment are +discussed in more detail below. + +Portability Issues +~~~~~~~~~~~~~~~~~~ + +The V2.10 UNIX/IRAF kernel now includes “#ifdef SYSV” support for System +V UNIX, making it easier to port IRAF to SysV based systems. The +UNIX/IRAF HSI (host system interface) is still not as portable to UNIX +variants as it could be, but at this point it is easier for us to make +the minor revisions required for a new port than to further refine the +HSI. The disadvantage is that it is harder than it should be for people +in the community to do their own IRAF ports, due to the level of IRAF +expertise required to tune the code. Someday we plan to generate a +generic-UNIX HSI. Note that these comments pertain only to the few +thousand lines of code in the HSI - the bulk of the IRAF code is 100% +portable (identical on all IRAF systems) as it has always been. + +The recent port of IRAF to A/UX (the Apple Macintosh UNIX) is +interesting from a portability standpoint because we used the publically +available Fortran to C translator *f2c* plus the GNU C compiler *gcc* to +compile all the SPP and Fortran code in IRAF. This was remarkably +successful and means that the IRAF code is now portable to any system +with a C compiler. In the process of performing these compilations a few +dozen minor bugs were found by the static compile time checking +performed by *f2c* and *gcc*. The IRAF C code was run through *gcc* with +ANSI mode enabled, and hence should now be ANSI-C compatible. The GNU +debugger *gdb* proved to be an effective tool for debugging of IRAF code +compiled with *gcc*. + +Software Tools +~~~~~~~~~~~~~~ + +LOGIPC feature +^^^^^^^^^^^^^^ + +A new facility has been added to UNIX/IRAF (all systems) for debugging +interprocess communication (IPC). This feature will also be useful for +debugging tasks standalone, particularly in cases where a bug seen when +running a task from the CL is difficult to reproduce when the task is +run standalone. The new facility allows one to carry out a normal IRAF +session while transparently logging all interprocess communications. +Each process can then be rerun individually using the logged IPC to +exactly duplicate the functioning of the process to, e.g., examine the +program operation in detail under a debugger. + +The facility is this: if LOGIPC is defined in the host environment when +an iraf process is started, the process will create two files +*pid\ ``.in`` and*\ pid\ ``.out``, where *pid* is the process id. +Everything read from the IPC input file is copied to the ``.in`` file, +and everything written to the IPC output (i.e., sent back to the CL) is +copied to the ``.out`` file. This is done only for connected +subprocesses. It will work for any connected subprocess, e.g., normal +cached processes and graphics subkernels in both foreground and +background CLs, but not the i/o of the CL itself since the CL is not +driven by IPC. + +The IPC streams saved are an exact binary copy of whatever was sent via +IPC, including the binary IPC packet headers, and binary graphics data, +and so on. All the IPC communications used to start up the process, run +zero or more tasks, and close the process down will be logged. Most IPC +traffic is textual in nature so it will usually be possible to examine +the IPC files with a file pager, although the results may be less than +satisfactory if binary data such as a graphics metacode stream is +logged. It is not necessary to examine the IPC files to use them for +process execution or debugging. + +A particularly interesting use of this feature is to allow a process to +be run under the CL in the normal fashion, then rerun under a host level +debugger using the saved IPC input to duplicate the input and actions of +the process when run under the CL. For example, + +:: + + % setenv LOGIPC + % cl + cl> dir + cl> logout + % unsetenv LOGIPC + +will run the CL, saving the IPC of all subprocesses, +e.g. ``x_system.e``. We can then run the system process manually, using +the saved IPC input: + +:: + + % $iraf/bin/x_system.e -c < *pid.in + +To run the process under *adb* or *dbx*, using the saved input: + +:: + + % adb $iraf/bin/x_system.e + :r r -c < pid.in + +Note that the redirection has to be given first for *adb*, and last for +*dbx*. This also works for *gdb* using the *run* command. Some +implementations of *adb* are picky about syntax and will not allow a +space between the “<” and the process id in the :r command. + +Running a task in this way is not identical to running the task +standalone, e.g. using a *dparam* file for parameter input, because the +full runtime context of the process as run under the CL is reproduced by +LOGIPC but not when the task is run standalone. The differences are +subtle but can be important when trying to reproduce a bug seen when the +process is run under the CL. It is often the case that a bug seen when a +task is run from the CL will disappear when the task is run standalone, +but in most cases LOGIPC will duplicate the bug. + +XC changes +^^^^^^^^^^ + +The *xc* program (IRAF compiler-linker) underwent the following changes +for V2.10, in addition to the usual host-system specific changes +required to support new host compiler versions. + +Multiple “-p pkgname” arguments are now supported. These are used when +compiling a module which uses multiple package environments, e.g., + +:: + + cl> xc -p noao -p tables foo.x + +Each package environment may define package environment variables, +directories to be searched for include files and libraries, and so on. +Package environments are used by the IRAF layered packages. + +Host libraries named on the command line using the -l switch (e.g., +“-lresolv”) are now searched after the IRAF system libraries, rather +than before as in previous versions of *xc*. If the host library is +referenced by absolute pathname it is still searched before the IRAF +libraries, since the command line order determines the search order. + +SPPLINT code checker +^^^^^^^^^^^^^^^^^^^^ + +A static code checker utility *spplint* has been developed for checking +SPP programs. This uses the SPP translation utilities in IRAF to convert +SPP to Fortran, *f2c* to generate C code, and *lint* to check the C +code. The code is checked in various ways at all phases of translation. +Some of the most useful checking are performed by *f2c*, which checks +the number and type of arguments in all calls to IRAF VOS library +procedures. In other words, *spplint* will determine if an IRAF library +procedure is called incorrectly, as well as perform a variety of other +checks. + +The *spplint* utility is not included in the main IRAF release, but is +available separately. Contact the IRAF project for information on the +availability of this and other optional code development utilities. + +Multiple architecture support +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Multiple architecture support is a way of using multiple sets of +compiled program binaries within a single copy of IRAF. Multiple sets of +binaries are used to support different machine architectures (e.g. sparc +and Motorola), different compiler options (floating point options, +vectorization options, profiling options), different compilers, and so +on. + +The command for checking the architecture of the IRAF core system or a +layered package has been changed from *showfloat* to *arch* to reflect +the fact that multiple architecture support is no longer used merely to +select the floating point option. + +:: + + cl> mkpkg arch + sparc + +The default architecture of the distributed system is “generic”, meaning +no specific architecture has been set (the source tree is generic, not +configured for any particular architecture). + +It is suggested that developers of layered software for IRAF adopt this +same convention in their root *mkpkg* files. + +Package environments +^^^^^^^^^^^^^^^^^^^^ + +All the HSI software utilities now permit multiple “-p pkgname” package +environment references. The host ``PKGENV`` environment variable now +also permits multiple package environments to be referenced, e.g. + +:: + + % setenv PKGENV "noao tables xray" + +The package names should be whitespace delimited (``PKGENV`` is used to +avoid having to give the “-p” flags on the *mkpkg* or *xc* command +line). To successfully load a package enironment, the package root +directory must be defined in ``hlib$extern.pkg`` or in the user’s host +environment. A host environment definition will override the value given +in extern.pkg. + +Finding module sources +^^^^^^^^^^^^^^^^^^^^^^ + +IRAF V2.10 includes a “tags” file in the IRAF root directory to aid +software development. This file contains an index to all procedures in +the IRAF VOS and HSI and can be used with host editors such as *vi* to +rapidly find and display the source for IRAF system procedures. Note +that the names of the kernel procedures are given in upper case, e.g., +“ZOPNBF”, whereas the names of the VOS procedures are given in lower +case. To use the tags file with *vi*, start the editor at the IRAF root +directory and while in the editor, type a command such as “:ta foo” to +view the source for procedure *foo*. + +Programming Interface Changes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +IEEE floating support +^^^^^^^^^^^^^^^^^^^^^ + +Modifications were made to the IEEE floating conversion routines in the +OSB package to support NaN mapping. This is a low level package used by, +e.g., the MII package in ETC. The interface as it currently stands is +summarized below. + +:: + + ieepak[rd] (datum) # pack scalar value + ieeupk[rd] (datum) # unpack scalar value + ieevpak[rd] (native, ieee, nelem) # pack vector + ieevupk[rd] (ieee, native, nelem) # unpack vector + iee[sg]nan[rd] (NaN) # set/get NaN value + ieemap[rd] (mapin, mapout) # enable/disable NaN mapping + ieestat[rd] (nin, nout) # get count of NaN values + ieezstat[rd] () # zero NaN counters + +The new or modified routines are *ieesnan*, *ieegnan*, *ieemap*, +*ieestat*, and *ieezstat*. By NaN (not-a-number) we refer collectively +to all IEEE non-arithmetic values, not just IEEE NaN. The routines +*ieesnan* and *ieegnan* set or get the native floating value used to +replace NaNs or overflows occurring when converting IEEE to the native +floating format (any floating value will do, e.g., zero or INDEF). If +NaN mapping is enabled, the *ieestat* routines may be used to determine +the number of input or output NaN conversions occurring since the last +call to *ieezstat*. Both real and double versions of all routines are +provided. + +The NaN mapping enable switch and statistics counters are undefined at +process startup; programs which use the IEEE conversion package should +call *ieemap* to enable or disable NaN mapping, and *ieezstat* to +initialize the statistics counters. + +MATH libraries +^^^^^^^^^^^^^^ + +The following changes were made to the MATH libraries in the IRAF core +system. Refer to the online help pages of the affected routines for +detailed information. + +- The one-dimensional image interpolation library **iminterp** was + modified to add support for sinc interpolation. + +- A new library **nlfit** was added for non-linear function fitting. An + interactive graphics front end to this was also added in XTOOLS. + +- The name of the symbol ``E`` in ```` was changed to + ``BASE_E`` to minimize the chance of name clashes. + +CLIO interface +^^^^^^^^^^^^^^ + +The CLIO (command language i/o) interface underwent the following +changes for version 2.10 IRAF. + +- A README file was added to the source directory containing an up to + date interface summary. + +- The routines *clgpset* and *clppset* (get/put string valued + parameter) were renamed *clgpseta* and *clppseta*. The old procedures + were retained for compatibility but are now obsolete and may at some + point in the future disappear or be reused for some other function. + +- Two new routines *cllpset* and *clepset* were added for listing and + editing psets (parameter sets). + +The calling sequences for the new pset routines are as follows. + +:: + + cllpset (pp, fd, format) # list pset + clepset (pp) # edit pset + +These new routines are still considered experimental and should be +avoided or used with caution (they could change). + +Internal to the CLIO code, the CLIO parameter caching package underwent +minor changes to add a new *clc_compress* routine and improve pset +handling, as part of the minilanguage support effort. + +ETC interface +^^^^^^^^^^^^^ + +The ETC interface contains miscellaneous system interface routines. The +ETC interface underwent the following changes for V2.10 IRAF. + +Calling sequence for onentry changed +'''''''''''''''''''''''''''''''''''' + +The calling sequence for the *onentry* routine was changed. The new +calling sequence is as follows. + +:: + + action = onentry (prtype, bkgfile, cmd) + +The *onentry* procedure is an optional procedure which is called when an +IRAF process starts up. Normally the onentry procedure is a no-op, +passing control to the IRAF main in-task interpreter. Custom IRAF +applications, e.g., the CL, have a special *onentry* procedure which +replaces the default in-task interpreter. + +The change made to the *onentry* calling sequence was the addition of +the additional argument *cmd*. This argument receives the command line +used to invoke the IRAF process at the host level. The application can +parse this command line to extract arguments, allowing the IRAF process +to operate as a host program (it is already possible to call any IRAF +task from the host level, but use of an *onentry* procedure allows the +in-task interpreter to be bypassed and gives the application control +over parsing the command line). + +See ``etc$onentry.x`` for additional information on how to use this +procedure. + +New onerror and onexit procedures +''''''''''''''''''''''''''''''''' + +Two new procedures *onerror_remove* and *onexit_remove* were added. +These have the following calling sequences. + +:: + + onerror_remove (proc) # remove posted onerror procedure + onexit_remove (proc) # remove posted onexit procedure + +The new routines are used to remove *onerror* or *onexit* procedures +posted by a task during task execution. Such user procedures are called +if the task aborts (*onerror* procedures) or during normal task exit +(*onexit* procedures). Formerly there was no way to “unpost” the +procedures other than by the normal cleanup occurring during task +termination. + +New gqsort routine +'''''''''''''''''' + +A new quick-sort routine *gqsort* (generalized quick sort) was added. +This has the following calling sequence. + +:: + + gqsort (x, nelem, compare, client_data) + +*gqsort* is identical to the old *qsort* routine except for the addition +of the fourth argument *client_data*. This is an integer value which is +passed on to the *compare* procedure during sorting to compare two data +values. The *compare* routine is called as follows. + +:: + + result = compare (client_data, x1, x2) + +The new routine eliminates the need to use a common area to pass +information to the compare routine, as was often necessary with *qsort*. + +FIO interface +^^^^^^^^^^^^^ + +The FIO interface (file i/o) underwent minor changes to fix some bugs +affecting pushed back data. The ``F_UNREAD`` file status parameter will +now correctly report pushed back data as well as any buffered input file +data. The ``F_CANCEL`` file set option will now cancel any pushed back +data. + +Nonblocking terminal i/o +'''''''''''''''''''''''' + +A new nonblocking form of raw mode terminal input has been added. This +permits polling the terminal for input without blocking (suspending +process execution) if no input is available. In a character read, EOF is +returned if no input is available otherwise the character value is +returned. An example illustrating the use of nonblocking terminal i/o +follows. + +:: + + include + + task foo + + procedure foo() + int fd, ch + int getci() + + begin + fd = STDIN + call fseti (fd, F_IOMODE, IO_RAW+IO_NDELAY) + + repeat { + if (getci(fd,ch) == EOF) + call printf ("no pending input\\\\r\n") + else { + call printf ("ch = %03o\\\\r\n") + call pargi (ch) + } + call sleep (1) + } until (ch == '\\\\004' || ch == 'q') + + call fseti (fd, F_IOMODE, IO_NORMAL) + end + +This sample program sets the terminal i/o mode to nonblocking raw mode +and polls the terminal once per second, printing the character value in +octal if a character is typed on the terminal, exiting when ctrl/d or +‘q’ is typed. Note that in raw mode characters such as ctrl/d or ctrl/c +are passed through as data and do not get mapped to EOF, generate an +interrupt, and so on. Raw mode i/o such as this will work both when +running a task under the CL and standalone, and in combination with IRAF +networking (e.g. to access a remote device). + +Nonblocking terminal input is used in applications which run +continuously but which we wish to be able to control interactively. + +FMTIO interface +^^^^^^^^^^^^^^^ + +The FMTIO interface (formatted i/o) is used to format output text or +decode input text. The V2.10 release adds two new *printf* output +formats, ``%H`` and ``%M``. These are used to print numbers in +hours-minutes-seconds or minutes-seconds format and are equivalent to +the older output formats ``%h`` and ``%m`` except that the number is +first divided by 15. This converts degrees to hours allowing values +given in units of degrees to be printed as hours with just a change of +the output format. In other words, given a number N in units of degrees, +``%H`` would print the number in hours-minutes-seconds, i.e., +“hh:mm:ss.ss”, whereas ``%h`` would print the same number as +degrees-minutes-seconds, “dd:mm:ss.ss”. The ``%m`` formats are similar +except that only two of the three fields are printed. + +GTY interface +^^^^^^^^^^^^^ + +The GTY interface is a generalized version of that portion of the older +TTY interface dealing with termcap format files. The TTY code which +accesses termcap format files has been extracted to form the new GTY +interface, allowing arbitrary termcap format files to be accessed by +filename, unlike TTY which returns TTY descriptors given the termcap or +graphcap device name. GTY was contributed by Skip Schaller of Steward +Observatory. + +:: + + gty = gtyopen (termcap_file, device, ufields) + gtyclose (gty) + cp = gtycaps (gty) + pval = gtyget[bir] (gty, cap) + nchars = gtygets (gty, cap, outstr, maxch) + +The *gtyopen* call returns the GTY descriptor for the named *device* +from the file *termcap_file*. The *ufields* string may be either NULL or +a list of colon-delimited device capabilities, which will override the +corresponding capabilities in the device entry given in the termcap +file. If *termcap_file* is the null string *ufields* is taken to be the +device entry for the named device. The *gtycaps* routine may be used to +get the entire device entry as a string, whereas the *gtyget* and +*gtygets* routines are used to get the values of individual capabilities +or parameters. + +MTIO interface +^^^^^^^^^^^^^^ + +MTIO is the magtape i/o interface. The magtape i/o subsystem was +extensively revised for V2.10 IRAF, as documented earlier in this +revisions summary. The VOS level MTIO interface itself was not changed +other than to add a few new routines. The *tapecap* facility is new in +V2.10. The revisions to the host level magtape driver ZFIOMT required +that the calling sequences of some of the interface routines be changed. + +MTIO applications programming interface +''''''''''''''''''''''''''''''''''''''' + +The current MTIO applications programming interface is summarized below. +Most of these routines are new: the old routines are *mtfile*, *mtopen*, +*mtrewind* and *mtposition*. + +:: + + yes|no = mtfile (fname) + yes|no = mtneedfileno (mtname) + gty = mtcap (mtname) + mtfname (mtname, file, outstr, maxch) + + mtparse (mtname, device, fileno, recno, attrl, maxch) + mtencode (mtname, maxch, device, fileno, recno, attrl) + + fd = mtopen (mtname, acmode, bufsize) + mtrewind (mtname, initcache) + mtposition (mtname, file, record) + +The *mtfile* routine is used to test whether the given filename is a +magtape file or something else, i.e., a disk file. *mtneedfileno* tests +whether a file number has been specified in *mtname* (e.g., to determine +whether or not to query for a file number parameter). *mtfname* takes +*mtname* and a file number and constructs a new magtape device name in +the output string. *mtparse* parses a magtape device name into its +component parts, and *mtencode* does the reverse. *mtcap* returns the +GTY descriptor of the tapecap entry for the device. *gtyclose* should be +used to free this descriptor when it is no longer needed. + +Some older magtape applications programs parse the magtape device name +directly, looking for characters like \`[’. These old programs are +making assumptions about the form of a magtape device name which are +probably no longer true. Such old applications should be rewritten to +use the new MTIO procedures for all magtape device name operations. + +MTIO system procedures +'''''''''''''''''''''' + +The MTIO interface also includes a number of procedures intended for use +in systems code. These are summarized in the table below. + +:: + + mtallocate (mtname) + mtdeallocate (mtname, rewind_tape) + mtstatus (out, mtname) + mtclean (level, stale, out) + +The only new routine here is *mtclean*. This is called by the *mtclean* +task in the V2.10 SYSTEM package and is used to scan the magtape status +file storage area to delete old magtape position status files. Prior to +V2.10 these files were stored in the user’s UPARM directory, but in +V2.10 the files are stored in ``/tmp`` so that multiple IRAF sessions +will share the same tape position information. A special task is needed +to delete old position files in order to protect against, e.g., one user +deleting another user’s device position file while the device is +actively in use. + +Magtape driver procedures +''''''''''''''''''''''''' + +All access to the physical magtape device is via the host level IRAF +magtape device driver ZFIOMT. The driver procedures had to be revised +for V2.10 to add support for the tapecap facility and to accommodate +changes in the way the device position is maintained. The new driver +procedures are summarized below. + +:: + + zzopmt (device, acmode, devcap, devpos, newfile, chan) + zzrdmt (chan, buf, maxbytes, offset) + zzwrmt (chan, buf, nbytes, offset) + zzwtmt (chan, devpos, status) + zzstmt (chan, param, value) + zzclmt (chan, devpos, status) + zzrwmt (device, devcap, status) + +The corresponding KI (kernel interface) routines were also modified to +reflect the new calling sequences. A result of this is that IRAF +networking for magtape devices is incompatible between V2.10 and earlier +versions of IRAF. + +The host level device driver procedures are not normally called directly +in applications code (applications use *mtopen*). Refer to the comments +in the source file ``os$zfiomt.c`` for additional details. + +MWCS interface +^^^^^^^^^^^^^^ + +The MWCS interface provides world coordinate system support for the IRAF +system and applications. The main changes in the MWCS interface for +V2.10 were bug fixes and semantic changes, e.g. various restrictions +having to do with WCS attributes were removed, new function drivers were +added, and so on. These changes are documented elsewhere in this +revisions summary. + +The only interface change affecting MWCS was the addition of the new +MWCS procedure *mw_show*. + +:: + + mw_show (mw, fd, what) + +This is used to dump a MWCS descriptor to the given output file, and is +useful for examining MWCS descriptors while debugging applications. + +Getting Copies of this Revisions Summary +---------------------------------------- + +Additional copies of this revisions summary are available via anonymous +ftp from node ``iraf.noao.edu`` in the directory ``iraf/v210``, or via +email from ``iraf@noao.edu``. diff --git a/doc/releases/v211revs.rst b/doc/releases/v211revs.rst new file mode 100644 index 000000000..c6a115200 --- /dev/null +++ b/doc/releases/v211revs.rst @@ -0,0 +1,1336 @@ +IRAF V2.11EXPORT Release Notes +============================== + +:Authors: IRAF Group +:Date: August 27, 1997 +:Abstract: Modifications and additions to IRAF V2.11EXPORT, compiled since the last + documented release of IRAF, V2.10.3, are summarized below. V2.11EXPORT + is a major release of IRAF and will be available for all supported + platforms. These release notes provide a summary of the major changes in + V2.11. More detailed technical documentation of all system changes will + be found in the notes.v210 and notes.v211 files in the + ``iraf$doc`` and ``iraf$local`` directories. + +Things to be aware of or watch out for +-------------------------------------- + +Parameter file changes +~~~~~~~~~~~~~~~~~~~~~~ + +Since this is a major release we recommend that you do a *mkiraf* and +delete all your old parameter files. You may choose not to do this if +you are in the midst of a project and have setups that may be difficult +to reproduce. Old IMAGES package parameter files will no longer be +recognized, however, because of the package reorganization mentioned +below. Generally, old parameter files are merged automatically with any +new parameter files if there have been any changes, but if you do have +problems you will need to *unlearn* the task before you can proceed. A +list of the parameter file changes appears below and you may wish to +check this list to see how this will affect your setups. + +The automatic parameter file update/merge mechanism, which is used if +you do not initialize your parameters with *mkiraf*, is based on file +date comparisons. If you run IRAF V2.10 after V2.11 has been +installed, the file dates on your uparm parameter files will be more +recent than the V2.11 installation date. If you then try to run V2.11, +the automatic parameter file merge/update will fail due to the file +dates. The system only updates personal parameter files which are +older than the update date of the system. A *mkiraf* avoids the +problem if you delete your parameter files, causing them to be updated +from the system default versions. + +Networking change +~~~~~~~~~~~~~~~~~ + +The “set node = foo” syntax, used to enable remote image display under +IRAF networking, has changed. The new syntax requires that an +exclamation be appended to the node name as in the example below (this +dates back to V2.10.4 so many users will already be familiar with the +feature). + +:: + + cl> set node = "orion!" + +Image format change +~~~~~~~~~~~~~~~~~~~ + +The internal IRAF image format (.imh images) has changed. V2.11EXPORT +can read the old image format but the new image format is not readable +by V2.10.4 or earlier versions. This means that you can not easily go +from the new IRAF system (V2.11) to an old one (V2.10.4 or earlier) +unless you first convert the V2.11 IRAF images to FITS files. All your +old V2.10.4 or earlier images are readable by V2.11EXPORT. The benefit +is that the new image format is machine independent, slightly more +storage efficient, and supports long file pathnames. If it is necessary +to be able to read images written by V2.11 with older software, V2.11 +can be made to write the old IRAF image format by setting the +*oifversion* environment variable, e.g., “set oifversion = 1” (the +default is version 2). See below for details. + +FITS kernel +~~~~~~~~~~~ + +A FITS image kernel is available in V2.11, allowing runtime read and +write access to FITS files on disk. There are many related changes to +IRAF image i/o and FITS support. More information on the new image +kernel, and on the expanded FITS support available in V2.11, is given +below. + +RFITS/WFITS changes +~~~~~~~~~~~~~~~~~~~ + +*rfits* and *wfits* have been modified to support multi-extension FITS +files. The extension numbering convention used is the same as in the +FITS image kernel. As a result, users who read simple FITS files on disk +with a command such as “rfits diskfilename 1 foo” will find that this no +longer works - instead use “rfits diskfilename 0 foo”. See below for +details. + +Merged SunOS and Solaris IRAF systems +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A single installation of Sun/IRAF will now simultaneously support both +SunOS and Solaris (previously separate IRAF distributions were required +for each). + +Tape access +~~~~~~~~~~~ + +The “tapecap” mechanism has changed. The system now looks for the +filename “tapecap.” followed by the default “tapecap”. : should be the +hostname (as used by IRAF networking) of the server hosting the tape +drives described by the tapecap file. For example if host “gemini” +serves up some tape drives it’s tapecap file is named “tapecap.gemini”. +If a server-specific tapecap file is not found the default “tapecap” (on +the possibly remote server node) is used. This feature allows a single +IRAF installation to be shared by multiple servers. + +Default magnitude zero changed +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The default APPHOT magnitude zero point has been changed from 26.0 to +25.0 to bring it into agreement with the DAOPHOT package default value +and thereby avoid confusion for users who switch back and forth between +packages. The affected APPHOT tasks are *phot*, *photpars*, *polypars*, +*polyphot*, *qphot*, *radprof*, and *wphot*. The APPHOTX package in the +addon DIGIPHOTX package will retain the old zero point values until IRAF +2.11 is released after which they will be updated. + +The default value of the magzero parameter in *imexamine* was changed +from 30.0 to 25.0 for consistency with the DIGIPHOT package. + +IMAGES package changes +---------------------- + +The IMAGES package has been reorganized by function into the 7 +subpackages listed below. + +:: + + imcoords - Image coordinates package + imfilter - Image filtering package + imfit - Image fitting package + imgeom - Image geometric transformation package + immatch - Image matching and combining package + imutil - Image utilities package + tv - Image display utilities package + +The new IMAGES package contains a total of 82 tasks, including 26 new +tasks from the IMMATCH and VOL external addon packages, 6 existing PROTO +package tasks, and 1 existing NOAO.PROTO package task. The undocumented +IMAGES package IMDEBUG and its 6 tasks have been deleted from the IMAGES +package. User should use the tasks in the ARTDATA package instead. + +This reorganization of the IMAGES package should be mostly transparent +to the user and not affect any existing scripts, unless you were using +any of the 6 deleted tasks. By default, the IMAGES subpackages are +automatically loaded when you log in to the CL. Old parameter files will +not be recognized since the package names have changed. + +Major system changes +-------------------- + +New FITS image kernel (FXF) +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +V2.11 introduces a new image kernel providing runtime access to FITS +multi-extension image datafiles. What this means is that IRAF tasks can +now read and write FITS images directly at runtime. The native IRAF +image format (used by images with the .imh extension), remains the +default as it is the most efficient and well-tested format. IMH, FITS, +and the other types of images supported by IRAF can be used +interchangeably in most IRAF tasks. Although we have extensively tested +the new FITS image kernel, it is still evolving, is complex, and still +has some bugs. Users should use it with caution. Please let us know of +any problems. + +Besides support for classical FITS images, the new FITS kernel also +supports multi-extension FITS files: several FITS files packed into one +large file with a PHU (Primary Header Unit) that contains global header +information shared by the other files. Multi-extension FITS files are +0-indexed, with the PHU being 0 and the first image extension (or other +data extension) at index 1. If there is no PHU then the first FITS image +is 0 and there is no global header. + +For further details about the FITS kernel please see the new FITS Kernel +User’s Guide by Nelson Zarate. + +Changes to the IRAF native image format (OIF) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- It was necessary to change the IRAF image format to increase the + maximum path length for header and pixel files. This made it + necessary to change the disk image format, since the old format only + allowed 80 characters for the pixel file pathname. The path lengths + can now be up to 255 characters. + + Support for two versions of the image and pixel file headers was + added. V2.11 will read both the old image format (V1) and the new + image format (V2). But the new image format is not readable by older + versions of IRAF. + +- Native format IRAF images (OIF type or extension “.imh”) are now + machine independent, for example, a PC and a Sun can now access the + same images. + +- Support was added for byte swapping pixels. With the machine + independent image header, this allows .imh images to be read on any + node (integer) or any IEEE-compatible node (floating). + +- Some pointers: “strings foo.imh” (or other tools like the “less” file + viewer) can be used at the Unix level to look at the text contained + in the new V2 OIF image headers. + +IMFORT changes +~~~~~~~~~~~~~~ + +- IMFORT was brought up to date to read and write the new V2 “.imh” + images. The old V1 format is still supported but new images are + written using the new machine independent V2 format by default. + +- Image headers can now be any size (the old IMFORT had a fixed, + relatively low, limit on the image header size). + +- The “min_lenuserarea” variable is now supported by IMFORT (since + IMFORT is host level the variable must be defined in the host + environment). The builtin default header buffer is 64000 chars, which + is about 800 card images. + +Environment variables +~~~~~~~~~~~~~~~~~~~~~ + +Several new environment variable have been added to the system. + +- The new environment variable *imextn* determines the image kernels + (image file formats) recognized by IRAF and defines the mapping of + imagefile extensions to these image formats. A file that does not + have an extension listed in imextn may not be recognized as an image + by all IRAF tasks. The default value of imextn is as follows: + + :: + + imextn = "oif:imh fxf:fits,fit plf:pl qpf:qp stf:hhh,??h" + + IRAF tasks will not recognize a file as an image unless it has an + extension (except *rfits* which will read FITS files on disk that + have no extensions). The *rename* task can be used to add extensions + to image files if needed. “imextn” can be redefined (use reset imextn + = “new-value”) to modify the mapping of extensions to image types. + + The meaning of the fields of the default “imextn” are as follows. + Each substring corresponds to a single kernel. The “xxx:” is the + internal name of the image kernel, i.e. “oif”, “fxf”, “plf”, etc. A + comma delimited list of the extensions, or extension patterns, + associated with that image format follows the colon. For example, for + the FITS image kernel, the internal kernel name is “fxf” and the + system default file extensions are “.fits” and “.fit”. + + - oif:imh - The original (native) IRAF image format. + + - fxf:fits,fit - The FITS image extension format, which supports + classical FITS images as well as multi-extension FITS files. + + - plf:pl - The pixel list format used for compressed pixel masks. + + - qpf:qp - The QPOE image format for event list data (typically + X-ray or other high energy data). + + - stf:hhh,??h - The Space Telescope runtime GEIS image format. + + Users can define extensions for the fxf and stf kernels. For example, + if you have FITS files on disk that have a .ft extension then you can + reset imextn so that IRAF will recognize these image extensions: + + :: + + cl> reset imextn="fxf:ft" + + The new .ft extension for the FITS kernel images will now override + the default values - the other kernels remain unchanged. “.fits” will + no longer be recognized as a FITS file unless you include it in the + list of extensions for the “fxf” kernel. + + The first extension given for a kernel defines the default file + extension for new images of that type (rather than e.g. the value of + imtype, or a builtin default). + + The value of “imextn” is only read once when a process starts up. + Hence it is advisable to do a “flpr” (flush process cache) after + changing this variable, to force all processes to re-read it. + +- The environment variable *imtype* defines the default image type for + new images created by IRAF. If a file extension is given explicitly + when creating a new image then this file extension, in combination + with the “imextn” mappings, determines the type of the new image. + Otherwise the type is determined by the value of “imtype”. Typical + values are “imh” for native IRAF images, or “fits” for FITS images. + The internal kernel name documented above for “imextn” can be used + instead of a file extension to ensure that the desired image format + is used regardless of what extensions are assigned to that type by + imextn. + + The default value of imtype is “oif,noinherit” which means that the + IRAF native format is the default for all new images, regardless of + the type of the input image (i.e. do not “inherit” the input image + type). “inherit” was the default in V2.10 and earlier versions of + IRAF. + + For example, if you wish to use FITS as the default for new images + you can set imtype=fits as follows: + + :: + + cl> reset imtype="fits" + cl> flpr % needed before the next task execution + + Assuming “imextn” defines “.fits” as a valid file extension for FITS + imagefiles (kernel “fxf”), all new images produced by IRAF will be + FITS files with the extension .fits unless some other extension is + given explicitly when creating a new image. + + :: + + cl> reset imtype = "imh,inherit" + + This example sets the default type for new images to “.imh” for + native format images, but enables image type inheritance. By default + new images will be of the same type as the input image. For example + if a FITS image is being read another FITS image will be output, or + if a pixel mask is being read a pixel mask will be created. + + You can override the default output image type specified by imtype by + giving an image extension (as defined by imextn) explicitly in the + image name, e.g. “pix.imh”, “pix.fits”, “pix.pl” and so on. + +- A new environment variable called *imclobber* has been added. The + default value is set to no. If imclobber is set to yes, images can + and will be overwritten, without warning, when you create new images. + +- The original IRAF image format (OIF) kernel now supports an + environment variable *oifversion* which, if defined, specifies the + file version for new OIF images (for example, oifversion=2 produces + the new format, or version 2 images). By default the variable is + undefined, the builtin OIF default will be in effect, and new-format + images will be generated. This variable is provided only for + backwards compatibility, e.g., when using V2.11 IRAF with old + software which cannot easily be updated. + +New intrinsic functions +~~~~~~~~~~~~~~~~~~~~~~~ + +Two new intrinsic functions were added to the CL, *imaccess* and +*defvar*. *imaccess* tests whether an image exists, e.g., +(imaccess(“dev$pix”)) or (imaccess(foo.fits[3])). *defvar* tests whether +an environment variable exists, e.g. (defvar(“imextn”)). + +System default modifications +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- The default size of the user area (*min_lenuserarea*) was increased + to 64000 (about 800 80 character cards). There was some ambiguity + about units for min_lenuserarea; it should be consistently characters + now. + +- The maximum number of open IRAF logical files was increased from 128 + to + + 256. This is good news for *imcombine* users. + +- Various buffer limits were increased: + + - The IRAF line length was increased from 161 to 1023 characters. + One often ran into this lower limit when entering a long list of + input image names, for example. + + - CL commands can now be 2047 characters long (the old limit was + + 1024) + + - this is particularly useful for scripts. + + - IRAF file names can now be up to 255 characters long. + + - Expanded file names (pathnames) can be up to 511 characters long. + +Libraries added +~~~~~~~~~~~~~~~ + +The Starlink positional astronomy library SLALIB was added to the math +package. + +Graphics changes +~~~~~~~~~~~~~~~~ + +- SGI Translator change: Modified the header ID string produced by + sgi2uapl to be “%!PS”, this is required by certain models of + printers. + +- Installed graphcap support for the STSDAS PostScript graphics kernel. + +- The SGI graphics kernel was upgraded with a better roman font, and a + new greek font was added. To use the new high-quality greek fonts use + the “:raw-latex:`\fG`” escape sequence when you use the “T” keystroke + to mark text in a plot, e.g., + :raw-latex:`\fGa `:raw-latex:`\fRHydra `would produce ” Hydra”. The + greek font may also be used in label parameters for tasks like GRAPH, + for example + + :: + + cl> graph dev$pix xlabel="Wavelength\\fG(A)" + + would produce an Angstrom symbol in parenthesis. The double backslash + is necessary to pass the escape string thru the CL. A file containing + the mappings for the greek fonts and other special characters can be + found at http://iraf.noao.edu/greek.ps. + +FITS-related core-level task changes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +IMHEADER +^^^^^^^^ + +The behavior of *imheader* has changed a bit - typed with no arguments +it will list all the images in the current directory, as in the +following example: + +:: + + cl> imhead + pix4.imh[512,512][short]: m51 B 600s + boc.fits: FXF: must specify which FITS extension (boc.fits) + fits.fits[512,512][short]: m51 B 600s + pix.fits[512,512][short]: m51 B 600s + pix3.fits[512,512][short]: m51 B 600s + pix5.fits: FXF: must specify which FITS extension (pix5.fits) + zero.fits: FXF: must specify which FITS extension (zero.fits) + mask.pl[512,512][int]: m51 B 600s + foo.qp[1024,811][int]: + +The multi-extensions FITS files show up in the list with the message +“FXF: must specify which FITS extension”, since these files contain +multiple images and the task does not know which image to open to get +header information. + +At present imheader does not use “imextn” to determine what is and is +not an image. The parameter “imlist” defines the valid imagefile +extensions. If imextn is modified “imlist” may need to be modified as +well. + +RENAME +^^^^^^ + +The *rename* task was modified to allow a destination directory to be +specified without changing the filename. A new “field” parameter option +“all” was added and made the default so the entire filename is changed +(or moved in the case of a destination directory). When field is set to +“extn” filenames without an extension will not have the new extension +appended so a filename isn’t generated which can get overwritten. + +*rfits*/*wfits* +^^^^^^^^^^^^^^^ + +Some changes were also implemented in *rfits* and *wfits* to add support +for multi-extension FITS files. + +- The default action of *wfits* when writing to tape is unchanged for + single image files. + + *wfits* now has a new parameter called “fextn” and it is set to + “fits”. This parameter only affects FITS files written by *wfits* to + disk - the extension .fits will automatically be added to the + filenames, so that the files will be automatically recognized by the + FITS image kernel. + + *wfits* also has two additional parameters called “extensions” and + “global_hdr” that deal with writing multi-extension FITS files. + +- The default action of *rfits* from tape to disk remains unchanged. + + If *rfits* is used to read FITS files on disk then users need to be + aware of a change to the behavior of the “file-list” parameter. + File-list is now used to define the list of files on the tape as well + as the list of extensions in a multi-extension FITS image. To read + single FITS images on disk use “” as the value for “file-list”. Some + users have been using “1” for this value but now that value will try + to read the first extension which doesn’t exist - use “0” if you wish + to put something there. + + *rfits* will unpack multi-extension FITS files upon a read. If you + wish to retain the multi-extension FITS format then use T2D and + RENAME. + +The help pages have been updated to reflect these changes. + +*wfits* now writes ushort (16 bit unsigned short) images to FITS images +with bitpix=16, bscale=1.0, and bzero=32768.0 by default. *rfits* will +read these images back as type ushort. + +General changes +~~~~~~~~~~~~~~~ + +- The GSURFIT package has been updated to include support for the + “half” cross terms option useful in computing plate solutions. Tasks + that can make use of this feature have been updated although their + default behaviors have not changed. + +- The code which computes the CD matrix from CDELT/CROTA was modified. + The old code computed the diagonal (scale) terms correctly but the + rotation terms were evidently incorrect. The old code was based on + the 1988 Hanisch and Wells WCS paper and the new code is based on a + more recent paper by Mark Calabretta et al, which supersedes the 1988 + representation. The affect of this change should be limited as it + only affects rotated images for which CDELT is given but no CD matrix + is defined. (V2.10.4p2) + +- Several new celestial coordinate projection functions have been + added. Users with IPAC data that use the CAR projection function + should now be able to read the image coordinates directly with + LISTPIXELS, etc. + +New tasks, or old tasks moved to new packages +--------------------------------------------- + +:: + + Task Name Package Function + + CCXYMATCH IMCOORDS Four new tasks for computing and evaluating + CCMAP simple astrometric plate solutions and storing + CCSETWC them in the image headers in fits-compatible + CCTRAN format. + + CCFIND IMCOORDS CCFIND locate objects in an image given a + celestial coordinate list and the image wcs. + + IMCCTRAN IMCOORDS Two new tasks for transforming celestial + SKYCTRAN coordinate lists and image celestial + coordinate systems from one celestial + coordinate system to another. + + STARFIND IMCOORDS STARFIND automatically detects stellar objects + in a list of images. + + WCSCTRAN IMCOORDS A new task for transforming between IRAF image + coordinate systems. + + WCSEDIT IMCOORDS Two unaltered former PROTO package tasks for + WCSRESET editing IRAF image coordinate systems. + + FRMEDIAN IMFILTER Four new tasks for doing circular/elliptical/ + FRMODE ring image median filtering. + RMEDIAN + RMODE + + IM3DTRAN IMGEOM The former addon VOL package task IM3DTRAN for + doing 3D image transposes. + + GEOXYTRAN IMMATCH A new task for transforming coordinate lists + using the results of the GEOMAP task. + + IMCENTROID IMMATCH Four new tasks for computing matched pixel + SKYXYMATCH lists. IMCENTROID is a modified version of the + WCSXYMATCH PROTO package task of the same name. + XYXYMATCH + + SKYMAP IMMATCH Two new tasks for computing geometric + WCSMAP transforms using the image coordinate system + information. + + IMALIGN IMMATCH Three new tasks for doing automated image + SREGISTER registration. IMALIGN is a modified version + WREGISTER of the PROTO package task of the same name. + + WCSCOPY IMMATCH A new task for copying the coordinate system + of a reference image to a set of input images. + + PSFMATCH IMMATCH A new task for matching the PSFs of a set of + input images to the PSF of a reference image + using Fourier techniques. + + LINMATCH IMMATCH A new task for matching the linear intensity a + scale of a set of input images to the + intensity scale of a reference image. + + IMFUNCTION IMUTIL The former PROTO package task for applying a + single argument function to an image. + + IMJOIN IMUTIL The former addon VOL package task for joining + same-dimensioned images along a specified + dimension. + + IMREPLACE IMUTIL The former PROTO package task IMREPLACE for + replacing bad pixels based on their value. + + IMTILE IMUTIL A modified version of the NOAO.PROTO IRMOSAIC + task for tiling same sized 2D images into a + single mosaiced image. + + EXPORT DATAIO Two new tasks from the external IMCNV package + IMPORT for exporting IRAF images to binary formats + and for importing binary files into IRAF + images. + + TEXT2MASK PROTO This new task appears in conjunction with a + new pixel mask based version of FIXPIX. + + IMEXTENSIONS PROTO This task selects and lists image extensions + in files. Image extensions currently occur + in multi-extension FITS files and multi-group + Geiss (STF format) files. + + CCDMASK CCDRED This new task creates a pixel mask from a + CCD image. + + AIDPAR ONEDSPEC New parameter set for automatic line + identification for the tasks AUTOIDENTIFY, + IDENTIFY and REIDENTIFY. + + AUTOIDENTIFY ONEDSPEC A new task to automatically identify lines + and fit the dispersion function. + + SKYTWEAK ONEDSPEC Sky spectra are shifted and scaled to best + subtract sky features from data spectra. + + TELLURIC ONEDSPEC Telluric calibration spectra are shifted and + scaled to best divide out telluric features + from data spectra. + + ASTCALC ASTUTIL An astronomical calculator. + + ASTRADIUS ASTUTIL Finds images within a circle on the sky. + +Task and package deletions +-------------------------- + +CUBE, DUMP, GSUBRAS, MAXMIN, MKIMAGE, MKTEST: These tasks have been +superseded by the equivalent tasks in the IMAGES or ARTDATA packages. +The functionality of these tasks still exists in the +iraf$pkg/images/lib/zzdebug.x file. + +REGISTER: This task has been renamed to GREGISTER. + +IMALIGN, IMCENTROID, IMFUNCTION, IMREPLACE, WCSEDIT, WCSRESET: Moved to +the IMAGES package. + +Modifications to old tasks +-------------------------- + +Grouped by package, a list of modifications to old tasks in IRAF are +summarized below. We have included modifications since the V2.10.3 +release. + +- **IMFILTER:** + + - FMEDIAN, FMODE, MEDIAN, MODE: + + Minimum and maximum good data value parameters zloreject and + zhireject and a verbose option parameter were added. + + - MEDIAN, MODE + + The 64 x 64 maximum kernel size limit was removed from these + tasks. + +- **IMMATCH:** + + - GEOMAP + + Renamed the output parameter to database for the sake of + consistency with other new images tasks. + + Changed the default value of the reject parameter from 0.0 to + INDEF. + + Added the transforms parameter. Transforms permits the user to + specify the names of the output database records explicitly. + + Added the parameter results. Results permits the user to save a + summary of the results including a description of the transform + geometry, and a listing of the input coordinates, the fitted + coordinates, and the fit residuals. + + Added the fitgeometry parameter. Fitgeometry permits the user to + constrain the linear part of the fit to: 1) x and y shifts only, + 2) x and y shifts and rotation only, 3) x and y shifts and x and y + scale changes only, 4) x and y shifts, rotation, and a scale + change only, 5) x and y shifts, rotation, x and y scale changes + only, and 5) x and shifts, rotation, skew, and x and y scale + changes. + + - GREGISTER + + Renamed the register task gregister to emphasize that it is paired + with the geomap task and to avoid confusion with the new + registration tasks. + + - GEOTRAN, GREGISTER + + Renamed the transform parameter to transforms. + + Added the verbose parameter. + + - GEOTRAN + + Added the ability to write to a section of an existing image. + + - IMCOMBINE + + The limit of the number of images that may be combined has been + removed. If the number of images exceeds the maximum number of + open images permitted then the images are stacked in a single + temporary image and then combined with the project option. Note + that this will double the amount of diskspace temporarily. There + is also a limitation in this case that the bad pixel mask from the + first image in the list will be applied to all the images. + + Integer offsets may be determined from the image world coordinate + system. + + A combination of ushort and short images now defaults to integer. + + Added support for type ushort images. + + Added a new options for computing offsets using the image wcs. + + Removed the limit on the maximum number of images that can be + combined. + + - IMALIGN, IMCENTROID + + Renamed the images parameter to input, changed the reference + parameter mode from hidden to automatic, and reversed the order of + the reference and coords parameters. + +- **IMUTILS:** + + - IMEXPR + + Modified the task so that it will accept an image name that looks + like a number in the first few characters, but which is really an + image name. For example, “123.imh” or “../foo.imh”. The previous + version of imexpr was treating any string which looked like a + number in the first few characters as a numeric constant. + (V2.10.4p2) + + - IMREPLACE + + The lower value is now rounded up for integer images so that a + range like 5.1-9.9 affects pixels 6-9 instead of 5-9. + + - IMSUM + + Now allows “ushort” data types. + +- **TV:** + + - DISPLAY + + The bad pixel mask, overlay mask, sample mask, and overlay colors + parameters and functionality have been added. The “nsample_lines” + parameter is now an “nsample” parameter. + + Bugs in the coordinate system sent to the image display for cursor + readback were fixed. + + - IMEDIT + + If xorder or yorder are zero then a median background is computed + for the ‘a’ and ‘b’ keys. + + - IMEXAMINE + + (‘a’ and ‘r’): The fit to the radial profile points now includes + both a Gaussian and a Moffat profile. The Moffat profile exponent + parameter, beta, may be fixed or left free to be fit. + + (‘a’ and ‘r’): New estimates fo the FWHM were added to the ‘a’ and + ‘r’ keys. These include the Moffat profile fit noted above, a + direct measurement of the FWHM from the radially binned profile, + and a Gaussian or Moffat fit to the radial enclosed flux profile. + The output from these keys was modified to include the new + information. + + (‘a’ and ‘r’): The direct FWHM may be used to iteratively adjust + the fitting radius to lessen the dependence on the initial fitting + radius value. + + (‘k’): Added a kimexam parameter set. + + The default value of rimexam.magzero parameter was changed from + 30.0 to 25.0 for consistency with the digiphot package. + +- **PROTO:** + + - FIELDS + + The default value for the lines parameter was changed to an open + upper limit. + + Changed the default value of the lines parameter from “1-999” to + “1-” so that the upper bound would be open ended. + + - FIXPIX + + This task replaces the old task (now obsolete.ofixpix) and works + with the more general pixel mask facilities. It also provides + greater flexibility in choosing the interpolation direction. + +- **ICFIT** used in various tasks: + + - ICFIT + + The :xyshow output was modified to 1) not include colon labels, + + 2) print (X, Y, Y fit, Weight) instead of (X, Y fit, Y), and 3) + the printed values are those actually used in the fit when + using composite points (naverage not 1). + +- **ARTDATA:** + + - MK1DSPEC + + Lorentzian and Voigt profiles were added and the parameters and + input line list format were changed. The widths are now FWHM + instead of gaussian sigmas. + + - MKOBJECTS, MKNOISE + + The default value of “ranbuf” was changed to zero. + + - GALLIST + + The default value for the minimum elliptical galaxy axial ratio + was changed to 0.3 to cover the range E0-E7 uniformly. + + - MKPATTERN + + Now allows ndim=0 to make an dataless header. Now allows ushort + pixel type. + +- **ASTUTIL:** + + - SETJD + + The checking of the epoch keyword value was improved. Previously + if there was a problem with the keyword value (missing or + malformed) the task would use the epoch of the observation. Now it + is an error if an epoch keyword is specified but the epoch value + can’t be determined. Also a leading ‘B’ or ‘J’ is allowed and a + warning will be given if the epoch value is unlikely. + + - ASTHEDIT + + There are new astronomical functions and input/output functions. + The command syntax may now use “=” as a delimiter as well as the + whitespace. + + A new parameter “update” allows protecting images and accessing + read-only images for the purpose of calculating and printing + quantities. + + The special variable name “$I” has the value of the image name, $D + the current date, and $T the current time. + + The case of no image name creates and deletes a temporary image so + the task can be used purely as a calculator (but see astcalc). + +- **CCDRED:** + + - CCDPROC + + The bad pixel fixing was modified to allow use of pixel masks, + images, or the text file description. Bad pixel masks are the + desired description and use of text files is only supported for + backward compatibility. Note that support for the trimmed or + untrimmed conversion from text files has been eliminated. + + Line-by-line overscan/prescan subtraction is now provided with + three simple algorithms. + + - COMBINE + + The limit of the number of images that may be combined has been + removed. If the number of images exceeds the maximum number of + open images permitted then the images are stacked in a single + temporary image and then combined with the project option. Note + that this will double the amount of diskspace temporarily. There + is also a limitation in this case that the bad pixel mask from the + first image in the list will be applied to all the images. + + Integer offsets may be determined from the image world coordinate + system. + + Fixed a bug where a variable was improperly used for two different + purposes causing the algorithm to fail. This also affected + IMCOMBINE and SCOMBINE. See bug 316 for details. (V2.10.4p2) + + - COSMICRAYS + + | The output bad pixel data accidentally included some extra + fields making it incorrect to use the file directly with + BADPIXIMAGE. + | The extra diagnostic fields were removed. For details, see bug + 311 in the buglog. (V2.10.4p2) + +- **ECHELLE:** + + - ECIDENTIFY + + The dispersion units are now determined from a user parameter, the + coordinate list, or the database entry. + +- **IMRED** Spectral Packages: + + - DOARGUS, DOFIBERS, DOHYDRA + + A sky alignment option was added. + + The aperture identification can new be taken from image header + keywords. + + The initial arc line identifications is done with the automatic + line identification algorithm. + + - DOSLIT, DO3FIBER + + The initial arc line identifications is done with the automatic + line identification algorithm. + +- **ONEDSPEC:** + + Support for the Sloan Sky Survey was added by allowing multifiber + reductions with up to 500 fibers with non-linear dispersions. + (V2.10.4p2) + + - BPLOT + + Fixed a general problem in BPLOT and SLIST that caused a + segmentation violation error. See buglog 312 for details. + (V2.10.4p2) + + - FITPROFS + + Modified to include lorentzian and voigt profiles. The parameters + and positions file format have changed in this version. A new + parameter controls the number of Monte-Carlo samples used in the + error estimates. + + - IDENTIFY + + The dispersion units are now determined from a user parameter, the + coordinate list, or the database entry. A new key, ‘e’, has been + added to add features from a line list without doing any fits. + This is like the ‘l’ but without the automatic fitting before and + after adding new features. + + A new key, ‘b’, has been added to apply an automatic line + identification algorithm. + + The ‘x’ key has been changed to use the automatic line + identification algorithm. The allows finding much larger shifts. + + The match parameter may now be specified either in user + coordinates or in pixels. The default is now 3 pixels. + + The default threshold value has been changed to 0. + + - REIDENTIFY + + A new parameter, “search”, was added to specify a search radius + for the automatic line identification algorithm. + + The “nlost” parameter now also applies when not tracing; i.e. it + will issue a warning and not record a solution if the specified + number of features is lost when reidentifying against a specific + reference spectrum as is done with multispec data. + + The task will now work with only a warning if the reference image + is absent; i.e. it is possible to reidentify given only the + database. + + The addfeatures function will now add features before a fit if + there are no reference database features. Previously features + could only be added after an initial fit using the reference + features and, so, required the reference database to contain + features for reidentification. This new feature is useful if one + wants to uses a dispersion function from one type of calibration + but wants to add features for a different kind of calibration. + + - SAPERTURES + + This task has been modified to allow use of image header keywords + as done in the APEXTRACT package. + + - SARITH + + Previously both w1 and w2 had to be specified to select a range to + be used. Now if only one is specified the second endpoint defaults + to the first or last pixel. + + The noise band in multispec data is only copied from the primary + spectrum and not modified. This is a kludge until the noise is + handled properly. + + Fixed a problem in SARITH and SCOPY where a segmentation error + occurred when a wavelength range was specified in the reverse + sense of the data and without rebinning. See buglog 323 for + details. (V2.10.4p2) + + - SBANDS + + Fixed a problem in SBANDS that caused a segmentation violation + when the number of input bandpasses was greater than 10. See + buglog 298 for details. (V2.10.4p2) + + - SCOPY + + Previously both w1 and w2 had to be specified to select a range to + copy. Now if only one is specified the second endpoint defaults to + the first or last pixel. + + - SPECPLOT + + The scale and offset parameters may now be a value, a filename, or + and image header keyword. + + The ‘f’ key was added to toggle between world and logical pixel + coordinates. + + - SPLOT + + The profile fitting and deblending was expanded to include + lorentzian and voigt profiles. A new parameter controls the number + of Monte-Carlo samples used in the error estimates. + + - RSPECTEXT + + The task now automatically senses the presence of a header. + +- **APEXTRACT:** + + - APALL, APSUM, APNOISE, APNORMALIZE, APSCATTER, APTRACE, + APRECENTER, APRESIZE, APMASK, APFIND, APFLATTEN + + The “apertures” parameter can be used to select apertures for + resizing, recentering, tracing, and extraction. This parameter + name was previously used for selecting apertures in the + recentering algorithm. The new parameter name for this is now + “aprecenter”. + + - APALL, APSUM + + The “nsubaps” parameter now allows onedspec and echelle output + formats. The echelle format is appropriate for treating each + subaperture as a full echelle extraction. + + - APALL + + The aperture ID table information may now be contained in the + image header under the keywords SLFIBnnn. + + - APSUM + + The dispersion axis parameter was moved to purely a package + parameter. + + As a final step when computing a weighted/cleaned spectrum the + total fluxes from the weighted spectrum and the simple unweighted + spectrum (excluding any deviant and saturated pixels) are computed + and a “bias” factor of the ratio of the two fluxes is multiplied + into the weighted spectrum and the sigma estimate. This makes the + total fluxes the same. In this version the bias factor is recorded + in the logfile if one is kept. Also a check is made for unusual + bias factors. If the two fluxes disagree by more than a factor of + two a warning is given on the standard output and the logfile with + the individual total fluxes as well as the bias factor. If the + bias factor is negative a warning is also given and no bias factor + is applied. In the previous version a negative (inverted) spectrum + would result. + +- **RV:** + + - RVIDLINES, RVREIDLINES + + These tasks now work in the units of the input spectra. + + - FXCOR + + The input spectra are converted to Angstroms for the + crosscorrelation and analysis. Thus the velocities will be + correctly computed regardless of the units of the input spectra. + +- **DAOPHOT:** + + - DAOFIND + + A major bug in the DAOFIND task centering code that affects the + computed x and y positions was fixed. Users should refer to bug + log entry number 332 for details. (V2.10.4p2) + + A new roundness statistic was added to the DAOFIND output to bring + the task into conformance with standalone DAOPHOT II. The new + statistic is sensitive to and tries to eliminate detected objects + which are significantly elongated in directions other than 0, 90, + 180, and 270 degrees. The original roundness statistic is stored + in the ground column, the new one in the sround column. The same + default roundness limits apply to both statistics. (V2.10.4p2) + + - DAOPARS + + Added a new parameter “mergerad” to the DAOPARS parameter set. + Mergerad permits the user to control the merging process. If + mergerad is INDEF (the default setting) the default merging radius + is used. If mergerad is 0 object merging is turned off altogether. + Otherwise the user can set the merging radius to a specific value. + Mergerad is used by the nstar and allstar tasks, but their default + behavior is unchanged. (V2.10.4p2) + + Changed the name of the “critovlap” parameter to “critsnratio” to + avoid confusion with the meaning of the parameter especially with + regard the mergerad parameter. The behavior of the parameter is + unchanged. (V2.10.4p2) + +.. _parameter-file-changes-1: + +Parameter file changes +---------------------- + +The parameter file changes below are for modifications between V2.10.4 +and V2.11. For a list of parameter file changes between V2.10.3 and +V2.10.4 see the file iraf/v210/params.v2104.Z in the IRAF FTP archives. + +In the tables below each parameter change is identified with one of the +following codes followed by task_name.parameter_name and the description +of the change. + +- n = new parameter +- c = changed/modified parameter +- d = deleted parameter + +**TV:** + +:: + + n display.nsample: replaces nsample_lines + d display.nsample_lines: replaced by nsample + n display.bpmask: specify a bad pixel mask + n display.bpdisplay: specify display mode for bad pixel mask + n display.bpcolors: specify overlay colors for bad pixel mask + n display.overlay: specify an overlay mask + n display.ocolors: specify overlay colors for overlay mask + n display.zmask: specify a sample mask for the zscale calculation + c imedit.xorder: now allows a value of zero for median background + c imedit.yorder: now allows a value of zero for median background + n rimexam.fittype: specify a profile type to fit - default is now moffat + n rimexam.iterations: specify number of iterations to adjust fitting radius + n rimexam.beta: specify beta value for moffat fitting + c rimexam.buffer: default value changed from 1 to 5 + c rimexam.width: default value changed from 2 to 5 + c rimexam.magzero: default value changed from 30 to 25 + n wcslab.overplot: specify overplotting + +**DATAIO:** + +:: + + n wfits.fextn: extension to append to output disk FITS filename - default is + fits + n wfits.extensions: write all images to a single FITS file ? - default is no + n wfits.global_hdr: prepend a global header to the FITS extensions - default + is yes + +**IMAGES:** + +:: + + n fmedian.zloreject: good data minimum + n fmedian.zhireject: good data maximum + n fmedian.verbose: verbose option + n fmode.zloreject: good data minimum + n fmode.zhireject: good data maximum + n fmode.verbose: verbose option + n median.zloreject: good data minimum + n median.zhireject: good data maximum + n median.verbose: verbose option + n mode.zloreject: good data minimum + n mode.zhireject: good data maximum + n mode.verbose: verbose option + n geomap.transforms: list of record names + n geomap.results: results summary file + n geomap.fitgeometry: fitting geometry + d geomap.output: renamed to database + c geomap.reject: changed from 0.0 to INDEF + n [g]register.verbose: verbose option + d [g]register.transform: renamed to transfo + n geotran.verbose: verbose option + d geotran.transform: renamed to transforms + c imcombine.offsets: now allows specifying "wcs" to compute offsets from WCS + d imalign.images: renamed to input + c imalign.reference: went from hidden to auto + c imalign.coords: reversed places with reference + d imcentroid.images: renamed to input + c imcentroid.reference: went from hidden to auto + c imcentroid.coords: reversed places with reference + n imheader.imlist: default image names + +**PLOT:** + +:: + + n graph.ltypes: specify the line types + n graph.colors: specify the colors + +**PROTO:** + +:: + + n fixpix.masks: new version specifies bad pixel masks + n fixpix.linterp: specify mask values for line interpolation + n fixpix.cinterp: specify mask values for column interpolation + n fixpix.pixels: list pixels that are modified + d fixpix.badpixels: new version does not use bad pixel region description + c fields.lines: default value changed from "1-9999" to "1-" + +**ARTDATA:** + +:: + + n mk1dspec.profile: define the profile type + n mk1dspec.gfwhm: replaces sigma for gaussian profile width + n mk1dspec.lfwhm: width for lorentzian profile + c artdata.randbuf: default value changed from 1000 to 0. + c mkpattern.ndim: allows a value of 0 for a dataless header. + c mkpattern.pixtype: allows ushort. + c gallist.ar: default value changed to 0.3. + d mk1dspec.sigma: replaced by gfwhm + +**ASTUTIL:** + +:: + + n rvcorrect.keywpars: added to define keywords used + n asthedit.prompt: used for new calculator option + n asthedit.update: update the header + n asthedit.oldstyle: to allow backward compatibility + +**APEXTRACT, IMRED** spectral packages: + +:: + + n apnoise.apertures: select apertures to be used + n apfit.apertures: select apertures to be used + n apedit.apertures: select apertures to be used + n apfind.apertures: select apertures to be used + n apnormalize.apertures: select apertures to be used + n apscatter.apertures: select apertures to be used + n apsum.apertures: select apertures to be used + n aptrace.apertures: select apertures to be used + n apresize.apertures: select apertures to be used + n apmask.apertures: select apertures to be used + n apflatten.apertures: select apertures to be used + n aprecenter.apertures: select apertures to be used + n aprecenter.aprecenter: was what was previously the apertures parameter + n apall.apertures: select apertures to be used + n apall.aprecenter: was what was previously the apertures parameter + +**ARGUS, HYDRA, SPECRED:** + +:: + + n doargus.crval: for automatic line identifications + n doargus.crdelt: for automatic line identifications + n doargus.skyalign: night sky alignment option + n dohydra.crval: for automatic line identifications + n dohydra.crdelt: for automatic line identifications + n dohydra.skyalign: night sky alignment option + n dofibers.crval: for automatic line identifications + n dofibers.crdelt: for automatic line identifications + n dofibers.skyalign: night sky alignment option + n do3fiber.crval: for automatic line identifications + n do3fiber.crdelt: for automatic line identifications + +**ARGUS, HYDRA, KPNOCOUDE, KPNOSLIT, SPECRED:** + +:: + + c params.match: default value changed to -3 (3 pixels instead of Angstroms) + c sparams.match: default value changed to -3 (3 pixels instead of Angs) + +**ONEDSPEC, IMRED** spectral packages: + +:: + + d fitprofs.sigma: replaced by gfwhm + d fitprofs.function: replaced by profile + d fitprofs.fitsigmas: replaced by fitgfwhm + d rspectext.header: removed since the task now senses the header information + +**ONEDSPEC, LONGSLIT, IMRED** spectral packages: + +:: + + n identify.units: specify the desired units for the dispersion function + n identify.crval: for automatic line identifications + n identify.crdelt: for automatic line identifications + n identify.aidpars: parameter set for automatic line identifications + c identify.match: default value changed to -3 (3 pixels instead of Angstroms) + c identify.threshold: default value changed from 10 to 0. + c reidentify.match: default value changed to -3 (3 pixels instead of Angs) + c reidentify.threshold: default value changed from 10 to 0. + n reidentify.crval: for automatic line identifications + n reidentify.crdelt: for automatic line identifications + n reidentify.aidpars: parameter set for automatic line identifications + n reidentify.search: specify a search radius for the automatic line + identification algorithm + n ecidentify.units: specify the desired units for the dispersion function + n fitprofs.profile: define the profile type + n fitprofs.gfwhm: replaces sigma for gaussian profile width + n fitprofs.lfwhm: width for lorentzian profile + n fitprofs.fitgfwhm: replaces fitsigmas + n fitprofs.fitlfwhm: select whether to fit lorentzian profile widths + n fitprofs.nerrsample: allows control of the error calculation accuracy + n splot.nerrsample: allows control of the error calculation accuracy + +**CCDRED:** + +:: + + c ccdproc.fixfile: this now specifies a bad pixel mask + c combine.offsets: now allows specifying "wcs" to compute from WCS + +**RV:** + +:: + + n rvcorrect.par: Added the KEYWPARS pset declaration + +**DAOPHOT:** + +:: + + c daopars.critsnratio: critical S/N ratio for group membership - changed + the name only from critovlap (V2.10.4p2) + n daopars.mergerad: critical object merging radius in scale units + (V2.10.4p2) diff --git a/doc/releases/v212revs.rst b/doc/releases/v212revs.rst new file mode 100644 index 000000000..52b79bbe1 --- /dev/null +++ b/doc/releases/v212revs.rst @@ -0,0 +1,1313 @@ +IRAF V2.12EXPORT Release Notes +============================== + +:Authors: IRAF Group +:Date: January 25, 2002, updated March 25, 2002 +:Abstract: These release notes provide a summary of the major changes in V2.12. + This is a major release of IRAF and will be available for all supported + platforms. More detailed technical documentation of all system changes + will be found in the ‘notes.v211’ and ‘notes.v212’ files in the + ``iraf$doc`` and ``iraf$local`` directories. Detailed revisions notes + for each application package are in the package directories in a file + called Revisions, e.g. ``apphot$Revisions``. + +Highlights of This Release +-------------------------- + +Pixel Mask Support Added to FITS Kernel +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The FITS kernel was modified to add support for storing images in +extensions as compressed pixel masks using the binary table extension. +These masks may be accessed like any other image and allow for tasks to +more easily store bad-pixel masks, regions masks, or error arrays in the +same image file as the science data. + +New Pixel Mask Tasks +~~~~~~~~~~~~~~~~~~~~ + +Several new tasks have been added to the system PROTO package for +anipulating pixel masks: + +- MIMSTATISTICS allows image statistics to be computed while rejecting + pixels specified by an input mask. + +- MSKEXPR task is a general-purpose mask expression evaluator similar + to IMEXPR for images, but has builtin boolean region functions which + can be used to set values inside or outside of certain geometric + shapes. + +- MSKREGIONS creates an output mask based on an input text description. + Region descriptions can be composed of geometric shapes and logical + operation on mask regions. + +- OBJMASKS in the NPROTO package is a new task for detecting objects in + an image and creating an output catalog or pixel mask of found + objects. + +Shared Memory Limitations Eased +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The IMAGES and DAOPHOT packages executables are now linked statically to +remove per-process memory limitations imposed by the IRAF shared library +on Sun and Dec Alpha systems. Previously tasks such as DAOFIND and +IMCOMBINE were limited to 268Mb on Sun systems, these tasks can now use +up to the machine memory limits. + +Image I/O Buffer Sizes Increased +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Support for large image I/O was improved by changes to the internal +buffer sizes. These buffers may automatically adjust to optimal values +for the image being accessed, however new environment variables may be +set to further tune the buffers at the user level. Where needed +applications tasks were modified to take advantage of these buffer size +changes to force the imio buffer to be the size of the input image. + +Simplified Installation Script +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The install script was rewritten to clarify the output and provide some +basic checking of the IRAF system setup prior to installation, and to do +some of the most common post-install configuration. The script will +print an explanation of any errors it finds and suggest corrective +action, the hope is this will lead the user past some of the most common +installation errors. + +In addition, the SYSINFO diagnostic script which does more extensive +checking of the system is also now part of the distribution. This script +can be used to verify the system once the install is complete, or to +generate a report of the system configuration if needed by site support. +An UNINSTALL script to remove iraf command links and files created by +the INSTALL script is also available to remove IRAF from a machine. All +scripts are now installed in the hlib$ directory. + +New HELP GUI and Output Options +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The HELP task was enhanced to have a new GUI option for XGterm users. +This is essentially the XHELP task which has been available in the +GUIAPPS external package for some time, however the task is fully +backwards compatible and the text-mode output is still the default. As +part of this work, help pages may also now be formatted as either HTML +or Postscript for web presentation or pretty-printing to a hardcopy +device. The LROFF task was similarly modified to provide direct +conversion of lroff text sources. + +DISPLAY Task Changes +~~~~~~~~~~~~~~~~~~~~ + +As part of the recent X11IRAF enhancements, the DISPLAY task and others +such as IMEXAMINE which interact with the display server were modified +to take advantage of the new features in XImtool V1.3. These include +support for 16 frame buffers (increased from 4 in previous versions), +and enhanced WCS readout capabilities. The changes are fully backwards +compatible for use with older XImtool versions or display servers such +as SAOimage, SAOtng, or DS9 which have not yet been updated. + +X11IRAF V1.3 is being released simultaneously (but still separately) +with IRAF V2.12. While V2.12 is fully compatible with older versions of +X11IRAF, however users will need to upgrade both systems to take full +advantage of all the new features. Users should consult the X11IRAF +Release Notes for details on what has changed there. + +New Packages +~~~~~~~~~~~~ + +Several new packages are available in this release (see the NOAO package +change notes below for details): + +- A new ASTCAT package for extracting astrometric and photometric + calibration data from remote or local catalogs was added to NOAO. + +- A new CRUTIL package for doing cosmic ray detection and removal + package was installed in the IMRED package. + +- A new QUADRED reduction package for QUAD format data was installed in + the IMRED package. This is a generalized replacement for the + ARED.QUAD and XCCDRED external packages for processing CTIO and ESO + FORS1 multi-amplifier data. + +- A new OBSUTIL package was installed in NOAO. This is a collection of + tasks from various external packages which are useful to plan or + carry out observations. + +New Developer Libraries +~~~~~~~~~~~~~~~~~~~~~~~ + +Several new libraries are available for SPP developers: + +- PSIO is a new Postscript text generation library installed in + sys$psio. + +- CATQUERY is a remote astrometric/photometric catalog access lib + installed in the XTOOLS utility library. + +- SKYWCS is a sky coordinate transformation library installed in the + XTOOLS utility library. + +IRAF System Revisions Summary +----------------------------- + +- The IRAF shared library version number was incremented for SunOS and + Solaris systems. See below for details on how this change will affect + external packages and locally-compiled software. + +- The maximum number of nodes in a local iraf network was increased + from 320 to 512. + +- The max number of open files in FIO, FIO_MAXFD, was increased from + 256 to 4096. This is the “hard limit” on the maximum number of open + files in an IRAF process. + +- The maximum number of host level open files, MAXOFILES, was increased + from 64 to 256. This is the maximum number of files that can be + simultaneously open at the host level. It determines the maximum + number of files that can be simultaneously open by an IRAF process in + the usual case. + +- The number of keywords in a group header block for STF images (i.e. + the MAX_PCOUNT) was increased from 50 to 99 in the STF image kernel. + +- Added support for the bitwise boolean operators: ‘&’ (and), ‘\|’ + (or), ‘^’ (xor), and ‘~’ (not/complement), to vectory expression + evaluator fmtio$evvexpr.gy. The IMEXPR task was modified to allow + these new bitwise operations. + +- Added new vector operators to VOPS library: alan, alank (logical AND) + and alor, alork (logical OR). These take any integer data as input + (short, int, long) and return a logical (expressed as int) result. + +- The ‘imextn’ environment variable will now accept upper-case + extensions to specify image types. + +- Host Command Execution: The way command line arguments are parsed was + modified to make it easier to set the value of a string parameter to + the null string. Whitespace is still skipped in @par files as before, + however null strings are valid parameter values and will no longer + cause a parameter prompt. + +- The MKPKG special file list link support was enhanced to allow + replacing LFLAGS (the link flags variable) as well as the entire link + line. This makes is possible to write special-file list entries for + packages which need e.g. to be compiled nonshared on certain + platforms without creating a platform specific mkpkg file for the + package itself. + +- The HSI zawset.c routine which controls a process working set size + was modified to automatically detect the physical size of system + memory (with a maximum return value of 2Gb). The hard upper limit on + memory utilization defined by the unix kernel can be limited either + by the value return by the IRAF kernel (up to 90% of physical + memory), or by the value set in the user environment variable + MAXWORKSET (given in units of Mb). + +- New stdimage display devices were added to support the display of + Gemini GMOS CCD data. These devices are named ‘imt45’ thru ‘imt49’ + and correspond to the following frame buffer sizes: + + :: + + imt45 2080 x 4644 # imt45|imtgmosccd + imt46 6400 x 4644 # imt46|imtgmos + imt47 3200 x 2322 # imt47|imtgmos2 + imt48 1600 x 1161 # imt48|imtgmos4 + imt49 800 x 581 # imt49|imtgmos8 + +Core IRAF Revisions Summary +--------------------------- + +New Tasks +~~~~~~~~~ + +- imcoords: + + - ccget: extract objects from a test file catalog + - ccstd: transform to and from standard astrometric coordinates + +- proto: + + - mimstatistics: do image statistics through a mask + - rskysub: sky subtract images using running mean or median + - mskexpr: general mask expression evaluator + - mskregions: create a mask from a list of region specifications + +Existing Tasks with New Parameters or New Parameter Defaults +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- immatch: + + - imcentroid: new parameter maxshift + - imalign: new parameter maxshift + - geomap: new parameter maxiter, default reject = 3.0 not INDEF + +- imcoords: + + - ccmap: new parameter maxiter, default reject = 3.0 not INDEF + - imcctran: new parameter longpole + +- imutil: + + - hedit: new parameter addonly + - imstatistics: new parameters nclip, lsigma, usigma, cache + +Existing Tasks with New Capabilities +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- immatch: + + - imcentroid: optionally rejects objects whose centers wander too + much + - imalign: optionally rejects objects whose centers wander too much + - geomap: iterative rejection capability added + +- imcoords: + + - ccmap: iterative rejection capability added + - imcctran: support for non-zenithal projections added + +- imutil: + + - hedit: support for add keyword only if new option + - imstatistics: support for iterative rejection and memory caching + added + - imexpr: support for bitwise operators or, and, xor, and not added + +NOAO Package Revisions Summary +------------------------------ + +New NOAO Packages +~~~~~~~~~~~~~~~~~ + +- astcat: Astronomical catalog and surveys access package + +- crutil: Cosmic ray detection and removal package + +- obsutil: Observing utilities package + +New NOAO Package Tasks +~~~~~~~~~~~~~~~~~~~~~~ + +- apphot: + + - pcalc: Do arithmetic operations on a list of apphot databases + - pconvert: Convert a text database to a tables database + - pdump: Print selected fields from a list of apphot databases + - pexamine: Interactively examine and edit an apphot database + - prenumber: Renumber stars in an apphot database + - pselect: Select records from an apphot database + - psort: Sort an apphot database + +- astcat: + + - aclist: List the supported astrometric catalogs + - agetcat: Extract astrometry files from astrometric catalogs + - afiltcat: Filter astrometry files derived from astrometric + catalogs + - adumpcat: Catalog access debugging task + - aslist: List the supported image surveys + - agetim: Extract FITS images from image surveys + - ahedit: Initialize the image wcs and set standard keywords + - aimfind: Select images containing catalog objects + - adumpim: Image survey access debugging task + - aregpars: Default region parameter set + - acatpars: Default astrometry file format parameter set + - afiltpars: Default astrometry file filtering parameters + - aimpars: Default image data parameters + - awcspars: Default image wcs parameters + +- crutil: + + - cosmicrays: Remove cosmic rays using flux ratio algorithm + - craverage: Detect CRs against average and avoid objects + - crcombine: Combine multiple exposures to eliminate cosmic rays + - credit: Interactively edit cosmic rays using an image display + - crfix: Fix cosmic rays in images using cosmic ray masks + - crgrow: Grow cosmic rays in cosmic ray masks + - crmedian: Detect and replace cosmic rays with median filter + - crnebula: Detect and replace cosmic rays in nebular data + +- obsutil: + + - psfmeasure: Measure PSF sizes from stellar images + - specfocus: Determine spectral focus and alignment variations + - starfocus: Determine direct focus variations from stellar images + - ccdtime: CCD photometry exposure time calculator + - pairmass: Plot airmass vs time for a given coordinate + - sptime: Spectroscopic exposure time calculator + - specpars: Spectrograph instrument parameters for sptime + - bitcount: Accumulate the bit statistics for a list of images + - findgain: Estimate the gain and readnoise of a CCD + - shutcor: Shutter correction from images of varying exposure times + +- nproto: + + - objmasks: detect and catalog objects in image + +Existing Packages and Tasks with New Parameters or New Parameter Defaults +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- apphot: new package parameters wcsin, wcsout, and cache + + - center: new parameters wcsin, wcsout, cache + - daofind: new parameters wcsout, cache + - fitpsf: new parameters wcsin, wcsout, cache + - fitsky: new parameters wcsin, wcsout, cache + - phot: new parameters wcsin, wcsout, cache + - polymark: new parameters wcsin, wcsout, cache + - polyphot: new parameters wcsin, wcsout, cache + - qphot: new parameters wcsin, wcsout, cache + - radprof: new parameters wcsin, wcsout, cache + - wphot: new parameters wcsin, wcsout, cache + - txdump: replaced by pdump, available as a hidden task + +- astutil: + + - setairmass: new parameters ra, dec, equinox, st, ut, scale + +- daophot: new package parameters wcsin, wcsout, wcspsf, and cache + + - addstar: new parameters wcsin, wcsout, wcspsf, and cache + - allstar: new parameters wcsin, wcsout, and wcspsf + - daoedit: new parameters cache + - daofind: new parameters wcsout, and cache + - group: new parameters wcsin, wcsout, wcspsf, and cache + - nstar: new parameters wcsin, wcsout, wcspsf, and cache + - peak: new parameters wcsin, wcsout, wcspsf, and cache + - phot: new parameters wcsin, wcsout, and cache + - psf: new parameters wcsin, wcsout, and cache + - substar: new parameters wcsin, wcsout, and cache + +.. _existing-tasks-with-new-capabilities-1: + +Existing Tasks with New Capabilities +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- apphot: + + - center: coordinate system support, optional image cacheing + - daofind: coordinate system support, optional image cacheing + - fitpsf: coordinate system support, optional image cacheing + - fitsky: coordinate system support, optional image cacheing + - phot: coordinate system support, optional image cacheing + - polymark: coordinate system support, optional image cacheing + - polyphot: coordinate system support, optional image cacheing + - qphot: coordinate system support, optional image cacheing + - radprof: coordinate system support, optional image cacheing + - wphot: coordinate system support, optional image cacheing + +- astutil: + + - setairmass: ra, dec, equinox, st, ut, scale are no longer + hardwired + - rvcorrect: more flexibility in setting ut + +- daophot: + + - addstar: coordinate system support, optional image cacheing + - allstar: coordinate system support + - daoedit: optional image cacheing + - daofind: coordinate system support, optional image cacheing + - group: coordinate system support, optional image cacheing + - nstar: coordinate system support, optional image cacheing + - peak: coordinate system support, optional image cacheing + - phot: coordinate system support, optional image cacheing + - psf: coordinate system support, optional image cacheing + - substar: coordinate system support, optional image cacheing + +General Package Changes +----------------------- + +NOAO +~~~~ + +ONEDSPEC +^^^^^^^^ + +More than 999 apertures are now allowed. + +APPHOT +^^^^^^ + +- Coordinate Support: + + All the apphot tasks have been modified to accept input coordinates + in the logical, tv, physical, or world systems, and to write output + coordinates in the logical, tv, or physical coordinate systems. One + consequence of this is that the apphot tasks will now work correctly + on image sections in interactive mode. Another is that users can now + work directly on image sections while preserving the coordinate + system of the parent image. + +- Image Cacheing Support: + + All the apphot tasks which accept image pixel input have been + modified to optional cache the entire input image in memory. Cacheing + may significantly improve the performance of tasks where many random + access operations are performed. + +- File and image name directory information removed from output files + All the apphot tasks have been modified to strip directory infor- + mation from the image and coordinate file names written to the output + files, to the terminal, and to the plot headers. The colon commands + will still read and write full image and coordinate file path names. + +- New PTOOLS Tasks Added + + The ptools package tasks pcalc, pconvert, pdump, prenumber, pselect + and psort were added to the apphot package. The functionality of the + old txdump task as been replaced by the pdump. TXDUMP is still avail- + able as a hidden task. + +ASTCAT +^^^^^^ + +The astcat package is a set of tasks for extracting astrometric and +photometric calibration data from remote or local catalogs, filtering +the data, extracting FITS images from remote or local surveys, and +adding standard keywords to the extracted images. There is also a task +for selecting images which contain catalog objects and locating the +catalog objects in the image. + +IMRED.CRUTIL +^^^^^^^^^^^^ + +Cosmic ray detection and removal package. This package includes new +tasks and links to tasks from other package. It replaces the CRUTIL +external package. + +IMRED.QUADRED +^^^^^^^^^^^^^ + +Reduction package for QUAD format data. This replaces the ARED.QUAD and +XCCDRED external packages for processing CTIO and ESO FORS1 multi- +amplifier data. + +DAOPHOT +^^^^^^^ + +- Coordinate Support + + All the daophot tasks have been modified to accept input coordinates + in the logical, tv, physical, or world systems, and to write the + output coordinates in the logical, tv, or physical coordinate + systems. One consequence of this is that the daophot tasks will now + work correctly on image sections in interactive mode. Another is that + users can now work directly on image sections while preserving the + coordinate system of the parent image. + +- Image Cacheing Support + + All the daophot tasks which accept image pixel input have been + modified to optionally cache the entire input image in memory. + Cacheing signif- icantly improves the performance of the tasks when + many random access operations are performed. The cacheing already + performed by the ALLSTAR task is unchanged. + +- File and image name directory information removed from output files + + All the daophot tasks have been modified to strip directory + information from the image and coordinate file names written to the + output files, to the terminal, and to the plot headers. The colon + commands will still read and write full image and coordinate file + path names. + +OBSUTIL +^^^^^^^ + +New observing utilities package. This collects tasks from the NMISC, +SPECTIME, PROTO, and NLOCAL external package which are useful to plan or +carry out observations. The new tasks are: + +:: + + PSFMEASURE STARFOCUS SPECFOCUS CCDTIME + PAIRMASS SPTIME BITCOUNT FINDGAIN + SHUTCOR + +OBSOLETE +^^^^^^^^ + +- Added tasks OIMCOMBINE and OIMSTATISTICS which are the previous + versions from V2.113b system + +- Deleted the ODISPLAY task + +General Task Changes +-------------------- + +.. _noao-1: + +NOAO +~~~~ + +ONEDSPEC.SPLOT +^^^^^^^^^^^^^^ + +Rather than refusing to evaluate errors when there is negative data, +negative data is treated as zero. + +ASTUTIL.SETAIRMASS +^^^^^^^^^^^^^^^^^^ + +Modified to have greater flexibility in selecting the keyword defining +the universal time. New parameters define the keywords for RA, dec, +equinox, siderial time, universal time, and astrospheric scale height. + +ASTUTIL.RVCORRECT +^^^^^^^^^^^^^^^^^ + +Modified to have greater flexibility in selecting the keyword defining +the universal time. + +IMRED.ECHELLE.ECIDENTIFY +^^^^^^^^^^^^^^^^^^^^^^^^ + +Help page describes how to externally evaluate the dispersion fcns. + +IMRED.CCREDRED.COSMISRAYS +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Task was removed (see CRUTIL) + +NPROTO.FINDGAIN +^^^^^^^^^^^^^^^ + +Task was removed (see OBSUTIL) + +NPROTO.OBJMASKS +^^^^^^^^^^^^^^^ + +This is a new task for detecting objects in an image and creating an +output catalog or pixel mask of found objects. + +TWODSPEC.LONGSLIT.FITCOORDS +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- Help page describes the contents of the database and how to + externally evaluate the fits. + +- The RMS is shown in the graph title and in the :show output. + +TWODSPEC.APEXTRACT.APEDIT +^^^^^^^^^^^^^^^^^^^^^^^^^ + +When there is just one aperture the background regions are shown on the +graph without needing to enter the ‘b’ background mode. + +IMAGES +~~~~~~ + +TV.DISPLAY +^^^^^^^^^^ + +- The mask overlay feature when the displayed image is a reduction of + mask (e.g. a block average) now uses the maximum of all mask pixels + within the display pixel. + +- The task will now allow up to 16 frame buffers to be used for the + display if allowed by the server. (Currently requires XIMtool V1.3). + +TV.IMEXAMINE +^^^^^^^^^^^^ + +- A new key ‘t’ allows output of a region centered on the cursor as an + image for further analysis by other programs. + +- The task will now allow up to 16 frame buffers to be used for the + display if allowed by the server. (Currently requires XIMtool V1.3). + +- Cursor readback will now properly detect the correct image when more + than one image is displayed per frame, e.g. in a mosaic. (Currently + requires XIMtool V1.3). + +IMMATCH.IMCOMBINE +^^^^^^^^^^^^^^^^^ + +- New parameters “headers”, “bpmasks”, “rejmasks”, “nrejmasks”, and + “expmasks” provide additional types of output. The old parameters + “rejmask” and “plfile” were removed. The new “nrejmasks” parameter + corresponds to the old “plfile” and the new “rejmasks” parameter + corresponds to the old “rejmask”. + +- There is a new “combine” type “sum” for summing instead of averaging + the final set of offset, scaled, and weighted pixels. + +- There is a new parameter “outlimits” to allow output of a subregion + of the full output. This is useful for raster surveys with large + numbers of images. + +- Additional keywords may appear in the output headers. + +- Scaling is now done relative to the first image rather than an + average over the images. This is done so that flux related keywords + such as exposure time and airmass remain representative. + +- A median calculation was made faster. + +- The previous version is available in the OBSOLETE package. + +IMMATCH.IMCENTROID +^^^^^^^^^^^^^^^^^^ + +IMMATCH.IMALIGN +^^^^^^^^^^^^^^^ + +A new parameter maxshift has been added to the imcentroid and imalign +tasks. Maxshift defines the maximum permitted difference between the +predicted and computed shifts. It is used to reject objects whose +positions have wandered too far from the predicted positions. + +IMMATCH.GEOMAP +^^^^^^^^^^^^^^ + +IMCOORDS.CCMAP +^^^^^^^^^^^^^^ + +An iterative rejection capability has been added to the geomap and ccmap +tasks. The new parameter maxiter in combination with the existing +parameter reject define the rejection parameter. The default value of +the reject parameter has been changed from INDEF to 3.0. + +The colon command “:order ” has been added to the geomap and ccmap +tasks. The new command enables the user to change all the order +parameters simultaneously when experimenting with different fitting +functions. + +IMCOORDS.STARFIND +^^^^^^^^^^^^^^^^^ + +The starfind task background estimation algorithm has been modified so +that it no longer depends on the value and density of the central pixel. + +IMCOORDS.IMCCTRAN +^^^^^^^^^^^^^^^^^ + +Support for non-zenithal projections has been added to the imcctran +task. The previous technique of rotating the cd matrix does not work +properly for these functions. The new parameter longpole was added to +imcctran. Longpole enables the user to select either the cd matrix or +longpole / latpole method for transforming zenithal projections. + +IMCOORDS.CCGET +^^^^^^^^^^^^^^ + +The new task ccget was added to the imcoords package. Ccget extracts +objects in a user specified region from a simple text file catalog. + +IMCOORDS.CCSTD +^^^^^^^^^^^^^^ + +The task ccstd was added to the imcoords package. Ccstd transforms pixel +and celestial coordinates to standard coordinates and vice versa. + +IMUTIL.HEDIT +^^^^^^^^^^^^ + +The new parameter addonly was added to hedit task. The addonly switch is +used to add a parameter to the image header only if it does not already +exist. The addonly switch has a precedence intermediate between the add +and delete switches. + +IMUTIL.IMSTATISTICS +^^^^^^^^^^^^^^^^^^^ + +An interactive rejection capability has been added to the imstatistics +task. The new parameters nclip, lsigma, and usigma define the rejection +parameters. A memory cacheing option was also added to imstatistics in +order to optionally speed up performance if iterative rejection is en- +abled or the midpt/mode is computed. + +IMUTIL.IMEXPR +^^^^^^^^^^^^^ + +Support for the bitwise operators or (|), and (&), exclusive or (^), and +not (~) has been added to the imexpr task. The logical operators or (||) +and and (&&) have been made truly logical i.e. they return 0’s or 1’s, +rather than results of a bitwise or and and. + +PROTO +~~~~~ + +MIMSTATISTICS +^^^^^^^^^^^^^ + +The new task mimstatistics has been added to the proto package. +Mimstatistics does image statistics through a mask. + +RSKYSUB +^^^^^^^ + +The new task rskysub was added to the proto package. Rskysub does a +running mean or median sky subtraction on an ordered list of images +using optional background scaling and object masking. + +MSKEXPR +^^^^^^^ + +The new task mskexpr has been added to the proto package. Mskexpr +creates a new mask from a user supplied expression, an optional +reference image, and an optional reference mask. + +MSKREGIONS +^^^^^^^^^^ + +The new task mskregions has been added to the proto package. Mskregions +creates a new mask or modifies an existing mask using a list of region +definitions or region expressions. + +XTOOLS +~~~~~~ + +SKYWCS +^^^^^^ + +A new library skywcs has been added to the xtools package. The skywcs +library is a set of routines for managing image and catalog celestial +coordinate systems and for transforming from one celestial coordinate +system to another. Skywcs is layered on the Starlink Positional +Astronomy library slalib which is installed in the iraf math package. + +CATQUERY +^^^^^^^^ + +A new library catquery was added to the xtools package. The catquery +library is a set of routines for doing local and remote catalog and +image survey access. + +SYSTEM +~~~~~~ + +HELP +^^^^ + +Task was modified to call the XHELP code to run the GUI version of the +task if requested. Task output is the same if the device remains the +default ‘terminal’ value, however resetting the ‘device’ parameter to +one of ‘gui’, ‘html’, or ‘ps’ will either spawn the GUI task under +xgterm or print the converted help page to the stdout. + +LROFF +^^^^^ + +The task was enhanced with a new ‘format’ parameter that allows the text +to be formatted as one of: plain-text, HTML, or Postscript. + +Parameter File Changes +---------------------- + +In the tables below each parameter change is identified with one of the +following codes followed by task name and the description of the change. + +- n = new parameter +- c = changed/modified parameter +- d = deleted parameter + +CL +~~ + +:: + + n cl Added the new CL parameter "release". This + is a string valued parameter with values such + as "2.11.3a", "2.12", "3.0" etc. This differs + from "version" which is a descriptive string + such as "NOAO/IRAF V2.11.3 EXPORT". There can + be multiple releases of one version of the + software, and "release" specifies exactly what + build the software is. The release strings are + composed in such a way that they can be used + in expressions, e.g. (release >= 2.11.3) would + be true for IRAF V2.11.3 and all subsequent + releases. + +DATAIO +~~~~~~ + +:: + + c dataio.export Made the 'format' parameter automatic mode + c dataio.import Made the 'format' parameter automatic mode + +.. _images-1: + +IMAGES +~~~~~~ + +:: + + n imcoords.imcctran Added a new parameter longpole to the imcctran + task. If longpole=yes then coordinate transfor- + mations with zenithal projections will be rot- + ated using longpole rather than the CD matrix. + + c immatch.wregister Fixed boundary option typo, "refect" to "reflect". + c immatch.sregister Fixed boundary option typo, "refect" to "reflect". + + n immatch.imcentroid Added a new parameter maxshift to the imcentroid + immatch.imalign and imalign tasks. Maxshift is the maximum perm- + itted difference between the computed and predicted + shifts. Maxshift can be used to reject objects whose + centers have wandered too far from the expected + center. By default maxshift is undefined. + + n immatch.geomap Added a new parameter maxiter to the geomap and + immatch.ccmap ccmap tasks. Maxiter defines the maximum number of + rejection iterations and has a default value of 0 + for no rejection. + + c immatch.geomap Changed the default value of the ccmap and geomap + c immatch.ccmap parameter reject from INDEF to 3.0. + + c immatch.imcombine Numerous changes, see details above + + c imgeom.imlintran Changed the nrows argument names to nlines + + + n imutil.hedit Added a new addonly parameter to the hedit task. If + addonly is set a new field will only be added to + the image header if it does not already exist. + + n tv.imexamine Added new parameters 'output', 'ncoutput', and + 'nloutput' used by the new 't' keystroke when + outputting an image section centered on the cursor. + +.. _system-1: + +SYSTEM +~~~~~~ + +:: + + n help New parameters required for GUI options, output + formats for HTML/PS, printer, etc. + n lroff Added new 'format' parameter for HTML/PS output + +UTILITIES +~~~~~~~~~ + +:: + + c utilities.surfit Added support for the half cross-terms option to + the surfit task. This involved changing the type + of the xterms parameter from boolean (yes/no) to + string (none,half,full). + +.. _noao-2: + +NOAO +~~~~ + +ASTUTIL +^^^^^^^ + +:: + + n astutil.setairmass new parameters ra, dec, equinox, st, ut, scale + +DIGIPHOT +^^^^^^^^ + +:: + + n apphot new package parameters wcsin, wcsout, and cache + n apphot.center new parameters wcsin, wcsout, cache + n apphot.daofind new parameters wcsout, cache + n apphot.fitpsf new parameters wcsin, wcsout, cache + n apphot.fitsky new parameters wcsin, wcsout, cache + n apphot.phot new parameters wcsin, wcsout, cache + n apphot.polymark new parameters wcsin, wcsout, cache + n apphot.polyphot new parameters wcsin, wcsout, cache + n apphot.qphot new parameters wcsin, wcsout, cache + n apphot.radprof new parameters wcsin, wcsout, cache + n apphot.wphot new parameters wcsin, wcsout, cache + + n daophot new package params wcsin, wcsout, wcspsf, and cache + n daophot.addstar new parameters wcsin, wcsout, wcspsf, and cache + n daophot.allstar new parameters wcsin, wcsout, and wcspsf + n daophot.daoedit new parameters cache + n daophot.daofind new parameters wcsout, and cache + n daophot.group new parameters wcsin, wcsout, wcspsf, and cache + n daophot.nstar new parameters wcsin, wcsout, wcspsf, and cache + n daophot.peak new parameters wcsin, wcsout, wcspsf, and cache + n daophot.phot new parameters wcsin, wcsout, and cache + n daophot.psf new parameters wcsin, wcsout, and cache + n daophot.substar new parameters wcsin, wcsout, and cache + +.. _onedspec-1: + +ONEDSPEC +^^^^^^^^ + +:: + + n standard new parameter mag, magband, and teff. These + n splot params can be use to specify calibration files + n lcalib as blackbody curves scale to a specified magnitude + +TWODSPEC +^^^^^^^^ + +:: + + c apextract.apall1 Reduced the 'polysep' parameter. + c apextract.apdebug Reduced the 'polysep' parameter. + c apextract.apfit1 Reduced the 'polysep' parameter. + c apextract.apnoise1 Reduced the 'polysep' parameter. + c apextract.apnorm1 Reduced the 'polysep' parameter. + c apextract.apparams Reduced the 'polysep' parameter. + +Details of Major System Changes +------------------------------- + +FITS kernel changes +~~~~~~~~~~~~~~~~~~~ + +The FITS kernel was modified to add support for storing images in +extensions as compressed pixel masks. The mask is stored as a binary +table using the “ZIMAGE” (compressed image) convention proposed by +White, Greenfield, Pence, and Tody in 1999: + +`Specifications for Storing Compressed Images in FITS Binary +Tables `__ + +In the current implementation only the “PLIO_1” compression algorithm is +implemented. Mask extensions may be read or written directly by the +kernel. When writing a new extension it will be appended to the MEF +file. To append an image to a MEF file as a mask, include “type=mask” in +the image kernel section when the output image is opened. + +Masks are interfaced to the system as images and may be read and written +like any other image via IMIO. They have a normal image header and can +be manipulated with any program that deals with images. The pixel type +is INT. + +It is also possible to access a mask image as a PLIO mask. An IMSTATI +query for IM_PLDES parameter will return the PLIO mask descriptor. While +a mask extension is opened under IMIO it is represented as a PLIO mask +and may be accessed in this form like any other mask. + +The mask image is stored in the FITS binary table (BINTABLE) extension +when the image is closed, and is loaded from the extension when the +image is opened. The compression representation used to store the mask +in the binary table is the same as is used within PLIO. The new (V2.12) +encoding is used, allowing very large masks to be stored. Currently +masks up to 3D are supported. Data on each 2D mask plane will be +compressed in both X and Y as with PLIO. The depth of the mask is +preserved. + +Although a mask is stored as a binary table the format of the table is +not completely general. In the current implementation there can be only +one column in the table (COMPRESSED_DATA). This is an integer-valued +variable length array column containing, for each line of the +N-dimensional image, the PLIO compressed version of that image line. The +actual compressed data is stored in the heap area of the table. Multiple +image lines may point to the same compressed line list, e.g., to store +the empty line or to compression in Y. + +Large Image Support +~~~~~~~~~~~~~~~~~~~ + +The following changes were made to enable IMIO to use larger buffer +sizes to optimize i/o for large images: + +The default file buffer size set by IMIO is unchanged: it is still about +512 MB, the value set for V2.11.2. However, a new parameter IM_BUFFRAC +was added. Both IM_BUFSIZE and IM_BUFFRAC are used to help determine the +FIO buffer size set when an image is opened. The logic for this is +implemented in imsetbuf.x. + +Backwards compatibility. If you do nothing about IMIO/FIO buffers in +your program, the system may transparently use a larger buffer for +larger images. If you set BUFSIZE in your program, the system will by +default use the value you give, or possibly a larger value, if the image +you are accessing is very large. If you set BUFSIZE and you want to +guarantee that the value you set is used (even for very large images) +then you should also set BUFFRAC=0 to ensure that only BUFSIZE is used. + +How it works. BUFFRAC specifies the default FIO buffer size used to +access an image, expressed as a percentage of the size of the image. For +example, the builtin default value of BUFFRAC=10 will try to make a FIO +buffer 10% of the size of the image. The actual value used will be given +by BUFFRAC, but will be at least BUFSIZE, and no more than a builtin +default maximum value, currently 32 MB. Given the builtin defaults, the +buffer size will range from 0.5 to 32 MB depending upon the size of the +image being accessed. As noted above, BUFSIZE and BUFFRAC can be set to +force the buffer size to a specific value if desired. + +Environment variables for both parameters are provided. The names are +“IMIO_BUFSIZE” (specified as bytes) and “IMIO_BUFFRAC” (specified as a +decimal fraction). If defined, these override (at image open time) the +builtin default values for both parameters. An IMSET call by the +application will override all such defaults. + +The FIO buffer allocated will not be larger than the size of the image. +The FIO buffer will also not exceed the maximum size set by the file +driver being accessed. For example, for PLIO images the file buffer will +not exceed about 2KB, even for a very large mask. This is because the +“pixel file” for a PLIO image is dev$null, the driver for which +specifies a maximum i/o buffer size of 2K (the real file to load or save +the mask will use a different descriptor). + +The intent here is to provide an adaptive mechanism for setting the FIO +buffer size used to access an image, which automatically adapts to the +size of the image being accessed. If you access a lot of small images +you will get smaller buffers - everything will be as before. If you +access very large images, you may get large buffers up to the builtin +maximum value of (currently) 32 MB. + +Using large buffers could cause a machine to run out of memory. However, +it is likely that if someone is working on 300 MB images that they are +using a machine which has a memory at least that large - probably +larger. If there are problems, the environment variable overrides can be +used to tune IMIO. + +The reason for large file buffers is to limit the number of disk data +transfers, and hence the number of disk seeks. Using buffers larger than +a certain amount (32 MB is generous) is probably counterproductive. If +the i/o system provides 20 MB/sec i/o transfers, 32 MB will take 1.6 +seconds. This should be more than a large enough granularity to provide +efficient i/o, hence is a reasonable limit (at this point paging effects +are likely to dominate). + +Virtual Memory Cache +~~~~~~~~~~~~~~~~~~~~ + +The VMcache client interface and daemon provide a method by which +data-intensive IRAF tasks (or non-IRAF tasks for that matter) can manage +how files/images are maintained in virtual memory to avoid excessive +system paging. In essence it’s a way to “lock” a specific image in +memory to improve performance. As of this release no tasks in the system +have been modified to make use of the VMcache daemon, however installing +it in the system at this point provides a framework for future +applications and systems development. + +The following notes summarize the changes made for this feature and +describe it’s function in more detail. A more complete description of +the interface, environment variables which control it, etc can be found +in the main systems revisions file iraf$local/notes.v211. + +The source for the developmental version of the VMcache library and the +VMcache daemon (vmcached) have been installed in the unix$boot tree and +the HSI binary file driver was modified to add VMcache client support. +This adds two new capabilities to the driver: 1) built-in support for +direct i/o (on systems that support it), and 2) a client interface to +the VMcache daemon to permit the daemon to optimally manage binary file +i/o if a VMcache daemon is present. + +The vmcached code is complete but only enough debug/testing was done to +support development of the VMcache client interface for IRAF (the +vmcached code is debugged but the new version of the vmcache library +code has not been tested). Since the daemon can be utilized outside the +normal IRAF release we do not have to fully develop it for the release. + +It should be stressed that VMcache is only useful or warranted for +systems that are very data intensive. The standard host operating system +file access heuristics are best for “normal” processing where either the +system is not really busy, or the datafiles are not excessively large. +On systems with very large physical memories where massive amounts of +data are being processed, VMcache can make a significant difference in +overall system performance. + +VMcache is too complex to document here. Without going into the details, +its function is to manage a cache of files in system virtual memory. +Files can be explicitly cached or uncached, or they can be “accessed”, +and VMcache will decide whether or not to cache the file in virtual +memory. This is what the VMcache client interface does: every time it +accesses (opens or extends) a file larger then the VM threshold it sends +an “access” directive to the VMcache daemon. The daemon sends back a +response of 0 (file not cached; use direct i/o to access the file), or 1 +(file cached in VM; use normal VM-buffered i/o to access the file). Even +if a file is not cached the daemon keeps track of all accesses. Files +which are frequently accessed will have a higher priority and are more +likely to be cached in memory. + +The VMcache daemon is a separate system-level program outside of IRAF. +This is necessary to provide a central system-wide cache controller. It +also provides flexibility, allowing multiple versions of the daemon to +exist, e.g., to allow experimentation with different types of caching +algorithms. It also allows easy customization of the daemon +independently of the IRAF applications using the VMcache client +interface. + +.. _new-developer-libraries-1: + +New Developer Libraries +~~~~~~~~~~~~~~~~~~~~~~~ + +Several new libraries are now available for developers: + +- **PSIO** New Postscript text generation library installed in the + sys$psio. + + The PSIO interface is used to format a block of text as Postscript + output on a page of a given size (Letter, Legal, A4 or B5). See the + psio$README file for details. + +- **CATQUERY** Remote astrometric/photometric catalog access lib + installed in the XTOOLS utility library. + + The catquery package provides a set of routines for local and remote + catalog and image survey server access. The sup- ported catalogs and + image surveys are described in records stored in a catalog and image + survey configuration file respectively. The catalog and image survey + records specify the network address, the query format, and the output + format for each supported catalog or image display server. See “help + catalogs” and “help surveys” for details. + +- **SKYWCS** Sky coordinate transformation library installed in the + XTOOLS utility library. + + The skywcs package contains a simple set of routines for managing sky + coordinate information and for transforming from one sky coordinate + system to another. The sky coordinate system is defined either by a + system name, e.g. “J2000”, “galactic”, etc., or by an image system + name, e.g. “dev\ :math:`ypix" or "dev`\ ypix world”. + +System Changes Which May Affect You +----------------------------------- + +SHARED LIBRARY VERSION INCREMENTED (Sun/IRAF only) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The IRAF shared library for SunOS and Solaris platforms has been +incremented with this release due to the nature of various system +changes. Existing IRAF binaries (e.g. locally written software or +external packages) will continue to run using the old shared image, +however they will need to be recompiled against V2.12 in order to pick +up the numerous system bug fixes and features in this release. In +particular, pixel masks produced by V2.12 IRAF tasks may be incompatible +with external packages which have not been recompiled. + +EXTERNAL PACKAGE RECOMPILATION +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The V2.12 release contains changes to the FIO and PLIO/PMIO interface +header files used by numerous applications. Relinking of an external +package may fail to pick up these changes and not recompile a source +file which uses one of these header files if the mkpkg file doesn’t +correctly list all of the dependencies (nearly all packages have one or +more mkpkg files which have this problem). In the worst cases this could +lead to a runtime error due to the incompatibilities. + +For this reason we recommend that all packages and local tasks be +recompiled (completely from source\* (rather than simply relinked +against the new version) to assure that all changes and new features +will be included. Recompilation also guarantees that packages can take +advantage of some of the larger buffer sizes and optimizations in this +release. Site support can supply a list of missing mkpkg dependencies +for most external packages being developed outside NOAO that wish to fix +these files for a future release. + +.. _parameter-file-changes-1: + +PARAMETER FILE CHANGES +~~~~~~~~~~~~~~~~~~~~~~ + +As with all major releases, we recommend that you do a MKIRAF and delete +all your old parameter files after the IRAF upgrade. You may choose not +to do this if you are in the midst of a project and have setups that may +be difficult to reproduce. + +The automatic parameter file update/merge mechanism, which is used if +you do not initialize your parameters with MKIRAF, is based on file date +comparisons. If you run IRAF V2.11 after V2.12 has been installed, the +file dates on your uparm parameter files will be more recent than the +V2.12 installation date. If you then try to run V2.12, the automatic +parameter file merge/update will fail due to the file dates. The system +only updates personal parameter files which are older than the update +date of the system. A MKIRAF avoids the problem if you delete your +parameter files, causing them to be updated from the system default +versions. + +INSTALLATION SCRIPT CHANGES +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As the first step of an ongoing effort to simplify the installation and +system configuration, the IRAF install script was rewritten to do some +error-checking of the iraf setup, present a simplified and easier to +read output, and do some common post-install configuration of the +system. Additionally, the SYSINFO diagnostic script for finding system +errors and reporting on the configuration, and a new UNINSTALL script +for removing IRAF files/links from the system have also been installed. +The old install script is still available as a fallback in case problems +with the new script are found. + +HELP SYSTEM CHANGES +~~~~~~~~~~~~~~~~~~~ + +The HELP task was modified with several new parameters controlling the +display and formatting of the help pages. Help may now be presented as +formatted text (as before), HTML, or fully formatted Postscript. +Additionally, users running under an XGterm window can use the task in a +new GUI mode. The help GUI allows users to browse the help system and +easily search for tasks/topics using a familiar web-like interface. The +GUI mode is not the default, but can be enabled easily using the +‘device’ parameter. + +IMAGE DISPLAY CHANGES +~~~~~~~~~~~~~~~~~~~~~ + +Tasks which display images or interact with the image display were +modified to take advantage of new features added to XImtool V1.3 +(e.g. the multiple WCS and pixel-value readouts and 16 display frame +buffers). These changes were done in a backwards compatible way so +interaction with display servers such as SAOimage, SAOtng, DS9, or older +XImtool versions should be unaffected. If problems are dis- covered a CL +environment variable ‘disable_wcs_maps’ can be defined to force all of +the old behaviors. These changes do not add any new functionality to the +tasks themselves, only the underlying display protocols. + +PLIO Changes +~~~~~~~~~~~~ + +The LEN and BLEN fields of the encoded line list (LL) descriptor would +limit the length of a pixel area (and hence the size of a pixel mask) to +the max size of a signed short, 32768. This was due to the use of a +simple array of type short to encode the line list (which simplifies +handling considerably). Nonetheless the limit to 32K was unacceptable. +The fix adopted was to increase the LL header from 3 to 7 words. Two 16 +bit words are now used to encode each of LEN and BLEN. A “version” word +was added to allow the old, new, and future encodings to be +distinguished. A “hdrlen” word was added to parameterize the length of +the LL header, rather than fix it at compile time as in the initial +version. With this change, the maximum length of an image line under +PLIO is increased from 32768 to 1073741824 (32768*32768). All the higher +level PLIO code is integer, so should already support larger masks. + +This was done in such a way that old line lists can still be read, +although PLIO will always write out new format line lists (pixel mask +files and images, QPOE, and MWCS all store encoded line lists in +external storage, so backwards compatibility is important; also existing +complied programs will continue to generate the old format). The cost is +8 bytes per encoded line list. For most masks this should only increase +the size of the mask by a few percent at most. + +NEW ENVIRONMENT VARIABLES +~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following new environment variables may be defined to tune the size +of the system file i/o buffers used by the image i/o system. The system +will automatically adjust to use larger buffers when accessing larger +images, these variables may be set to further optimize the buffers + +- **IMIO_BUFSIZE**: Size of the FIO buffer size in bytes. + +- **IMIO_BUFFRAC**: FIO buffer size expressed as a percentage of the + image size. Actual value will be at least BUFSIZE and no more than + BUFMAX. + +- **IMIO_BUFMAX**: Max size of FIO buffer which will override the 32Mb + default. + +Other miscellaneous environment variables: + +- **disable_wcs_maps**: If defined or set to ‘yes’, this variable will + force any tasks which interact with the image display to use the old + protocols. + +- **pspage**: Variable which is used by the PSIO interface to set the + default page size. Acceptable values include “letter” (the default) + for US Letter, “legal” for US Legal, and “a4” and “b5” for the most + common European sizes. Pspage can be used by the new HELP and LROFF + tasks to automatically set the desired Postscript page size. diff --git a/doc/releases/v214revs.rst b/doc/releases/v214revs.rst new file mode 100644 index 000000000..0bc652a92 --- /dev/null +++ b/doc/releases/v214revs.rst @@ -0,0 +1,181 @@ +IRAF V2.14EXPORT Release Notes +============================== + +:Authors: IRAF Group +:Date: December 1, 2007 +:Abstract: These release notes provide a summary of the major changes in V2.14. + This is a major release of IRAF and will be available for all + supported platforms. More detailed technical documentation of all + system changes will be found in the ‘notes.v212’ files in the + ``iraf$local`` directories. Detailed revisions notes for each application + package are in the package directories in a file called Revisions, + e.g. ``apphot$Revisions``. + +IRAF V2.14 is a major-version release of the system and requires a FULL +INSTALLATION of the package, even if you have an existing V2.13 system. +The Installation Guide (pciraf.ps.Z) contains a detailed description of +the installation process for both first-time installations and updates +to existing systems. Installation will require downloading the AS, IB, +and NB distribution files from this directory. The AS distribution is +common to all PC-IRAF platforms and is required for any installation. +There are separate sets of binaries (the IB and NB distributions) for +each PC-IRAF platform and only those binaries required for a particular +platform will need to be downloaded. + +PC-IRAF V2.14 supports the following platforms: + ++-----------------------------+-------------+--------------------------+ +| System | D | Additional Systems | +| | istribution | | ++=============================+=============+==========================+ +| MacOSX 10.4 and higher | MACX | (Intel or PPC arch) | ++-----------------------------+-------------+--------------------------+ +| Linux RedHat 9 | RHUX | Fedora, Enterprise, | +| | | CentOS | ++-----------------------------+-------------+--------------------------+ +| Debian 3.1 (Sarge) and | LNUX | Other Debian-based | +| higher | | systems and all other | +| | | linux | ++-----------------------------+-------------+--------------------------+ +| Cygwin | CYGW | Windows XP only | ++-----------------------------+-------------+--------------------------+ + +**NOTE**: The SUSE architecture has been dropped as of this release, +however support for SuSE systems is available in the LNUX architecture. +Future releases may seek to merge RHUX and LNUX into a single Linux +platform release to minimize the number of required distributions. + +All versions are supported with a single IRAF distribution, although you +need to install separate binaries for for each platform. + +HIGHLIGHTS OF THIS RELEASE +-------------------------- + +The primary changes to IRAF V2.14 were done to support the new Mac Intel +and Cygwin platforms, as well as fix long-standing issues with the +viability of the system on recent Linux and Mac OS X systems. However, a +number of key features and tasks will be new to users. + +The following list is a partial summary of changes in this release: + +- Mac (Intel) Now a Supported Platform + +- Cygwin (for Windows XP) Now a Supported Platform + +- SUSE dropped as system architecture + +- ECL Now Default Interpreter + + Starting with this release, the ‘cl’ command to start IRAF will + invoke the ECL interpreter as the default. Users can still access the + old CL by starting with the command “% cl -o” + +- FITS Now Default Image File Format + + Starting with this release, FITS will be the default image format for + all output images. Use of OIF (i.e. the “.imh” format) is still + available by changing the ‘imtype’ variable setting. + +- ZPN Projection now supported by all tasks using the MWCS interface + + The ZPN projection driver from the Cambridge Astronomical Survey Unit + was installed in the MWCS interface. ZPN is a zenithal/azimuthal + polynomial projection. + +- RV.FXCOR now fits Gaussian peaks using double precision. Additionally + the HJD output is printed to 5 decimals precision. + +- Access to 2MASS and USNO-B1 catalogs from the ASTCAT package + +- Display overlay colors may be set with expressions + + - The masks specified by the ‘bpmask’ or ‘overlay’ parameters may + now be set using image data or colors represented by expressions. + See the ‘Overlay Colors’ section of the DISPLAY help page for + details. + - Transparent masks (using the name ‘transparent’ or a mapped color + less than zero) are now permitted. + +- IMEDIT has the following changes: + + - A new option to do vector constant replacement was added. This is + particularly useful for editing bad pixel masks. + - New options ‘=’, ‘<’, and ‘>’ to replace all pixels with values + ==, <=, or >= to the value at the cursor with the constant value + was added. This is useful for editing object masks. + - The ‘?’ help page is now set by an environment variable rather + than hardcoded to a file in lib$src. The environment variable is + imedit_help and is set in tv.cl to point to the file in the source + directory. + +- New Tasks In the System: + + - images.tv: + + - BPMEDIT - Examine and edit bad pixel masks associated with + images + + - images.imcoords: + + - MKCWCS - Make or update a simple celestial wcs + - MKCWWCS - Make or update a simple celestial/wavelength 3D wcs + + - lists: + + - RAVERAGE - Compute running average, standard deviation and + envelope + + - noao.nproto: + + - SKYSEP - Compute are separation between two RA/Dec values + - SKYGROUP - Group a list containing RA/Dec into spatial sublists + +- New Parameters + + - images.imutil: + + - HSELECT - Added a ‘missing’ parameter to be used when keywords + isn’t in header. + +- New Environment Variables + + Two new environment variables are available for use in IRAF + networking: + + - KS_RETRY, if defined, is the number of retry attempts using the + default rsh (or KSRSH) protocol. The task will sleep for 1 second + between attempts and then loop back to try again to make the + connection. This is meant to avoid potential clashes between + multiple machines connecting simultaneously as with the pipeline. + + - KS_NO_RETRY which when defined instructs the task *not* to attempt + a retry using the fallback rexec protocol. This test is made after + the KS_RETRY checks to allow for various combinations of settings + to allow the code to skip retries entirely (i.e. define only + KS_NO_RETRY), retry using the default protocol but not with rexec + (i.e. define KS_RETRY as some value and set KS_NO_RETRY), or retry + only with rexec (i.e. old behavior, don’t define anything). + +- Increased Buffer Sizes + + - Various environment buffers were increased to allow for longer + settings of $PATH or other strings that would occassionally + overflow. + - SZ_IMNAME was increased from 79 to 128 characters. + - SZ_ERRMSG in system error strings increased from 80 chars to + SZ_LINE (1023) to allow inclusion of full paths in error messages. + - The FFT procedures in the VOPS interface now permit vectors of + 2^31 points (up from 2^15) + +- New Developer Libraries. + + Several new libraries are available for SPP developers: + + - Installed the ‘mef’ library from the FITSUTIL package for doing + general MEF manipulation. This will remove the dependency on + FITSUTIL from several external packages. + - Installed the ‘dbc’ routines from the FITSUTIL package. This is an + extension to the imgead header database routines that allow for a + comment field to be created/manipulated in the header. + - xtools$xtargs.x is a simple interface to parse an argument string + consisting of a list of whitespace separated keyw=value pairs. diff --git a/doc/releases/v215revs.rst b/doc/releases/v215revs.rst new file mode 100644 index 000000000..00e02e937 --- /dev/null +++ b/doc/releases/v215revs.rst @@ -0,0 +1,445 @@ +IRAF V2.15 Release Notes +======================== + +:Authors: IRAF Group +:Date: November 22, 2010 (revised February 24, 2011) +:Abstract: These notes provide a summary of the major changes in the V2.15 release. + IRAF V2.15 is a major release of the IRAF system for all supported + platforms. The main feature of this release is support for 64-bit Linux + and Mac OSX systems, although there are numerous other enhancements as + well. Because changes to the system interfaces were fairly substantial, + and extended test release was made available to the community to gather + feedback about potential problems in the science code. There were only a + few reported problems and we now consider the system to be stable for + general release and recommended for all users. + + More detailed technical documentation of all system changes will be + found in the ‘notes.v214’ file in the ``iraf$local`` directory, detailed + revisions notes for each application package are in the package + directories in a file called Revisions, e.g. onedspec Revisions. + Please see also the ‘sysnotes.v215’ file in this directory for a + detailed list of the V2.15 changes, and similar files for the detailed + revisions of each patch. + +Highlights of This Release: +--------------------------- + +64-bit Platform Binary Support +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Linux and Mac OSX systems running 64-bit operating systems are now +supported in native 64-bit binary mode. There are currently NO plans to +support 64-bit versions of other operating systems (e.g. Windows, +Solaris, or FreeBSD). + +New MEMIO Interface +~~~~~~~~~~~~~~~~~~~ + +The MEMIO interface was necessarily changed to accomodate the 64-bit +upgrade, specifically we added extra structure to a memory object to aid +in debugging (e.g. sentinal values before/after a segment, a reporting +mechanism etc). This adds a slight bit of overhead to each heap memory +allocation, but we consider this to be minor given the capabilities of +today’s systems. A suite of environment variables can now also be set to +manage/monitor this new interface (see below). + +Single ‘linux’ Architecture for 32-bit Systems +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This is part of the overall architecture changes implemented in v2.15 +systems. The original logic for separate ‘suse’, ‘redhat’ and ‘linux’ +architectures was due to differences between these platforms in the +GCC/GLibc systems used that were inherently incompatibile. These +differences have since become irrelevant and now impose a burden to +support and maintain separate platforms, and so a common ‘linux’ +architecture is now preferred. + +Because external packages may lag in the changes needed to switch +architectures, we try to support legacy references to e.g. ‘redhat’ as +an alias to the new ‘linux’ structure and hope that the previous +deprecation (in v2.14) of ‘suse’ has now been removed entirely. Since +64-bit support requires a new architecture name (i.e. ‘linux’ versus +‘linux64’) there will be no confusion between the 32- and 64-bit +versions of systems. + +Mac OSX Architecture Changes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In previous IRAF releases the ‘macintel’ archicture was used for all OSX +versions running on Intel hardware, and ‘macosx’ was reserved for +PowerPC (PPC) CPUs. In order to avoid yet another IRAF architecture name +to distinguish 64 and 32-bit Intel systems, and because OSX systems are +moving generally towards Intel CPUs with 64-bit capabilities anyway, we +decided that future IRAF systems will favor 64-bit Intel architectures +as users upgrade machines. + +What this means is that starting with v2.15, the IRAF ‘macintel’ +architecture will now refer exclusively to 64-bit Intel hardware. In +order to retain compatibility with older systems, the ‘macosx’ IRAF +architecture will encompass 32-bit binaries for both PPC and Intel CPUs +in a Universal binary format. + +This is a departure from past platform architecture naming conventions +where a new unique name is used, however future MacOSX systems will all +be Intel-based and hardware will be 64-bit capable so shifting the focus +to ‘macintel’ being the primary platform and ‘macosx’ supporting older +systems made the most sense. (In hindsight, we would have preferred to +be able to use ‘macosx’ as being more descriptive). + +The ‘macosx’ architecture now includes both PPC and Intel binaries in +the system libraries (and those produced for external packages) and +executables. These binaries are compatible for OSX 10.4 and later +systems and the system will automatically use the appropriate binary for +the hardware (e.g. on an OSX 10.4 PowerPC machine the PPC binary for the +‘macosx’ arch will execute the PPC binary in the iraf executable file). + +While earlier IRAF versions would allow that PPC ‘macosx’ binaries could +be run on Intel systems using the Rosetta sytem, this isn’t currently +allowed with v2.15 as an Intel system would automatically use the Intel +binary. Thus, to test 32-bit PPC binaries you will need a machine with a +PPC CPU. This is seen as something that would affect a minimal number of +users. + +Compile-Time VOS/Kernel Prototype Checking +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +All library code in the IRAF ‘Virtual Operating Interface’ (VOS) and +IRAF Kernal (i.e. the $iraf/unix//os procedures) now have function +prototypes that are checked during compilation of any SPP code. + +Intra-Package Prototype Checking +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This is a feature that will be added in the near future and will provide +the same level of prototype checking as with the core system libraries. +The idea is that a ‘libpkg.a’ will produce a local prototype file that +ensures all calls within the package meet the prototype calls. As with +VOS/Kernel checking, this will validate the code within a package to +trap any potential errors. + +All C Library Code Converted to Clean ANSI-C +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As part of the 64-bit port, all C library code in the VOS and kernel was +converted from the old-style “K&R” style to true ANSI C with full +function prototypes. Additionally, the code was cleaned up to remove any +warnings generated by the compiler, i.e. compilation with “-Wall” under +GCC now compiles cleanly to further ensure the integrity of the code. + +Cross-Compilation of Architectures +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Compilation is now defined by the user environment rather than the +machine used to do the build, as before. What this means is that (within +reason) it is now possible to cross-compile for a different IRAF +architecture on machines which support such compilation. For instance, +on a 64-bit Mac OSX Snow Leopard system (where the native IRAF +architecture is ‘macintel’) one can now compile code for the 32-bit +‘macosx’ architecture (either PPC or Intel) by simply setting the +‘IRAFARCH’ environment varable as ‘macosx’ and reconfiguring the +system/package approriately. + +The same is true for Linux 64-bit systems and ‘linux64’ and ‘linux’ +architectures, meaning one doesn’t need access to machines to produce +binaries. Compilation flags are set auomatically based on the IRAFARCH +variable in order to produce the desired binaries. + +User-Selectable Architectures +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As with compilation, the IRAFARCH variable can be used to determine +which binaries to run. For example, on a 64-bit Linux system (where the +default arch would be ‘linux64’) the commands + +:: + + % setenv IRAFARCH linux + % cl + +would allow a user to run the 32-bit ‘linux’ binaries and thus switch +easily between systems to compare results and validate the science +results of a reduction/analysis task. The same is true for Mac (Intel) +systems where the 64-bit macintel and 32-bit macosx architectures could +be selected by the user. + +SVG Graphics Device for Better Web Presentation of Plots +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +SVG graphics are an XML format supported by many modern browsers that +permit scalable graphics for web presentation. This means that plots +produced by IRAF may be used in web pages without loss of resolution or +aliasing effects seen when using e.g. GIF images of a plot. + +A new ‘g-svg’ graphcap device was added to make use of this new driver. +It produces a file called ‘sgiXXXX.svg’ in the current working directory +(where ‘XXXX’ is a process id) and may be used as e.g. + +:: + + cl> contour dev$pix dev=g-svg + +or in cursor mode with a “:.snap g-svg”. Either instance should be +followed with a ‘gflush’ or ‘:.gflush’ to flush to output to disk. SVG +files can be embedded into HTML documents with the tag, the tag, or the +tag. + +Simplified Build From Source +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +At the request of users, a toplevel ‘Makefile’ is now available for +building or configuring the system with a single command. This Makefile +is a simple driver for scripts that do all the work using conventional +IRAF commands. Allowed ‘make’ command targets include: + +:: + + all alias for 'update' + sysgen do a complete sysgen + update update system since last sysgen + updatex update with debugging flags enabled + src clean system of current binaries + clean clean system of current binaries + pristine clean system of all binaries + noao compile the NOAO package + summary print core/noao/tables spool file summaries + showarch show currently configure arch + reconfigure for named architecture + +Simplified Download/Install Process +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This release introduces a change in the distribution model used for +IRAF. Specifically, we recognize the majority of users will be running +on single-user machines such as personal laptops or desktop systems (the +earlier distribution model was based on the idea of a central server +supporting many client machines). As such, the need for separate source +and binary distributions and a separation of these in the directory +hierarchy is now unnecessarily complicated for most users. While the +previous form of the distribution files are still available, the +preferred method is to use the single-file distributions. All +distribution files include full source, differences are in which +binaries are also included. + +Simplified External Package Installation +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Dynamic package loading is a new feature in v2.15 that allows for +package directories created in the +iraf\ :math:`extern directory to be automatically defined when the CL is started. The means that external package installation no longer *requires* that the `hlib`\ extern.pkg\` +file be edited to define the package, although that remains an option +for packages which somehow cannot conform to this new scheme. + +COLOR and VOL packages now part of Core System +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Both the COLOR and VOL external packages have been incorporated into the +PROTO package. These packages are no longer being developed but are +required by some users so will continue to be supported as prototype +software. + +Improved Documentation +~~~~~~~~~~~~~~~~~~~~~~ + +Thanks to Jason Quinn, the help pages for dozens of tasks have been +cleaned of long-standing typo and formatting errors. In many cases +Jason’s suggestions have also served to clarify the meaning of the text, +or correct the help wrt to how to task actually operates. + +Platform Support: +----------------- + +IRAF V2.15 supports only the following platforms: + +- PC-IRAF + + - supports RedHat 9 thru Fedora/RHEL/Centos (LNUX) + - supports Mac OS X 10.4 and higher (ppc and intel) (MACX) + - supports Debian 3.1 and higher (LNUX) + + (The following platforms are planned but not yet available:) + + - supports FreeBSD 6.3 and higher (FBSD) + - supports Solaris 10 (x86) (SSOL) + - supports Cygwin (Windows XP and Vista) (CYGW) + +- Sun/IRAF + + - supports SunOS 4.1 (SOS4) + - supports Solaris 5.5.1 thru Solaris 10 (SSUN) + +Note that PC platforms not mentioned here specifically may still be +supported by one or more of the distributions (e.g. Ubuntu can use +LNUX). + +CORE IRAF REVISIONS SUMMARY +--------------------------- + +This section describes changes to tasks in the IRAF core system other +than routine bug fixes. + +New Tasks +~~~~~~~~~ + +- images.imcoords: + + - hpctran - Convert between HEALPix row and spherical coordinate + +- proto: + + - mkglbhdr - Make global header from keywords in images and + reference + +- system: + + - bench - Demonstration benchmark task + +Existing Tasks with New Parameters or New Parameter Defaults +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- images.imfit.fit1d + + - Adds new ‘bpm’ bad pixel mask parameter + +- images.imutil.nhedit + + - A ‘rename’ parameter switch was added to renaming a keyword. + +Existing Tasks with New Capabilities +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- images.immatch.imcombine: New ‘quadrature’ and ‘nmodel’ options to + the ‘combine’ parameter are used for error propagation either with + input sigma images (quadrature) or where the pixel sigmas may be + computed by the noise model used by this task (nmodel). + +NOAO PACKAGE REVISIONS SUMMARY +------------------------------ + +This section describes changes to tasks in the NOAO package tasks other +than routine bug fixes. + +New NOAO Package Tasks +~~~~~~~~~~~~~~~~~~~~~~ + +- noao.nproto: + + - skygroup: Group a list containing RA and Dec into spatial sublists + - skysep: Compute arc separation of two RA/Dec values + +Existing Packages and Tasks with New Parameters or New Parameter Defaults +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- artdata.mkpattern: Added ‘long’ to allowed list of data types. + +- onedspec.specplot: Added new ‘transform’ parameter to allow scaling + the spectrum pixel values. Currently only ‘log’ is implemented. + +- twodspec.apextract.apall: Changed default for ’maxsep from 1000 to + 100000. + +.. _existing-tasks-with-new-capabilities-1: + +Existing Tasks with New Capabilities +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- astcat.agetcat Added usnob1@usno, usnoa2@usno, nomad@usno and + act@usno + +- imred.doecslit, imred.doefoe, imred.doslit: Changed the default + maxsep from 1000 to 100000. Unless users reset the default their + expectation is that marking apertures will not skip an aperture + number no matter how far apart the aperturers are. + +- fibers.skysub.cl: Added ‘sum’ as an enumerated “combine” choice. + +- nproto.skysep: Added an ‘enum’ to the ‘raunit’ param to enforce + choices. + +- obsutil.sptime: Made all graphs auto-scale. Added a “generic” + disperser type to force using the desired wavelength and dispersion + without defining a grating whose mapping between position on the + detector and wave- length might be wrong. + +- twodspec.apextract: The ‘s’ key now works on the current aperture + rather than the nearest. + +BUG LOGS FIXED BY THIS RELEASE +------------------------------ + +The following buglog entries are fixed by the this V2.15 release: + +:: + + NUMBER: 567 + MODULE: apall, apedit + SYSTEM: V2.11-V2.14.1 + DATE: Tue Oct 7 10:53:14 MST 2008 + FROM: valdes + + BUG: The :parameters and :apertures commands cause the task to exit with + an error that parameter "apertures" isn't found. This problem has + existed for a long time due to a missing parameter in the hidden + parameter sets. + + STATUS: Fixed for the next release. + +:: + + NUMBER: 568 + MODULE: imcombine + SYSTEM: -V2.14.1 + DATE: Tue Oct 7 12:52:35 MST 2008 + FROM: valdes + + BUG: When using avsigclip, ccdclip, or sigclip rejection around the + median (mclip=yes) the resulting final median may be incorrect. + This will generally only occur if unusually small low sigma values, + such as lsigma=1, are used. This was due to using a wrong + variable. + + STATUS: This is fixed for the next release. + +:: + + NUMBER: 570 + MODULE: imexpr, mskexpr, or tasks other asks using the expression evaluator + SYSTEM: -V2.14.1 + DATE: Mon Nov 3 22:16:41 MST 2008 + FROM: valdes + + BUG: Use of the built-in functions mod, min, max, and median produce an + "incompatible types" error even though the types of the arguments are + correct. This is a due to a coding error. There is no workaround + other than using alternative ways to express the desired + expression. + + STATUS: Fixed for the next release. + +:: + + NUMBER: 571 + MODULE: IMAGES.IMUTIL.HSELECT + SYSTEM: V2.14 + DATE: Fri Jan 2 21:41:53 MST 2009 + FROM: fitz + + BUG: The use of a '$' in a field name was causing the 'missing' value + to always be printed even if the field exists in the image. This + was caused by a failure to check for the character and removing it + prior to getting the value from the header. There is no workaround, + the code change is trivial. + + STATUS: Fixed for the next release. + +:: + + NUMBER: 573 + MODULE: mscimage + SYSTEM: - V4.9 August, 2008 + DATE: Fri Sep 18 08:36:30 MST 2009 + FROM: valdes (discovered and diagosed by Thomas de Boer) + + BUG: The task ignores the parameters "boundary" and "blank" which are + fixed to be "constant" and "0." respectively. + + STATUS: This is fixed for the next release. diff --git a/doc/releases/v216revs.rst b/doc/releases/v216revs.rst new file mode 100644 index 000000000..48b0773c0 --- /dev/null +++ b/doc/releases/v216revs.rst @@ -0,0 +1,718 @@ +IRAF V2.16 Release Notes +======================== + +:Authors: IRAF Group +:Date: March 22, 2012 +:Abstract: These notes provide a summary of the major changes in the V2.16 release. + V2.16 includes a number of bugfixes and new tasks, but is primarily a + platform-support release to add new Virtual Observatory (VO) + capabilities to the core system. Full integration of VO capabilities + requires new functionality to be available in all tasks and not simply + in new VO applications. In particular, tasks are now all able to deal + with remote data as easily as local disk files, and VO-specific formats + are supported as transparently as other long-used table formats. + Specifics about the new core capabilities are described in the + highlights section below. + +These new core capabilities have been fairly extensively tested and are +considered stable, however we expect there will no doubt be instances +that cause trouble that should be reported. Because bugs in new core +capabilities will affect all tasks, a simplified update procedure is +also featured in this release to assist in applying patches to the +entire system. This follows the earlier model for installing external +packages where the following ‘make’ commands in the $iraf directory will +suffice to bring a system up to date following a bug-fix release: + +:: + + make latest # Update entire system (core + extpkgs) + make latest_src # Update only source code + make latest_core # Update only the core iraf system + + make check_latest # Check is system is latest released version + +We expect that in the months immediately following the initial release +there will need to be one or more updates to the entire system. + +More detailed technical documentation of all system changes will be +found in the ``notes.v215`` file in the ``iraf$local directory``, +detailed revisions notes for each application package are in the package +directories in a file called ``Revisions``, e.g. ``onedspec$Revisions``. + +Highlights of This Release: +--------------------------- + +64-bit Bug Fixes +~~~~~~~~~~~~~~~~ + +A number of 64-bit bugs remaining in the v2.15 release have been fixed, +both in specific applications as well as system-level interfaces such as +IMIO. As of this writing, there are no known 64-bit issues in the system +and we now consider these architectures to be stable. + +All users of 64-bit systems are STRONGLY ENCOURAGED TO UPDATE to v2.16 +in order to fix these bugs in their installation of IRAF. Specific bugs +fixed by this release are given below, detailed changes + +“Free” Licenses +~~~~~~~~~~~~~~~ + +Previous releases of IRAF were seen as being “non-free” due to legacy +license retrictions in the system. In particular, the NCAR graphics code +restricted re-distribution of IRAF by parties other than NOAO, and +comments in the XYACC source directory were taken to mean that an +original BSD source license was required. + +We are happy to report that both restrictions have been removed from the +IRAF system: The XYACC code was rewritten prior to the v2.15.1a release +and is covered under the OpenSolaris CDDL license. Agreements between +NOAO and UCAR were reached to allow the NCAR code in IRAF to +(retroactively) be covered by the current UCAR license allowing +redistribution. + +A new COPYRIGHTS file and the text of the licenses now in use can be +found in the $iraf/local directory as well as the distrubution directory +on the iraf.noao.edu server. + +A new VO-CL +~~~~~~~~~~~ + +IRAF v2.16 features a modified version of the CL, called VOCL, that +provides new builtin functions to support VO task development. This +version of the CL is fully backward compatible with the earlier ECL +(which remains available) and since it is required for the proper +operation of the VO package tasks, will be the version started by +default. + +In addition to VO data and service integration, the VOCL is able to +exchange messages with other desktop applications using the SAMP +protocol. Proprietary message types are implemented that allow arbitrary +execution of IRAF commands, and which set/get both parameter and +environment values. Custom messages may also be defined by users to +permit any two IRAF sessions on the same machine to exchange messages. +This level of interoperability allows other applications designed for +e.g. table or spectrum visualization to be used seemlessly within the +IRAF environment. + +VO Package +~~~~~~~~~~ + +IRAF v2.16 is now distributed with a new VO external package as part of +the core release (similar to how the NOAO external package is considered +part of the ‘core’). This package provides utility tasks and +applications specifically for accessing an analyzing VO data and is +meant to provide a toolbox for scientists to incorporate VO data into +their reductions. + +The VO package is expected to evolve quickly as new tasks and features +are added, and due to limited testing, is considered to be only a +Beta-quality release at this stage. A detailed listing of tasks in the +VO package is given below. + +Enhance @-file Capabilities +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +IRAF has long had the ability to the ‘@-files’ as a mean of passing in +lists of images/files to tasks. For v2.16, the concept was expanded to +include other things that logically have as lists, e.g. a column in a +table of remote data URLS, the implicit list of images in an MEF file, +etc. + +In these enhanced templates, things like MEF files and tables can be +expanded automatically using the @-file operator to let any task that +takes an image list process the extensions automagically. Additionally, +selection of images based on image header keywrods can also be done +dynamically using expressions in the template strings. For example, +consider the following templates: + +:: + + @file* expand all files beginning w/ 'file' + @file//".fits" append ".fits" to contents of 'file' + @mef.fits expand image extensions of an MEF file + @mef.fits[SCI] select SCI extensions from MEF file + @mef.fits[SCI,2][noinherit] select v2 SCI extns, add kernel param + @mef.fits[1-16x2] select range of extensions from MEF file + @mef.fits[+1-8] create a list of extensions for an MEF + *.fits[1:100,1:100] append section to all FITS images + @@file[1:100,1:100] append section to expanded MEFs in file + *.fits[filter?='V'] select images where FILTER contains 'V' + @*.fits[gain==3.0] select extns where GAIN keyword is 3.0 + *.fits[filter?='V';gain==2.5] select using multiple OR's expressions + +These templates could be used e.g. to run IMSTAT on all the extensions +of a FITS file with a single command, as in + +:: + + Enhanced @-files Old @-files + ---------------- ----------- + cl> imext mef.fits output=file > list.dat + cl> imstat @mef.fits cl> if (imext.nimages > 0) + >>> imstat @list.dat + cl> del list.dat + +where before it would have been necessary to expand the extensions +explicitly using a second task into a standard @file. Notice how the +other examples above provide even more refined selection of the +extensions, either within a single MEF or across multiple images. + +These changes are all fully backward compatible but provide new syntax +to give users a powerful and compact way to dynamically build image +lists for use by all tasks. These new features will be especially useful +for script developers tired of managing temp files of image lists, or +those who just need to quickly examine MEF files or a directory of +images. + +System File Cache +~~~~~~~~~~~~~~~~~ + +The system file cache is used to provide local storage for URL files, +i.e. when a URL is encountered it is downloaded and put into the cache. +If that same URL is used again (e.g. from within a script), the cached +file is passed to the task instead of accessing the URL a second time. +The cache directory used is determined by the ‘cache’ environment +variable set in the user’s login.cl file, or by the +hlib\ :math:`zzsetenv.def file. Upon login, files in the cache older than 'cache_age' days will automatically be removed. This value may be changed in the login.cl file or the hlib`\ zzsetenv.def +as needed. + +URL Support by all tasks +~~~~~~~~~~~~~~~~~~~~~~~~ + +Because both queries for VO data, and access to remote files/images is +typically done using HTTP, the use of a URL in place of a local +file/image name is now supported by all tasks. This feature +transparently allows use of remote data from archives as input to all +tasks (use of URLs for output from tasks is not supported at this time). +For example, from the CL commandline + +:: + + cl> imstat http://iraf.noao.edu/votest/dpix.fits + cl> tinfo http://iraf.noao.edu/votest/usno-b.xml + cl> type http://iraf.noao.edu/index.html + +or programmatically from a script such as + +:: + + s1 = "http://archive.stsci.edu/wuppe/search.php?RA=0.0&DEC=0.0&SR=30." + type (s1) + +The file returned by the URL is automatically placed in the system file +cache meaning the URL can be used repeatedly without actually +downloading the file each time it is used. This can be especially +important in scripts where a URL may be constructed or retrieved from a +result table and be used multiple times within the script. For example, +in the use of ‘s1’ above, the URL is actually a catalog query string +that returns a VOTable document; When the TYPE task is called, we are +able to execute the query and print the results in a single step as +opposed to having a separate download step. Further, because the URL is +now cached we can continue to use the ‘s1’ script variable to refer to +the result table in other tasks without having to re-execute the query +each time. + +VOTable Support by all tasks +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Part of the core VO support in v2.16 is the ability for all tasks that +expect tablular input (e.g anything using the TABLES interfaces) to also +now accept the VOTable XML documents used by the VO. When a VOTable is +encountered, it is automatically converted internally to a FITS binary +table and placed in the system file cache, this cached file is actually +what is being manipulated by the task. + +In some cases, tasks in the VO external package that are specifically +VOTable-aware will be able to use (and expect) the raw XML document +directly. In many cases it will be possible to use VOTables as input to +VO-aware tasks without having to manage the XML yourself, in other cases +common tasks such as extracting a row/column from the table will behave +as they always have. + +SAMP Support by all tasks +~~~~~~~~~~~~~~~~~~~~~~~~~ + +SAMP is the Simple Applications Messaging Protocol, an XML-RPC messaging +system for desktop applications developed within the VO. The new VOCL is +able to send an receive SAMP messages in order to allow IRAF to +interoperate with other VO-enabled applications. + +URLGET Task (New!) +~~~~~~~~~~~~~~~~~~ + +A new URLGET task is available in the SYSTEM package that may be used in +scripts much as one might use the host WGET task to access a URL (see +the help page). In particular, this task is used by the package update +mechanism to provide a download capability on systems where e.g. ‘wget’ +is not available. + +FCACHE Task (New!) +~~~~~~~~~~~~~~~~~~ + +A new FCACHE task is available to manipulate and clean the system file +cache. In particular, a command such as + +:: + + cl> fcache init + +can be used to completely re-initialize the file cache when the disk +begins to fill or in some cases to remedy problems encountered with use +of URLs. + +Simplified Build From Source +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +At the request of users, a toplevel ‘Makefile’ is now available for +building or configuring the system with a single command. This Makefile +is a simple driver for scripts that do all the work using conventional +IRAF commands. Allowed ‘make’ command targets include: + +:: + + all alias for 'update' + sysgen do a complete sysgen + update update system since last sysgen + updatex update with debugging flags enabled + src clean system of current binaries + clean clean system of current binaries + pristine clean system of all binaries + tables compile the TABLES package + noao compile the NOAO package + summary print core/noao/tables spool file summaries + showarch show currently configure arch + reconfigure for named architecture + + latest Update entire system to latest patch release + latest_src Update only source code + latest_core Update only the core iraf system + + check_latest Check is system is latest released version + +Simplified Download/Install Process +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +IRAF systems now come in single-file downloads for the most common +configurations: + +:: + + iraf-src.tar.gz Source code only + iraf-all.tar.gz Source + all supported platform binaries + iraf-linux.tar.gz Source + linux/linux64 platform binaries + iraf-macosx.tar.gz Source + macosx/macintel platform binaries + + iraf.lnux.x86.tar.gz Source + 32-bit Linux binaries + iraf.lnux.x86_64.tar.gz Source + 64-bit Linux binaries + iraf.macx.uni.tar.gz Source + 32-bit OSX binaries + iraf.macx.x86_64.tar.gz Source + 64-bit OSX binaries + +With these distributions files, installation is a simple matter of +unpacking the tarball in the desired IRAF root directory (typically some +place like /iraf/iraf) and running the install script. The traditional +multi-part distribution files also remain available. + +Simplified External Package Installation +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +External packages may be installed and defined dynamically and no longer +need to be manually configured. The $iraf/exern directory contains a +‘configure’ script to create the files needed for a single-command +installation of an external package (and it’s dependencies). For +example, + +:: + + % cd $iraf/extern # go to extern directory + % ./configure # configure system (only once) + % make mscred # install the MSCRED package + +Packages defined in this way will be available the next time you login +to the system. See the $iraf/extern/README file for details. + +Improved Documentation +~~~~~~~~~~~~~~~~~~~~~~ + +Thanks to Jason Quinn for continued suggestions on improved wording of +help pages and careful proofreading of the docs. + +Platform Support: +~~~~~~~~~~~~~~~~~ + +IRAF V2.16 supports the following platforms: + +- PC-IRAF + + - 32-bit Linux (LNUX.X86) + - 32-bit Mac OS X 10.4 and higher (ppc and intel) (MACX.UNI) + - 64-bit Linux (LNUX.X86_64) + - 64-bit Mac OS X 10.4 and higher (intel) (MACX.X86_64) + +Note that PC platforms not mentioned here specifically may still be +supported by one or more of the distributions (e.g. Ubuntu can use +LNUX). + +CORE IRAF REVISIONS SUMMARY +--------------------------- + +This section describes changes to tasks in the IRAF core system other +than routine bug fixes. + +New Tasks +~~~~~~~~~ + +- VO-CL: A new version of the CL call ‘vocl’ is now the default CL on + startup. This version supports both SAMP messaging to interopate with + other VO applications, as well as new builtin functions to query VO + data and services. + +- system.urlget: Native IRAF task to retrieve and HTTP URL + +- system.fcache: List, clean or manipulate the system file cache + +Existing Tasks with New Parameters or New Parameter Defaults +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- images.imcoords.ccmap: A new option “tweak” was added to the values + for the “refpoint” parameter to allow controlling whether to tweak + the input tangent point. + +- images.imcoords.ccmap: New parameters xref and yref can be set to a + value or header keyword in order to constrain the solution to the + specified reference pixel. + +Existing Tasks with New Capabilities +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- All Tasks: Now able to use an HTTP URL in places where an input + image/file is expected. + +- All Tasks Using Lists: Support for enhanced @-files + +- All Tasks Expecting Tabular Input: Now able to use VOTable XML + documents + +- images.imcoords.ccdmap: Changes to allow constraining WCS solutions + to specified tangent point parameters (reference pixel and reference + coordinate). This adds parameters so potentially requires users to + update scripts. + +NOAO PACKAGE REVISIONS SUMMARY +------------------------------ + +This section describes changes to tasks in the NOAO package tasks other +than routine bug fixes. + +New NOAO Package Tasks +~~~~~~~~~~~~~~~~~~~~~~ + +- noao.onedspec: + + - hirescal - Apply HIRES wavelengths to flux data to produce an IRAF + file. + +Existing Packages and Tasks with New Parameters or New Parameter Defaults +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +N/A + +.. _existing-tasks-with-new-capabilities-1: + +Existing Tasks with New Capabilities +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- artdata.mkobjects: Added Sersic model profiles. This was done using + only the model name to avoid any additional parameters. + +- astutil.observatory: Added entries for SOAR, Baker Observatory, + McDonald Obs. HET, the Jack C. Davis Observatory and Langkawai + National Observatory + +- onedspec/splot: Added overplotting of individual components to + deblending code. + +VO PACKAGE REVISIONS SUMMARY +---------------------------- + +New VO Package Tasks +~~~~~~~~~~~~~~~~~~~~ + +The VO package is new to the IRAF v2.16 release. Current contents of the +package include: + +- Toplevel apps: + + - registry: Query the VO Registry + +- Toolbox sub-package: + + Data Query/Access Tools + + - getcat: Query catalog data services in the VO + - getimg: Query image data services in the VO + - getspec: Query spectral data services in the VO (NYI) + - getlines: Query spectral line data services in the VO (NYI) + - vodata: General purpose query of VO data service + + Image Utilities + + - dss: Display a DSS2 image of a named field + - imgcat: Create a catalog of detections in an image + - wcsinfo: Summarize the WCS information of an image + - dispname: Get the currently displayed image name + + VO Service Tools + + - sesame: Resolve an object name to a position + + Simple Catalog Tools + + - nedoverlay: Overlay NED objects in the image display + - obslogoverlay: Overlay an observation catalog (HST, XMM, etc) + - radiooverlay: Overlay NVSS radio contours in the image display + - xrayoverlay: Overlay RASS3 X-Ray contours in the image display + + Registry Tools + + - mkregdb - Create a local VO Registry database + - regdb - Manage/Query a local VO Registry database + - regmetalist - List the metadata fields of a Registry record + + Votable Utility Tools + + - votcopy: Copy a VOTable to another format + - votget: Download data referenced in a VOTable + - votpos: Extract the main positional columns from a VOTable + - votsize: Get the size of a VOTable + + Table Utilities + + - colbyid: Identify VOTable column by ID attribute + - colbyucd: Identify VOTable column by UCD attribute + - colbyname: Identify VOTable column by NAME attribute + - tabclip: Clip a table to given boundaries + - taboverlay: General table overlay in the image display + + External Applications + + - aladin: Start/Stop/Status of the Aladin image display application + - hub: Start/Stop/Status of the SAMP Hub + - topcat: Start/Stop/Status of the TOPCAT table display application + + SAMP Message Handlers + + - overhandler: Default SAMP handler for image overlays + - tblhandler: Default SAMP handler for table loading messages + - imghandler: Default SAMP handler for image loading messages + + Hidden Tasks + + - qstring: Generate a query string URL + - makewcs: Create an IRAF WCS from a plate solution + - prettystr: Pretty-print a long string + +.. _existing-packages-and-tasks-with-new-parameters-or-new-parameter-defaults-1: + +Existing Packages and Tasks with New Parameters or New Parameter Defaults +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +N/A + +.. _existing-tasks-with-new-capabilities-2: + +Existing Tasks with New Capabilities +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +N/A + +BUG LOGS FIXED BY THIS RELEASE +------------------------------ + +The following buglog entries are fixed by the this V2.16 release: + +:: + + NUMBER: 574 + MODULE: daophot.psf + SYSTEM: -V2.14 + DATE: Tue Apr 13 22:01:52 MST 2010 + FROM: fitz + + BUG: The ":function" command was not properly saving the new function + when refitting is done with the 'f' keystroke. This is because the + fitting function reinitializes the parameters to the startup + values without first saving the modified function. + + STATUS: Fixed for the next release + +:: + + NUMBER: 575 + MODULE: all tasks using the icfit tools + SYSTEM: - V2.14 + DATE: Mon Jun 28 14:08:48 MST 2010 + FROM: valdes + + BUG: The icfit tools are used in many tasks involving 1D function fitting. + These include onedspec tasks like continuum and identify. The + tools provide for a grow radius where any sigma rejected points + have neighbors also rejected. The logic was wrong + in two ways; one where if a neighbor was also a rejected point + it did not also reject neighbors of that point, and another where + the grow radius units were used both as in pixels and in user + coordinates. In reality the grow is supposed to be in user + coordinate units. In addition some tasks, like continuum, incorrectly + described the units adding to the confusion. + + STATUS: Fixed for the next IRAF release. + +:: + + NUMBER: 576 + MODULE: imcombine + SYSTEM: V2.14 + DATE: Wed Nov 17 15:20:16 MST 2010 + FROM: valdes + + BUG: The addition of the image names using imcmb="$I" does not work for + input images with a square bracket; e.g. foo[1], foo[im1], foo[*,*]. + The IMCMB value, in order to allow long filenames, is stripped of + any path. For an obscure reason related to VMS directories this + code failed to find a rootname. + + STATUS: This has been fixed for the next release. + +:: + + NUMBER: 577 + MODULE: dohydra, dofibers, doargus, do3fiber + SYSTEM: -V2.15.1 + DATE: Fri Feb 11 12:30:46 MST 2011 + FROM: valdes + + BUG: The tasks will shorten root input image names to six characters by + using the first five and last characters. Depending on the style + of image names this can result in name conflicts. The reason for + this shortening is no longer known so it is now considered a bug. + Workarounds are to be aware of this and rename image names to avoid + conflicts. + + STATUS: This is fixed in the next release. The fix is to modify the file + $iraf/noao/imred/src/fibers/proc.cl as shown (replace lines 125 to + 129 with "extn = extn // ".ms"). If you don't have permission + to make this change then copy the file to your iraf "home$" + directory, edit it, load the desired package, and then override + the definition of the file with "redefine proc = home$proc.cl". + + 125,129c125 + < i = strlen (extn) + < if (i < 7) + < extn = extn // ".ms" + < else + < extn = substr (extn, 1, 5) // substr (extn, i, i) // ".ms" + --- + > extn = extn // ".ms" + +:: + + NUMBER: 578 + MODULE: splot, scombine, fxcor, identify tasks, dispcor, disptrans + SYSTEM: v2.15-V2.15.1a (64-bit platforms only) + DATE: Tue Mar 8 21:57:38 MST 2011 + FROM: fitz + + BUG: The 64-bit port changes to smw.h improperly added a P2R() macro to + the APLOW/APHIGH macro declarations. This was causing tasks with + 2-D data to make an out-of-bounds request for data and leading to + and error message such as + + ERROR: Pixel subscript out of bounds (spec.fits) + + Normal onedspec data or use on 32-bit platforms is not affected. + + STATUS: Fixed for the next release. A re-application of the v2.15.1a patch + file will replace the affected binaries on 'linux64' and 'macintel' + platforms. + +:: + + NUMBER: 579 + MODULE: onedspec.specplot + SYSTEM: V2.15 + DATE: Thu Mar 31 10:41:56 MST 2011 + FROM: fitz + + BUG: SPECPLOT can sometimes throw a segmentation violation or not + recognize valid input spectra due to an incorrect macro definition + on 64-bit platforms (linux64 and macintel only). + + STATUS: This has been fixed for the next release. Patched x_onedspec.e + binaries can be installed from + + ftp://iraf.noao.edu/iraf/v215/support//x_onedspec.e + + where the is either 'linux64' or 'macintel'. + +:: + + NUMBER: 580 + MODULE: imcombine and variants + SYSTEM: -V2.15.1 + DATE: Fri Apr 1 10:53:41 MST 2011 + FROM: valdes + + BUG: When the grow options is used with masks or partially overlapping + data a segmentation could occur. This is because when data is + absent (because of non-overlap) or excluded (because of mask) an + identifier value was not initialized. The only workaround is to + not use the grow options. + + STATUS: Fixed for future patches and releases. + +:: + + NUMBER: 581 + MODULE: splot + SYSTEM: V2.15- + DATE: Mon Jun 6 17:21:27 MST 2011 + FROM: valdes + + BUG: When using the deblending options a memory free error occurs with + 64-bit versions. This is caused by allocating an integer array and + freeing it as a real array. + + STATUS: Fixed in future patches and releases. + +:: + + NUMBER: 582 + MODULE: utilities.curfit + SYSTEM: -V2.15.1 + DATE: Fri Jul 29 12:40:08 MST 2011 + FROM: valdes + + BUG: For input data with two or more values having the same x value + there is an arithmetic exception when setting the niterate parameter + greater than zero during interactive fitting. This occurs because + a check for the distance between two points for the purpose of the + grow option divides by the distance. This is done even if no growing + is requested (grow=0). The workaround is to edit the input so that + the values are not exactly the same. + + STATUS: This condition has been eliminated for the next release. + +:: + + NUMBER: 583 + MODULE: apall, + SYSTEM: V2.15 + DATE: Mon Mar 5 08:51:03 MST 2012 + FROM: valdes + + BUG: The optimal extraction for significantly tilted spectra, the Marsh + algorithm, has bug which manifests only under 64-bit architectures. + The symptom is a crash, usually a memory or segmentation panic. + The only workarounds are 1) go to an 32-bit system or 2) don't + use the optimal extraction option. + + STATUS: Fixed for V2.16. diff --git a/doc/releases/v217revs.rst b/doc/releases/v217revs.rst new file mode 100644 index 000000000..30b28dc5a --- /dev/null +++ b/doc/releases/v217revs.rst @@ -0,0 +1,334 @@ +IRAF 2.17 Release notes +======================= + +:Authors: IRAF Community +:Date: January 07, 2012 + +The current IRAF version 2.17 is available from github at + +https://github.com/iraf-community/iraf/releases/latest/ + +Changes to the NOAO 2.16.1 sources include: + +- **Community maintainance** + + IRAF is no longer maintained by NOAO, but by the community of + volunteers. Contributions of bug fixes, documentation or improvements + are welcome. + +- **All known non-free code removed** + + Although IRAF 2.16.1 was claimed to be “free software”, `it contained + source code that is not freely + distributable `__; namely code copied + from the book `“Numerical Recipes in + Fortran” `__. This code is replaced with + free equivalents. The IRAF community edition is `Open + Source `__, and as such included in + Debian. + +- **IRAF ported to other architectures** + + IRAF is now ported to a number of little endian architectures (ARM, + PowerPC, MIPS, x32, RISC-V64) and operating systems (GNU Hurd and + FreeBSD). Specifically, the Mac M1 processor is supported now. + +- **Major bug fixes** + + Many bugs of the 2.16.1 release are fixed. Some of he major ones are: + + - Linux systems crashed with “Out of memory” (`2.12 release + notes `__) + - ``noao.digiphot.photcal.fitparams`` failed with a segmentation + fault on 64-bit systems + (`iraf.net#1467834 `__) + - The system wide IRAF installation changed the permissions of + ``/tmp/``, creating a major security hole in the system + (`iraf-v216#23 `__) + - On Linux systems, self-compiled tasks gave wrong results + (`iraf.net#1467841 `__) + - On modern systems, background execution did not work + (`iraf.net#1467431 `__) + - The original code produced errornous executables when build on + Linux versions later than 2012. It also did not build from + scratch, but required an already compiled IRAF version. + +- **Simple CI test framework added** + + The tests are defined and documented in + `MarkDown `__ + files. Tests are run with Github Actions on Linux and MacOS X + platforms. + +- **VO package and vocl removed** + + The VO package, and the vocl shell heavily depend on a number of Java + jars, where the creation from sources is undocumented. The package + also uses outdated VO standards. A discussion with Mike Fitzpatrick + resulted in his plan to `move the VO functionality into an external + package `__. Therefore, no attempt was put into + getting these problems fixed, and the VO stuff was cut out. The + VOTable functionality, however, remains available + +Detailed list of changes +------------------------ + +This list shows all pull requests that were merged since 2.16.1. + +Since 2.16.1+2021.06.14 +~~~~~~~~~~~~~~~~~~~~~~~ + +- Consistently format doc/help examples + (`#195 `__) +- Fix some HTML help output glitches + (`#194 `__) +- Remove duplicate argument in call + (`#189 `__) +- Revert corruption of unix/os/net/rexec.c file + (`#180 `__) +- Force using POSIX shell in extpkg.cl script + (`#179 `__) +- Support freeBSD variants + (`#174 `__) +- Separate development (softools) packages + (`#172 `__) +- Remove obsolete tasks and links to iraf.noao.edu + (`#170 `__) + +Since 2.16.1+2018.11.01 +~~~~~~~~~~~~~~~~~~~~~~~ + +- Cleanup for unneeded and obsolete files + (`#166 `__) +- fix slalib bug in sla_EQEQX + (`#160 `__) +- Ignore existing iraf env var in ./install + (`#157 `__) +- Cleanup ecl and cl + (`#156 `__) +- Add macOS arm64 support + (`#131 `__) +- Replace hard-coded host$bin paths by IRAFPATH + (`#128 `__) +- Remove include/drvrsmem.h + (`#126 `__) +- Fix cpu_time calculation in unix/os/zgtime.c + (`#118 `__, + `#136 `__, + `#173 `__) +- Move zsvjmp assembler files to unix/os and merge them + (`#117 `__) +- Use PLT when calling sigsetjmp on i386 + (`#116 `__) +- Adjust external licenses + (`#115 `__) +- Definitely use flex to generate ``unix/generix/lexyy.c`` + (`#112 `__) +- Avoid multiple definition of ``errflag`` + (`#111 `__) +- Enable the use of Public Domain Ratfor to process ``.r`` files + (`#103 `__, + `#171 `__) +- Remove some C compiler warnings + (`#97 `__) +- Fix non-working fft841 code by replacing it + (`#95 `__) +- Add LAPACK license + (`#88 `__) +- Rename ``mkfloat.sh`` to ``mkfloat`` + (`#87 `__) +- Add support for the DEC Alpha processor + (`#79 `__) +- Fix and improve the shell scripts + (`#75 `__, + `#76 `__, + `#77 `__, + `#85 `__, + `#86 `__, + `#113 `__) + +Since 2.16.1+2018.06.15 +~~~~~~~~~~~~~~~~~~~~~~~ + +- Add riscv64 support + (`#72 `__) +- Fix buffer length in ``urlget.x`` + (`#70 `__) +- Mention Chisato Yamauchi as copyright owner of the x86_64 + ``zsvjmp.s`` code + (`#67 `__) +- Adjust calling of nttools subdir in ``pkg/utilities/mkpkg`` + (`#65 `__) +- Update and modernize top-level information files + (`#64 `__, + `#73 `__) +- Check for the existence of the ``arch`` variable before using it + (`#63 `__) +- Improve prototyping in bootlib + (`#62 `__) +- Appended ``ZTTYSZ()`` function to get width and height of terminal + (`#58 `__) +- Replace readline library by libedit on macos + (`#57 `__) +- Clean and fix shell scripts + (`#50 `__, + `#51 `__, + `#53 `__, + `#54 `__, + `#55 `__, + `#75 `__, + `#76 `__, + `#77 `__) +- Fix variable declaration in noao/obsutil/src/findgain.cl + (`#47 `__) +- Remove unused empty files + (`#45 `__) +- Add manpages + (`#44 `__) +- Update cfitsio to 3.450 + (`#43 `__) +- votable: Fix data type of loop variable + (`#41 `__) + +Since 2.16.1+2018.03.10 +~~~~~~~~~~~~~~~~~~~~~~~ + +- Implement the ‘apropos’ command + (`#37 `__) +- Don’t check for updates + (`#36 `__) +- Update cfitsio to 3.440 + (`#34 `__) +- Fix background execution in cl and ecl + (`#32 `__) +- Port IRAF to several architectures + (`#31 `__) + +Since 2.16.1+2018.02.04 +~~~~~~~~~~~~~~~~~~~~~~~ + +(Pull Requests from `iraf/iraf-v216 `__) + +- Update cfitsio to 3.430 (`#135 `__) +- Fix off-by-one problem in xppcode.c (`#133 `__) +- Remove files that were generated by ``generic.e`` or ``xyacc.e`` + (`#132 `__) + +Since 2.16.1+2017.12.28 +~~~~~~~~~~~~~~~~~~~~~~~ + +(Pull Requests from `iraf/iraf-v216 `__) + +- Make photcal 64-bit capable (`#130 `__) +- f2c: Fix allocated size of Dimblock (`#127 `__) + +Since 2.16.1 +~~~~~~~~~~~~ + +(Pull Requests from `iraf/iraf-v216 `__) + +- Check filepointer for ``NULL`` in ``envinit`` before trying to close. + (`#126 `__) +- Add the required credits for the IRAF64 project. + (`#125 `__) +- Use ``strncpy`` and ``snprintf`` to fill file header in wtar + (`#124 `__) +- Specify explicit format for ``fprintf()`` + (`#123 `__) +- Limit number of ``finfo`` structs returned by ``KI_ZFINFO`` to + ``MAX_ARGS`` (`#122 `__) +- Fix ``isalnum()`` and friends for non-ascii values + (`#121 `__) +- Use curl in ``pkgget`` (`#115 `__) +- Fix comparison for some optional command line arguments in xc + (`#111 `__) +- Add a trailing ``\0`` to the end of variable format strings in + ``pkg/tbtables/fitsio/`` (`#110 `__) +- Fix OS dirnames in ``README`` (`#108 `__) +- Adjust f2c’s internal ``integer`` size for ILP64 + (`#107 `__) +- Replace ``d1mach.f`` and ``r1mach.f`` by C sources + (`#106 `__) +- Handle negative pointers in ``sys/nmemio`` + (`#105 `__) +- Remove all executables and binaries in ``make src`` + (`#104 `__) +- *[linux64]* Correct underlines in ``mem`` symbol in ``zsvjmp.s`` + (`#102 `__) +- Correct string length of ``baseurl`` initialization in + ``chkupdate.x`` (`#101 `__) +- Fix segfault when opening a ``STRING_FILE`` + (`#100 `__) +- Fix statement order in ``vfn_expand_ldir`` + (`#99 `__) +- Fix linenumber generation with ``xpp -x`` (rpp and spp)) + (`#98 `__) +- Fix template expansion in ``generic.c`` + (`#94 `__) +- Remove VO related packages and libraries + (`#93 `__, +- Initialize ``oscwd`` in ``zglobl.c`` (`#91 `__) +- Check for identical addresses before ``strcpy()`` in ``mkpkg/tok.c`` + (`#89 `__) +- Fix type of arguments for several procedure calls + (`#88 `__) +- Bugfix for ``unix/os/gmttolst.c`` and ``unix/zgmtco.c`` + (`#87 `__) +- Fix location of ``yaccpar.x`` (`#84 `__) +- *[macosx]* Fix syntax error in ``readline/mkpkg`` on macosx + (`#83 `__) +- Remove absolute paths from header (`#82 `__) +- Reverse the condition when iraf should be set + (`#81 `__) +- *[macosx]* Fix MacOSX min version on ``zsvjmp_i386.s`` + (`#80 `__) +- Fix lex source files in xpp and generic + (`#79 `__) +- *[macintel]* Replace ``setpgrp(...)`` with POSIX ``setpgid()`` + (`#78 `__) +- Avoid identical src/target in ``strcpy()`` when creating library + names in xc (`#77 `__) +- *[linux]* Consequently add ``-m32`` flags if compiling for linux(32)) + (`#76 `__) +- Convert to ANSI C to fix return types of functions in ``memlog.c`` + (`#75 `__) +- Limit entries in bitmask to 64 bit. (`#74 `__) +- Accept zero date in archives (`#71 `__) +- Fix computation of offset in memory allocation at 32 bit + (`#67 `__) +- Fix ``ADDR_TO_LOC`` for i386 (32 bit)) + (`#62 `__) +- Fix declaration of ``cdsmem`` in rpp (`#60 `__) +- Force iraf to align on 128-bit boundaries + (`#57 `__) +- Remove ``curl/types.h`` includes (`#51 `__) +- Fixed spelling error, “the” not “teh”. + (`#47 `__) +- *[linux64]* Call the PLT for ``__sigsetjmp`` instead of calling + directly (`#45 `__) +- Removed an extra ``linux64`` (`#44 `__) +- Build vendor libs before starting the ``NOVOS`` build + (`#40 `__) +- Fixed recursive error in definition of ``LFLAGS`` + (`#39 `__) +- Convert ``mklibs`` to ``/bin/sh`` (`#38 `__) +- Replace or remove non-free code (Numerical Recipes etc.)) + (`#37 `__) +- Add continious integration testing with travis-CI + (`#36 `__) +- Replace absolute symlinks in sys/osb by relative ones + (`#33 `__) +- Don’t remove sticky bit from /tmp on install + (`#24 `__) +- Fix setting of non-default IRAF root (`#22 `__) +- Clean up sources from unnecessary code (`#2 `__, + `#14 `__, `#15 `__, + `#16 `__, `#17 `__, + `#18 `__, `#20 `__, + `#25 `__, `#68 `__, + `#69 `__, `#70 `__, + `#113 `__, `#116 `__, + `#117 `__) + +.. |GitHub release| image:: https://img.shields.io/github/release/iraf-community/iraf.svg + :target: https://github.com/iraf-community/iraf/releases/latest diff --git a/doc/releases/v28revs.rst b/doc/releases/v28revs.rst new file mode 100644 index 000000000..37ced5ea1 --- /dev/null +++ b/doc/releases/v28revs.rst @@ -0,0 +1,1463 @@ +IRAF Version 2.8 Revisions Summary +================================== + +:Authors: IRAF Group +:Date: June 30, 1989 + +Introduction +------------ + +This revisions notice coincides with the release of version 2.8 of IRAF. +The V2.8 release is a general release for all supported IRAF hosts. + +The following is a brief description of some of the new features +available in IRAF Version 2.8. This is not intended to be an exhaustive +list, but rather a brief summary of the major changes since the last +major release of IRAF Version 2.5 in July 1987 and subsequent +intermediate releases primarily to support Sun/IRAF: IRAF Version 2.6 +(February 1988), IRAF Version 2.6+ (March 1988), and IRAF Version 2.7 +(December 1988). + +More detailed revisions notes are available in the system notes files in +the ``iraf$doc`` and ``iraf$local`` directories, as well as in the +online revisions notes for the various packages. + +IRAF System Revisions +--------------------- + +This document highlights the most notable revisions made to the IRAF +core system software for Version 2.8. This is only a revisions summary; +no attempt is made to provide detailed technical documentation for each +revision, nor is there any attempt to exhaustively summarize all +revisions. A complete record of all core system revisions will be found +in the *System Notes* for V2.8. Additional information on some of the +topics covered below will be found in the various *Installation Guides* +and *Site Manager’s Guides*, and in the *IRAF User and Technical +Documentation* manual sets. + +Copyright notice +~~~~~~~~~~~~~~~~ + +Subject to AURA and NSF approval, the IRAF software will be copyrighted +sometime during 1989. As a first step in this process, a copyright +notice has been added to all core system source files. The notice reads +as follows: “Copyright(c) 1986 Association of Universities for Research +in Astronomy Inc”. We will also be adding a file called COPYRIGHT to the +distribution stating the terms of the copyright and associated licensing +agreement for the software. + +The intent of this action is solely to protect the software from +unauthorized commercial exploitation, and the copyright grants, or will +grant, the right to copy, modify, and redistribute the IRAF software +provided the original copyright notice remains intact, the software is +made available in source form, and the rights we grant are passed on +with the software. We wish to prevent others, especially commercial +firms, from copyrighting IRAF software in their own name and possibly +taking away the rights we grant with the software. Granting the right to +modify and redistribute IRAF software does not mean we want to encourage +people to do so, we merely want them to have the legal right to do so if +they feel they need to. + +Major system enhancements +~~~~~~~~~~~~~~~~~~~~~~~~~ + +The information in this section is provided primarily for the benefit of +IRAF site managers and programmers. The reader interested primarily in +science applications may wish to skip ahead. Some systems level +familiarity with the current IRAF system is assumed. + +Layered software enhancements +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A given IRAF installation consists of the core IRAF system, and any +number of **layered software products** or **external packages**. The +goal of the layered software enhancements introduced in V2.8 is to make +layered software products self contained and hence independent of the +core system and of other layered software. Examples of layered software +products are the NOAO packages, LOCAL, STSDAS, PROS, and so on. + +The layered software enhancements make it possible to install or +deinstall a layered product by modifying only a single file in the core +IRAF system. The core system may be updated without affecting layered +software, and vice versa. Since layered products are independent and are +simple to install, IRAF can easily be configured with only those +packages needed at a particular site. Software developers benefit from +the layered software enhancements because the facilities provided for +development and maintenance of layered software are equivalent to those +provided for development of the core IRAF system and the NOAO packages. +User sites benefit because it is easy to extend the system with LOCAL +packages of their own making. + +Each layered product (usually this refers to a tree of packages) is a +system in itself, similar in structure to the core IRAF system. Hence, +there is a LIB (global system library), one or more BINs (binary file +directories), a Help database, a set of global environment definitions, +and all the sources and runtime files, all contained within the same +directory tree. Layered software products, in their source only form, +are portable without change to any computer which runs IRAF. + +The hlib$extern.pkg file +'''''''''''''''''''''''' + +This is the file which is modified to install or deinstall layered +software products. To install a layered product, one creates a directory +to hold the software, restores the files to disk, and edits the +``extern.pkg`` file to tell IRAF the name of the root package of the +layered product, and where the root directory is located. If the layered +software is distributed in source only form it will also be necessary to +recompile the software, but this is a completely automated process. + +NOAO and LOCAL packages reorganized +''''''''''''''''''''''''''''''''''' + +As part of the project to better support layered software, the NOAO and +LOCAL packages have been reorganized as layered products. These packages +are now structurally equivalent to third party (non-NOAO) packages, +except that the directory trees are rooted in IRAF. Both packages are +now self contained, with their own LIB, BINs, Help database, etc., and +with an entry in ``extern.pkg``, like other layered products. The NOAO +package serves as a working example of how to configure a layered +package. The reorganization of these packages should be transparent to +anyone merely using the system. + +The template LOCAL +'''''''''''''''''' + +The LOCAL package included with the distributed system has been stripped +of all NOAO site-local tasks and restructured as a layered product, the +*template local*. The template local contains only two sample tasks and +is not intended as an end-user package, but rather as a template to be +copied and modified by sites to construct their own site dependent LOCAL +package. The desire to be able to easily develop and maintain locally +added packages was one of the major motivations for the layered software +enhancements project, and we hope that sites will realize the +significance of this new capability and take advantage of it. + +CL now supports package level BIN directories +''''''''''''''''''''''''''''''''''''''''''''' + +Rather than assuming a global BIN directory for all tasks and packages, +the CL now permits multiple BIN directories, each BIN directory being +associated with the package of definition and all subpackages of that +package (unless they have their own BIN). A new BIN directory is +declared with the optional argument ``bindir=*path`` in the ``package`` +statement, e.g., in a package script task. + +MKPKG support for package environments +'''''''''''''''''''''''''''''''''''''' + +Layered packages now have their own private LIB, including an +environment definitions file (``zzsetenv.def``), mkpkg global include +file (``mkpkg.inc``), and, optionally, a mkpkg special file list file +for each supported host system, listing files requiring special +compilation to work around host compiler bugs or whatever. The full +mkpkg environment is formed by reading the IRAF core system environment +and mkpkg definitions and include files, followed by the package +definitions and include files. Reading of the package environment occurs +*only* if mkpkg is called with the “**-p**” flag, or if the variable +``PKGENV`` is defined in the user’s environment. + +Another way of expressing this is, when using mkpkg within a layered +package, one must now specify the name of the layered package in order +to pick up the package environment definitions. For example, to update +the MTLOCAL package in NOAO, one would type “``mkpkg -p noao update``” +in the ``mtlocal`` directory. If this is not done compilation errors may +result, or the executable may not be successfully installed in the +package BIN directory. + +Multiple architecture support +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A single IRAF system (or layered package) can now simultaneously support +any number of machine architectures using multiple BIN directories +sharing a single machine independent copy of IRAF. Each BIN directory +contains all the object modules, object libraries, and executables for a +particular architecture. An architecture can represent either a type of +hardware, e.g., sparc, mc68020+f68881, mc68020+ffpa, vax, etc., or a +software distinction, e.g., systems compiled with different sets of +compiler flags, or different versions of a system. Multiple +architectures are now supported both for IRAF execution, and for IRAF +based software development, e.g., a single version of IRAF can now be +used to develop and run IMFORT programs on both Sun-3 and Sun-4 nodes. + +The only case where multiple architecture support is used at the present +time is in Sun/IRAF, which is often installed on a heterogeneous network +of workstations, e.g., Sun-3s with various hardware floating point +options, and Sun-4s. A single copy of IRAF will be configured with +several BIN directories, one for each supported architecture, and NFS +mounted on all the network nodes which will be using IRAF. There is no +reason that this feature need be restricted to use with Sun/IRAF, +however. + +IRAFBIN and IRAFARCH +'''''''''''''''''''' + +Starting with IRAF V2.8, the old environment variable ``IRAFBIN`` has +been obsoleted and replaced by ``IRAFARCH``. On machines which support +multiple architectures, the latter defines the architecture to be used +for both IRAF execution and software development. If only IRAF execution +is needed the variable is optional, with the best architecture being +selected automatically when the CL is started. If one will be doing +software development (including IMFORT) it is best to define the +variable in the host environment before starting IRAF or doing any host +level software development. Typical values of ``IRAFARCH`` for a Sun +workstation are “sparc”, “i386”, “f68881”, and “ffpa”. + +System libraries moved to the BIN directory +''''''''''''''''''''''''''''''''''''''''''' + +As part of the revisions required for multiple architecture support for +software development, all object libraries have been moved from the +global, architecture independent LIB to the architecture dependent BIN, +with the LIB entries being replaced by symbolic links (in the case of +Sun/IRAF). This should be transparent to both end users and programmers. + +New bin.generic architecture +'''''''''''''''''''''''''''' + +On Sun/IRAF systems, which are distributed configured for multiple +architecture support, the system architecture is set to ``generic`` in +the distributed system. What this means is that all architecture +dependent files (objects and object libraries) have been removed from +the system directories and archived in the file ``OBJS.arc`` in the BIN +directory for each architecture. Rebuilding any of the packages in a +system would require restoring the binaries for a particular +architecture, e.g., typing “``mkpkg sparc``” at the IRAF root would +restore the sparc binaries for the core system on a Sun/IRAF +installation. Note that this *only* affects software development for the +system in question; software development for external packages or +private user software is not affected. + +Shared library facility +^^^^^^^^^^^^^^^^^^^^^^^ + +IRAF version 2.8 adds support for a general shared library facility for +UNIX based systems. Although currently only used with Sun/IRAF, this +facility is potentially useful for other UNIX based IRAF systems as well +(VMS/IRAF already has its own shared library facility). + +What the shared library facility does is take most of the IRAF system +software (currently the contents of the ``ex``, ``sys``, ``vops``, and +``os`` libraries) and link it together into a special sharable image, +the file ``S.e`` in each core system BIN directory. This file is mapped +into the virtual memory of each IRAF process at process startup time. +Since the shared image is shared by all IRAF processes, each process +uses less physical memory, and the process pagein time is reduced, +speeding process execution. Likewise, since the subroutines forming the +shared image are no longer linked into each individual process +executable, substantial disk space is saved for the BIN directories. +Link time is correspondingly reduced, speeding software development. + +With the introduction of the shared library facility, the disk space +required for Sun/IRAF is substantially reduced. Due to the increased +memory sharing and reduced process pagein times performance is +substantially improved, especially on systems like the Sun/386i which +has a relatively slow SCSI disk and often limited memory. The disk size +of small programs is reduced by up to a factor of ten in some cases, +e.g., an executable for a small program that was formerly 250 Kb in size +might be as small as 25 Kb if the shared library is used and the shared +image symbols are omitted at link time. + +User interface changes +~~~~~~~~~~~~~~~~~~~~~~ + +Calling IRAF tasks from the host environment +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The IRAF main and zmain were modified to make it easier to call IRAF +tasks as host level tasks, i.e., without having to set up a command file +and run the process with the standard input redirected. In the new +scheme, any extra arguments given on the process command line are passed +into the IRAF main as a command buffer containing the IRAF command or +commands to be run. For example, + +:: + + cl> x_system.e netstatus + +would run the command ``netstatus`` in process ``x_system.e``. + +:: + + cl> x_system.e count "files=*.x" + +would run the ``count`` task, counting all “.x” files in the current +directory. + +:: + + cl> x_system.e count "files=*.x 4>_o" + +would do the same, redirecting the output at the IRAF main level to the +file ``_o``. + +:: + + cl> x_system.e 'directory @pars $nargs=0' + +would run the ``directory`` task with the given parameter set, with +``$nargs`` set to 0. If any of the parameters to a task are omitted the +task will query the terminal for them in the usual way, so for example + +:: + + cl> alias count "$iraf/bin/x_system.e count files=" + +would make the IRAF task ``count`` available in UNIX, allowing the IRAF +template specifying the files to be counted to be either given on the +UNIX command line, or prompted for if omitted. Given the above alias, +one could enter a UNIX command such as + +:: + + cl> count 'cl$*.h' + +This feature is available in all UNIX based versions of IRAF V2.8, but +did not make it into VMS/IRAF version 2.8. + +Image packing density control (impkden) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Some users have complained about images taking up more disk space than +they have to, due to the IMIO feature which conditionally blocks image +lines to fill an integral number of disk blocks. This can result in more +efficient image i/o but can also make a significant difference in the +amount of disk space consumed by an image in some cases. + +IMIO can actually support both block-aligned and fully packed images. +The decision is made at image creation time and is based on the **image +packing density** if image lines are block aligned. If the packing +density is too low for a block-aligned image, a fully packed image is +created to avoid wasting disk space. The default minimum packing density +is 0.6, i.e., up to 40% wasted space before IMIO switches to full +packing (no wasted space). + +For finer control over the packing density, the user can now specify the +optional environment variable ``impkden``, the numeric value being the +minimum packing density. For example, + +:: + + cl> set impkden = 1.0 + +would completely disable block-alignment of image lines in IMIO. + +User libraries (IRAFULIB) +^^^^^^^^^^^^^^^^^^^^^^^^^ + +It is now possible for the programmer (SPP or IMFORT) to specify a +private directory to be searched at compile or link time when developing +IRAF or IMFORT programs. This is done by defining the path to the +directory in the user environment as the variable ``IRAFULIB``. When +locating a particular file, this directory will be searched *before* the +IRAF system libraries are searched, hence this feature may be used to +substitute custom versions of files in the IRAF system libraries, e.g., +for debugging purposes. + +New logical printer device LPR +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A new logical line printer or plotter device ``lpr`` is now supported on +all UNIX/IRAF systems. This treats the UNIX task *lpr* as a kind of +pseudo-device, leaving it up to UNIX to decide what physical device to +dispose of the output to. This default is system dependent, but on some +systems can be controlled by defining the variable ``PRINTER`` in the +user environment. + +Machine independent help database +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The IRAF ``help`` task uses a precompiled binary database to speed help +keyword searching. This file is now machine independent, allowing it to +be generated on one system and included in software distributions +without having to be recompiled. In addition, as part of the layered +software support, ``help`` now allows each external package to have its +own private help database. The first time ``help`` is run, all such +databases are read and linked to produce a database containing entries +for all help modules in the core system and all installed external +packages. The help database file is the file ``helpdb.mip`` in the LIB +directory of the core system and each external package. + +Set terminal type will no longer hangup +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +On systems, e.g., workstations, which provide virtual terminal windows +which can change in size, IRAF may query the terminal at run time to +determine the screen size. This query is performed, for example, at +login time if the terminal type is set to ``gterm`` or ``sun``. Formerly +this could cause the login process to hang indefinitely (i.e., until the +user typed return or interrupt) if the terminal did not respond to the +size query, as would happen when the terminal type was set improperly +and the actual terminal ignored the query. Thanks to the addition of +non-blocking raw terminal i/o in V2.8 IRAF, the terminal screen size +query will now time out with a warning message to reset the terminal +type, if the terminal does not respond to the query within several +seconds. + +Installing a new version of IRAF obsoletes old user parameter files +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The problem of old, obsolete user (``uparm``) parameter files being used +with a newly installed version of IRAF, which could lead to “parameter +not found” error aborts, has been fixed. The CL now checks the date of +the file ``utime`` in HLIB, and refuses to use the user pfile if it is +older than either ``utime`` or the package pfile provided with the new +system. The contents of old user pfiles are merged into the new system +pfile, as before, preserving learned parameter values even when the user +pfile is obsolete. + +@file list bug fixed +^^^^^^^^^^^^^^^^^^^^ + +The problem of the “@file” (at-file-list) syntax not working when the +file in question was not in the current directory has been fixed. + +Programming interface changes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +IMFORT pixel directory control +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +IMFORT has been modified to permit specification of the pixel file +directory by the calling program. The modifications are completely +upwards compatible, i.e., existing programs linked with the new +interface will still create pixel files in the same directory as the +header file, with “HDR$” in the image header. + +The Fortran programmer may set or query the pixel file directory using +the following routines: + +:: + + imsdir (dir) # set pixel directory pathname + imgdir (dir) # get pixel directory pathname + +where *dir* is a Fortran character variable. The value should be either +“HDR$” (the default) or a concatenable host directory pathname (i.e., +trailing / required for UNIX). Once set, the pixel directory will be +used for all subsequent image create or rename operations by the calling +process. + +For example, + +:: + + call imsdir ("/tmp3/pixels/") + call imcrea (image1, axlen, naxis, dtype, ier) + call imcrea (image2, axlen, naxis, dtype, ier) + +If desired the default pixel directory may be specified in the host +environment as ``imdir`` or ``IMDIR`` before running the program. IMFORT +will check the host environment for this environment variable then use +“HDR$” as the default if no host definition is found. + +Note that although this is similar to setting the value of ``imdir`` in +the IRAF environment, IMFORT programs are not part of the IRAF +environment and are not affected by changes to the IRAF ``imdir``. Also, +since IMFORT is a host level facility and IRAF networking is not +supported, the network prefix (e.g., “node!”) is omitted from the +pixelfile pathname, and since IMFORT programs are not necessarily used +in conjunction with IRAF, the “``..``” (hidden file protection) files +are not used to protect against image deletion. + +Image display interface: IMD +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A new interface IMD has been added to provide a rudimentary facility for +interactive image display device control. This is an interim prototype +interface which will be replaced by the new display interfaces when the +latter become available. + +The IMD interface operates by mapping an image display device frame +buffer onto an IMIO image descriptor. The display frame buffer may then +be randomly edited by normal image i/o operations, e.g., to modify +subrasters of the displayed image, or overlay the image with color +graphics. The image pixel to display frame buffer coordinate +transformation is supported, allowing applications to work in image +pixel coordinates if desired. This interim interface is what is used by +the new display oriented tasks ``imexamine``, ``imedit``, and +``tvmark``. + +Image masks: PLIO, PMIO, MIO +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following new VOS interfaces have been added in V2.8 to provide a +general boolean or integer image mask facility. + +:: + + PLIO pixel list i/o + PMIO pixel (image) mask i/o + MIO masked image i/o (image i/o through a mask) + +PLIO is a general interface for storing and manipulating +multidimensional integer valued rasters containing regions of constant +value (i.e., masks). The masks are stored in a highly compressed form, +the size of the compressed mask being a function of the information +content of the mask. Both pixel array and range list i/o facilities are +provided, as well as a set of general boolean raster operators, e.g., to +extract or insert subrasters, AND or OR a source with a destination, do +the same through a stencil, draw regions of various kinds (point, line, +box, circle, polygon), and so on. See the ``PLIO.hlp`` file in the PLIO +source directory for further information. + +An interactive debug program (``plio$zzdebug.x``) is provided for +experimenting with masks. Note that PLIO is a stand alone interface and +is not tied in any way to IMIO, even though the data structure operated +upon is similar to an image matrix. + +PMIO is very similar to PLIO except that it is used to associate a masks +with an IMIO maintained reference image. Currently, the PMIO mask must +be the same resolution as the physical reference image. All coordinates +input to PMIO are in the \*image section coordinates\` of the reference +image. Hence, given a physical image and associated mask, one can +operate upon both through a user specified image section transparently +to the applications program. This includes all PLIO style boolean +rasterop operations, as well as mask pixel and range list i/o. The PMIO +interface is layered upon PLIO and IMIO, and the calling sequences are +identical with PLIO except for the package prefix, and the addition of +several new PMIO specific routines. + +MIO is essentially an extension of image i/o for pixel i/o through a +mask. The central routines are the following: + +:: + + mio_setrange (mp, vs, ve, ndim) + n|EOF = mio_[gp]lseg[silrdx] (mp, ptr, mval, v, npix) + +One defines a rectangular region of the image with mio_setrange, and +then sequentially reads or writes line segments until all pixels visible +through the mask have been accessed. This type of i/o should be ideal +for most image processing applications which need to operate upon only +those pixels visible through a region mask (e.g., a surface fitting +task), upon all pixels except those on a bad pixel mask (e.g., any +analysis program), and so on. + +PLIO (or PMIO) masks may be stored in binary files on disk, the files +having the extension “``.pl``”. The V2.8 version of IMIO has the +capability to treat such masks as if they were images, allowing masks to +be easily displayed, used in image expressions, converted to image +matrices and vice versa, etc. Applications may do either pixel or *range +list i/o* to a mask image via IMIO, if MIO is not suitable for some +reason. + +Photon images: QPOE, QPIO, QPEX +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A new set of VOS interfaces supporting photon or **event list data** are +now available. The QPOE interface implements the Position Ordered Event +list object, which consists of a general header mechanism plus an event +list, wherein the events are little data structures, e.g., the +attributes required to describe a photon detection (position, energy, +time, etc.). QPOE is designed to efficiently access very large event +lists, e.g., several hundred thousand or several million events in size. +Builtin event attribute filtering and region filtering capabilities are +provided for selecting photons from the event list. These filtering +capabilities may be combined with the sampling capability to produce +filtered, block averaged image matrices from event lists. + +The QPOE interfaces are the following: + +:: + + QPOE header and file access and management facilities + QPIO raw and filtered event i/o + QPEX event attribute filter mechanism + QPF IMIO/IKI kernel for image interface to QPOE files + +QPOE and QPF add a new image type to the system, with ``.qp`` file +extension. Hence, event list data can be used as input to any of the +image processing tasks in standard IRAF, in addition to being analyzed +by tasks which deal with the individual photon events. A QPOE image is +contained in a single file. When a QPOE file is accessed as an image the +interface filters and samples the event list in real time, using a user +defined filter, block averaging factor, region mask, and so on, +producing the image matrix seen by applications at the IMIO level. The +QPOE object may be repeatedly examined with different event filters to +view the data in different ways. + +The QPOE interface, in addition to providing an event list capability +for IRAF, serves as a prototype for the “flex-header” portion of the new +image structures project. Many of the capabilities to be provided for +image storage under the new image structures are already present in +QPOE. + +Further information is given in the ``QPOE.hlp`` file in the QPOE source +directory. + +File manager: FMIO +^^^^^^^^^^^^^^^^^^ + +A new VOS library FMIO has been installed. FMIO is “File Manager I/O”, +and is used to implement a simple binary file manager which maintains +the file data of so-called “lfiles” (lightweight files) inside a single +host binary file. The system overhead for accessing lfiles is much less +than that of host files, and many lfiles can be used to store a complex +data structure without cluttering a host directory or incurring the +inefficiency of accessing host files. FMIO is part of the DFIO project +and will serve as the lowest level interface within DFIO; it is also +used currently in the QPOE interface. Additional information is given in +the README file in the source directory for the interface. + +IMIO changes +^^^^^^^^^^^^ + +IMIO is the image i/o interface, the standard IRAF VOS interface for +managing all varieties of image data. + +Mask image support +'''''''''''''''''' + +IMIO now supports a new type of image, the **mask image**, stored as a +highly compressed binary (PLIO) file with the extension “``.pl``”. Image +masks are most commonly used to store information describing selected +pixels in an associated data image. An image mask is logically a boolean +or integer image, up to 28 bits deep, containing information only on +selected pixels or regions of pixels. Masks are stored in highly +compressed format, e.g., a simple mask may be stored in only a few +hundred bytes of space. Mask images are readable, writable, and randomly +modifiable, like ordinary raster images. + +Photon image support +'''''''''''''''''''' + +Support has also been added to IMIO for **event list images**, stored as +position ordered event list datafiles using the QPOE interfaces. This +new image type has the extension “``.qp``”. QPOE images are read-only +under IMIO. Subject to that restriction, they may be accessed like any +other image by any IRAF image analysis program. Accessing an event list +image as a raster image necessarily involves a runtime sampling +operation, wherein the events in the region of interest are accumulated +into an initially zero image matrix; in the process the event list may +optionally be filtered by event attribute or event position, e.g., + +:: + + cl> display "xray.qp[t=(30:40),pha=10,block=4]" + +would display the QPOE image ``xray.qp`` with a blocking factor of 4, +selecting only those events with ``t`` (time) in the range 30 to 40 and +for which ``pha`` (energy) has the value 10. The event attributes and +their names are user definable and may vary for different types of data. + +IMPUTH +'''''' + +A new procedure ``imputh`` has been added to the IMIO header access +library. The new procedure is used to append FITS like HISTORY or +COMMENT cards to the image header. + +IMPARSE +''''''' + +The calling sequence of the internal IMIO procedure ``imparse`` has +changed. Although this procedure is internal to the IMIO interface and +is not supposed to be used within applications, there may be +applications which make use of this procedure. Any such applications +must be modified to reflect the new procedure calling sequence or +runtime problems are guaranteed. + +Null string environment variables +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The semantics of the VOS procedures ``envgets`` and ``envfind`` have +changed. This could affect existing programs and any programs which use +these functions should be checked to make certain they will still work +properly. + +These procedures, used to fetch the string values of environment +variables, return the length of the output string as the function value. +Formerly, a value of zero would be returned both when the named variable +existed but had a null string value, and when the variable was not +found. This made it impossible to discriminate between the case of a +variable not being defined, and one which is defined but has a null +value. The routines have been changed to return the value ERR (a +negative integer) if the variable is not defined. Programs which do not +wish to make the distinction between undefined and null-valued should +check for a function value less than or equal to zero. Programs which +check for a function value equal to zero will fail if the named variable +is not defined. + +Environment substitution in filenames +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The VOS filename mapping code has been modified to add support a +powerful new environment substitution syntax. Previously the only +environment substitution mechanism available was the logical directory +facility, which could only be used to parameterize the directory field. +The new facility may be used to perform environment substitution +anywhere in a filename. This is used in IRAF version 2.8 to implement +multiple architecture support, e.g., + +:: + + cl> set bin = "iraf$bin(arch)/" + +is how the core system BIN is defined in V2.8 IRAF. The syntax +“``(arch)``” tells the filename mapping code to substitute the string +value of the environment variable ``arch``, if defined. If the variable +is not defined the null string is substituted. Hence, if the host system +does not implement multiple architecture support and ``arch`` is not +defined, BIN is defined as “``iraf$bin/``”, which is the backwards +compatible definition. If ``arch`` is defined as, e.g., “``.vax``”, then +BIN is defined as “``iraf$bin.vax/``”. The new feature allows use of a +single environment variable to define the architecture, not only to form +filenames, but for other purposes as well, e.g., to generate compiler +switches or to control library searching in ``mkpkg``. + +Nonblocking raw terminal i/o +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The VOS file i/o interfaces have been modified to add support for +nonblocking terminal i/o. This facility makes it possible to, in effect, +“poll” the terminal to see if there is any input waiting to be read, to +allow interaction without having a program block if the user has not +typed anything. + +The immediate application of this in version 2.8 was the modification of +the ``stty`` (set-terminal) facility to implement a time out for the +terminal size query. Formerly, ``stty`` would hang up indefinitely when +the terminal type was set to “gterm” but the actual terminal was +something different, causing the screen size query to be ignored. + +In the more general case, nonblocking terminal i/o makes possible a new +class of user interface, which is not only interactive, but **event +driven**. Nonblocking i/o makes it possible for an application to be +continually processing, while checking the terminal occasionally to see +if the user has input any commands. + +At present, nonblocking i/o is always used in conjunction with raw mode +input from a terminal. A new flag ``F_NDELAY``, defined in ````, +is used to enable or disable nonblocking i/o. For example, + +:: + + call fseti (fd, F_RAW, YES) + +enables conventional blocking, single character raw mode reads, and + +:: + + call fseti (fd, F_RAW, YES + F_NDELAY) + +enables nonblocking raw mode input (``YES``, ``NO``, and ``F_NDELAY`` +are bit flags). These modes are mutually exclusive, e.g., the first call +may be issued while nonblocking raw mode is in effect to make the reads +block, and vice versa. A call to ``fset(fd,F_RAW,NO)`` disables both raw +mode and nonblocking mode. Once nonblocking raw mode is in effect one +merely reads characters from the terminal in the usual way, using +``getc``. EOF is returned if a read is performed when no data is +available for input, otherwise the next character is returned from the +input queue. Further information on nonblocking i/o is given in the +system notes file. + +Function call tables (ZFUNC) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +IRAF has always had the ability to compute the integer valued address of +a procedure, store that address in a table, and later use the address as +an argument to one of the ``zcall`` kernel primitives to call the +addressed procedure. This facility has been extended by the addition of +a set of ``zfunc`` primitives, used to call integer valued *functions*. +Only integer valued functions are supported (in order to simplify the +kernel support required), but in the systems oriented applications where +procedure call tables are used, this is unlikely to be a serious +limitation. + +Sun/IRAF specific revisions +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +IEEE exception handling +^^^^^^^^^^^^^^^^^^^^^^^ + +By default the IEEE hardware is now configured, on all Sun systems, with +the invalid, overflow, and divide by zero IEEE exceptions enabled, and +with the default rounding direction and precision modes (nearest, +extended) in effect. This configuration should ensure that all +questionable floating point operations are detected, and that no IEEE +“funny numbers” (NaN, Inf, etc.) get into the data. These values, since +they don’t behave like ordinary numbers, can cause programs to +misbehave, e.g., go into an infinite loop. In Sun/IRAF V2.8, if a +computation results in an IEEE funny number being generated, an +exception abort will result. The most common example is divide by zero. + +The IRAF/IEEE interface offers a special debug feature that may be of +interest to programmers developing numerically sensitive software. If +desired, one can change the default rounding direction and precision +(e.g., to test the numerical stability of applications) by using the +debugger to set a nonzero value of the variable ``debug_ieee`` before +running an executable. The procedure for doing this is documented in the +system notes file. + +IMTOOL enhancements +^^^^^^^^^^^^^^^^^^^ + +A number of enhancements and bug fixes have been made for V2.8 to the +SunView based IMTOOL image display server. The most notable changes are +summarized here; refer to the IMTOOL manual page for a more complete +description of the new features. + +Software ZOOM added +''''''''''''''''''' + +IMTOOL, which has had for some time the ability to pan about on a large +image, now has the ability to zoom as well. Both pan and zoom are +controlled very conveniently by the middle mouse button: place the mouse +on an object and tape the middle button once to pan the object to the +center of the display window; tap it again and the image will be zoomed. +Zoom, currently implemented by writing directly into the hardware frame +buffer, is very fast, almost as fast as a normal unzoomed window +refresh. The default set of zoom factors is 1,2,4,8 after which the +sequence wraps around to 1. The zoom factors are user configurable via +the IMTOOL setup panel; very large zoom factors, e.g., x64, are +possible. Dezoom (making a large image smaller) is not currently +supported. + +WCSDIR eliminated +''''''''''''''''' + +The host level ``WCSDIR`` environment variable, and the text file used +to communicate image coordinate (WCS) information between the display +task and the display server, have been eliminated. All WCS information +is now passed via the datastream used to pass commands and data between +the client and the display server. This eliminates the need for users to +have to remember to define ``WCSDIR`` in order to get coordinates in +image units, and some subtle process synchronization problems are +eliminated as well. + +In a related change, the frame buffer configuration index is no longer +passed in during a frame erase, hence it is no longer necessary to erase +a frame before displaying an image to ensure that a frame buffer +configuration change is passed to the server. The configuration index is +now passed when the WCS information for a frame is set. + +Graphics colors +''''''''''''''' + +IMTOOL now allocates a range of pixel values for use as graphics overlay +colors. Setting a frame buffer pixel to one of these values causes it to +always be displayed with the assigned color. The graphics color values +are not affected by windowing the display. The most common use of +graphics colors with V2.8 IRAF is for drawing graphics into a displayed +frame with the new ``tvmark`` task, available in PROTO. See the IMTOOL +manpage for a table listing the color index assignments. + +New imtoolrc entries +'''''''''''''''''''' + +Several new predefined frame buffer configurations have been added to +the default ``imtoolrc``. These include an 128 pixel square frame buffer +(``imt128``), a 256 pixel square frame buffer (``imt256``), and a full +screen display with the same aspect ratio as a 35 mm slide +(``imtfs35``). + +System crash (FIFO) bug fixed +''''''''''''''''''''''''''''' + +Versions of SunOS through at least 4.0.1 have a bug in the FIFO driver +code which can cause the internal kernel FIFO data buffer to be +deallocated while it is still in use. This will result in a bad kernel +which will eventually panic and reboot the system. This is the cause of +the IMTOOL crash problem which some sites may have experienced. IMTOOL +has been modified to avoid the circumstances (repeated 4096 byte +transfers) which cause the bug to surface. So far as we know, the real +bug (in SunOS) has not yet been fixed, but at least on the NOAO systems, +the frequency of occurrence of the system crashes is greatly reduced +with the new version of IMTOOL which incorporates the workaround for the +SunOS bug. + +Cursor marking now disabled by default +'''''''''''''''''''''''''''''''''''''' + +When the interactive image cursor read facility was first added to +IMTOOL, the default response to each cursor read was to draw a small +white dot at the position of the cursor. This is convenient when marking +a series of objects to make a list, but with the increasing number of +IRAF programs making user of the interactive image cursor, it has been +necessary to change the default to disable automatic marking of each +cursor read. The cursor mark feature is still available as an option and +can be enabled via the setup panel. + +Ctrl/b may be used for manual blinking +'''''''''''''''''''''''''''''''''''''' + +In addition to the list of blink frames and the timed blink feature +IMTOOL has provided for some time, it is now possible to manually cycle +through the blink frames with the key. Typing while the mouse is in the +image window will cause the display to display the next blink frame in +sequence. + +F4 key will now toggle setup panel +'''''''''''''''''''''''''''''''''' + +The F4 function key on the Sun keyboard may now be used to toggle +whether or not the setup panel is displayed. This provides a single +keystroke alternative to calling up the setup panel with the frame menu. + +VMS/IRAF specific revisions +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +NEWUISDISP added to VMS/IRAF +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Nigel Sharp’s ``NEWUISDISP`` display program, used for image display +under UIS on microvaxes with bitmapped displays, is now available in the +standard VMS/IRAF release, in the directory ``[IRAF.VMS.UIS]``. + +New INSTALL.COM script +^^^^^^^^^^^^^^^^^^^^^^ + +A new ``INSTALL.COM`` script (also written by Nigel Sharp) has been +added to VMS/IRAF. This script, run by the system manager to install +selected IRAF executable images, will now automatically check for and +deinstall any old versions of the executables before installing the new +ones. + +VMS 4.7/5.0 +^^^^^^^^^^^ + +Testing of the standard V2.8 VMS/IRAF release, which was prepared on VMS +4.7, on a VMS 5.0 system has thus far not revealed any problems (NOAO is +still running VMS 4.7 as our standard system). Hence it appears that the +standard V2.8 VMS/IRAF will *run* under VMS 5. It is likely, however, +that any attempt to *recompile* VMS/IRAF under VMS 5 would cause +problems, since we have not yet tried to rebuild IRAF under VMS 5, and +such a major operating system upgrade will often require changes to the +IRAF code. The system may be relinked under VMS 5 if desired, and this +does not appear to cause any problems, but neither does there appear to +be any benefit to be gained from doing so. + +Summary of IRAF System Packages Revisions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- The tasks RFITS and WFITS in the DATAIO package now support the + reading and writing of arbitrary sized data blocks (IRAF version 2.7 + and later). + +- Several new tasks were added to the IMAGES package. IMCOMBINE (IRAF + version 2.6 and later) provides for the combining of images by a + number of algorithms. The new task CHPIXTYPE (IRAF version 2.7 and + later) changes the pixel types of a list of input images. The task + IMSLICE slices images into images of one less dimension (IRAF version + 2.8). The task IMSTACK has been moved into the IMAGES package + (although it still resides in PROTO as well). + +The IMSTATISTICS task has been rewritten and now allows the user to +select which statistical parameters to compute and print (IRAF version +2.8). The IMRENAME task has been modified to allow “in place” image +renames, used chiefly for moving the pixel files to a new IMDIR. + +Several other tasks in the IMAGES package were modified (IRAF version +2.8). IMSHIFT was modified to accept a list of shifts from a file. +REGISTER and GEOTRAN were modified to accept a list of transforms +instead of only a single one. IMHISTOGRAM has undergone extensive +revision including support for “box” type plots, support for linear or +log scaling in the y coordinate, as well as support for antialiasing of +the histogram bins. + +- All the tasks in the IMAGES.TV package were modified (IRAF version + 2.8) so that if a task is used with an unsupported display device a + message is printed to that effect. + +- The STTY task in the LANGUAGE package has been improved (IRAF version + 2.6 and later) to better facilitate its “playback” feature. These + changes have been documented in the online help for the task. This + feature is little used by external sites but can be a very useful + instructional aid if users are aware of its capability. + +- A new task PVECTOR was added to the PLOT package that allows one to + plot an arbitrary vector in a two dimensional image (IRAF version 2.6 + and later). + +The task STDPLOT was modified (IRAF version 2.8) so that it uses the +more popular SGI kernel rather than the NSPP (NCAR) kernel (STDPLOT is +now equivalent to the SGIKERN task). A new task NSPPKERN was added that +uses the NSPP kernel. + +- Two new tasks were added to the SYSTEM package (IRAF version 2.8). + The task DEVICES simply prints the ``dev$devices.hlp`` file as edited + by the site manager listing available devices on the local host or + network. The REFERENCES task is used to search the help database for + all tasks or other help modules pertaining to a given topic, e.g., + ``references vector`` will list all tasks that have the string + “vector” in their one line description. + +Glossary of New Tasks in the IRAF System Packages +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ++------------+---------------------+-----------------------------------+ +| Task | Package | Description | ++============+=====================+===================================+ +| chpixtype | images | Change the pixel type of a list | +| | | of images | ++------------+---------------------+-----------------------------------+ +| devices | system | Print information on the locally | +| | | available devices | ++------------+---------------------+-----------------------------------+ +| imcombine | images | Combine images pixel-by-pixel | +| | | using various algorithms | ++------------+---------------------+-----------------------------------+ +| imslice | images | Slice images into images of lower | +| | | dimension | ++------------+---------------------+-----------------------------------+ +| imstack | images | Stack images into a single image | +| | | of higher dimension | ++------------+---------------------+-----------------------------------+ +| nsppkern | plot | Plot metacode on a NSPP (NCAR) | +| | | plotter device | ++------------+---------------------+-----------------------------------+ +| pvector | plot | Plot an arbitrary vector in a 2D | +| | | image | ++------------+---------------------+-----------------------------------+ +| references | system | Find all help database references | +| | | for a given topic | ++------------+---------------------+-----------------------------------+ + +In addition, there are new image display oriented tasks ``imexamine``, +``imedit``, and ``tvmark`` in the PROTO package in NOAO (used to +interactively examine and edit images, or draw graphics into image +display frames). These really belong in the core system but have been +placed in ``noao.proto`` since they are prototype tasks. + +NOAO Package Revisions +---------------------- + +Some of the major revisions to the NOAO packages are listed below. + +Summary of NOAO Packages Revisions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +New NOAO Packages +^^^^^^^^^^^^^^^^^ + +Several new packages have been added to the NOAO suite of packages. + +- The APPHOT package is a set of tasks for performing aperture + photometry on uncrowded or moderately crowded stellar fields in + either interactive or batch mode. This package is now installed in + the DIGIPHOT package (IRAF version 2.7 and later). The APPHOT package + was available as an add-on package to IRAF version 2.5 and later + while it was undergoing alpha testing. Many new features have been + added to the package since it first became available including the + new task QPHOT (quick aperture photometry) and interaction with the + image display cursor for supported image displays (Sun workstation, + IIS model 70). + +- The CCDRED package provides tools for the easy and efficient + reduction of CCD images. This package has been installed in the IMRED + package (IRAF version 2.6 and later). The CCDRED package was also + available as an add-on to IRAF version 2.5. + +A short demonstration of many of the tasks in the CCDRED package is +provided with the DEMO task in the CCDRED.CCDTEST package. + +- The IMRED.ECHELLE package has been replaced with a more sophisticated + collection of tasks for reducing echelle type data (IRAF version 2.7 + and later). The new ECHELLE package recognizes a new image format in + which each extracted echelle order becomes a line in a two + dimensional image rather than having a separate one dimensional + spectrum for each order, although this old output format is still + available as an option. Several new tasks exist for computing and + applying a wavelength calibration to the data using the echelle + relationship between the orders (ECIDENTIFY, ECREIDENTIFY, and + ECDISPCOR) as well as for manipulating the new echelle format + (ECSELECT, ECCONTINUUM, and ECBPLOT). + +- The IRRED package has been added to the IMRED package. The IRRED + package collects together in one place those tasks used most + frequently by users reducing IR data such as that taken with the IR + imager at KPNO. The IRMOSAIC and IRALIGN tasks were available with + IRAF version 2.6 and later. IRMOSAIC takes an ordered list of input + images and places them on a grid in an output image. IRALIGN uses + this grid and a coordinate list of overlapping objects from the + individual subrasters to produce an aligned output image. The tasks + IRMATCH1D and IRMATCH2D were available with IRAF version 2.7 and + later. These tasks are similar to IRALIGN expect that the intensities + of adjacent subrasters can be matched as well. A script called + MOSPROC (IRAF version 2.8) has also been added that prepares a list + of images for a quick look mosaic. + +- The MSRED package has been added to the IMRED package. The MSRED + package is a collection of tasks used for reducing multispectral + types of data, e.g. fiber arrays, where the individual spectra are + for different objects. Like the ECHELLE package, it also has its own + multispectral image format (a two dimensional image in which each + line is an extracted spectrum). Several new tasks have been added to + the package for wavelength calibration of multispectral data. + +Modifications to Existing NOAO Packages +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- The ASTUTIL package was reorganized (IRAF version 2.6 and later - see + IRAF Newsletter No. 3 for details) and several tasks were added + and/or modified. A new task ASTTIMES computes and prints astronomical + dates and times given a local date and time. A new task RVCORRECT + computes and prints radial velocity corrections for an observation. + The tasks PRECESS and GALACTIC were modified slightly using different + but more accurate algorithms. + +The new task SETAIRMASS (IRAF version 2.8) computes the effective +airmass and middle UT of an exposure. This task was also made available +in the TWODSPEC and IMRED packages. + +- The two tasks in the IMRED.BIAS package, COLBIAS and LINEBIAS, were + modified slightly (IRAF version 2.7 and later) so that the fitting + parameters for the overscan region can be set by the user as hidden + parameters to the tasks. + +- The task COSMICRAYS (from the CCDRED package) was made available in + the IMRED.GENERIC package (IRAF version 2.6 and later). + +- A new task called SYNDICO has been added to the IMRED.VTEL package + (IRAF version 2.6 and later). SYNDICO makes glossy prints on the NOAO + Dicomed printer of the synoptic, full disk, magnetograms and + spectroheliograms taken at the vacuum telescope at Kitt Peak. + +- Modifications were made to the IMRED.DTOI package. These changes have + been documented in IRAF Newsletter No. 4. + +- Three new tasks in the ONEDSPEC package, REFSPECTRA, SEXTRACT, and + SPECPLOT, were made available in the IMRED.COUDE, IMRED.IIDS, + IMRED.IRS, and IMRED.SPECPHOT packages. + +- Many new tasks and features have been added to the ONEDSPEC package. + +The SENSFUNC task was completely rewritten (IRAF version 2.6 and later) +to allow determination of extinction, display of flux calibrated +spectra, and many new features for displaying and manipulating the data. + +IDENTIFY, REIDENTIFY and DISPCOR were modified (IRAF version 2.6 and +later) so that a dispersion solution from IDENTIFY could be shifted +without changing the original shape of the coordinate function (see IRAF +Newsletter No. 3 for details). + +A new deblending algorithm was added to SPLOT (IRAF version 2.7 and +later). See the online help for SPLOT as well as the article in IRAF +Newsletter No. 4. + +The tasks in the ONEDSPEC.ONEDUTIL package were absorbed into the +ONEDSPEC package (IRAF version 2.7 and later). + +The EXTINCT task disappeared with its functionality being taken over by +a rewritten CALIBRATE (IRAF version 2.7 and later). + +The COEFS task was moved to the IMRED.IIDS and IMRED.IRS packages since +this is a very instrument specific task (IRAF version 2.7 and later). + +Three new tasks were added to the package. SEXTRACT (IRAF version 2.6 +and later) extracts subspectra from one dimensional input spectra. +REFSPECTRA (IRAF version 2.7 and later) takes over part of the +functionality of the old DISPCOR task and allows the user to define +which arc spectra are to be used in the calculation of the dispersion +solution of object spectra. SPECPLOT (IRAF version 2.8) is a new +plotting task that allows the compression of many spectra to a page (see +IRAF Newsletter No. 6). + +- Several new tasks have been added to the PROTO package. + +Four tasks were added to IRAF version 2.6 and later. BSCALE is a task +that can be used to linearly scale images by the mean, average, or mode +of the image. IRMOSAIC and IRALIGN can be used to combine many frames +into one large image. These three tasks are also available in the +IMRED.IRRED package. MKHISTOGRAM calculates the histogram of the data in +a text file. + +Three new tasks were added to IRAF version 2.7 and later. IMSLICE is a +task that slices an image into images of lower dimension. IRMATCH1D and +IRMATCH2D are two tasks that allow combining of many overlapping images +while matching the background intensities in two different ways. + +Three new tasks have been added to IRAF version 2.8 that allow the user +to interact with the image display (for supported display devices, ie +Sun workstation, IIS model 70). IMEXAMINE allows the user to +interactively examine portions of the displayed image. TVMARK allows the +user to mark objects on the image display. IMEDIT allows the user to +interactively edit an image. + +- The APEXTRACT package in the TWODSPEC package has had several rounds + of modifications, as discussed in the IRAF Newsletters, No. 3 and 4. + These changes included improved techniques and additional options for + the extraction of data. + +A new task, APSCATTER, has been added to the package (IRAF version 2.8). +This task determines and subtracts scattered light from two dimensional +aperture or echelle spectra. The task was also made available from +within the ECHELLE package. This task was discussed in IRAF Newsletter +No. 6. + +Modifications and Additions to Calibration Data +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The calibration data used by some of the tasks in the TWODSPEC, +ONEDSPEC, and many of the IMRED packages are kept in a directory called +ONEDSTDS in ``noao$lib``. The current contents of this directory are +best summarized by paging through its README file, e.g., + +:: + + cl> page noao$lib/onedstds/README + +Two additional line lists (used by IDENTIFY) have been added to this +directory (IRAF version 2.8). These lists, ``vacidhenear.dat`` and +``vacthorium.dat``, are simply the standard ``.dat`` files in air +wavelengths converted to vacuum wavelengths. The equation used for the +conversion as well as the appropriate reference in the literature are +contained in the README file. + +The ``thorium.dat`` file has been updated to contain thorium lines from +3180 Angstroms to 9540 Angstroms (IRAF version 2.6 and later). Please +see the README file for the source. + +Two new directories have been added containing flux information for +standard stars (IRAF version 2.6 and later): SPECHAYESCAL and SPEC50CAL. +Both of these lists are from Massey et al., 1988, Ap. J., Vol. 328, +p. 315. + +Glossary of New Tasks in the NOAO Packages +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ++------------+---------------------+-----------------------------------+ +| Task | Package | Description | ++============+=====================+===================================+ +| apsc | apextract | Fit and subtract scattered light | +| atter [1]_ | | | ++------------+---------------------+-----------------------------------+ +| apselect | apphot | Extract select fields from apphot | +| | | output files | ++------------+---------------------+-----------------------------------+ +| asttimes | astutil | Compute UT, Julian day, epoch, | +| | | and sidereal time | ++------------+---------------------+-----------------------------------+ +| b | ccdred | Create a bad pixel mask image | +| adpiximage | | from a bad pixel file | ++------------+---------------------+-----------------------------------+ +| b | proto | Brightness scale images: new = | +| scale [2]_ | | (old-bzero) / bscale | ++------------+---------------------+-----------------------------------+ +| c | ccdred | Discussion of CCD | +| cdgeometry | | coordinate/geometry keywords | ++------------+---------------------+-----------------------------------+ +| ccdgroups | ccdred | Group CCD images into image lists | ++------------+---------------------+-----------------------------------+ +| ccdhedit | ccdred | CCD image header editor | ++------------+---------------------+-----------------------------------+ +| ccdlist | ccdred | List CCD processing information | ++------------+---------------------+-----------------------------------+ +| ccdproc | ccdred | Process CCD images | ++------------+---------------------+-----------------------------------+ +| ccdred | ccdred | CCD image reduction package | ++------------+---------------------+-----------------------------------+ +| ccdtypes | ccdred | Description of the CCD image | +| | | types | ++------------+---------------------+-----------------------------------+ +| c | apphot | Compute accurate centers for a | +| enter [3]_ | | list of objects | ++------------+---------------------+-----------------------------------+ +| cente | apphot | Edit the centering parameters | +| rpars [4]_ | | | ++------------+---------------------+-----------------------------------+ +| combine | ccdred | Combine CCD images | ++------------+---------------------+-----------------------------------+ +| cosmi | ccdred | Detect and replace cosmic rays | +| crays [5]_ | | | ++------------+---------------------+-----------------------------------+ +| daofind | apphot | Find stars in an image using the | +| | | DAO algorithm | ++------------+---------------------+-----------------------------------+ +| d | ccdred | Combine and process dark count | +| arkcombine | | images | ++------------+---------------------+-----------------------------------+ +| dat | apphot | Edit the data dependent | +| apars [6]_ | | parameters | ++------------+---------------------+-----------------------------------+ +| demo | ccdtest | Run a demonstration of the CCD | +| | | reduction package | ++------------+---------------------+-----------------------------------+ +| ecbplot | echelle | Batch plots of echelle spectra | ++------------+---------------------+-----------------------------------+ +| e | echelle | Fit the continuum of echelle | +| ccontinuum | | spectra | ++------------+---------------------+-----------------------------------+ +| ecdispcor | echelle | Dispersion correct spectra | ++------------+---------------------+-----------------------------------+ +| ecidentify | echelle | Identify features in spectrum for | +| | | dispersion solution | ++------------+---------------------+-----------------------------------+ +| ec | echelle | Automatically reidentify features | +| reidentify | | in spectra | ++------------+---------------------+-----------------------------------+ +| ecselect | echelle | Select and extract apertures from | +| | | echelle spectra | ++------------+---------------------+-----------------------------------+ +| fitpsf | apphot | Model the stellar psf with an | +| | | analytic function | ++------------+---------------------+-----------------------------------+ +| fitsky | apphot | Compute sky values in a list of | +| | | regions | ++------------+---------------------+-----------------------------------+ +| fitskypars | apphot | Edit the sky fitting parameters | ++------------+---------------------+-----------------------------------+ +| f | ccdred | Combine and process flat field | +| latcombine | | images | ++------------+---------------------+-----------------------------------+ +| flatfields | ccdred | Discussion of CCD flat field | +| | | calibrations | ++------------+---------------------+-----------------------------------+ +| guide | ccdred | Introductory guide to using the | +| | | CCDRED package | ++------------+---------------------+-----------------------------------+ +| imedit | proto | Examine and edit pixels in images | ++------------+---------------------+-----------------------------------+ +| imexamine | proto | Examine images using image | +| | | display, graphics, and text | ++------------+---------------------+-----------------------------------+ +| imslice | proto | Slice images into images of lower | +| | | dimension | ++------------+---------------------+-----------------------------------+ +| i | ccdred | Instrument specific data files | +| nstruments | | | ++------------+---------------------+-----------------------------------+ +| ir | proto | Align the mosaiced image produced | +| align [7]_ | | by irmosaic | ++------------+---------------------+-----------------------------------+ +| irma | proto | Align and intensity match image | +| tch1d [8]_ | | produced by irmosaic | ++------------+---------------------+-----------------------------------+ +| irma | proto | Align and intensity match image | +| tch2d [9]_ | | produced by irmosaic | ++------------+---------------------+-----------------------------------+ +| irmo | proto | Mosaic an ordered list of images | +| saic [10]_ | | onto a grid | ++------------+---------------------+-----------------------------------+ +| m | ccdred | Make fringe correction images | +| kfringecor | | from sky images | ++------------+---------------------+-----------------------------------+ +| m | proto | List or plot the histogram of a | +| khistogram | | data stream | ++------------+---------------------+-----------------------------------+ +| mkillumcor | ccdred | Make flat field iillumination | +| | | correction images | ++------------+---------------------+-----------------------------------+ +| m | ccdred | Make iillumination corrected flat | +| killumflat | | fields | ++------------+---------------------+-----------------------------------+ +| mkimage | ccdtest | Make or modify an image with | +| | | simple values | ++------------+---------------------+-----------------------------------+ +| mkskycor | ccdred | Make sky iillumination correction | +| | | images | ++------------+---------------------+-----------------------------------+ +| mkskyflat | ccdred | Make sky corrected flat field | +| | | images | ++------------+---------------------+-----------------------------------+ +| mosproc | irred | Prepare images for quick look | +| | | mosaicing | ++------------+---------------------+-----------------------------------+ +| msdispcor | msred | Dispersion correct spectra | ++------------+---------------------+-----------------------------------+ +| ms | msred | Reidentify features from/to a | +| reidentify | | multispec image | ++------------+---------------------+-----------------------------------+ +| msselect | msred | Select and extract apertures from | +| | | spectra | ++------------+---------------------+-----------------------------------+ +| observe | ccdtest | Create an artificial CCD | +| | | observation | ++------------+---------------------+-----------------------------------+ +| phot | apphot | Measure magnitudes for a list of | +| | | stars | ++------------+---------------------+-----------------------------------+ +| photpars | apphot | Edit the photometry parameters | ++------------+---------------------+-----------------------------------+ +| polymark | apphot | Create polygon lists for polyphot | ++------------+---------------------+-----------------------------------+ +| polypars | apphot | Edit the polyphot parameters | ++------------+---------------------+-----------------------------------+ +| polyphot | apphot | Measure magnitudes inside a list | +| | | of polygonal regions | ++------------+---------------------+-----------------------------------+ +| qphot | apphot | Measure quick magnitudes for a | +| | | list of stars | ++------------+---------------------+-----------------------------------+ +| radprof | apphot | Compute the stellar radial | +| | | profile of a list of stars | ++------------+---------------------+-----------------------------------+ +| refspe | onedspec | Assign wavelength reference | +| ctra [11]_ | | spectra to other spectra | ++------------+---------------------+-----------------------------------+ +| rvcorrect | astutil | Compute radial velocity | +| | | corrections | ++------------+---------------------+-----------------------------------+ +| setair | astutil | Compute effective airmass for an | +| mass [12]_ | | exposure | ++------------+---------------------+-----------------------------------+ +| set | ccdred | Set instrument parameters | +| instrument | | | ++------------+---------------------+-----------------------------------+ +| sext | onedspec | Extract subspectra from | +| ract [13]_ | | dispersion corrected spectra | ++------------+---------------------+-----------------------------------+ +| spec | onedspec | Stack and plot multiple spectra | +| plot [14]_ | | | ++------------+---------------------+-----------------------------------+ +| subsection | ccdtest | Create an artificial subsection | +| | | CCD observation | ++------------+---------------------+-----------------------------------+ +| subsets | ccdred | Description of CCD subsets | ++------------+---------------------+-----------------------------------+ +| syndico | vtel | Make dicomed print of daily grams | +| | | 18 cm across | ++------------+---------------------+-----------------------------------+ +| tvmark | proto | Mark objects on the image display | ++------------+---------------------+-----------------------------------+ +| wphot | apphot | Measure magnitudes for a list of | +| | | stars with weighting | ++------------+---------------------+-----------------------------------+ +| z | ccdred | Combine and process zero level | +| erocombine | | images | ++------------+---------------------+-----------------------------------+ + +.. [1] + Tasks also in echelle and msred packages. + +.. [2] + Tasks also in irred package. + +.. [3] + Tasks also in irred package. + +.. [4] + Tasks also in irred package. + +.. [5] + Tasks also in generic package. + +.. [6] + Tasks also in irred package. + +.. [7] + Tasks also in irred package. + +.. [8] + Tasks also in irred package. + +.. [9] + Tasks also in irred package. + +.. [10] + Tasks also in irred package. + +.. [11] + Tasks also in coude, echelle, iids, irs, msred, and specphot + packages. + +.. [12] + Tasks also in imred and twodspec packages. + +.. [13] + Tasks also in coude, iids, irs, and specphot packages. + +.. [14] + Tasks also in coude, echelle, iids, irs, msred, and specphot + packages. diff --git a/doc/releases/v29revs.rst b/doc/releases/v29revs.rst new file mode 100644 index 000000000..949175872 --- /dev/null +++ b/doc/releases/v29revs.rst @@ -0,0 +1,875 @@ +IRAF Version 2.9 Revisions Summary +================================== + +:Authors: IRAF Group +:Date: April 10, 1990 + +Introduction +------------ + +This document summarizes the changes in IRAF version 2.9. This was +primarily a development release intended to support applications +software development, hence the major changes were in the programming +environment, although there are important new features of interest to +general users too. Since IRAF V2.9 is primarily a development release, +it is not being released on all platforms, and it is expected that many +sites will not need to upgrade until IRAF V2.10 is available. Sites +interested in obtaining IRAF V2.9 should contact the IRAF project to +determine if the release is available for a particular host system. At +the present time, the release is being made available for all Sun +systems, for VAX/VMS, and for the DECstation running Ultrix. + +What follows is a brief description of some of the new features +available in IRAF Version 2.9. This is not intended to be an exhaustive +list, but rather a brief summary of the major changes since the last +release of IRAF, Version 2.8, released in July 1989. More detailed +revisions notes are available in the system notes file, +*iraf$local/notes.v29*, as well as in the online revisions notes for the +various packages. + +Users looking for information on a particular new package should note +that if the package is not mentioned in these release notes and +therefore is not included in IRAF V2.9, that does not necessarily mean +that it is not available. Most major reduction and analysis packages are +now made available for testing as user installable layered packages +before they are included in the standard distribution. For information +on the available add-on packages, contact the IRAF group, or check the +latest *IRAF Newsletter*. + +IRAF System Revisions +--------------------- + +IEEE to native floating point conversions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Support has been added to the programming interfaces (section 4.2.3) for +converting between the IEEE floating point and native floating point +data formats, including both single and double precision. The FITS +programs in DATAIO (section 3.1.1) make use of this, allowing floating +point data to be exchanged in FITS format without having to convert to +type integer. + +World coordinate system support +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A major new VOS interface MWCS has been added to support general world +coordinate systems (WCS) and transformations thereon (section 4.2.1). +This includes support for linear, piecewise linear or sampled WCS, and +general nonlinear WCS such as the tangent plane or gnomonic projection. + +If a FITS image is read into the system which has WCS information in the +header, the WCS will be retained in the IRAF image header and can be +used in coordinate transformations. The IMAGES tasks which move pixels +around have been modified to edit the WCS to reflect the transformation +(section 3.1.2). The image i/o system will automatically propagate the +WCS of an image to a new copy of the image, and will edit the WCS as +necessary if an image section is copied (this applies to all IRAF tasks +which operate upon images). The task RIMCURSOR in the LISTS package has +been rewritten to add support for coordinate transformations (section +3.1.3), and can be used, e.g., to read out the RA and DEC of objects on +the image display using the image cursor, if the image has the necessary +WCS information in the image header. + +Full integration of the new world coordinate facilities into all the +IRAF applications, e.g., the graphics tasks and the spectral reduction +packages, will take a year or longer due to the amount of software +involved. In V2.9 the IRAF spectral packages have not yet been converted +to use MWCS, and if MWCS is enabled it could alter the normal behavior +of these packages. *IRAF V2.9 is therefore shipped with MWCS disabled*. +What “disabled” means is that WCS information in the image headers is +not edited to reflect operations involving image sections, or geometric +transformations of images. Tasks such as RIMCURSOR which use an already +existing WCS will still work whether or not header editing is disabled. +If the spectral tasks will not be used and it is desired that world +coordinates be propagated correctly in image transformations, MWCS +header editing can be enabled in either of the following ways. + +The MWCS transformations are disabled by defining the variable +“*nomwcs*” in the IRAF environment. To globally enable MWCS by default +for everyone using the system, edit the file “*hlib$zzsetenv.def*” and +comment out the following line as shown (you want to add the leading +*#*, which will be missing in the distributed version): + +:: + + #set nomwcs = yes + +To enable MWCS header editing temporarily, for the current IRAF run: + +:: + + cl> reset nomwcs = no + +Detailed information on the coordinate systems defined by MWCS can be +obtained in the online system with the command + +:: + + cl> phelp mwcs$MWCS.hlp fi+ + +Additional information is also given in the help page for RIMCURSOR. + +IMFORT changes +~~~~~~~~~~~~~~ + + +The IMFORT interface (host level Fortran or C interface to the IRAF image +format) has undergone the following bug fixes and enhancements: + +- A couple of bugs associated with the IMDIR (image pixel-file + directory) feature introduced in IRAF V2.8 have been fixed. + +- Image clobber checking has been added. By default, if you create a + new image and another image with the same name already exists, the + image create will now return an error code leaving the existing image + unchanged. To override clobber checking in IMFORT programs, restoring + the previous behavior of the interface, define “*clobber*” in your + host environment. + +- IMFORT will now perform a limited filename translation service using + the IRAF VOS filename translation code. This should allow most IRAF + filenames to be used as input to host level IMFORT programs. Full VOS + filename mapping is not provided, but filenames containing upper case + characters and multiple “.” delimited fields should be translated as + in IRAF programs. + +On systems with multiple architecture support (e.g., Sun, Convex) the FC +task, used to compile and link IMFORT programs from within the IRAF +environment, is now a script rather than a simple foreign task front end +to XC. The purpose of the script is to see that all the necessary IRAF +and host level command line switches and environment definitions +(*IRAFARCH*, *FLOAT_OPTION*, etc.) are used. Previously, users had to +make these environment definitions manually, and if they forgot the +IMFORT program could fail to link or execute. + +- On most UNIX/IRAF systems, the host library *-lU77* is now searched + automatically by FC when an IMFORT program is linked. This library is + not used by any of the IRAF code, but is required to link some + Fortran programs that might want to use IMFORT. + +Users are encouraged to use FC to link their IMFORT programs. It is +possible to manually link against the IRAF libraries if you know what +you are doing, but the location of the libraries and the required host +level command line switches vary for different systems and for different +architectures of a single system, and it is easy to make mistakes. + +MKIRAF now copies login.cl to login.cl.OLD +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +On UNIX/IRAF systems, the MKIRAF command will now copy any existing +*login.cl* file to *login.cl.OLD*, so that, for example, you can more +easily merge any custom changes back in after running MKIRAF. On +VMS/IRAF systems a new file version is created, as before. + +Local additions to termcap/graphcap +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The termcap and graphcap device capability files have been reorganized +with a section at the top for local additions. It is recommended that +any locally added entries be made in this area, to simplify future +system updates. The local additions can then be simply transferred to +the new version of the file when a new version of IRAF is installed (any +entries which are modified versions of standard entries should always be +checked to see if anything has changed in the distributed version). + +BIN directories now smaller +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +On systems with multiple architecture support, the architecture save +file *OBJS.arc* stored in the BIN directory for each architecture is now +maintained as a compressed file. In a typical case this reduces the size +of the file by about a factor of two, saving 1-2 Mb of disk space in +each BIN directory. + +Various system buffers increased in size +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The layered software support in IRAF V2.8 (*extern.pkg* and all that) +had a problem with very long *helpdb* environment strings, limiting the +number of external packages which could be defined. To fix this problem, +various buffers were increased in size all over the system. The maximum +length of an environment variable such as *helpdb* is now 960 characters +(12 80 character lines of text). String parameters to tasks can also be +larger, and the system is more resistant to problems when size limits +are exceedd. Foreign task commands, OS escapes, etc., can all be larger +now. The current limit on such strings is about 1024 characters, and is +defined at sysgen time by the new system parameter *SZ_COMMAND* in +*hlib$iraf.h*. + +Shared library versions +~~~~~~~~~~~~~~~~~~~~~~~ + +The Sun/IRAF shared library mechanism was modified to add support for +shared library versions. The result is that when you install IRAF V2.9, +which has a different shared library than V2.8, any local programs or +other layered software linked under V2.8 will continue to run, because +both the old V2.8 shared library and the new V2.9 shared library are +included in V2.9 (with different version numbers). Although old programs +will continue to run with V2.9, it is recommended that they be relinked +eventually to take advantage of the many features and bug fixes provided +by V2.9. In the case of very large packages, e.g., STSDAS 1.0, it may be +wise to wait until the latest release can be obtained and installed +before relinking, as the old version will not have been tested under +IRAF V2.9 (which of course, didn’t exist back then). + +File pager enhancements +~~~~~~~~~~~~~~~~~~~~~~~ + +The system file pager, used in the PAGE task, the new PHELP task, and +other places, has undergone the following enhancements. + +- The N and P keys, used to move to the next or previous file when + paging a list of files, now have a dual meaning: when paging a + *single* file containing multiple formfeed delimited pages, the keys + will move to the next or previous *page* in the file. This feature is + used in the new PHELP task to page a large file containing, e.g., all + the HELP pages for a package. + +- A limited upscrolling capability is now supported, e.g., if you hit + the ‘k’ key while in the pager, the screen will be scrolled up one + line in the file being paged. This feature may not be supported for + some terminals, in which case the entire screen is redrawn at the new + file location. + +STF image kernel enhancements +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Extensive work has been done on the STF image kernel in this release +(the STF kernel allows IRAF to access the Space Telescope image format +directly). The changes included the following. + +- Header file caching. STF images often have quite large FITS headers + which can be time consuming to read. A header file caching scheme is + now used to optimize the kernel in cases where the same imagefile is + repeatedly accessed, e.g., when successively reading each element of + a large group format image. By default up to 3 header files will be + cached; this default should be fine for most applications. If + necessary the number of cache slots can be changed by defining the + integer variable “*stfcache*” in the IRAF environment (the builtin + maximum is 5 cached headers per process). + +*The semantics of the kernel regarding header updates have changed*. STF +images differ from other IRAF images in that they may consist of a group +of images all in the same file, with each individual image having its +own header (the group header), plus a single global FITS header shared +by all images in the group. This is no problem in a read operation, but +in a write or update operation there can be problems since parameters +cannot be added to or deleted from the individual group headers. The new +semantics regarding STF image header updates are as follows: 1) when +updating the header of a multigroup image (not recommended) only the +group header is updated, and attempts to add new parameters are ignored; +2) when updating the header of an image containing a single group, both +the group header and the FITS header are updated. + +As a result of these changes, the behavior of a single group STF image +is now identical to that of a regular IRAF image. It is recommended that +multigroup STF images be treated as read only if possible, creating only +single group images during interactive processing (except when running a +program that is explicitly designed to create multigroup images). + +- The kernel was modified to work with the new MWCS (world coordinate + system) interface. The image section transformation is now performed + by MWCS rather than by the STF kernel. + +- A number of minor changes were made to the way the group parameter + block (GPB) cards are maintained in the IRAF image descriptor. The + comments on GPB definition cards are now preserved. Restrictions on + the grouping of GPB cards in the header have been removed. + +- A number of bugs were fixed and restrictions removed, e.g., the size + of a header is no longer limited to 32767 characters (404 lines). + +The IRAF core system and NOAO science applications were extensively +tested with both single and multigroup STF images using the new kernel, +and we now feel that it is safe to use the STF image format with these +tasks, although the regular format is preferred if there is no special +reason to use the STF format (the regular format is more efficient). + +QPOE (event list image format) enhancements +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The QPOE image kernel, used for event list data (photon counting +detectors, e.g., X-ray satellites such as ROSAT) underwent the following +changes. + +- MWCS (world coordinate system) support has been added (section + 4.2.2). This provides a consistent coordinate system despite, e.g., + the blocking factor, rect, or image section used to construct an + image matrix from an event list. + +- When opening a QPOE file as an IRAF image, the runtime filter + expression used to create the image matrix is now saved in the + parameter *QPFILT*\ n\* in the image header (multiple cards are used + for long expressions). + +- Region masks of arbitrary complexity and size can now be used to mask + the event list when reading time-ordered or unordered (unindexed) + event lists. This is done using the new PLRIO package (section 4.2.5) + which provides the capability to efficiently random access large + image masks of arbitrary complexity. + +- Unmatched brackets, braces, or parentheses are now reported as an + error by the filter expression parser (this can occur even with a + valid expression, e.g., due to truncation of the expression string). + A reference to an undefined keyword, e.g., due to a spelling error, + is now detected and reported as an error. Any errors occurring during + expression parsing will now result in termination of the calling + task, unless caught in an error handler. + +- A number of bugs were fixed. + +Changes affecting image display in VMS/IRAF +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A new version of Nigel Sharp’s UISDISPLAY program, for image display on +VMS systems running UIS, has been installed in +“*iraf\ :math:`vms/uis*". An executable for an early version of the SAOIMAGE display program for the X window system, written by Mike VanHilst (SAO), and ported to VMS by Jay Travisano (STScI) has been placed in the directory "*iraf`\ vms/x11*”. +An executable for a VMS version of XTERM (the X window terminal +emulator, ported to VMS by Stephan Jansen), is also in this directory. +We wanted our VMS users to have access to these programs, although more +development work and testing is needed before we can offer good support +for X window based image display and graphics on VMS. A more +comprehensive package providing enhanced capabilities should be +available as an add-on later this year. + +IRAF Package Revisions +---------------------- + +The most notable changes to the tasks in the IRAF packages are +summarized below. Further information may be obtained by reading the +help page for each task, or by paging the revisions file for a +particular package. For example, to page the revisions for the DATAIO +package: + +:: + + cl> phelp dataio.revisions op=sys + +Changes to the System Packages +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Modifications to tasks in the DATAIO package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- The RFITS and WFITS tasks have been modified to add support for the + IEEE floating point format. The “bitpix” parameter in WFITS can be + set to -32 or -64 to specify real or double precision IEEE floating + numbers on output. RFITS recognizes these same values in the bitpix + keyword in the FITS header on input and converts the data + accordingly. Note that this option must be selected by the user as + the defaults for writing a FITS tape have not changed. The user is + cautioned that support for the IEEE floating formats is a new feature + of FITS and may not be supported by all FITS readers. + +- RFITS was modified so that the “iraf_file” parameter can be a list of + output images or a image root name. + +Modifications to tasks in the IMAGES package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- MWCS (world coordinate system) support was added to those tasks in + the IMAGES package which change the geometry of an image, i.e., + IMSHIFT, SHIFTLINES, MAGNIFY, IMTRANSPOSE, IMCOPY, BLKREP, BLKAVG, + ROTATE, IMLINTRAN, REGISTER, and GEOTRAN (REGISTER and GEOTRAN only + support simple linear transformations). If one of these tasks is used + to linearly transform an image, the world coordinate system (WCS) in + the image header will be updated to reflect the transformation. Note + that MWCS is disabled by default in IRAF V2.9, and must be explicitly + enabled to allow these tasks to edit the image header to update the + WCS (see section 2.2). + +- The IMSTATISTICS task was modified. The “verbose” parameter was + renamed “format” with the default being set to “yes” (fixed format + with column labels). Otherwise the fields are printed in free format + with 2 blanks separating the fields. The name of the median field has + been changed to “midpt”. + +- The IMHISTOGRAM task has a new parameter called “hist_type” that + gives the user the option of plotting the integral, first derivative, + or second derivative of the histogram instead of the normal + histogram. + +Modifications to tasks in the LISTS package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- The RIMCURSOR task in the LISTS package was completely rewritten to + add MWCS support, so that coordinates may be output in any user + specified coordinate system defined by the WCS information in the + image header of the reference image. For example, if an image with a + TAN projection WCS is loaded into the image display, RIMCURSOR may be + used to print the right ascension and declination at the location + defined by the image cursor. Refer to the help page for details. + +Modifications to tasks in the PLOT package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- A new graphics kernel task IMDKERN (written by Zolt Levay at STScI) + has been added to the PLOT package. The new graphics kernel allows + the graphics output of any task to be plotted as a graphics overlay + on the image display. As with the other graphics kernels, this may be + done by calling the IMDKERN task directly, but is more often done by + specifying the image display (e.g., device “*imd*”) as the output + device when running a graphics task. Refer to the help page for + details. + +- The CONTOUR task was modified so that it could be used with IMDKERN + to overlay contour plots on the image display. If the parameters + *fill=yes* and *perimeter=no* are set the contour plot is scaled to + fill the entire device viewport and all axis and plot labeling is + disabled. If the image being displayed also fills the entire device + viewport (display frame) then the contour plot will be drawn to the + same scale as the displayed image. Refer to the help page for + details. + +- Several tasks in the PLOT package were modified to allow use with + image specifications containing brackets, e.g., group format images, + QPOE filter expressions, and image sections. The tasks modified were + PROW, PROWS, PCOL, PCOLS, SURFACE, and CONTOUR. + +- An option was added to the PVECTOR task to output the vector (cut + through the image at an arbitrary angle and center) as a text file or + image, rather than plotting the vector. + +Modifications to tasks in the SYSTEM package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- A new task PHELP (paged help) was added to the SYSTEM package. PHELP + is a script task front end to HELP which collects the output of HELP + in a scratch file and pages it with the system pager, allowing one to + randomly skip around to read the help text. Note that paging of all + the help pages in a package is supported, e.g., + + :: + + cl> phelp images.* + + would page all the help files for the IMAGES package. + +- The NEWS task was completely rewritten, and is now used to page the + revisions summary for the current and previous releases. In other + words, one can now type NEWS to find out what is new in the current + release. + +- The GRIPES task was modified to send mail to *iraf@noao.edu* or + *5355::iraf*. The IRAF site administrator may want to check this + script for compatibility with the local mail system. + +Glossary of New Tasks in the IRAF System Packages +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ++------------+---------------------+-----------------------------------+ +| Task | Package | Description | ++============+=====================+===================================+ +| imdkern | plot | Image display device (IMD) | +| | | graphics kernel | ++------------+---------------------+-----------------------------------+ +| news | system | Summarize what is new in the | +| | | current release | ++------------+---------------------+-----------------------------------+ +| phelp | system | Paged HELP: collects and pages | +| | | the output of HELP | ++------------+---------------------+-----------------------------------+ +| rimcursor | lists | Read image cursor position in | +| | | world coordinates | ++------------+---------------------+-----------------------------------+ + +Changes to the NOAO Packages +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +New NOAO Packages +^^^^^^^^^^^^^^^^^ + +A new package ARTDATA, used to generate artificial data, has been added +to the NOAO packages. ARTDATA includes tasks for the generation of star +fields, optionally containing galaxies, and one and two dimensional +spectra as well as simple test pattern images. The tasks GALLIST and +STARLIST provide many options for producing lists of galaxies or stars +that can then be used by the task MKOBJECTS to produce output images. +The tasks MK1DSPEC and MK2DSPEC provide tools for making artificial +spectral data. The task MKNOISE allows the user to add readout noise, +poisson noise and/or cosmic ray events to new or already existing +images. The task MKPATTERN allows the user to make images from a choice +of patterns. + +Modifications to Existing NOAO Packages +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ASTUTIL package +''''''''''''''''''' + +- The task SETAIRMASS in the ASTUTIL package was modified so that it + now processes the coordinates to the epoch of the observation. + +The DIGIPHOT.APPHOT package +''''''''''''''''''''''''''' + +- A new task APTEST was added to the DIGIPHOT.APPHOT package that tests + the execution of the package. Output files are generated that the + user can review. + +- Two new parameters were added to DATAPARS, “datamin” and “datamax”. + Pixels outside this range are rejected from the sky fitting + algorithms and from the non-linear least square fits in FITPSF and + RADPROF. + +- An “update” parameter was added to all of the APPHOT tasks. If the + “verify” parameter is set to “yes” and the task is run in + non-interactive mode *update=yes* will update the critical parameters + in their respective parameter sets. + +- Four new parameters, “airmass”, “xairmass”, “filter”, and “ifilter”, + were added to the DATAPARS task. These parameters provide the user + the option of having the filter and airmass quantities from the image + headers to be carried over into the APPHOT database files for later + transmission to calibration programs. + +- A new algorithm “mean” was added to the sky fitting options. + +- A setup menu mode was added to all the APPHOT tasks. When the user + types “i” in interactive mode a setup menu is presented rather than a + fixed set of predefined commands. + +The IMRED.IRRED package +''''''''''''''''''''''' + +- The APSELECT task (from the APPHOT package) has been made visible. + +- The image i/o for IRMOSAIC, IRALIGN, IRMATCH1D, and IRMATCH2D has + been optimized so things should run much faster. There is now an + option to trim each section before insertion into the output image. + The actions of these tasks can now optionally be output to the + terminal. + +The IMRED.MSRED package +''''''''''''''''''''''' + +- A task called MSBPLOT was added to the IMRED.MSRED package. This task + allows the user to plot a range of lines in multispec images in batch + mode. + +The ONEDSPEC package +'''''''''''''''''''' + +- Several modifications were made to the ONEDSPEC package. These + changes affect all of the IMRED packages that include these tasks as + well. + +- The equivalent width measurement using the “e” keystroke in SPLOT is + now computed using the ratio of the spectrum to the continuum. The + previous approximation is included in the logfile for comparison. + +- The DISPERSION task will now add CD\ *i*\ \_\ *j* (CD matrix) + keywords to the image header as an alternative way of expressing the + dispersion function. If the keywords W0 and WPC or CRVALn and CDELTn + are not in the image header the tasks reading this information for + setting the wavelength (IDENTIFY, SENSFUNC, SPLOT, and SPECPLOT) will + look for the CD\ *i*\ \_\ *j* keywords. This change should have no + affect on the NOAO applications but provides compatibility with + STSDAS applications using the new MWCS interface provided with IRAF + version 2.9. + +- The call to the CALIBRATE task in the script task BATCHRED was + modified so that the “extinct” parameter is always set to “yes”. + Since CALIBRATE checks to be sure the data has not been previously + extinction corrected this simple change provides more flexibility. + +The PROTO package +''''''''''''''''' + +- Two new tasks, IMALIGN and IMCENTROID, were added to the package. + IMCENTROID computes a set of relative shifts required to register a + set of images. The task IMALIGN both computes the shifts and aligns + the images. + +- The JOIN task (previously a simple script) has been replaced by a + compiled version which removes many of the restrictions of the + previous version. + +- The IR tasks have been modified as mentioned above under the + IMRED.IRRED section (section 3.3.2.3). + +- The TVMARK task was modified to permit deletion (the “u” key) as well + as addition of objects to the coordinate file. Another cursor + keystroke, the “f” key, was added allowing the user to draw a filled + rectangle. + +The TWODSPEC.LONGSLIT package +''''''''''''''''''''''''''''' + +- Tasks in the TWODSPEC.LONGSLIT package that are used for setting + wavelength information (EXTINCTION, FLUXCALIB, and TRANSFORM) were + modified for the CD\ *i_j* keywords as outlined above for ONEDSPEC. + +Modifications and Additions to Calibration Data +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The calibration data used by some of the tasks in the TWODSPEC, +ONEDSPEC, and many of the IMRED packages are kept in a directory called +ONEDSTDS in *noao$lib*. The current contents of this directory are best +summarized by paging through its README file, e.g., + +:: + + cl> page noao$lib/onedstds/README + +A new directory *spec50redcal* in “*noao$lib/onedstds*” has been added +containing flux information for standard stars. The data in this list +are from Massey and Gronwall, Ap. J., July 20, 1990. + +Glossary of New Tasks in the NOAO Packages +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ++------------+---------------------+-----------------------------------+ +| Task | Package | Description | ++============+=====================+===================================+ +| aptest | apphot | Run basic tests on the apphot | +| | | package tasks | ++------------+---------------------+-----------------------------------+ +| gallist | artdata | Make an artificial galaxies list | ++------------+---------------------+-----------------------------------+ +| imalign | proto | Register and shift a list of | +| | | images | ++------------+---------------------+-----------------------------------+ +| imcentroid | proto | Compute relative shifts for a | +| | | list of images | ++------------+---------------------+-----------------------------------+ +| mk1dspec | artdata | Make/add artificial 1D spectra | ++------------+---------------------+-----------------------------------+ +| mk2dspec | artdata | Make/add artificial 2D spectra | ++------------+---------------------+-----------------------------------+ +| mknoise | artdata | Make/add noise and cosmic rays to | +| | | 1D/2D images | ++------------+---------------------+-----------------------------------+ +| mkobjects | artdata | Make/add artificial stars and | +| | | galaxies to 2D images | ++------------+---------------------+-----------------------------------+ +| mkpattern | artdata | Make/add patterns to images | ++------------+---------------------+-----------------------------------+ +| msbplot | msred | Batch plots of multispec spectra | +| | | using SPLOT | ++------------+---------------------+-----------------------------------+ +| starlist | artdata | Make an artificial star list | ++------------+---------------------+-----------------------------------+ + +Programming Environment Revisions +--------------------------------- + +Changes to the Programming Utilities +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +MKPKG changes +^^^^^^^^^^^^^ + +The MKPKG utility can now substitute the contents of a file back into +the input stream, as a special case of the macro replacement syntax. For +example, the sequence + +:: + + abc$(@file)def + +would be translated as + +:: + + abc10def + +if the file “*file*” contained the string “10”. The replacement is +performed by inserting the contents of the file back into the input +stream, replacing sequences of newlines, spaces, or tabs by a single +space, and omitting any trailing whitespace. + +The “-p ” argument to MKPKG, XC, and so on loads the environment of the +named package *pkg*, to define the package environment variables, load +the mkpkg special file list, define the directories to be searched for +global include files and libraries, and so on. Multiple “-p” arguments +may be given to load multiple package environments. What is new is that +if *pkglibs* is defined in the environment of a package to list the +package library directories to be searched (the usual case), and +multiple package environments are loaded, successive redefinitions of +*pkglibs* will *add* to the list of directories to be searched, rather +than redefining the old list as each new package environment is loaded. +For example, if two package environments are loaded, and each defines +its own library, both libraries will be searched. + +Generic preprocessor +^^^^^^^^^^^^^^^^^^^^ + +A minor change was made to the generic preprocessor which affects how +strings such as “FOO_PIXEL” are translated. In the usual case, the +preprocessor replaces all occurrences of “PIXEL” by “int”, “real”, or +whatever the actual datatype is. The translation is now context +sensitive. Rather than translating “FOO_PIXEL” as “FOO_int” (e.g., +“MII_PIXEL” -> “MII_int”), the type name will now be output in upper +case if the rest of the name in which it occurs is upper case. Hence, a +string such as “MII_PIXEL” will now be translated as “MII_INT”. This +allows the use of generic constructs to symbolize SPP macros. + +SPP changes +^^^^^^^^^^^ + +The language constant ARB, formerly defined as 32767, is now treated +differently depending upon how it is used. In a declaration of an array +argument, ARB is replaced in the output Fortran by a “*”, e.g., ”*\ int +data[ARB]\ *” becomes ”*\ INTEGER DATA(*)*”. In an executable statement, +ARB is replaced by a very large (“arbitrarily” large) integer value, +e.g., to define a DO-loop which is to loop an arbitrary number of times. +If ARB is mistakenly used to dimension an array which is a local +variable rather than an argument, the SPP translator will now detect and +report the error. + +Interactive development and the process cache +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Whenever a CL task is run and the process containing the task is already +idling in the CL process cache, the CL will now check to see if the +modify date on the process executable has changed, and restart the +process if the executable has been modified. For example, when doing +software development from within the CL and a process is alternately +relinked and tested, the CL will now automatically detect that the +process has been relinked and will run the new process, without any need +to manually flush the process cache. + +Programming Interface Changes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +New MWCS interface (world coordinate system support) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A major new VOS interface MWCS, providing general facilities for linear +and nonlinear world coordinate systems, has been added to the +programming environment and is used in IRAF V2.9 in IMIO, IMAGES, and +other parts of the system. MWCS is intended for use in scientific +applications as well as in system code such as IMIO, hence is of +potential interest to anyone developing software within the IRAF +environment. The source directory is “*mwcs*” and the interface is +documented in the file “*mwcs$MWCS.hlp*”. Users should be aware that, +although the new interface addresses the general WCS problem and has +been carefully designed, a second version of the interface is planned +and the current interface is not yet a “frozen” interface. + +QPOE interface changes +^^^^^^^^^^^^^^^^^^^^^^ + +The QPOE (event list image) interface has been extended to add routines to +store MWCS objects in the QPOE header. By default, there is one MWCS per +QPOE file, stored encoded in a machine independent binary format in a +variable length array *qpwcs* of type *opaque*. The new routines are as +follows: + +:: + + mw = qp_loadwcs (qp) + qp_savewcs (qp, mw) + mw = qpio_loadwcs (io) + +The routines *qp_savewcs* and *qp_loadwcs* merely save a MWCS in the +QPOE header, or load a previously saved one. The QPIO (event i/o) +routine *qpio_loadwcs* is like *qp_loadwcs*, except that it will also +modify the Lterm of the MWCS to reflect any blocking factor or “rect” +specified in the filtering expression when the event list was opened. +The new routine is called automatically by QPF and IMIO whenever a QPOE +event list is opened under image i/o, making the physical coordinate +system of the image matrix the same as physical event coordinates. + +The calling sequences of the *qp_add* and *qp_astr* routines, used to +conditionally add or update header parameters, have been changed (so far +as we could determine very few programs exist yet which use these +routines, so we decided to risk an interface change). The change made +was to add a *comment* argument. This change was motivated by the +observation that people would not use the routines but would instead use +lower level routines, in order to be able to set the comment field if +the parameter has to be added to the header. + +IEEE support routines added +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Routines for IEEE floating to native floating conversions have been added to +the MII and OSB interfaces. The new MII routines are as follows: + +:: + + nelem = miiread[rd] (fd, spp, maxelem) + miiwrite[rd] (fd, spp, nelem) + miipak[rd] (spp, mii, nelems, spp_datatype) + miiupk[rd] (mii, spp, nelems, spp_datatype) + +The *miiread* and *miiwrite* routines are like their FIO counterparts, +except that they are used only with data of the indicated type, and +perform the IEEE to native floating conversion (or vice versa) as part +of the i/o operation. The *miipak* and *miiupk* routines pack +(native->IEEE) and unpack (IEEE->native) arrays of the indicated type. + +The lowest level conversion routines are the OSB routines, which are +what the MII routines use to perform the lowest level translation. + +:: + + ieepak[rd] (datum) + ieeupk[rd] (datum) + ieevpak[rd] (native, ieee, nelem) + ieevupk[rd] (ieee, native, nelem) + iee[sg]nan[rd] (NaN) + +The *ieepak* and *ieeupk* routines transform a single scalar value in +place, while the *ieevpak* and *ieevupk* routines transform vectors +(note that the package prefix is “iee”, not “ieee”). In-place vector +conversions are permitted. Since IRAF does not support the IEEE +not-a-number formats, *NaN*, *Inf* etc. values are converted to a legal +native floating value on input. The native floating value to which +*NaN*\ s are mapped (default zero) may be globally set with *ieesnan*. + +On some systems, e.g., the VAX, the low level conversion routines may be +written in assembler or machine dependent C. If so, the source file +actually used by the system will be found in the “*host$as*” directory. + +New routine GETLLINE added to FIO +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A new routine *getlline* (get long line) has been added to FIO. This is +similar to *getline*, except that it will reconstruct arbitrarily long +newline delimited lines of text, whereas *getline* returns at most +SZ_LINE characters. + +:: + + nchars = getlline (fd, outstr, maxch) + +The new routine should not be confused with the old routine +*getlongline*, a higher level routine which performs a similar function, +but which also ignores comment lines and help blocks, and maintains a +line counter. + +Modifications to PLIO/PMIO +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A new routine \*p[lm]_sectnotconst\* has been added to PLIO and PMIO +(the pixel list and image mask interfaces). As the name suggests, the +routine tests whether a given rectangular section of the mask is all at +the same value, and if so returns the mask value as an output argument. + +:: + + bool = pl_sectnotconst (pl_src, v1, v2, ndim, mval) + +A new subpackage PLRIO has been added. This is used to efficiently +random access any 2D plane of an existing pixel list or image mask. + +:: + + plr = plr_open (pl, plane, buflimit) + plr_setrect (plr, x1,y1, x2,y2) + mval = plr_getpix (plr, x, y) + plr_getlut (plr, bufp, xsize,ysize, xblock,yblock) + plr_close (plr) + +The mask is opened for random access on a special descriptor which +incorporates a scaled, active 2D lookup table. Most subsequent +*plr_getpix* calls will return the given mask value directly from the +table with very little overhead; only if the referenced pixel occurs in +a region too complex to be described by a single table entry is the +value computed by direct evaluation of the mask. A special 2D binary +recursive algorithm (using *pl_sectnotconst* above) with log2(N) +performance is used to calculate the scaled lookup table. These +algorithms provide efficient table generation and random mask pixel +access even for very large masks. From 7c65e0e434f927625f2444b7bd7fae822f75da6d Mon Sep 17 00:00:00 2001 From: Ole Streicher Date: Fri, 10 Mar 2023 11:33:02 +0100 Subject: [PATCH 2/2] Add IRAF logo --- doc/README | 3 ++- doc/logo.svg | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+), 1 deletion(-) create mode 100644 doc/logo.svg diff --git a/doc/README b/doc/README index 77fcef3be..a97d4509a 100644 --- a/doc/README +++ b/doc/README @@ -10,4 +10,5 @@ system as a whole. paspconf.sty, iraf92f3.eps, iraf92.tex IRAF in the Nineties (paper) (1992) - releases IRAF release notes \ No newline at end of file + logo.svg IRAF logo (1987) + releases IRAF release notes diff --git a/doc/logo.svg b/doc/logo.svg new file mode 100644 index 000000000..14700d523 --- /dev/null +++ b/doc/logo.svg @@ -0,0 +1,54 @@ + + + IRAF logo + + + + image/svg+xml + + IRAF logo + 1987 + + + Clark Enterline, NOAO + + + + + National Optical Astronomy Observatory + + + IRAF newsletter #2, September 1987 + + + + + + + + + + + + + + +