diff options
Diffstat (limited to 'doc/newsfile')
| -rw-r--r-- | doc/newsfile | 8008 |
1 files changed, 8008 insertions, 0 deletions
diff --git a/doc/newsfile b/doc/newsfile new file mode 100644 index 00000000..51a19e99 --- /dev/null +++ b/doc/newsfile @@ -0,0 +1,8008 @@ + +IRAF (Mar02) V2.12EXPORT Release Notes IRAF (Mar02) + + + IRAF V2.12EXPORT Release Notes + January 25, 2002 + Updated: March 25, 2002 + + +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. + + 1. Highlights of This Release + 2. IRAF System Revisions Summary + 3. Core IRAF Revisions Summary + 3.1 New Tasks + 3.2 Existing tasks with new parameters/defaults + 3.3 Existing tasks with new capabilities + 4. NOAO Package Revisions Summary + 4.1 New NOAO Packages + 4.2 New NOAO Package Tasks + 4.3 Existing tasks with new parameters/defaults + 4.4 Existing tasks with new capabilities + 5. General Package Changes + 6. General Task Changes + 7. Parameter File Changes + 8. Details of Major System Changes + 8.1 FITS Kernel Changes + 8.2 Large Image Support + 8.3 Virtual Memory Cache + 8.4 New Developer libraries + 9. System Changes Which May Affect You + 9.1 Shared Library Version Incremented + 9.2 External Package Recompilation + 9.3 Parameter File Changes + 9.4 Installation Script Changes + 9.5 Help System Changes + 9.6 Image Display Changes + 9.7 PLIO Changes + 9.8 New Environment Variables Changes + + + + +1. Highlights of This Release + + o 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. + + o New Pixel Mask Tasks + Several new tasks have been added to the system PROTO package for + manipulating pixel masks: + + o MIMSTATISTICS allows image statistics to be computed while + rejecting pixels specified by an input mask. + o 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. + o MSKREGIONS creates an output mask based on an input text de- + scription. Region descriptions can be composed of geometric + shapes and logical operation on mask regions. + + o 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. + + o 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. + + o 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. + + o 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. + + o 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. + + o 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. + + o 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. + + o 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. + + + + +2. IRAF System Revisions Summary + + o 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. + + o The maximum number of nodes in a local iraf network was increased + from 320 to 512. + + o 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. + + o 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. + + o 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. + + o 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. + + o 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. + + o The 'imextn' environment variable will now accept upper-case extensions + to specify image types. + + o 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. + + o 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. + + o 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). + + o 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 + + + +3. CORE IRAF REVISIONS SUMMARY + + + +3.1 New Tasks + imcoords.ccget - extract objects from a test file catalog + imcoords.ccstd - transform to and from standard astrometric coordinates +proto.mimstatistics - do image statistics through a mask + proto.rskysub - sky subtract images using running mean or median + proto.mskexpr - general mask expression evaluator + proto.mskregions - create a mask from a list of region specifications + + + +3.2 Existing Tasks with New Parameters or New Parameter Defaults + immatch.imcentroid - new parameter maxshift + immatch.imalign - new parameter maxshift + immatch.geomap - new parameter maxiter, default reject = 3.0 not INDEF + imcoords.ccmap - new parameter maxiter, default reject = 3.0 not INDEF + imcoords.imcctran - new parameter longpole + imutil.hedit - new parameter addonly +imutil.imstatistics - new parameters nclip, lsigma, usigma, cache + + + +3.3 Existing Tasks with New Capabilities + immatch.imcentroid - optionally rejects objects whose centers wander too much + immatch.imalign - optionally rejects objects whose centers wander too much + immatch.geomap - iterative rejection capability added + imcoords.ccmap - iterative rejection capability added + imcoords.imcctran - support for non-zenithal projections added + imutil.hedit - support for add keyword only if new option +imutil.imstatistics - support for iterative rejection and memory caching added + imutil.imexpr - support for bitwise operators or, and, xor, and not added + + + + +4. NOAO PACKAGE REVISIONS SUMMARY + + + +4.1 New NOAO Packages + astcat - Astronomical catalog and surveys access package + crutil - Cosmic ray detection and removal package + obsutil - Observing utilities package + + + +4.2 New NOAO Package Tasks + apphot.pcalc - Do arithmetic operations on a list of apphot databases + apphot.pconvert - Convert a text database to a tables database + apphot.pdump - Print selected fields from a list of apphot databases + apphot.pexamine - Interactively examine and edit an apphot database + apphot.prenumber - Renumber stars in an apphot database + apphot.pselect - Select records from an apphot database + apphot.psort - Sort an apphot database + + astcat.aclist - List the supported astrometric catalogs + astcat.agetcat - Extract astrometry files from astrometric catalogs + astcat.afiltcat - Filter astrometry files derived from astrometric catalogs + astcat.adumpcat - Catalog access debugging task + astcat.aslist - List the supported image surveys + astcat.agetim - Extract FITS images from image surveys + astcat.ahedit - Initialize the image wcs and set standard keywords + astcat.aimfind - Select images containing catalog objects + astcat.adumpim - Image survey access debugging task + astcat.aregpars - Default region parameter set + astcat.acatpars - Default astrometry file format parameter set + astcat.afiltpars - Default astrometry file filtering parameters + astcat.aimpars - Default image data parameters + astcat.awcspars - Default image wcs parameters + + crutil.cosmicrays - Remove cosmic rays using flux ratio algorithm + crutil.craverage - Detect CRs against average and avoid objects + crutil.crcombine - Combine multiple exposures to eliminate cosmic rays + crutil.credit - Interactively edit cosmic rays using an image display + crutil.crfix - Fix cosmic rays in images using cosmic ray masks + crutil.crgrow - Grow cosmic rays in cosmic ray masks + crutil.crmedian - Detect and replace cosmic rays with median filter + crutil.crnebula - Detect and replace cosmic rays in nebular data + +obsutil.psfmeasure - Measure PSF sizes from stellar images + obsutil.specfocus - Determine spectral focus and alignment variations + obsutil.starfocus - Determine direct focus variations from stellar images + obsutil.ccdtime - CCD photometry exposure time calculator + obsutil.pairmass - Plot airmass vs time for a given coordinate + obsutil.sptime - Spectroscopic exposure time calculator + obsutil.specpars - Spectrograph instrument parameters for sptime + obsutil.bitcount - Accumulate the bit statistics for a list of images + obsutil.findgain - Estimate the gain and readnoise of a CCD + obsutil.shutcor - Shutter correction from images of varying exposure times + + nproto.objmasks - detect and catalog objects in image + + + +4.3 Existing Packages and Tasks with New Parameters or New Parameter Defaults + apphot - new package parameters wcsin, wcsout, and cache + apphot.center - new parameters wcsin, wcsout, cache + apphot.daofind - new parameters wcsout, cache + apphot.fitpsf - new parameters wcsin, wcsout, cache + apphot.fitsky - new parameters wcsin, wcsout, cache + apphot.phot - new parameters wcsin, wcsout, cache + apphot.polymark - new parameters wcsin, wcsout, cache + apphot.polyphot - new parameters wcsin, wcsout, cache + apphot.qphot - new parameters wcsin, wcsout, cache + apphot.radprof - new parameters wcsin, wcsout, cache + apphot.wphot - new parameters wcsin, wcsout, cache + apphot.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 + daophot.addstar - new parameters wcsin, wcsout, wcspsf, and cache + daophot.allstar - new parameters wcsin, wcsout, and wcspsf + daophot.daoedit - new parameters cache + daophot.daofind - new parameters wcsout, and cache + daophot.group - new parameters wcsin, wcsout, wcspsf, and cache + daophot.nstar - new parameters wcsin, wcsout, wcspsf, and cache + daophot.peak - new parameters wcsin, wcsout, wcspsf, and cache + daophot.phot - new parameters wcsin, wcsout, and cache + daophot.psf - new parameters wcsin, wcsout, and cache + daophot.substar - new parameters wcsin, wcsout, and cache + + + +4.4 Existing Tasks with New Capabilities + apphot.center - coordinate system support, optional image cacheing + apphot.daofind - coordinate system support, optional image cacheing + apphot.fitpsf - coordinate system support, optional image cacheing + apphot.fitsky - coordinate system support, optional image cacheing + apphot.phot - coordinate system support, optional image cacheing + apphot.polymark - coordinate system support, optional image cacheing + apphot.polyphot - coordinate system support, optional image cacheing + apphot.qphot - coordinate system support, optional image cacheing + apphot.radprof - coordinate system support, optional image cacheing + apphot.wphot - coordinate system support, optional image cacheing + +astutil.setairmass - ra, dec, equinox, st, ut, scale are no longer hardwired + astutil.rvcorrect - more flexibility in setting ut + + daophot.addstar - coordinate system support, optional image cacheing + daophot.allstar - coordinate system support + daophot.daoedit - optional image cacheing + daophot.daofind - coordinate system support, optional image cacheing + daophot.group - coordinate system support, optional image cacheing + daophot.nstar - coordinate system support, optional image cacheing + daophot.peak - coordinate system support, optional image cacheing + daophot.phot - coordinate system support, optional image cacheing + daophot.psf - coordinate system support, optional image cacheing + daophot.substar - coordinate system support, optional image cacheing + + + + +5. 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 mod- + ified 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 + o Added tasks OIMCOMBINE and OIMSTATISTICS which are the previous + versions from V2.113b system + o Deleted the ODISPLAY task + + + + +6. General Task Changes + +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 ext- + ernally 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 <value>" 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 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 interative 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 ben 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. + + + + +7. 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 + 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 + 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 boolen (yes/no) to + string (none,half,full). + +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 + 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. + + + + + +8. Details of Major System Changes + + + +8.1 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: + + http://heasarc.gsfc.nasa.gov + /docs/software/fitsio/compression/compress_image.html + + 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. + + + + +8.2 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). + + + +8.3 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 prority 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. + + + + +8.4 New Developer Libraries + + o 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$ypix" + or "dev$ypix world". + + + + +9. 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 + 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. + + IRAF (Aug97) V2.11 Revisions Summary IRAF (Aug97) + + + + IRAF V2.11 Revisions Summary + August 27, 1997 + +Introduction + + 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. + + 1. Things to be aware of or watch out for + 1.1. Parameter file changes + 1.2. Networking change + 1.3. Image format change + 1.4. FITS kernel + 1.5. RFITS/wfits changes + 1.6. Merged SunOS and Solaris IRAF systems + 1.7. Tape access + 1.8. Default magnitude zero changed + + 2. IMAGES package changes + + 3. Major system changes + 3.1. New FITS image kernel (FXF) + 3.2. Changes to the IRAF native image format (OIF) + 3.3. IMFORT changes + 3.4. Environment variables + 3.5. New intrinsic functions + 3.6. System default modifications + 3.7. Libraries added + 3.8. Graphics changes + 3.9. FITS-related core-level task changes + 3.10. General changes + + 4. New tasks, or old tasks moved to new packages + + 5. Task and package deletions + + 6. Modifications to old tasks + + 7. Parameter file changes + + +The IRAF V2.11 release notes can also be found online on the Internet at +the URL http://iraf.noao.edu/v211revs.html. + + +1. Things to be aware of or watch out for + + +1.1 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. + + +1.2 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!" + + +1.3 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. + + +1.4 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. + + +1.5 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. + + +1.6 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). + + +1.7 Tape access + +The "tapecap" mechanism has changed. The system now looks for the +filename "tapecap.<node>" followed by the default "tapecap". <node>: +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. + + +1.8 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. + + +2. 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. + + +3. Major system changes + + +3.1 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. + + +3.2 Changes to the IRAF native image format (OIF) + + o 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. + + o 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. + + o 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). + + o 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. + + +3.3 IMFORT changes + + o 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. + + o Image headers can now be any size (the old IMFORT had a fixed, relatively + low, limit on the image header size). + + o 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. + + +3.4 Environment variables + +Several new environment variable have been added to the system. + + o 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. + + o 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. + + o 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. + + o 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. + + +3.5 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")). + + +3.6 System default modifications + + o 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. + + o The maximum number of open IRAF logical files was increased from 128 to + 256. This is good news for imcombine users. + + o 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. + + +3.7 Libraries added + +The Starlink positional astronomy library SLALIB was added to the math +package. + + +3.8 Graphics changes + + o SGI Translator change: Modified the header ID string produced by + sgi2uapl to be "%!PS", this is required by certain models of printers. + + o Installed graphcap support for the STSDAS PostScript graphics kernel. + + o 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 "\fG" escape sequence when you use the "T" keystroke to mark text + in a plot, e.g., \fGa Hydra 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. + + +3.9 FITS-related core-level task changes + + +3.9.1 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. + + +3.9.2 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. + + +3.9.3 rfits/wfits + +Some changes were also implemented in rfits and wfits to add support +for multi-extension FITS files. + + o 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. + + o 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. + + +3.10 General changes + + o 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. + + o 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 supercedes 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) + + o 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. + + +4. 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. + + +5. 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. + + +6. 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 chosing 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 the meaning of the parameter especially + with regard the mergerad parameter. The behavior of the parameter is + unchanged. (V2.10.4p2) + + +7. 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 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) + IRAF (Jul92) V2.10 Revisions Summary IRAF (Jul92) + + + IRAF Version 2.10 Revisions Summary + July 1992 + + + + +1. 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. + +This revisions summary is organized as follows: + + 1. Introduction + + 2. IRAF System Revisions + + 3. IRAF and NOAO Package Revisions + 3.1. Changes to the System Packages + 3.2. Changes to the NOAO Packages + + 4. Programming Environment Revisions + 4.1. Compatibility Issues + 4.2. Portability Issues + 4.3. Software Tools + 4.4. Programming Interface Changes + + 5. Getting Copies of this Revisions Summary + +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. + + + +2. IRAF System Revisions + + +2.1 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. + + +2.1.1 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. + + o 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. + + o 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. + + o 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). + + o 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. + + o 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. + + o 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. + + +2.1.2 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. + + + +2.2 CL Enhancements + + +2.2.1 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. + + +2.2.2 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. + + +2.2.3 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). + + +2.2.4 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. + + + +2.3 System Management Related Changes + + +2.3.1 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. + + +2.3.2 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. + + +2.3.3 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. + + +2.3.4 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). + + + +2.4 Networking Enhancements + + +2.4.1 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. + + +2.4.1.1 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. + + +2.4.1.2 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 : <user> ? + * : <user> <user> + + +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 "<user>" +the user name on the client node is used for login authentication on +the remote node. Setting the password to "<user>" 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. + + +2.4.1.3 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. + + +2.4.2 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. + +o 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. + +o 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. + + + +2.5 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. + + +2.5.1 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. + + +2.5.1.1 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. + + +2.5.1.2 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. + + +2.5.1.3 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. + + +2.5.1.4 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. + + +2.5.1.5 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. + + +2.5.2 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. + + +2.5.2.1 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". + + +2.5.2.2 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). + + +2.5.3 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. + + +2.5.3.1 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 = [tapecap-file] [`:' capabilities-list] + +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. + + +2.5.3.2 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". + + +2.5.3.3 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. + + +2.5.4 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.) + + +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. + + +2.5.5 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. + + +2.5.6 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. + + +2.5.7 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. + + + +2.6 Graphics and Imaging Subsystem Enhancements + + +2.6.1 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. + + +2.6.2 Graphics system changes + + +2.6.2.1 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. + + +2.6.2.2 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). + + +2.6.2.3 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. + + +2.6.2.4 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. + + +2.6.2.5 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). + + +2.6.2.6 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. + + +2.6.2.7 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. + + + +2.7 Image Structures + + +2.7.1 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. + + +2.7.1.1 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. + + +2.7.1.2 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. + + +2.7.1.3 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). + + +2.7.1.4 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). + + +2.7.2 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. + + +2.7.2.1 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. + + +2.7.2.2 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. + +o 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. + +o 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. + +o 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. + + +2.7.2.3 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. + +o 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. + +o 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. + + +2.7.2.4 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. + +o 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. + +o 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. + + +2.7.3 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. + + +2.7.3.1 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. + + +2.7.3.2 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. + + +2.7.3.3 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. + + +2.7.3.4 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 WAXMAPnn was added to store the axis map +in image headers. + + +2.7.3.5 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. + + +2.7.3.6 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. + + +2.7.4 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. + + +2.7.4.1 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. + + +2.7.4.2 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. + + +2.7.4.3 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. + + +2.7.4.4 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. + + +2.7.4.5 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. + + +2.7.4.6 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. + + +2.7.4.7 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). + + + +2.8 System Specific Changes + + +2.8.1 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. + +o 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). + +o 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. + +o 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. + + + +3. 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+ + + + +3.1 Changes to the IRAF system packages + + +3.1.1 DATAIO package modifications + +o 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. + +o 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. + +o 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. + +o 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. + +o rfits was modified to map ASCII control characters in the header to + blanks. + +o The sequence number appended to disk file names by rfits and wfits + was modified to 4 digits, i.e. 0001 - 9999. + + +3.1.2 IMAGES package modifications + +o 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. + +o 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. + +o 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. + +o The imhistogram task has a new "binwidth" parameter for setting + histogram resolution in intensity units. + +o 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. + + +3.1.3 IMAGES.TV package reorganization and modifications + +o 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. + +o 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. + +o 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. + +o A new option was added to imexamine to allow for fitting 1D + gaussians to lines or columns. + +o 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". + + +3.1.4 LISTS package modifications + +o 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. + + +3.1.5 OBSOLETE package added + +o 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. + +o 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. + + +3.1.6 PLOT package modifications + +o 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. + +o 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. + +o 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. + +o 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. + +o 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. + +o graph has a another new parameter "overplot" that allows the user + to overplot multiple plots with different axes. + +o The default parameters for "floor" and "ceiling" in contour and + surface were changed to INDEF. + + +3.1.7 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. + +o 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. + +o 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. + +o 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. + +o A new version of bscale was added to the package. The task now + takes a list of input images and output images. + +o 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. + +o imreplace was modified to support the "ushort" pixel type. + +o The task join has been renamed joinlines. + + +3.1.8 Additions to XTOOLS and MATH + + Programmers may be interested in the following new additions to the +XTOOLS and MATH libraries. + +o The interactive non-linear least squares fitting package INLFIT, + developed by Pedro Gigoux at CTIO, was added to XTOOLS. + +o The 1D image interpolation routines in the MATH library were + modified to support sinc interpolation. + + +3.1.9 Glossary of new tasks in the IRAF core system + +Task Package Description + +gdevices plot List imaging or other graphics devices +hfix proto Fix image headers +imcombine images Combine images pixel-by-pixel +phistogram plot Plot or print the histogram of an image or list +pradprof plot Plot or list the radial profile of an object +suntoiraf proto Convert Sun rasters into IRAF images +wcsedit proto Edit the image coordinate system +wcslab tv Overlay an image with a world coordinate grid +wcsreset proto Reset the image coordinate system + + +3.2 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. + + +3.2.1 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. + +o A new task mkechelle has been added that creates artificial 2D + echelle images. + +o 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. + +o A new task mkheader adds or modifies image headers using a header + keyword data file. + +o The mk1dspec task was modified to create multispec and echelle + format images, line by line. + +o 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. + +o A "comments" parameter was added to various tasks to + include/exclude comments in the header of the output image that + describe the data parameters. + + +3.2.2 ASTUTIL package modifications + +o 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. + +o 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. + +o 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. + + +3.2.3 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). + + +3.2.4 DIGIPHOT.APPHOT package modifications + +o 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. + +o 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. + +o All of the APPHOT tasks will now query to verify the "datamin" and + "datamax" values, if these values are used by the tasks. + +o 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. + +o If there is bad data within the photometry aperture a value of + INDEF will be stored in the data file for that magnitude. + + +3.2.5 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. + +o The append, convert, dump, renumber, select, and sort tasks were + renamed to pappend, pconvert, pdump, prenumber, pselect, and psort. + +o The "text" parameter was moved from daopars to the DAOPHOT package + parameters. + +o All the DAOPHOT routines were modified so that "psfrad", "fitrad", + and "matchrad" are defined in terms of scale. + +o The tasks allstar, group, nstar, peak, psf, and substar were all + modified to include "datamin" and "datamax" in their verify + routines. + +o 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. + +o All the DAOPHOT tasks except psf have been modified to accept lists + of input and output files. + +o 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. + +o 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. + +o group was modified so that the groups are output in y order instead + of in order of the size of the group. + +o Both group and peak were modified so that stars with INDEF centers + are not written to the output file. + + +3.2.6 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. + + +3.2.7 IMRED.CCDRED package modifications + +o 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. + +o 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. + +o 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. + +o The default computation and output "pixeltype" in the package + parameter for CCDRED are both real. Note that both can now be + specified separately. + +o The default parameters for darkcombine and flatcombine have been + changed. + + +3.2.8 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. + + +3.2.9 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. + +o 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. + +o 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. + +o The task ndprep used for CTIO 2DFRUTTI reductions was moved to the + ONEDSPEC package. + +o The task toonedspec was removed since its function can now be + performed by the onedspec.scopy task. + + +3.2.10 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: + +o The new task deredden corrects input spectra for interstellar + extinction, or reddening. + +o 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. + +o 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. + +o The task ndprep was moved to this package from the PROTO package. + ndprep is used for CTIO 2DFRUTTI reductions. + +o The new task sapertures adds or modifies beam numbers and aperture + titles for selected apertures based on an aperture identification + file. + +o 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. + +o 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. + +o The new task scopy copies subsets of apertures and does format + conversions between the different spectrum formats. + +o 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. + +o The tasks addsets, batchred, bswitch, coincor, flatdiv, flatfit, + subsets and sums were moved to the IIDS and IRS packages. + +o The task combine was removed with the all new scombine suggested in + its place. + +o 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. + +o bplot and slist have been modified to support the multispec format. + +o The task continuum now does independent fits for multispec and + echelle format spectra. + +o 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". + +o 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. + +o The task specplot has new parameters "apertures" and "bands" to + select spectra for plotting in the multispec format. + +o 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. + +o 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. + + +3.2.11 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. + + +3.2.12 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. + + +3.2.13 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. +Thus: + + 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. + +o New techniques for cleaning and variance weighting extracted + spectra have been implemented. + +o Special features for automatically numbering and identifying large + numbers of apertures have been added. + +o There is no longer a limit to the number of apertures that can be + extracted. + +o The new task apall integrates all the parameters used for one + dimensional extraction of spectra. + +o The new task apfit provides various types of fitting for two + dimensional multiobject spectra. + +o The new task apflatten creates flat fields from fiber and slitlet + spectra. + +o 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. + +o The new tasks and algorithms, aprecenter and apresize, will + automatically recenter and resize aperture definitions. + +o The task apio is defunct. Its functionality has been replaced by + the APEXTRACT package parameters. + +o The task apstrip has been removed. + +o 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. + + +3.2.14 TWODSPEC.LONGSLIT package modifications + +o The "dispaxis" parameter was added to the package parameters. This + value is used unless DISPAXIS is in the image header. + + +3.2.15 Glossary of new tasks in the NOAO packages + +Task Package Description + +addstar daophot Add artificial stars to an image +allstar daophot Group and fit psf to multiple stars +apall apextract Extract 1D spectra +apfit apextract Fit 2D spectra +apflatten apextract Remove shapes from flat fields +apmask apextract Create an IRAF pixel mask from apertures +aprecenter apextract Recenter apertures +apresize apextract Resize apertures +ccdinstrument ccdred Review instrument translation files +centerpars daophot Edit the centering algorithm parameters +chkconfig photcal Check the configuration file +continpars rv Edit continuum subtraction parameters +daofind daophot Find stars 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 standard indices +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 +fitparams photcal Compute transformation equations +fitprofs onedspec Fit gaussian profiles +fitskypars daophot Edit the sky fitting parameters +fxcor rv Radial velocities via cross correlation +gratings astutil Compute and print grating parameters +group daophot Group stars +grpselect daophot Select groups from a daophot database +invertfit photcal Compute the standard indices by inversion +istable ptools Is a file a table or text database file? +linpol nproto Polarization and Stoke's parameters +keywpars rv Translate image header keywords +mkcatalog photcal Type in a standard star catalog +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 mkNobsfile +mk(n)obsfile photcal Make a starfield observations file +mkphotcors photcal Check photometric corrections files +msresp1d argus Create 1D response spectra +msresp1d hydra Create 1D response spectra +msresp1d kpnocoude Create fiber response spectra +msresp1d specred Create 1D response spectra +nstar daophot Fit the psf to groups of stars +obsfile photcal Make a starfield observations file +pappend daophot Concatenate daophot databases +pappend ptools Concatenate apphot/daophot databases +pconvert daophot Convert text database to tables database +pconvert ptools Convert text database to tables database +pdump daophot Print fields from daophot databases +pdump ptools Print columns of daophot/apphot databases +peak daophot Fit the psf to single stars +pexamine apphot Examine or edit an apphot output file +pexamine daophot Examine and edit a daophot database +pexamine ptools Examine and edit an apphot/daophot database +phot daophot Compute sky values and initial magnitudes +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 daophot database +pselect ptools Select records from 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 +scopy onedspec Select and copy apertures +seepsf daophot Compute an image of the PSF +setjd astutil Compute and set Julian dates in images +sfit onedspec Fit spectra +substar daophot Subtract the fitted stars +tbappend ptools Concatenate apphot/daophot tables databases +tbdump ptools Print columns of tables databases +tbrenumber ptools Renumber apphot/daophot tables databases +tbselect ptools Select records from apphot/daophot databases +tbsort ptools Sort apphot/daophot tables databases +txappend ptools Concatenate apphot/daophot text databases +txdump apphot Dump selected fields of apphot output file +txdump ptools Print columns of text databases +txrenumber ptools Renumber apphot/daophot text databases +txselect ptools Select records from text databases +txsort ptools Sort apphot/daophot text databases + + + +4. Programming Environment Revisions + + + +4.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 <math.h> 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. + + + +4.2 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. + + + +4.3 Software Tools + + +4.3.1 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 <pid.in -c + +or + + % dbx $iraf/bin/x_system.e + dbx> 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. + + +4.3.2 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. + + +4.3.3 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. + + +4.3.4 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. + + +4.3.5 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. + + +4.3.6 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. + + + +4.4 Programming Interface Changes + + +4.4.1 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. + + +4.4.2 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. + +o The one-dimensional image interpolation library iminterp was + modified to add support for sinc interpolation. + +o A new library nlfit was added for non-linear function fitting. An + interactive graphics front end to this was also added in XTOOLS. + +o The name of the symbol E in <math.h> was changed to BASE_E to + minimize the chance of name clashes. + + +4.4.3 CLIO interface + + The CLIO (command language i/o) interface underwent the following +changes for version 2.10 IRAF. + +o A README file was added to the source directory containing an up to + date interface summary. + +o 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. + +o 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. + + +4.4.4 ETC interface + + The ETC interface contains miscellaneous system interface routines. +The ETC interface underwent the following changes for V2.10 IRAF. + + +4.4.4.1 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. + + +4.4.4.2 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. + + +4.4.4.3 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. + + +4.4.5 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. + + +4.4.5.1 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 <fset.h> + + 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. + + +4.4.6 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. + + +4.4.7 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. + + +4.4.8 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. + + +4.4.8.1 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. + + +4.4.8.2 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. + + +4.4.8.3 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. + + +4.4.9 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. + + + +5. 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. + IRAF (Mar90) V2.9 Revisions Summary IRAF (Mar90) + + + IRAF Version 2.9 Revisions Summary + April 10, 1990 + + + + +1. 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. + + +This revisions summary is organized as follows: + + 1. Introduction + + 2. IRAF System Revisions + + 3. IRAF Package Revisions + 3.1. Changes to the System Packages + 3.2. Glossary of New Tasks in the IRAF System Packages + 3.3. Changes to the NOAO Packages + 3.4. Modifications and Additions to Calibration Data + 3.5. Glossary of New Tasks in the NOAO Packages + + 4. Programming Environment Revisions + 4.1. Changes to the Programming Utilities + 4.2. Programming Interface Changes + + + +2. IRAF System Revisions + + +2.1 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. + + +2.2 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. + + +2.3 IMFORT changes + + The IMFORT interface (host level Fortran or C interface to the IRAF +image format) has undergone the following bug fixes and enhancements: + +o A couple of bugs associated with the IMDIR (image pixel-file + directory) feature introduced in IRAF V2.8 have been fixed. + +o 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. + +o 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. + +o 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. + +o 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. + + +2.4 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. + + +2.5 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). + + +2.6 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. + + +2.7 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 exceeded. 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. + + +2.8 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). + + +2.9 File pager enhancements + + The system file pager, used in the PAGE task, the new PHELP task, +and other places, has undergone the following enhancements. + +o 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. + +o 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. + + +2.10 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. + +o 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). + +o 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). + +o 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. + +o 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. + +o 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). + + +2.11 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. + +o 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. + +o 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 QPFILTn in the image header (multiple cards are used for + long expressions). + +o 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. + +o 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. + +o A number of bugs were fixed. + + +2.12 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$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. + + + +3. 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 + + + +3.1 Changes to the System Packages + + +3.1.1 Modifications to tasks in the DATAIO package + +o 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. + +o RFITS was modified so that the "iraf_file" parameter can be a list + of output images or a image root name. + + +3.1.2 Modifications to tasks in the IMAGES package + +o 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). + +o 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". + +o 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. + + +3.1.3 Modifications to tasks in the LISTS package + +o 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. + + +3.1.4 Modifications to tasks in the PLOT package + +o 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. + +o 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. + +o 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. + +o 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. + + +3.1.5 Modifications to tasks in the SYSTEM package + +o 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. + +o 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. + +o 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. + + +3.2 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 + + + +3.3 Changes to the NOAO Packages + + +3.3.1 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. + + +3.3.2 Modifications to Existing NOAO Packages + + +3.3.2.1 The ASTUTIL package + +o The task SETAIRMASS in the ASTUTIL package was modified so that it + now precesses the coordinates to the epoch of the observation. + + +3.3.2.2 The DIGIPHOT.APPHOT package + +o 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. + +o 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. + +o 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 + noninteractive mode update=yes will update the critical parameters + in their respective parameter sets. + +o 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. + +o A new algorithm "mean" was added to the sky fitting options. + +o 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. + + +3.3.2.3 The IMRED.IRRED package + +o The APSELECT task (from the APPHOT package) has been made visible. + +o 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. + + +3.3.2.4 The IMRED.MSRED package + +o 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. + + +3.3.2.5 The ONEDSPEC package + +o Several modifications were made to the ONEDSPEC package. These + changes affect all of the IMRED packages that include these tasks + as well. + +o 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. + +o The DISPERSION task will now add CDi_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 CDi_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. + +o 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. + + +3.3.2.6 The PROTO package + +o 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. + +o The JOIN task (previously a simple script) has been replaced by a + compiled version which removes many of the restrictions of the + previous version. + +o The IR tasks have been modified as mentioned above under the + IMRED.IRRED section (section 3.3.2.3). + +o 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. + + +3.3.2.7 The TWODSPEC.LONGSLIT package + +o Tasks in the TWODSPEC.LONGSLIT package that are used for setting + wavelength information (EXTINCTION, FLUXCALIB, and TRANSFORM) were + modified for the CDi_j keywords as outlined above for ONEDSPEC. + + +3.4 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. + + +3.5 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 + + + +4. Programming Environment Revisions + + +4.1 Changes to the Programming Utilities + + +4.1.1 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 <pkg>" 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. + + +4.1.2 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. + + +4.1.3 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. + + +4.1.4 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. + + +4.2 Programming Interface Changes + + +4.2.1 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. + + +4.2.2 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. + + +4.2.3 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 +NaNs 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. + + +4.2.4 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. + + +4.2.5 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. + IRAF (Mar90) V2.8 Revisions IRAF (Mar90) + + + IRAF Version 2.8 Revisions Summary + June 30, 1989 + + + + +1. 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. + + + +2. 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. + + + +2.1 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. + + + +2.2 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. + + +2.2.1 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. + + +2.2.1.1 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. + + +2.2.1.2 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. + + +2.2.1.3 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. + + +2.2.1.4 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. + + +2.2.1.5 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 exectable may not be successfully installed in the +package BIN directory. + + +2.2.2 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. + + +2.2.2.1 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". + + +2.2.2.2 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. + + +2.2.2.3 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. + + +2.2.3 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. + + + +2.3 User interface changes + + +2.3.1 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. + + +2.3.2 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 +mininum packing density. For example, + + cl> set impkden = 1.0 + +would completely disable block-alignment of image lines in IMIO. + + +2.3.3 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. + + +2.3.4 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. + + +2.3.5 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. + + +2.3.6 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. + + +2.3.7 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. + + +2.3.8 @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. + + + +2.4 Programming interface changes + + +2.4.1 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 concatenatable 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. + + +2.4.2 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. + + +2.4.3 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. + + +2.4.4 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. + + +2.4.5 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. + + +2.4.6 IMIO changes + + IMIO is the image i/o interface, the standard IRAF VOS interface +for managing all varieties of image data. + + +2.4.6.1 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. See \(sc2.4.3 for +more information. + + +2.4.6.2 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. See +\(sc2.4.4 for more information. + + +2.4.6.3 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. + + +2.4.6.4 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. + + +2.4.7 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. + + +2.4.8 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. + + +2.4.9 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 <fset.h>, 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. + + +2.4.10 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. + + + +2.5 Sun/IRAF specific revisions + + +2.5.1 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. + + +2.5.2 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. + + +2.5.2.1 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. + + +2.5.2.2 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. + + +2.5.2.3 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. + + +2.5.2.4 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). + + +2.5.2.5 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. + + +2.5.2.6 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. + + +2.5.2.7 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 <ctrl/b> key. Typing <ctrl/b> while +the mouse is in the image window will cause the display to display the +next blink frame in sequence. + + +2.5.2.8 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. + + + +2.6 VMS/IRAF specific revisions + + +2.6.1 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]. + + +2.6.2 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. + + +2.6.3 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. + + + +2.7 Summary of IRAF System Packages Revisions + + +o 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). + +o 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. + +o 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. + +o 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. + +o 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. + +o 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. + + +2.8 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. + + + +3. NOAO Package Revisions + + Some of the major revisions to the NOAO packages are listed below. + + +3.1 Summary of NOAO Packages Revisions + + +3.1.1 New NOAO Packages + + Several new packages have been added to the NOAO suite of packages. + +o 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). + +o 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. + +o 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). + +o 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. + +o 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. + + +3.1.2 Modifications to Existing NOAO Packages + + +o 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. + +o 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. + +o The task COSMICRAYS (from the CCDRED package) was made available in + the IMRED.GENERIC package (IRAF version 2.6 and later). + +o 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. + +o Modifications were made to the IMRED.DTOI package. These changes + have been documented in IRAF Newsletter No. 4. + +o 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. + +o 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). + +o 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. + +o The APEXTRACT package in the TWODSPEC package has ungone 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. + + +3.2 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. + + +3.3 Glossary of New Tasks in the NOAO Packages + +Task Package Description + +apscatter(1) apextract Fit and subtract scattered light +apselect apphot Extract select fields from apphot output files +asttimes astutil Compute UT, Julian day, epoch, and sidereal time +badpiximage ccdred Create a bad pixel mask image from a bad pixel file +bscale(3) proto Brightness scale images: new = (old-bzero) / bscale +ccdgeometry ccdred Discussion of CCD 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 +center(3) apphot Compute accurate centers for a list of objects +centerpars(3) apphot Edit the centering parameters +combine ccdred Combine CCD images +cosmicrays(4) ccdred Detect and replace cosmic rays +daofind apphot Find stars in an image using the DAO algorithm +darkcombine ccdred Combine and process dark count images +datapars(3) apphot Edit the data dependent parameters +demo ccdtest Run a demonstration of the CCD reduction package +ecbplot echelle Batch plots of echelle spectra +eccontinuum echelle Fit the continuum of echelle spectra +ecdispcor echelle Dispersion correct spectra +ecidentify echelle Identify features in spectrum for dispersion solution +ecreidentify echelle Automatically reidentify features 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 +flatcombine ccdred Combine and process flat field 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 +instruments ccdred Instrument specific data files +iralign(3) proto Align the mosaiced image produced by irmosaic +irmatch1d(3) proto Align and intensity match image produced by irmosaic +irmatch2d(3) proto Align and intensity match image produced by irmosaic +irmosaic(3) proto Mosaic an ordered list of images onto a grid +mkfringecor ccdred Make fringe correction images from sky images +mkhistogram proto List or plot the histogram of a data stream +mkillumcor ccdred Make flat field illumination correction images +mkillumflat ccdred Make illumination corrected flat fields +mkimage ccdtest Make or modify an image with simple values +mkskycor ccdred Make sky illumination correction images +mkskyflat ccdred Make sky corrected flat field images +mosproc irred Prepare images for quick look mosaicing +msdispcor msred Dispersion correct spectra +msreidentify msred Reidentify features from/to a 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 +refspectra(5) onedspec Assign wavelength reference spectra to other spectra +rvcorrect astutil Compute radial velocity corrections +setairmass(6) astutil Compute effective airmass for an exposure +setinstrument ccdred Set instrument parameters +sextract(2) onedspec Extract subspectra from dispersion corrected spectra +specplot(5) onedspec Stack and plot multiple spectra +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 +zerocombine ccdred Combine and process zero level images + + +Notes: + +(1) Tasks also in echelle and msred packages. + +(2) Tasks also in coude, iids, irs, and specphot packages. + +(3) Tasks also in irred package. + +(4) Tasks also in generic package. + +(5) Tasks also in coude, echelle, iids, irs, msred, and specphot + packages. + +(6) Tasks also in imred and twodspec packages. + NEWS (Jul86) Ancient News NEWS (Jul86) + +30 July 86 IMIO Modifications +------------------------------------------------------------------------------- + + The new IMIO interface, used by all IRAF tasks to access bulk image data +on disk, is now capabable of operating upon both the old IRAF format (OIF) +images as well as STScI SDAS/GEIS format images. The default image type is +the OIF format. Any existing OIF format images are readable by the new system +without change. Although IRAF can read either OIF or STF format images, +SDAS can read only STF format images, so serious SDAS users should configure +IRAF to work with STF format images as the default. All other users should +continue to use the OIF format images as image access is more efficient, +and the IRAF software has been extensively tested only for OIF format images. +Users of the OIF format should note that they can read a VMS BACKUP tape +(or UNIX TAR tape) containing STF format images directly to disk and immediately +access the images, without changing the default configuration of IRAF. + + The image type is specified by a filename extension; extensions for the +OIF format images are new in this release of the system. The recognized +extensions are shown below. + + image type header file extensions + + OIF .imh + STF .??h (? stands for any character) + +In most cases when operating upon an image with an IRAF task the extension +can be omitted. The most important exception occurs in image templates. +THE PATTERN GIVEN IN AN IMAGE TEMPLATE MUST FULLY MATCH THE IMAGE HEADER +FILE NAMES AS THEY APPEAR IN A DIRECTORY LISTING, i.e., the header filename +extension must be matched by the image template. The image type extension +must also be specified to access an image which is not of the default image +type (OIF or STF), or when changing the type of an image. For example, + + cl> imcopy dev$pix.imh pix.hhh + +will make an STF format copy in the current directory of the OIF format image +"dev$pix". + +The default image type is controlled by the new environment variable IMTYPE. +The string value of IMTYPE is the desired image header file extension, e.g., +"imh" (omit the dot) for an OIF format image. If IMTYPE is not defined the +default image type is "imh". For STF format images there are many possible +image header extensions, and IMTYPE specifies the default type IMIO should +look for when the extension is not explicitly given, or the default extension +to use when a completely new image is to be created. When making a new copy +of some existing image, IMIO will make a new image of the same type as the +existing input image unless an extension is given to force some other type +of image to be created. + + environment variable description + + IMTYPE the default image type (extension) + IMDIR pixel storage directory for OIF images + +The IMDIR environment variable defines the directory in which the pixel file +is to be placed when creating a new OIF format image. In V2.2 and older +versions of IRAF, IMDIR could only be a logical or machine dependent directory +pathname. The new system also recognizes the special "builtin" logical +directory name "HDR$" (must be upper case). If the value of IMDIR is "HDR$", +IMIO will create the pixel file in the SAME directory as the header file, +rather than in some other directory. It is also possible to place the pixel +file in some subdirectory of the header directory, e.g., "HDR$pixels/" will +cause the pixel files to go into the subdirectory "pixels". + + set imdir = "/tmp/user/" # pixel files -> specified directory + set imdir = "HDR$" # pixel files -> header file directory + set imdir = "HDR$pixels/" # pixel files -> subdirectory of HDR$ + +The root filename of OIF pixel files is now the same as that of the header +file, rather than a computer generated name. The filename extension of an +OIF pixel file is ".pix". + +The STF format images support group format, a format very similar to that +used for group format FITS tapes. IRAF users accessing an STF group format +image can specify the `group' (subimage) to be accessed by appending a +subscript to the image name, e.g., + + cl> imstat pix.aah[3] # access group 3 +or + cl> imstat pix.aah[3][*,100] # line 100 of group 3 + +A new group format image can be created in a similar fashion, specifing the +number of groups to preallocate space for, e.g., + + cl> imcopy dev$pix testimage[1/10] + +would create a new group format image "testimage" with space for 10 groups +(subimages), and initialize group 1. The remaining groups would then be +initialized by specifying only the group subscript "[N]". Note that all +groups must be the same size, new groups cannot be allocated, old groups +cannot be deleted, the set of possible group parameters is fixed at creation +time, and all groups share the same FITS header. + + +15 June 86 System Tasks +------------------------------------------------------------------------------- + + The DIRECTORY, HELP, and PAGE system tasks have all undergone important +revisions. The directory task has been completely rewritten and now handles +directory pathnames, etc., correctly, and in addition it has a more concise +syntax. The HELP and PAGE tasks have been modified to replace the old "more" +boolean query mechanism (used to pause between pages of output) with a nicer +keystroke driven mechanism which offers more options and is faster. Read the +manual pages for additional details. The old parameter files should be +unlearned. + + +28 April 86 Package Reorganization +------------------------------------------------------------------------------- + + The basic package structure of IRAF has been modified to make a distinction +between the system packages and the NOAO optical astronomy packages. The basic +directory structure of the system was also changed to reflect the new package +organization, and the printed documentation will be changed as well when time +permits. These changes were necessary to better isolate science software such +as the NOAO and STScI/SDAS packages from the system software, for a more logical +package structure, and to make it easier to install and maintain the science +packages. + +The new root menu of IRAF is as follows: + + dataio images lists noao sdas system + dbms language local plot softools utilities + +The NOAO menu is as follows: + + artdata astutil focas mtlocal proto twodspec + astrometry digiphot imred onedspec surfphot + +Three new packages were added and three old packages were extensively revised. +The NOAO mountain tape readers were moved from the DATAIO package into the new +MTLOCAL package. The astronomically oriented utility tasks were moved from +the UTILITIES package to the new ASTUTIL package. The old LOCAL package was +renamed PROTO, and a new LOCAL package was added in the directory +"iraf$local/tasks". + +The concept of the new PROTO package is appropriate for what the old LOCAL +package was used for, i.e., prototype, temporary, or contributed tasks which +are part of the NOAO package and which are exported with the system, but which +are expected to eventually disappear or be replaced by planned system +facilities. The new LOCAL package is a place to put tasks of strictly local +interest, or tasks which are not portable, e.g., foreign tasks and the Peritek +package. The LOCAL package should be particularly useful for outside sites +as it gives them a place to put locally added tasks which will not be affected +by future updates of the system. Also, the framework (mkpkg, local.cl, etc.) +is all set up, making it easier for outside sites to add their own software +without having to figure out how to set up an IRAF package. + + +20 Feb 85 Recovery from Interrupts +------------------------------------------------------------------------------- + + Tests today (unfortunately only shortly before the first IRAF release) +have shown that VMS/IRAF has higher failure rate than expected for recovery +from a ctrl/c interrupt of a running subprocess, especially if the process +is actively doing i/o. It is probably much safer to interrupt a compute +bound process than a process which is doing heavy i/o, e.g., reading a tape +or doing many file opens, or probably large numbers of any type of system +calls. The failure rate for i/o intensive processes was as high as 1 failure +to recover in 4 interrupts in some of the cases tested. Testing of UNIX/IRAF +turned up some of the same problems, but the failure rate was considerably +lower, probably because the kernel and i/o system are so much simpler. + +Interrupting a process at the wrong time can cause many problems, e.g., +[1] subprocess memory can be corrupted, resulting in unpredictable behaviour +and possibly deadlock when the CL later tries to talk the the process, +[2] a VMS forced exit of the process can occur, e.g., when trying to deliver +an AST to an invalid address, [3] corruption of the CL/subprocess communications +protocol can occur, resulting in deadlock or the loss of sync (the output of +a task will come out when the next command is entered), and various other +problems as well. + +Tests on the old version of VMS/IRAF, which dates back to last fall, show +that the problem has existed all along. The fact that we did not fully +appreciate the problem until now indicates that the problem is not a serious +hindrance provided one is conservative about the use of interrupts. It also +appears that this will not be an easy problem to solve, hence it is likely +to be with us for a while. Probably nothing at all will be done about it +for some months since other projects are likely to have a higher priority +if this problem is understood and can be worked around. + +In summary, try to minimize the use of interrupts, and in particular, avoid +interrupting processes which are doing heavy i/o. When in doubt, type +"flpr" after interrupting a process to force it to be restarted. If a +subprocess becomes hung it may be necessary to restart the CL itself. + + +20 Feb 85 Process connect failure during ":.snap" in cursor mode +---------------------------------------------------------------------------- + + We are still ocasionally having problems when trying to spawn a graphics +subkernel in response to a ":.snap" command in cursor mode. This happens +infrequently (which is why it is so hard to find the bug), and will usually +go away after exiting and reentering cursor mode and trying again. It might +also help to do a ":.gflush" while in cursor mode. |