4.0 LAS File Structures
4.1 Introduction
LAS creates a whole set of computer files related to the processing of
its various components. The types and maintenance of some of the more
common files used are described in this section. The types of files
that may be found within LAS are:
- Image file
- Data descriptor record (DDR) file
- Display and lookup table file (DLTF)
- Projection definition file
- Geometric mapping grid file
- Graphics overlay files (GOFs)
- Header ancillary annotation trailer (HAAT) file
- History (HIS) file
- Merged tie point file
- Resampled weight table file
- Statistics file
- Tie point location file
- Tie point selection file
The formats for each of these files and a complete list of the types
of files found in LAS are described in detail in the LAS 7.0 Programmer's
Guide.
4.2 LAS Filename Syntax
The traditional LAS filename syntax is based on VMS filename
conventions, with additional fields for handling image subwindows,
band sets, etc. (described in later sections). Support for the native
Unix directory/filename syntax is the new LAS standard, with backwards
compatibility to support the previous standard, VMS-style
directory/filename syntax.
Following are the requirements for a filename in LAS:
- 1.
- The traditional LAS format, based on VMS
conventions (square brackets, directory levels separated by dots,
semicolons separating root name and extension), will continue to
be supported. This includes directory options to define the
entire path, start at the user's home directory, start at the
local directory, and start at the parent of the local directory
(i.e., ``
[-]
'').
- (a)
- If a directory/filename contains
square brackets (``
[]
'') and/or a semicolon
(``;
''), it will be interpreted with VMS syntax.
- (b)
- The input directory/filename will be
interpreted as case-sensitive. This is a departure from the
existing case-insensitive standard of converting to all lower
case during conversion to a host name.
- (c)
- An extension may be added to the
filename depending on the form of the input filename.
- i.
- If a filename has been determined
to be in VMS syntax and contains a semicolon, the filename as
input is assumed to be complete and no extension will be
appended.
- ii.
- If a filename has been determined
to be in VMS syntax and does not contain a semicolon, a
default extension (application based) may be appended.
- 2.
- Unix directory/filename syntax (forward
slashes separating directory levels, dots separating root name and
extension, case-sensitive) will be supported as the new LAS
filename syntax standard.
- (a)
- If a directory/filename does not
contain square brackets and/or a semicolon, it will be
interpreted with Unix syntax. VMS format will only be assumed
if VMS-specific characters exist. (See requirement 1a.)
- (b)
- In Unix syntax, dots are not
restricted to representing only file extensions the way that
semicolons are in traditional LAS format. This can lead to
ambiguities in some applications.
- i.
- If a specific extension is
required and the Unix filename ends with the required
extension, the filename as input is assumed to be complete and
no extension will be appended. Required extensions only apply
to image file sets (``
.img
'',
``.ddr
'', ``.his
'').
- ii.
- If a specific extension is
required and the Unix filename does not end with the required
extension, the required extension will be appended to the
filename.
- iii.
- If a LAS input filename
parameter does not require a specific filename extension, the
filename will be determined as follows:
- a.
- If the filename contains at
least one dot, the string following the last dot is
interpreted as the extension and the input name is used.
- b.
- If the filename does not
contain any dots, the default extension is appended to the
name. (No default or an empty default are interpreted as a
default extension of nil and will append nothing.)
- 3.
- The legacy capabilities to specify
windows, bands, and multiple images in a single input string
shall continue to be supported. The details are given in later
sections.
- 4.
- Input strings that do not match either
the VMS format or the Unix format will induce an error.
- (a)
- If a directory/filename contains
illegal characters an error will occur. Legal characters (not
including those associated with windowing/banding information)
in VMS format are all alphanumerics,
``
[].;-@_#%^
'' , and `*
'' (as a
wildcard in certain applications). Legal characters in Unix
format are all alphanumerics, ``~/.-@_#%^
''
(``~
'' only as the first character in the path),
and ``*
'' (as a wildcard in certain applications).
The plus sign (``+
'') is a legal character in both
VMS and Unix syntax, but should be avoided due to potential
confusion with its line continuation role in the LAS command
line.
- (b)
- If a directory/filename contains
multiple left or right square brackets, multiple semicolons, or
multiple tildes, an error will occur.
If the user-specified name for an image or file in a LAS applications
module is input in traditional, VMS syntax, it's translated into a
host computer name. During this translation all periods "." are
turned into underscores "_" and a period and file extension are added
to the name. For example:
IN = [-]madtown.tm
will be stored, along with DDR and history files, in the files called:
madtown_tm.img | (image file)
|
madtown_tm.ddr | (DDR file)
|
madtown_tm.his | (history file)
|
in the parent directory of the current working directory.
To store another user-created file with this image, such as a text
file, would require the user to follow a similar naming convention
such as:
madtown_tm.txt (a text file created by the editor).
4.3 LAS Catalog Manager
All LAS files created during the sessions are cataloged and maintained
by the LAS Catalog Manager (CM). The CM modules used to manipulate
and integrate the catalog are:
Module | Description
|
---|
cmalias
| Creates,deletes, and lists aliases
|
cmcopy
| Copies cataloged on-line and off-line files
|
cmdel
| Deletes directories or cataloged files
|
cmlist
| List cataloged files
|
cmmkdir
| Creates a new directory
|
cmrename
| Renames a cataloged file
|
cmset
| Sets the user's default directory
|
cmshow
| Shows the current catalog directory
|
Wildcards are allowed for the filename, extension, and the last
directory specification of most catalog manager applications. A more
general directory wild card is allowed for those applications which
include the parameter nlevels, the number of child or
subdirectories to search. In such an instance, a wildcard can be
substituted for the entire filename specification. The following list
provides guidelines about wildcards in catalog manager filenames.
- If a filename is specified without a directory specification, the
current directory is assumed.
- For a catalog manager application, a filename without an extension
specification implies file-name.img and all files
associated with filename.img (unless the parameter is
actually requesting an image name).
- For other LAS application modules, if no extension is specified,
the application will look for a file with the appropriate
extension for its input requirements. For example, an input image
(in) would look for an image or put the .img
extension on the user-specified name.
- If an extension is specified, just that specific file is used; for
example, ny.ddr means only the ny.ddr file.
- "*" implies *.img and all files associated with
*.img.
- "*.*" implies all files.
Examples:
Images under the user quirk:
dogimagesnoopy
landsat_image_band1
landsat_image_band2
landsat_image_band3
madtown
spot_isoclass
*image*
Would find:
dogimagesnoopy.img
landsat_image_band1.img
landsat_image_band2.img
landsat_image_band3.img
*t_
Would find:
None of the previously listed examples.
*t_*
Would find:
landsat_image_band1.img
landsat_image_band2.img
landsat_image_band3.img
spot_isoclass.img
*1*
Would find:
landsat_image_band1.img
~quirk/*.*
Would find:
dogimagesnoopy
landsat_image_band1
landsat_image_band2
landsat_image_band3
madtown
spot_isoclass
4.4 LAS Data Structures
4.4.1 Image Storage
LAS images will always have the following information associated with
them:
- Image data values
- Data descriptor record (DDR) which contains information such as
data type of the image, master coordinates, image size, etc. See
Appendix A for a full description of
the DDR contents.
- History records which contain history of the image, the modules
run to create the image, the parameters used, the data used, etc.
Each image may also have another set of associated files, which may
include any of the files listed in Section 4.
In the course of processing raster images, several types of associated
data files may be created for each image. LAS uses a standard set of
extensions to implicitly associate a file with an image. All files in
a directory with the same filename but different extensions are
considered to be associated. The existence of separate files for the
associated information gives increased flexibility, simplifies the
task of accessing the associated information, and allows the image and
its associated files to be easily treated as a "data set" for archive
and file transfer. Files may use any extension; however, some
standard extensions are used in naming types of files that are
frequently used and the user should avoid using these extensions.
Some of the file types are:
Extension | Description
|
---|
dltf | Display and lookup table file
|
ddr | Data descriptor record (DDR)
|
gof_pnt | Graphics overlay point file
|
gof_line | Graphics overlay line file
|
gof_poly | Graphics overlay polygon file
|
gof_anot | Graphics overlay annotation file
|
grid | Geometric mapping grid
|
his | History
|
ibis_tab | LAMS tabular file
|
ibis_graph | LAMS graphics file
|
lt | General purpose labeled table file
|
img | Image data file
|
mtp | Merged tie point file
|
rwt | Resampling weight table file
|
proj | Projection definition file
|
stat | Statistics file
|
tpl | Tie point location file
|
tps | Tie point selection file
|
txt | General purpose ASCII file
|
LAS stores the image data and associated data in separate files.
Multiband images are stored in the same file in a band sequential
(BSQ) format. Image data may be transferred or ingested from computer
compatible tapes to disk, or from disk to disk. Image data may also
be transferred as output to tape from disk.
4.4.2 Multi-band Images, Spatial, and Spectral Specifications
LAS applications modules accept both single-band and multi-band
images. An optional spatial window specification may be used along
with the image name, such as:
"LASIMAGE(SPATIAL_WINDOW : SPECTRAL_WINDOW; SPATIAL_WINDOW_TYPE)"
Restrictions and notes:
- The image name can be 100 characters long. The LAS image name
represents the name as one of the following:
- LAS single or multiple image name
- Alias name
- The window specification is given as SL, SS, NL, NS where:
- SL = start line number
- SS = start sample number
- NL = number of lines
- NS = number of samples
The individual window specification values must be delimited by either
a blank space or a comma. The following examples are valid ways of
using or combining image names:
"lasname1(200,200,100,100:2,3,4,5)+lasname2(1,1,100,100:3,5)"
The images lasname1 and lasname2 are considered as
multi-band images in this example. The window 200, 200, 100, 100 will
be applied to all the bands of the selected bands 2, 3, 4, and 5 from
lasname1 and bands 3 and 5 using the window 1, 1, 100, 100
from lasname2. Note that the spectral window size must be
the same in most LAS modules. The exception is concat.
The following rules and limitations apply:
- No more than one window in a single image is allowed. The module
will abort with an error message if more than one window is
specified.
- No window is allowed for nonimage files. The module will abort
with an error message.
- Band selection is allowed only for multi-band images. The band
specification is given as integers delimited by a comma "," or a
blank space " " preceded by a colon. As an example, bands one
through four may be specified as :1,2,3,4 or :1 2 3 4 or 1-4.
- Acceptable image data types are byte, integer*2,
integer*4, and real*4. All LAS modules will handle
these four data types unless otherwise specified.
- All individual images must have the same data types, sizes, and
file types. For example, the data types integer*2 and
integer*4 cannot be mixed in the same image. Nor can
file types such as an image file and a stats file be mixed in an
image. However, some LAS modules will allow mixed data types on
input but never on output.
To create an image of multiple files or bands, the user may use the
LAS module copy. For modules with single logical images--such
as copy, normd, and
list, IN will be a single-dimensioned parameter with
the following allowable images:
IN="image1"
IN="image1(1 1 100 100)"
IN="image1(:1 2)"
IN="image1(1 1 100 100:1 2)"
IN="image1+image2"
IN="image1(1 1 100 100)+image2(1 1 100 100)"
IN="image1(:1 2)+image2(:1 2)"
IN="image1(1 1 100 100:1 2)+image2(1 1 100 100)"
As an example, this is how a LAS module will handle singledimensioned
IN parameters and what the results will be.
COPY IN="image1(:1 2)+image2(:2 3)" OUT="image3"
In this example, bands one and two of image1 are copied as
bands one and two of image3 along with bands two and three of
image2 which are bands three and four of image3.
This example shows how a user can group four bands of two images into
four bands of one image.
For modules that allow or expect multiple logical images - such as
math, composit, and
diff - IN will be a multidimensioned parameter with the
following allowable images:
IN="image1, image2"
IN="image1(1 1 100 100), image2(1 1 100 100)"
IN="image1(:1 2), image2(:1 2)
IN="image1(1 1 100 100:1 2), image2(1 1 100 100:1 2)"
IN="image1+image2, image3+image4"
IN="image1(1 1 100 100)+image2(1 1 100 100),
image3(1 1 100 100)+image4(1 1 100 100)"
IN="image1(:1 2)+image2(:1 2), image3(:1 2)+image4(:1 2)"
IN="image1(1 1 100 100:1 2)+image2(1 1 100 100:1 2),
image3(1 1 100 100:1 2)+image4(1 1 100 100:1 2)"
In addition, the comma may be replaced with a blank, and the elements
may be entered individually as in the following examples:
IN(1)="image1"
IN(2)="image2"
IN="image1(:1 2) image2(:1 2)"
IN(1)="image1(1 1 100 100:1 2)+image2(1 1 100 100:1 2)"
IN(2)="image3(1 1 100 100:1 2)+image4(1 1 100 100:1 2)"
As an example, this is how a LAS module will handle multidimensioned
IN parameters and what the results will be.
MATH-ADD IN="image1(:1 2),image2(:2 3)" OUT="image3"
In this example, bands one and two of image1 are added,
respectively, to bands two and three of image2. The output
image3 consists of two bands. The first band is the sum of
image1 band one and image2 band two with the second band
consisting of the sum of image1 band two and image2 band
three. This example shows how the user can treat the input images as
two separate unique images as opposed to the first example where the
input is treated as one logical input image.
4.4.2.1 Optional Specifications
Optional spatial window specifications include:
"LASIMAGE(SPATIAL_WINDOW : SPECTRAL_WINDOW; SPATIAL_WINDOW_TYPE)"
This format may be used in place of the standard image specifications
discussed in Section 4.4.2.
The SPATIAL_WINDOW has three possible definitions.
- default:
(SL SS NL NS)
- method 2:
(MAX_LAT MIN_LON MIN_LAT MAX_LON)
- MAX_LAT = Maximum Latitude
- MIN_LON = Minimum Longitude
- MIN_LAT = Minimum Latitude
- MAX_LON = Maximum Longitude
- method 3:
(UL_Y UL_X LR_Y LR_X)
- UL_Y = Upper left projection value
- UL_X = Upper left projection value
- LR_Y = Lower right projection value
- LR_X = Lower right projection value
The SPATIAL_WINDOW_TYPE defines the format of the window components
and may be set to:
Key | Units | Definition
|
---|
Not specified | Line/Sample | default
|
"LS" | Line/Sample | default
|
"DEG" | Degrees | method 2
|
"DMS" | DDDMMMSSS.SSSS | method 2
|
"PRO" | Projection | method 3
|
If SPATIAL_WINDOW_TYPE corresponds to the default method, then the
window will be processed the same as the standard method described in
Section 4.4.2.
If SPATIAL_WINDOW_TYPE corresponds to method 2, then:
- The specified latitudes and longitudes are assumed to be in the
GEOGRAPHIC projection.
- The input IMAGE DDR must contain valid projection information
and corner values.
- The window is transformed to the image projection using the
projection information in the IMAGE DDR and the General
Cartographic Transformation Package.
- A projection unit min box window is calculated.
- The resulting window is expanded so that the projection
coordinates are even increments of the exact pixel size. This
will ensure that all the desired data is included.
- The projection units are then converted to line/samples.
- Some examples would be:
IN="image1(20.3 120.5 18.6 118.2:1 2;DEG)"
IN="image1(020018000 120030000 018048000 118012000:1 2;DMS)"
IN="image1(20.3 120.5 18.6 118.2:1 2;DEG),
image1(020018000 120030000 018048000 118012000:1 2;DMS)"
If SPATIAL_WINDOW_TYPE corresponds to method 3, then:
- The specified coordinates are assumed to be in the same
projection as the IMAGE DDR.
- The input IMAGE DDR must have a valid pixel size.
- The line sample window is calculated directly from the input
window using the formulas in the Geometric Overview.
- Some examples would be:
IN="image1(103400 234560 98650 239640:2 3;PRO)"
IN="image1(207300 125430 187520 145360;PRO"
4.4.3 Associated Files
4.4.3.1 Image History
Image history information is stored in an associated history file.
The image history consists of the modules used in the creation of the
image, modules run using the image, data and time executed, and
parameters used.
The history of a LAS image file may be displayed on the terminal by
running the module dsphistry or by using any computer system
utility which will display an ASCII file.
Fri Sep 1 16:55:23 1989
UNIX
quirk
GEOM1P
IN="nhap_raw_map"
INGRID="nhap.grid"
OUT="nhap_reg"
WINDOPT="OUT"
WINDOW=--
RESAMP="CC"
INRWT=--
PCCALPHA=-0.5
BACKGRND=0.0
INTLIM=--
ODTYPE="SAME"
Tue Sep 5 08:37:23 1989
UNIX
quirk
copy
IN="nhap_reg(2232,2943,2100,2709)"
OUT="nhap_reg_sub"
ODTYPE="SAME"
ROUNDOPT="TRUNC"
Thu Sep 7 00:36:01 1989
UNIX
quirk
ISOCLASS
IN="nhap_reg_sub"
OUT="nhap_reg_iso"
OUTSTAT="nhap_stats"
STATSRC="NONE"
INSTAT=--
MAXNUMIT=10
CLUSDIST=3.2
MAXCLSTD=4.5
SSEPVAL=0.0
PRINTIT=11
VIEWIT=21
MINNUM=30
MAXCLUST=24
CHNTHR=3.2
PRINT="LP"
PRTFILE="ISOCLASS_112544.pr"
4.4.3.2 Data Descriptor Record
Every image will have an associated data descriptor record (DDR) file.
This file contains the contents shown below.
The DDR file contains five basic types of information. Each time a
module is executed, each of the fields is updated. The rules
governing how each field is updated is outlined in the LAS 7.0 Programmer's
Guide. The DDR can be displayed using the LAS module dspddr, or each of the fields
can be edited by using the LAS module editddr. The five types of
information in the DDR are:
- Required information about the image - number of lines, number of
samples, number of bands, data type, and the system on which the
data was created
Most modules only require that the number of lines, number of
samples, number of bands, data type, and the system the data was
created on be valid for the module to use this DDR; all the other
fields may be invalid. There are some modules which require
other fields to be valid. For example, concat-auto
requires that the corner coordinates and related projection
information to be valid.
- Corner coordinates of the image and the related projection
information
These coordinates are useful in the mosaicking of images and/or
retrieval of the projection coordinates of any pixel in the
image. For a more detailed description of these fields and how
they can be used, refer to the Geometric Manipulation Package
Overview document.
- The minimum and maximum values for each band of the image
This is calculated by any module that creates an output image and
only when the TAE global $MINMAX is set to "yes."
- Information describing how and when each band of the image was
acquired
These fields are used to keep track of acquisition date and time
of each band of the image and how it was acquired.
- Miscellaneous information
This information includes the last date and time an image was
modified and the master line and sample of an image. The last
access date and time are useful in deciding which images should
be archived. The master line and sample keep track of where
pixel 1,1 of the image is in relation to the original image.
This is useful if the image has been copied or used as a
subset.
IMAGE NAME:image/valddr
NL:512 NS:512 NB:3 DTYPE:BYTE
LAST USED: DATE:26Jan89 TIME:1451:03 SYSTEM:gouldutx
PROJ. CODE:(1)UTM Valid:VALID
ZONE CODE:11 Valid:VALID
DATUM CODE:0 Valid:VALID
PROJ. PARM: Valid:VALID
A: 0.00000000000000E+00 0.00000000000000E+00 0.00000000000000E+00
B: 0.00000000000000E+00 0.00000000000000E+00 0.00000000000000E+00
C: 0.00000000000000E+00 0.00000000000000E+00 0.00000000000000E+00
D: 0.00000000000000E+00 0.00000000000000E+00 0.00000000000000E+00
E: 0.00000000000000E+00 0.00000000000000E+00 0.00000000000000E+00
CORNER CORR: Valid:VALID
ULcorner:3.65777500000000E+06 4.99200000000000E+05
URcorner:3.65777500000000E+06 5.11975000000000E+05
LLcorner:3.64500000000000E+06 4.99200000000000E+05
LRcorner:3.64500000000000E+06 5.11975000000000E+05
PROJ. DIST:2.50000000000000E+01 2.50000000000000E+01 Valid:VALID
PROJ. UNITS:meters Valid:VALID
INCREMENT:0.00000000000000E+00 0.00000000000000E+00 Valid:INVALID
MASTER CORR:0 0
IMAGE NAME:[image]valddr
BAND NO:1
MINIMUM:0.00000000000000E+00 Valid:VALID
MAXIMUM:1.95000000000000E+02 Valid:VALID
DATA SOURCE:landsat4
SENSOR TYPE:mss
CAPT. DIRECTION:ascending
DATE:23apr86
TIME:1305:55
IMAGE NAME:image/valddr
BAND NO:2
MINIMUM:0.00000000000000E+00 Valid:VALID
MAXIMUM:2.33000000000000E+02 Valid:VALID
DATA SOURCE:landsat4
SENSOR TYPE:mss
CAPT. DIRECTION:ascending
DATE:23apr86
TIME:1305:55
IMAGE NAME:image/valddr
BAND NO:3
MINIMUM:0.00000000000000E+00 Valid:VALID
MAXIMUM:1.64000000000000E+02 Valid:VALID
DATA SOURCE:landsat4 SENSOR TYPE:mss
CAPT. DIRECTION:ascending
DATE:23apr86
TIME:1305:55
4.5 Statistics Files
In the process of interpretation and image analysis, some LAS modules
use or generate statistics files. These files may or may not be
associated with a specific LAS image. LAS statistics files are
tree-structured files that contain statistical information derived
from the associated images. The types of information contained in
statistics files are mean and covariances matrices, correlation data,
histograms, and polygon vertices.
When training sites are defined by the mensuration modules, the site
polygon vertices are based on entire image coordinates even if the
image needed to be subsampled to be displayed. For example, if
polygons are selected from a 512 by 512 subsection, starting at image
coordinates (1001,2001) , the coordinates of any site polygon within
that subsection will be in the range (1001,2001) to (1512,2512). This
is important to users who wish to edit their polygon vertices.
4.5.1 Nodal Structure
The data in a statistics file is stored in a data tree structure. The
tree structure consists of three levels. The three levels are:
- Level 0: Data items associated with an entire image such as
eigenvectors, eigenvalues, the number of classes in the image,
and the mean vector and covariance matrix for the image, number
of bands, confusion matrix, histograms, and correlation
matrix.
- Level 1: Data items associated with classes such as the number of
training sites, class mean vector and covariance matrix, and
class name, histogram, and number of points.
- Level 2: Data items associated with training sites such as the
number and listing of the vertices of the polygon defining the
site, histogram of intensities within the polygon, site name, and
site statistics.
Level 0 contains only one node which is the root of the data tree.
The nodes that belong to the Level 1 category are immediate successors
of the root node. The nodes that belong to the Level 2 category are
immediate successors of the nodes in Level 1.
Statistics files are generated by the clustering/classification
modules such as isoclass
or by the training site definition module put-poly. Note that
the statistics files generated by the clustering/classification
modules may not have any "sites" for Level 2; they may only have class
information at Level 1.
4.6 Display and Lookup Tables
Display and lookup tables files (DLTF) are used within LAS to store
lookup tables that are utilized by both the LAS display module
(XID) and enhancement modules such as map. A DLTF is a
file that defines a sample intensity mapping to be applied to an
image. The sample value in an input image is the index to the DLTF,
and the contents of the index is the sample value of the output image
that would result if the DLTF was applied to the input image. DLTF
can be used on either black and white or color images.
4.7 Geometric Transformation Files
Several types of files are used in performing geometric transformation
of image data in LAS. Not all geometric corrections will use all of
the file types listed as described in the following list, although
some of them will. Additional information may be referenced in the Geometric Manipulation Package
Overview document. The types of files used in geometric
registration are:
- Tie point selection (TPS) files are typically produced as the
first step in performing geometric registration of image data.
TPS files are produced through interactive selection of image
pixel locations using the display. The data in the files may
also be produced or modified manually.
- A merged tie point (MTP) file incorporates the combined
information from two TPS files for use in the image-to-image
correlation process. In typical image registration, an entry in
the MTP file contains (among other things) both the "search"
image coordinates and the "reference" image coordinates of the
tie point.
- In typical image registration, tie point location (TPL) files
contain the results of the correlation operation, if performed.
TPL files thus contain postcorrelation or refined "search" tie
point coordinates, which, in the some cases, may be fractional
values. TPL files also contain "reference" tie point coordinates
as well as information about the strength of the correlation.
- LAS offers three standard resampling options: nearest neighbor
(NN), bilinear interpolation (BI), and cubic convolution (CC).
In the event that none of these is satisfactory, the user may
create a table of resampling weights (TABLE).
- In the geometric transformation process, the mapping between
input image coordinates and output image coordinates may be
represented in either of two ways: (1) by means of a mapping grid
where the selected points in output space and the coordinates of
the corresponding points in input space are provided or (2) by
means of a set of polynomial coefficients that directly specify a
transformation from output to input coordinates. As indicated by
its name, the mapping grid/polynomial file can contain either or
both types of information.
4.8 TAE Files
TAE also creates and updates a set of files on the computer system.
These include parameter files, session histories, PDFs, script files,
and the results of batch processing. These files are described in
detail in the TAE User's Reference Manual, but several are
included in the following list. These files may be found under any
user's account by using the computer system's file listing utility.
File Descriptions:
- pixcount.par
- A parameter file that the user saved from the pixcount module. These
parameter files may be saved from any LAS module with the default
name being the module name. They are binary files.
- last.par
- The file where the parameters are saved for the last module the
user ran. This allows the user to use the restore last
capability in TAE.
- session.tsl
- This file contains all information from a particular session if
enable-log has been set.
- taescreen.txt
- File created by typing screenon followed by
screenoff. It stores all the tutor screens displayed
between these two commands in this file. This ASCII file may be
viewed and/or printed.
- ulogon.pdf
- A file setup by the user and executed when the user starts a LAS
session. It allows a user to customize his/her LAS session.
- ulogoff.pdf
- A file setup by the user and executed when the user ends a LAS
session. It allows a user to customize his/her LAS session.
- procname.job
- These files are created by running a module in batch mode.
- procname.log
- A log file of the batch job.
- name.src
- Script files saved using the scripton and scriptoff
sequence of commands.
- name.pdf
- TAE proc that can be setup by the user to run interactively or in
batch mode.