xvimage. Only a pointer is
needed, the structure should not be
malloced.
2. demimage -- a pointer to a structure of type
demimage. This structure should be
allocated and should contain the DEM
data.
3. location -- a flag which tells this routine if the
output AVS data should have implicit
(0) or explicit (1) location data.
4. sfactor -- an integer which gives the ratio by
which the DEM data should be
subsampled before being written to
the AVS image.
OUTPUT
1. AVSimage -- upon exit this double pointer will
point to a struture of type xvimage
that is allocated and filled with the
AVS data.
AVSimage is modified to point to the output structure,
so be careful that you do not overwrite an important
pointer.
DESCRIPTION
dem2AVS converts digital elevation map data in the format
distributed by the United States Geological Survey to AVS
format so that it may be used by the khoros system.
DEM data in both the 7.5-minute and 1-degree formats can be
used.
For large files, the data may be subsampled using the -s
flag before it is written to the output AVS file.
The output may be written with location data using the -l
flag. If explicit locations are choosen, the units that the
locations are given in depend on the format of the input
file. Locations for 7.5-minute data will be given in utm
meters, and locations for 1-degree data will be given in arc
seconds.
SEE ALSO
dem2AVS(1), intro(3), vipl(3), verror(3), vutils(3)
RESTRICTIONS
dem2AVS works with both 7.5-minute and 1-degree DEM files,
but the elevation units in either format must be meters.
The ground units in a 7.5-minute DEM file must also be
meters, and the ground units in a 1-degree DEM file must be
arc seconds. A 7.5-minute DEM must use utm coordinates, and
a 1-degree DEM must use geographical coordinates. This pro-
gram reads fixed format data, so it is very sensitive to the
spacing of the fields in the input file. If the input file
format deviates in any way from the standard DEM format the
program will crash.
This program has received only minimal testing with 7.5-
minute DEM files.
AUTHOR
Per Lysne
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module dlg2AVS
INPUT
1. dlgimg - a pointer to a dlgimage structure. This
structure should not be allocated as it
will be in the library.
2. rows - the number of rows in the xvimage that the
dlg data is to be rasterized and stored
to.
3. cols - the number of columns in the xvimage that
the dlg data is to be rasterized and
stored to.
4. loc_flag - an integer flag which specifies the
type of locations to be written with the
output files. 0=no location data,
1=sparse location data, 2=full location
data.
OUTPUT
1. xv_img1 - a double pointer to the xvimage structure
that is returned for the first DLG category
2. xv_img1 - a double pointer to the xvimage structure
that is returned for the second DLG category
3. xv_img1 - a double pointer to the xvimage structure
that is returned for the third DLG category
4. xv_img1 - a double pointer to the xvimage structure
that is returned for the fourth DLG category
This function returns 1 on success and 0 on failure.
DESCRIPTION
dlg2AVS converts an optional format digital line graph
file to VIFF raster format.
A DLG file may contain several categories of data. Each
category contains data of different types. For instance,
the first category might be roads and the second category
streams. Dlg2AVS will create a separate output file for
each category in the in the input DLG file. The input DLG
file may not contain more that four categories. Most often
DLG files are created with a single category, so this should
not be a problem.
This program reads the vector data (points and lines) and
plots them in the AVS raster output image. DLG data asso-
ciates pairs of attributes with the points and lines to
describe each feature. Each pair of attributes contains a
major attribute and a minor attribute. For example, the
major attribute may specify fresh water, and the minor
attribute could specify a small stream. Each output file
that dlg2AVS writes will contain a separate data band for
each pair of attributes that occur in its DLG category. If
three pairs of attributes are present in the DLG category
for roads, then the output AVS file for roads will have
four bands in it. The first band in an output AVS image is
always reserved for features with no attributes associated
with them. The last three bands will each contain data
associated with the three pairs of attributes. The attri-
butes that go with each data band are stored in the map for
that band. The map for each band has one row and two
columns, one for each attribute, with the major attribute
stored in the first column. Each attribute is stored in a
short (2 byte) field.
The output images are written in bit format. This is possi-
ble because for a given band there is only one pair of
attributes. For each pixel in the band, there is either a
feature present for that pair of attributes or there is not.
A binary 0 or 1 is suitable to represent this. The number
of columns in the output images is given by the -x option on
the command line. The number of rows will then be deter-
mined by the size of the geographical region covered by the
DLG data. This is done automatically so the output image
will be scaled correctly.
There are three options for location data in the output
which may be specified using the -l option on the com-
mand line. The default option (-l 0) is that no location
data will be written. This is best when the map created is
to be displayed as an image, because the location data will
be ignored by most programs. The second option (-l 1) is
that sparse location data will be written with the output
images. Since the output images are bit overlays, there is
no data associated with the zero-valued pixels in the image.
All the data in the image is contained in the maps and the
pixels with a non-zero value. For this reason all of the
zero pixels in the image may be discarded. When sparse
location data is selected, the zero-valued pixels in the
image will be discarded and locations will be written for
the remaining non-zero pixels. This is advantageous because
of the reduced size of the output files, but requires a
display package (such as xprism3) which is capable of using
explicit location data. The final location option (-l 2)
writes an explicit location for each pixel in the output
image. The image is not thinned as in the second option.
All pixels, including zeros, are saved and each is assigned
a location. This option can result in very large output
files.
SEE ALSO
dlg2AVS(1), intro(3), vipl(3), verror(3), vutils(3)
lvmapdlg(3), lvlayer(3)
RESTRICTIONS
dlg2AVS can only read optional format DLG files. The DLG
files are restricted to four or fewer DLG categories. This
program reads fixed format data files, so it is very sensi-
tive to correct formatting in the input DLG files.
AUTHOR
Per Lysne
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module elas2AVS
INPUT
ELAS *elas_image - pointer to elas image structure
int elas_fid - file descriptor
struct xvimage **AVS_image - pointer to a pointer of
a VIFF image file
int band_num - band number to process
int x_coord - starting x location into ELAS image.
int y_coord - starting y location into ELAS image.
int width - desired width of VIFF image.
int height - desired width of VIFF image.
int color_model - the color space model specified by
the user.
int subimage - flag specifying whether to process
entire band or only a specified portion of the band.
OUTPUT
struct xvimage **AVS_image - malloced and copied
imagedata for VIFF image
DESCRIPTION
elas2AVS is a routine that converts an ELAS image file for-
mat into a VIFF file format. The ELAS image file format
describes the image format used by the ELAS Image system.
An ELAS image usually contains more than one channel or band
of information, although it can exist as a single band
image. This routine performs the conversion from the ELAS
image format to the VIFF image format one band at a time.
That is, only one band can be converted at a time.
Additionally, an option is provided which allows for the
conversion of a selected area of the ELAS image. This is
accomplished by specifying the starting x and y coordinates
along with the desired width and height of the resulting
image. If no subimage information is provided, then the
entire band is converted to the VIFF format. Another option
allows for the selection of the desired color space model of
the resulting image.
Record 1 contains all the header information. The remaining
records, beginning with record 2 store image data one scan-
line at a time in (BIL) band-interleaved-by-line format for
any number of bands. Each record contains one scan line of
one channel, thus each record corresponds to a new scan line
for a particular channel.
The Band-Interleaved-By-Line order means that the first
scanline of the first band is stored first. It is followed
by the first scanline of the second band, third band, fourth
band, and so on up to the last band avaliable. This order
then repeats for the second scanline, the third scanline and
so on.
The format is according to the following scheme:
Record Number Data Description
------------ ----------------
1 Header Record
2 Scan line 1, channel 1
3 Scan line 1, channel 2
4 Scan line 1, channel 3
5 Scan line 2, channel 1
6 Scan line 2, channel 2
. .
. .
. .
Note that the terminology for band and channel is used
interchangably, The term band is typically used in the con-
ventional image processing community, while channel is com-
monly used in the remote sensing community. Scan line here
refers to one row of the image.
The image header for the ELAS image file format is as fol-
lows:
BYTES TYPE DESCRIPTION
------- ---- -------------------------------------------
[1-4] int (NBIH) Number of bytes in header.
[5-8] int (NBPR) Number of bytes per record.
[9-12] int (IL) Initial line of data file.
[13-16] int (LL) Last line of data file.
[17-20] int (IE) Initial element of each scan line.
[21-24] int (LE) Last element of each scan line.
[25-28] int (NC) Number of channels (bands).
[29-32] int (4321) Header record identification.
[33-36] ASCII Grid descriptor for Y-axis: NOR, LSNL, etc.
[37-40] int Y-Offset: Y-coordinate value for scan line 0.
[41-44] ASCII Grid descriptor for X-axis: EAS, LNSE, etc.
[45-48] int X-Offset: X-coordinate value for element 0.
[49-52] float Y Spot size, or pixel element height.
[53-56] float X Spot size, or pixel element width.
[57-72] float Transformation matrix (linear) from line and
column (IL, LL, IE, LE) coordinates to the
coordinates described by the grid descriptors.
1., 0., 0., 1. = identity transformation
1., 0., 0., -1. = data in UTM format
[73-84] --- Not Used.
[85-88] int (Eikonix) Used by modules RFEKDA and VEKS.
[89-92] int (LABL) Used by module LABL.
[93-96] ASCII (HEAD) Used by module HEAD.
[97-480] ASCII Comments - 6 lines at 64 characters each or
96 4-character descriptiors for data base use.
[481-992] int Color Table (color map)
[993-1024] --- Not Used.
The following fields in the VIFF image header are set as
follows:
1. data_storage_type = BYTE (VFF_TYP_1_BYTE)
2. data_encode_scheme = RAW (VFF_DES_RAW)
3. map_scheme = NONE (VFF_MS_NONE)
4. map_enable = OPTIONAL (VFF_MAP_OPTIONAL)
5. location_type = NONE
6. num_images = 1
The following arguments define the use of the library rou-
tine "lelas2AVS":
elas_image a pointer to an ELAS image structure.
elas_fid an integer specifying the file descriptor of
the ELAS image. This is most readily
obtained by including a call to "open_elas()"
contained in the file elas.c. The routine
"open_elas()" opens the specified file and
verifies the header and performs byte
swapping if necessary using the machine
dependencies.
AVS_image a pointer to a pointer of a VIFF image file.
The resulting VIFF image is returned through
the use of this pointer.
band_num an integer specifying which band number to
process.
x_coord an integer specifying the starting x location
or column into the ELAS image for processing
of only a portion of the ELAS image.
y_coord an integer specifying the starting y location
or row into the ELAS image for processing of
only a portion of the ELAS image.
width an integer specifying the width (number of
columns) of the resulting VIFF image.
height an integer specifying the height (number of
rows) of the resulting VIFF image.
color_model an integer specifying the color space model
of the resulting image.
subimage an integer representing the optional subimage
flag. A value of TRUE indicates that the
routine will use the subimage coordinate
information indicated in the parameters,
x_coord, y_coord, width, and height. A value
of FALSE indicates that the routine will
ignore the subimage coordinate information
and process the entire band of information.
IMPORTANT
The utilities used to read and write the BIG image file are
machine dependent. WE ASSUME THAT THE BIG IMAGE WILL ALWAYS
BE IN LITENDIAN BYTE FORMAT, since the Terra-Mar Image pro-
cessing system runs under DOS on a PC. This means that a
machine that uses bigendian byt order (i.e. sun, sony, etc)
must byte swap some fields in the image header. So, a #if
has been placed in the code to allow conversion between
litendian byte order and bigendian byte order.
The only file that has machine dependencies is big.c in the
file formats library (libfile_formats.a).
1. The not define flag
This routine can be compiled so that it is not
machine dependent by using -DNMD option. NMD
stands for not machine dependent. When compiled
with this option the bigendian to litendian
conversion is not performed.
2. defines for machine dependencies
The defines for machine dependencies (conversion
to and from bigendian) are sun, bigendian, and
ieeeorder. So big.c can be compiled with -Dbigen-
dian. Note, when compiling on a sun machine, sun
is defined so the conversion code from bigendian
to litendian will be be compiled. If it is
unwanted see 1. above.
SEE ALSO
elas2AVS(1), intro(3), vipl(3), verror(3), vutils(3)
RESTRICTIONS
Only one band at a time is converted.
Elas images are assumend to be in NS byte order (little
endian).
AUTHOR
Charlie Gage
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module elasinfo
INPUT
ELAS *elas_image - pointer to elas image structure
int elas_fid - file descriptor
char *input_file - input file name
OUTPUT
FILE *printdev - output ascii file
DESCRIPTION
elasinfo is a routine that reads and prints an ELAS image
file format header. The ELAS image file format describes
the image format used by the ELAS Image system.
Record 1 contains all the header information. The remaining
records, beginning with record 2 store image data one scan-
line at a time in (BIL) band-interleaved-by-line format for
any number of bands. Each record contains one scan line of
one channel, thus each record corresponds to a new scan line
for a particular channel.
The Band-Interleaved-By-Line order means that the first
scanline of the first band is stored first. It is followed
by the first scanline of the second band, third band, fourth
band, and so on up to the last band avaliable. This order
then repeats for the second scanline, the third scanline and
so on.
The format is according to the following scheme:
Record Number Data Description
------------ ----------------
1 Header Record
2 Scan line 1, channel 1
3 Scan line 1, channel 2
4 Scan line 1, channel 3
5 Scan line 2, channel 1
6 Scan line 2, channel 2
. .
. .
. .
Note that the terminology for band and channel is used
interchangably, The term band is typically used in the con-
ventional image processing community, while channel is com-
monly used in the remote sensing community. Scan line here
refers to one row of the image.
The image header for the ELAS image file format is as fol-
lows:
BYTES TYPE DESCRIPTION
------- ---- -------------------------------------------
[1-4] int (NBIH) Number of bytes in header.
[5-8] int (NBPR) Number of bytes per record.
[9-12] int (IL) Initial line of data file.
[13-16] int (LL) Last line of data file.
[17-20] int (IE) Initial element of each scan line.
[21-24] int (LE) Last element of each scan line.
[25-28] int (NC) Number of channels (bands).
[29-32] int (4321) Header record identification.
[33-36] ASCII Grid descriptor for Y-axis: NOR, LSNL, etc.
[37-40] int Y-Offset: Y-coordinate value for scan line 0.
[41-44] ASCII Grid descriptor for X-axis: EAS, LNSE, etc.
[45-48] int X-Offset: X-coordinate value for element 0.
[49-52] float Y Spot size, or pixel element height.
[53-56] float X Spot size, or pixel element width.
[57-72] float Transformation matrix (linear) from line and
column (IL, LL, IE, LE) coordinates to the
coordinates described by the grid descriptors.
1., 0., 0., 1. = identity transformation
1., 0., 0., -1. = data in UTM format
[73-84] --- Not Used.
[85-88] int (Eikonix) Used by modules RFEKDA and VEKS.
[89-92] int (LABL) Used by module LABL.
[93-96] ASCII (HEAD) Used by module HEAD.
[97-480] ASCII Comments - 6 lines at 64 characters each or
96 4-character descriptiors for data base use.
[481-992] int Color Table (color map)
[993-1024] --- Not Used.
The following arguments define the use of the library rou-
tine "elasinfo":
elas_image a pointer to an ELAS image structure.
elas_fid an integer specifying the file descriptor of
the ELAS image. This is most readily
obtained by including a call to "open_elas()"
contained in the file elas.c. The routine
"open_elas()" opens the specified file and
verifies the header and performs byte swap-
ping if necessary using the machine dependen-
cies.
i_file this is the input image filename.
printdev
NOTE:
The driver of this routine calls the routine open_elas() in
the file elas.c, which opens the file, gets a file descrip-
tor (fid), allocates space for the header, performs byte
swapping if necessary, and reads the header information into
the structure defined in elas.h.
IMPORTANT
The utilities used to read and write the BIG image file are
machine dependent. WE ASSUME THAT THE BIG IMAGE WILL ALWAYS
BE IN LITENDIAN BYTE FORMAT, since the Terra-Mar Image pro-
cessing system runs under DOS on a PC. This means that a
machine that uses bigendian byt order (i.e. sun, sony, etc)
must byte swap some fields in the image header. So, a #if
has been placed in the code to allow conversion between
litendian byte order and bigendian byte order.
The only file that has machine dependencies is elas.c in the
file_formats library (libfile_formats.a).
1. The not define flag
This routine can be compiled so that it is not
machine dependent by using -DNMD option. NMD
stands for not machine dependent. When compiled
with this option the bigendian to litendian
conversion is not performed.
2. defines for machine dependencies
The defines for machine dependencies (conversion
to and from bigendian) are sun, bigendian, and
ieeeorder. So elas.c can be compiled with -Dbigen-
dian. Note, when compiling on a sun machine, sun
is defined so the conversion code from bigendian
to litendian will be be compiled. If it is
unwanted see 1. above.
SEE ALSO
elasinfo(1), intro(3), vipl(3), verror(3), vutils(3)
AUTHOR
Charlie Gage
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module AVS2big
INPUT
struct xvimage *AVS_image - input image to be con-
verted
OUTPUT
struct big **big_image - resulting big image.
DESCRIPTION
AVS2big is a routine that converts a BIG image file format
into a VIFF file format. The BIG image file format describes
the image format used by Terra-Mar MicroImage. This format
is based on record sizes of 512.
Record 1 contains all the header information. The remaining
records, beginning with record 2 store image data one scan-
line at a time in (BIL) band-interleaved-by-line format for
any number of bands. Since a scanline has a variable number
of pixels depending on the original data, each scanline is
divided into an appropriate number of records (512 pixels
per record). If the number of pixels per scanline is not
evenly divisible by 512, then the last record for each line
will contain the remainder for that line; it will be only
partially full. Note, records are padded to a length of 512.
The Band-Interleaved-By-Line order means that the first
scanline of the first band is stored first. It is followed
by the first scanline of the second band, third band, fourth
band, and so on up to the last band avaliable. This order
then repeats for the second scanline, the third scanline and
so on.
The image header is assigned as follows:
Bytes[1-22] reserved1[22]; /* Reserved */
Bytes[23] data_type; /* 'L' -> MSS data */
/* 'T' -> TM data */
/* 'S' -> SPOT data */
Bytes[24] reserved2; /* Reserved */
Bytes[25-26] num_channels; /* Number of Channels/Bands */
Bytes[27-28] start_line_num; /* Starting Line Number */
Bytes[29-30] start_pixel_num; /* Starting Pixel Number */
Bytes[31-32] num_lines; /* Number of Lines (row size) */
Bytes[33-34] num_pixels_line; /* Number of Pixels per Line */
/* (column size) */
Bytes[35-36] reserved3[2]; /* Reserved */
Bytes[37-38] reserved4[2]; /* Reserved */
Bytes[39-119] title[80]; /* Title of Image */
Bytes[120-121] records_line; /* Records_Per_Line (rounded up) */
Bytes[122-512] reserved5[392]; /* Reserved */
The image type for the BIG image file format is set by the
number of bands:
1. If the number of bands is less than or equal to 3 the
image type is set to 'S' = SPOT.
2. If the number of data bands is greaterr than 3 the
image type is set to 'L' = MSS.
IMPORTANT
The utilities used to read and write the BIG image file are
machine dependent. WE ASSUME THAT THE BIG IMAGE WILL ALWAYS
BE IN LITENDIAN BYTE FORMAT, since the Terra-Mar Image pro-
cessing system runs under DOS on a PC. This means that a
machine that uses bigendian byt order (i.e. sun, sony, etc)
must byte swap some fields in the image header. So, a #if
has been placed in the code to allow conversion between
litendian byte order and bigendian byte order.
The only file that has machine dependencies is big.c in the
file formats library (libfile_formats.a).
1. The not define flag
This routine can be compiled so that it is not
machine dependent by using -DNMD option. NMD
stands for not machine dependent. When compiled
with this option the bigendian to litendian
conversion is not performed.
2. defines for machine dependencies
The defines for machine dependencies (conversion
to and from bigendian) are sun, bigendian, and
ieeeorder. So big.c can be compiled with -Dbigen-
dian. Note, when compiling on a sun machine, sun
is defined so the conversion code from bigendian
to litendian will be be compiled. If it is
unwanted see 1. above.
SEE ALSO
AVS2big(1), intro(3), vipl(3), verror(3), vutils(3)
file_formats(3)
RESTRICTIONS
The input image must be of data storage type BYTE.
AUTHOR
Mark Young, Tom Sauer
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module vll2utm
INPUT
1. img -- a pointer to a struct xvimage. This pointer
is used for both the input and the output
images. The location data in the input
image will be replaced by the converted
coordinates in the ouput image, so be
careful not to overwrite important data.
2. s_flag -- a flag that is set to specify that the
input coordinates are given in arc seconds
instead of degrees of latitude and
longitude.
OUTPUT
DESCRIPTION
vll2utm converts explicit location data from geographical
to universal transverse mercator coordinates.
When digital elevation model data is imported using
dem2AVS, it is optional to write explicit location data
along with the elevations. If the file input to dem2AVS is
a 1-degree DEM file, the explicit locations will be given in
arc seconds of latitude and longitude. This program may be
used to convert the coordinates in arc seconds to their
equivalents in utm. This is desirable because the other
geographical information programs in Khoros use locations in
utm.
The -s flag specifies whether the geographical coor-
dinates are given in degrees or arc seconds. Dem2AVS will
always write geographical coordinates in arc seconds, but
the degrees option has been included for possible future
use.
SEE ALSO
vll2utm(1), intro(3), vipl(3), verror(3), vutils(3)
ldem2AVS(3)
RESTRICTIONS
vll2utm requires that the input file contains only one
image and that the image must contain explicit location
data.
AUTHOR
Per Lysne
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************