path: root/doc/newsfile

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.