ERDAS - Developers Toolkit Examples on-LineManual'

DevelopersToolkitExamples'
O N - L I N E M A N U A L
Copyright 1982 - 1999 by ERDAS, Inc. All rights reserved. Printed in the United States of America. ERDAS Proprietary - Delivered under license agreement. Copying and disclosure prohibited without express written permission from ERDAS, Inc. ERDAS, Inc. 2801 Buford Highway, N.E. Atlanta, Georgia 30329-2137 USA Phone: 404/248-9000 Fax: 404/248-9400 User Support: 404/248-9777
Warning All information in this document, as well as the software to which it pertains, is proprietary material of ERDAS, Inc., and is subject to an ERDAS license and non-disclosure agreement. Neither the software nor the documentation may be reproduced in any manner without the prior written permission of ERDAS, Inc. Specications are subject to change without notice.
Trademarks ERDAS is a trade name of ERDAS, Inc. ERDAS and ERDAS IMAGINE are registered trademarks of ERDAS, Inc. Model Maker, CellArray, ERDAS Field Guide, and ERDAS Tour Guides are trademarks of ERDAS, Inc. Other brands and product names are trademarks of their respective owners.
DevelopersToolkitExamplesOn-LineManual'
Purpose of the Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Reading and Writing ERDAS IMAGINE Files . . . . . . . . . . . . . . . . . . . . . . 1
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Introduction to Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Developers Toolkit Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Rules for using the Developers Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Toolkit Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Error Logging and Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Argument Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Coordinate Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Raw Coordinate System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Map Coordinate Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Units Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Radial Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Geographic Coordinates (Projections) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Image File Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 ERDAS IMAGINE .img Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

File Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Sensor Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Raster Layer Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Block Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Attribute Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
iii
Continuous Raster Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Thematic Raster Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 25
Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Map Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Map Projection Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Pyramid Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Reading and Writing .img Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
eerr . emif . ehfa . edsc . eprj . esta . eimg . estr . emap .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
27 27 27 28 28 28 28 28 28
Hardcopy Device Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Roles of Map Composer, Mapmaker, and Printmanager . . . . . . . . . . . . . . . . . . . . . . . . . 29 Running Map Composer, Mapmaker, and Printmanager . . . . . . . . . . . . . . . . . . . . . . . . . 29 The Preference Denition File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 The Device Setup Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 The Raster Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 The Installation Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 User Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Machine Independent Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

MIF Data Elements . . . . . . . . . . . . . . . . . . EMIF_T_U1 (Unsigned 1-bit Integer). . . . EMIF_T_U2 (Unsigned 2-bit Integer). . . . EMIF_T_U4 (Unsigned 4-bit Integer). . . . EMIF_T_UCHAR (8-bit Unsigned Integer) . EMIF_T_CHAR (8-bit Signed Integer) . . . EMIF_T_USHORT (16-bit Unsigned Integer) EMIF_T_SHORT (16-bit Signed Integer) . . EMIF_T_ENUM (Enumerated Data Types) . EMIF_T_ULONG (32-bit Unsigned Integer). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 46 46 47 47 47 47 48 48 48
iv
EMIF_T_LONG (32-bit Signed Integer) . . . . . . EMIF_T_PTR (32-bit Unsigned Integer) . . . . . . EMIF_T_TIME (32-bit Unsigned Integer). . . . . . EMIF_T_FLOAT (Single Precision Floating Point) . . EMIF_T_DOUBLE (Double Precision Floating Point). EMIF_T_COMPLEX (Single Precision Complex) . . EMIF_T_DCOMPLEX (Double Precision Complex) . EMIF_T_BASEDATA (Matrix of Numbers) . . . . . EMIF_M_INDIRECT (Indication of Indirect Data) . . EMIF_M_PTR (Indication of Indirect Data) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 49 50 50 50 51 51 52 54 55
MIF Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
HFA Object Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Hierarchical File Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Nodes and Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Pre-dened HFA File Object Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Basic Objects of an HFA File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Ehfa_HeaderTag 62 Ehfa_File 62 Ehfa_Entry 63 Objects of a .img File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Eimg_Layer 66 Eimg_Layer_SubSample 67 Eimg_NonInitializedValue 68 Ehfa_Layer 68 RasterDMS 69 Edms_VirtualBlockInfo 70 Edms_FreeIDList 72 Edms_State 72 Edsc_Table 73 Edsc_BinFunction 73 Edsc_Column 74 Eded_ColumnAttributes_1 76 Esta_Statistics 78 Esta_Covariance 78 Esta_SkipFactors 79 Esta_ExcludedValues 79
Eprj_Datum 79 Eprj_Spheroid 80 Eprj_ProParameters 80 Eprj_Coordinate 85 Eprj_Size 85 Eprj_MapInfo 85 Efga_Polynomial 86 Calibration_Node 87
External File Format Header Object Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

ADRG Header 89 ADRI Header 91 BandInfo Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AVHRR Header 94 DEM Header 97 DOQ Header 100 DTED Header 105 MSS Header 107 TickMark Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 SPOT Header 112 struct SpotHeader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 GeoSpot Header Tablea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Spot Canadian Header Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 TM Header 133 93
Preference Denition File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Installing, Compiling, and Running the Example Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Under Microsoft Windows . . . . . . Installation . . . . . . . . . Requirements. . . . . . . . Using the Example Projects . . Compatibility Limitations . . Structure Packing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 142 142 142 142 143
Under UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Example File Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
vi
Example: read80descrip.c 147 Example: copy80layer.c 149 Example: RasterAccess.c 150 Example: display_anno.c 152 Example: draw_demo.c 153 Example: convolve.c 154 Example: canvas_test.c 155 Example: subset1.c 156 Example: subset2.c 158 Error Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Example: subset3.c 159 EML Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Event Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Example: readmssephemeris.c 162 Example: degrad.c 163 Example: digview.c 164 Example: eprj_sample.c 165 Example: fonttablemaker.c 166 Example: eemlsample.c 167 Example: table.c 168 Example: importex.c 169 Example: exportex.c 170 Example: chartdemo.c 171 Example: fxgeneral.c 172 Initialize the Toolkit . . . . . . . . . Determine the Layers . . . . . . . . Open the Input Layer . . . . . . . . Create the Output Layer . . . . . . . Allocate Pixel Array . . . . . . . . . Read Data . . . . . . . . . . . . . Modify the Data. . . . . . . . . . . Write the Data . . . . . . . . . . . Close the Layers . . . . . . . . . . Create the Design For the Special Object Write the Object to the File . . . . . . Example: imagecopy.c 178 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 172 173 173 174 175 175 176 176 177 177
vii
Purpose of the Toolkit
Purpose of the Toolkit

The ERDAS Developers Toolkit is intended to allow outside developers to extend the capabilities of IMAGINE. Using the Toolkit, an IMAGINE user can write specialized functions for his or her particular needs. The Toolkit allows the creation of applications which are faster and more powerful than those written with the Spatial Modeler language. In fact, the capabilities of applications written using the Toolkit are limited only by the C language itself and the programmers own skills. Moreover, the Toolkit enables new applications to be integrated into IMAGINE. Examples of Toolkit applications include, but are by no means limited to, the following:
o Import/Export between unsupported file formats and IMAGINE files o Specialized classification routines o Operations on FFT images o Specialized contrast algorithms o Reading the ephemeris data structure from IMAGINE files created by importing from satellite
images such as LANDSAT or SPOT Instructions for installing the C Programmers Toolkit examples are given in Installing, Compiling, and Running the Example Files.
A complete list of function packages is given in Developers Toolkit Packages. Reading and Writing ERDAS IMAGINE Files If you are using the Developers Toolkit to read and write image files in the ERDAS IMAGINE file format (i.e., hardware vendors), refer to the following chapters for specific instructions pertaining to these tasks: ERDAS IMAGINE .img Files Hardcopy Device Drivers Machine Independent Format HFA Object Directory External File Format Header Object Types Preference Definition File
System Requirements
System Requirements
Before you begin using the Toolkit, you need to make sure that you have the following:
o The C compiler for your computer (from your computer vendor). See the table below. o IMAGINE 8.4 (from ERDAS, Inc.). o A good working knowledge of IMAGINE and C programming in general.
Architecture Sun SPARCstation HP 9000 family, series 700 and 800 IBM RS/6000 Operating System Solaris 2.6 HP-UX 11 C Compiler SPARCompiler C 4.0 HP-UX ANSI C Developers Bundle C for AIX 3.1.4 or C Set++ for AIX 3.1.4
AIX 4.3.2
DEC AlphaStation
Digital Unix 4.0E
A fully functional but separately licensed C compiler is supplied with the OS. ANSI C compiler shipped with IRIS Development Options 6.2 Visual C++ 6.0
Silicon Graphics R4000 and up Intel Pentium
IRIX 6.5
Microsoft Windows NT 4.0
These requirements are subject to change! Check the Release Notes in the Important Information Folder for corrections or visit our web site at http://www.erdas.com for the latest information.
Introduction to Libraries
The Developers Toolkit consists of a set of three libraries and about fifty include files. The libraries are:
o libelib, the core of the Toolkit, o libeml, the EML (user interface) library, and o libeix, which contains data import/export functions.
These libraries are located in the directory <IMAGINE_HOME>/usr/lib/arch (where arch is one of sun4, sun4sol, decosf, sgi, hp700, rs6000 or aviion, depending on your platform). The Toolkit include files are located in <IMAGINE_HOME>/usr/include. User Interface functions are found in library emllib: The ERDAS Macro Language (EML) provides a simple means for creating and modifying a program interface, which is actually separate from the program. The feature which distinguishes this from something like UIL (the Motif User Interface Language) is that in addition to the definition of user interface objects, EML also provides a built-in script interpreter which allows actions as well as appearance to be customized. The eml library provides access to the ERDAS Macro Language (EML) services from within a C program. Import and Export functions are found in library eixlib: The import/export library contains specialized functions pertaining to data import and export. In addition to providing functions to aid in creating new import and export programs, the library contains routines to read and write ephemeris data structures. Ephemeris data are the data normally contained in the header of external raster data formats such as MSS, TM or SPOT. They contain information on the size and location of the image, sensor characteristics, and date of image acquisition, among other things. All other functions are found in library elib: Library elib contains the majority of the functions in the Toolkit. It is grouped into packages containing routines with similar functionality. A complete listing of packages is given below. All packages begin with the letter e and are followed by a three-letter identifying mnemonic. For example, the Argument Parsing package is denoted earg. All routines and data types in a particular package begin with the four-letter package name (earg_DoArgs, for example), and the Include file also reflects the mnemonic, such as earg.h. Beginning Toolkit programmers should familiarize themselves first with Rules for using the Developers Toolkit and then with the following packages:
o eint: Toolkit Initialization

3
o eerr: Error Logging and Reporting o earg: Argument Parsing o eimg: Image File Access
Developers Toolkit Packages
Developers Toolkit Packages

Click on one of the following Toolkit Packages to go to the Index of Functions for that package. From there, you may go to the general package description (the first item in the index) or directly to a specific function. Occasionally you will see a reference to a macro (which looks like a function). If you click on a macro reference, you are taken to the Index of Functions. Click on the package description and look for the definition of the referenced macro.
eant - Annotation Package eaoi - Area of Interest Package earg - Argument Parsing Package ebst- Binary Search Tree Package ecfg - Conguration manager Package eclb - Color Library Package ecls - Classication Package ecvt - Unit Conversion Package edlm - Dynamic List Manager Package edsc - Descriptor Table Access Package edsp - Digital Signal Processing Package eeml - EML API Functions Package. eerr - Error Logging and Reporting Package eevg - Annotation Support Package. efft - Fourier Transform Package efga - Floating-Point Graphics Arithmetic Package eo - Low Level File I/O Functions Package efnp - File Node Parse Package efsp - Feature Space Package
Developers Toolkit Packages egda - General Data Arithmetic Package ehfa - Low Level Access to the Hierarchical File Access System ehst - Histogram and Lookup Table Package eimg - Image File Access Package eint - Master Toolkit Initialization Package eirf - Image Rectication Package eixm - Raster Import/Export Package eklb - Kernel Library Package ellm - Linked List Manager Package emap - Map Printing Package emet - Progress Meter Support Package emif - Machine Independent Format Data Package empu - MultiProcessor Support Package emsc - Miscellaneous functions for common operations emta - Magnetic Tape Access Package. epmg - Parameter Manager Package eprj - Map Projection Package epxm - Pixel Management Package erec - Rectication Package erga - Raster GIS Analysis Package esec - Security Package esed - Seed (Region Growing) Package esel - Selection Package eshm - Shared Memory Package esig - Signature Package esmg - Session Manager API Package. 6
Developers Toolkit Packages esta - Statistics Package estr - String Package esym - Symbol Table Management Package etim - Timer Package. evec - Vector Package evue - Communication Routines for Viewer Operations exfr - Transformation Package.
Rules for using the Developers Toolkit
Rules for using the Developers Toolkit Introduction

Before you begin to write C programs using the IMAGINE Developers Toolkit, please read carefully the following rules. Following these rules ensures your program will be integrated closely with the IMAGINE Systems Session Manager and will be treated just like any other IMAGINE program.
Rules o Decide what type of program you are going to develop (JOB or APPLICATION). See the
description of these types of programs below.
o Never use any undocumented or private functions that you may find in the included files.
Even if the undocumented/private function works for you, DO NOT use them in your program. The author of these functions is free to remove them, change arguments, or change functionality. Any change to these functions is likely to cause your program to fail.
o Do not install any signal handlers in your programs. This certainly will cause problems, since
the integrity of the Session Manager depends on some specific system signals such as SIGCHLD, SIGINT, SIGHUP, SIGQUIT, SIGTSTP, SIGPIPE, SIGTERM.
o Do not use functions designed for a Job if your program is an Application or vice versa; doing
so will produce unpredictable results.
o If you are not sure about a Toolkit function or the On-Line documentation is not sufficient, call
Toolkit Support at ERDAS for clarification. A simple call will save a lot of time at a later stage of development. Also, this will provide ERDAS with feedback on the type of problems Toolkit users may encounter and signal us to add more documentation on these specific subjects. Types of Programs The Developers Toolkit supports two basic types of programs:
o GUI programs -- Programs that use a Graphical User Interface for user input. These
programs, after they start, will create an interface, present it to the user and wait indefinitely for the user input. This type of program is called an APPLICATION.
o Non-GUI programs -- Programs that take user input as command line arguments and start
and complete the task on their own (i.e. they will not wait for user input while they are running). These programs also inform the user how much of the task is currently completed. This type of program is called a JOB.
Rules for using the Developers Toolkit There are different sets of functions provided under IMAGINE to build APPLICATIONS and JOBS. 1. Application - Every program which calls the function eeml_Init() is registered by the IMAGINE Session Manager as an APPLICATION. The communication between the Application and the Session Manager is two way (i.e. the Session Manager sends/receives commands to/from an application). An application can call all of he documented toolkit functions in the eeml package. Applications can freely exit with the C system call exit() any time they need to exit. The Session Manager will automatically detect the applications exit. 2. Job - Every program which calls the function esmg_JobInit() is registered by the IMAGINE Session Manager as a JOB. The Session Manager automatically displays a progress meter for every job. A job can regularly call esmg_JobProgress() to report the status of task to the IMAGINE Session manager which, in turn, displayed the progress in the progress meter for that job. A job should call the esmg_InterruptQuery() function regularly during its processing. This function will inform the job whether the user has cancelled the job through the Cancel button provided by Session Manager in the progress meter. After it has completed, the job must call esmg_JobEnd() to signal the Session Manager that it is exiting. The communication between a job and the Session Manager is one way most of the time (i.e., the job sends commands to the Session Manager). For certain query commands, the Session Manager will send a reply back to the job.
Jobs should not call any functions designed for Applications (i.e., functions documented in the eeml package). Conversely, Applications should not call functions designed for Jobs, such as esmg_JobInit, esmg_JobState, esmg_JobProgress, esmg_JobEnd, etc.
Toolkit Initialization
Toolkit Initialization
The eint package contains the function eint_InitToolkit, an initialization routine which must be the first Toolkit function called. This function returns a pointer to a structure, Eint_InitTookitData, which is an argument in many Toolkit functions.
10
Error Logging and Reporting
Error Logging and Reporting

The eerr package provides a convenient means of reporting errors detected by Toolkit functions. Errors are reported through a structure, Eerr_ErrorReport, which contains:
o a pointer to subsequent Eerr_ErrorReport structures, o the name of the function reporting the error o a numeric code identifying the specific error within the function, and o a pointer to a character string containing more information about the error.
Virtually every Toolkit function has an error argument in its calling procedure, which is the last fixed argument of the functions argument list. Thus, even if a Toolkit program does not use the error reporting scheme directly, a pointer to an Eerr_ErrorReport structure must be declared to provide an error argument to each function. It is recommended that the error argument be checked after each Toolkit function call. If the returned error argument is NULL, no error was detected by the function. Otherwise, the error argument points to an Eerr_ErrorReport structure identifying the exact source of the error. The linked-list nature of the Eerr_ErrorReport structure allows the user to trace each function sub-call down to the source of the error. Thus, the source of a runtime error may often be pinpointed without using a debugger.
11
Argument Parsing
Argument Parsing
The earg package provides a very convenient means of processing command-line arguments and options. The package works by allowing the application developer to define an array of Earg_Cmd structures in the application which defines the legal command-line options and the values which they may take. Each structure contains:
o a pointer to a function to execute when the argument is recognized, o a description of the syntax for an option or argument, o a description of the argument, and o a pointer to an error function.
This structure is then passed on to the earg_DoArgs function along with the command line arguments. The parsing and error checking is done in this function. The primary function, i.e., the function corresponding to the name of the program itself, is always called last, and the other functions are called in the order listed in the command line. The command-line format must obey the following rules:
o Required arguments immediately follow the name of the program. o Command-line options are indicated by a hyphen and one or more letters. o Parameters belonging to an option, if any, immediately follow the option and are separated
by spaces. For example, suppose there is a program called printtext which prints text files. The only required command line argument is the name of the file to be printed. Optionally, the line width and page length may also be specified. The command format is
printtext filename [ -w width ] [ -l length ]
A fragment from the beginning of the program would look something like
#include <earg.h> void ChangeWidth(); void ChangeHeight(); void mainfunction(); Earg_Cmd command [] = { ChangeWidth, "-w[idth] %d","Change line width",EARG_NO_ERR, ChangeHeight, "-l[ength] %d","Change page length",EARG_NO_ERR, mainfunction, "printtext %s","Main routine", EARG_NO_ERR, EARG_END
12
Argument Parsing
};
The EARG_END structure indicates the end of the array. The second element in the Earg_Cmd structure, the format string, is similar to a printf format string. Items in brackets are optional. In the above example, the name of the program, printtext, must be followed by a string (the name of the file), and may be followed by either -w or -l, each of which must be immediately followed by an integer. All of the following are valid invocations of the printtext program:
printtext printtext printtext printtext myfile myfile -w 70 myfile -w 74 -l 60 myfile -length 60
The following are incorrect:

printtext printtext myfile 60 74 printtext myfile -w60 printtext myfile -w -l 60 74
Functions governed by the Earg_cmd structure are assumed to be defined as:

void functionname( argc, argv ) int argc; char *argv[];
The arguments argv[1], argv[2], etc., for each function correspond to the arguments listed in the Earg_Cmd structure after the function name. For example, if printtext is called with
printtext myfile -w 70
the argument argv[1] to the function ChangeWidth is 70. Although the format of the command description may call for integers, floating point values, etc., this is for syntax error checking purposes only. The arguments are passed to the functions as strings in the *argv array and must be converted to the proper data type inside the function.
13
Coordinate Systems
Coordinate Systems Raw Coordinate System

An IMAGINE image file is a rectangular array of pixels. The leftmost column of pixels is column 0 and the topmost row of pixels is row 0. The row(y) and column (x) numbers increase to the right and down. This is the coordinate system which is used with the eimg_LayerRead and eimg_LayerWrite functions. File Origin Column 0 Row 0
Upper Left Map
CellSize Y
Map Origin CellSize X
Lower Right Map
14
Coordinate Systems
Map Coordinate Systems

IMAGINE image files may have a cartesian map coordinate system assigned to the pixels. The system has the origin at the lower left pixel in the image. The coordinate system is assigned by specifying the map coordinate which corresponds to the center of the upperleft pixel and the map coordinate which corresponds to the center of the lower right pixel. The pixel separation is also specified as the X Cellsize and the Y Cellsize. The specification of upperleft, lowerright, and cellsize is redundant. Only the upperleft and cellsize are actually used in practice. The following formulas are used to convert between row/column and map x/y.
x = X ul + c X size
y = Y ul r Y size
The following formulas are used to convert from map x/y to row/column
x X ul c = ---------------X size y + Y ul r = ---------------Y size Units Conversion

The map coordinates x and y and the cellsizes are in the units specified in the MapInfo object. To convert between these sizes and meters the ecvt package is used.
15
Coordinate Systems The ecvt package is a generalized units conversion package, which can be used to convert distance, angle, time, mass, etc. It is controlled by a file called <IMAGINE_HOME>/etc/units.dat. This is a simple ASCII file which contains definitions for various types of units categories such as distance, angle, time, etc. Within each category there is a definition which consists of a unit name followed by the conversion to the standard unit. Here is an example of the entry for distance:
distance { meters 1.0 ; meter 1.0 ; feet 0.3048006099012192 ; : }
This says that meters (or meter) is the standard unit of distance and that feet are converted to units by multiplying by 0.304800609901219. To add other units (surveyfeet for example) one would edit the units.dat file and add a new entry in the distance category which looks like surveyfeet 0.314159....; (whatever the proper conversion factor is). IMAGINE must be restarted for the new units to take effect. The new units will not show up in any dialogs automatically, but they will be understood by the system. The EML scripts must be edited to have the new unit appear to the user. Here is an example of reading the MapInfo header.
Eimg_MapInfo *mi; double xul, yul, xsize, ysize; double x, y; double xm, ym; int r, c; mi = eimg_MapInfoRead(layer, NULL, &err); if ( mi==NULL) /* No Map Information available */ xul = mi->upperLeftCenter->x; yul = mi->upperLeftCenter->y; xsize = mi->pixelSize->width; ysize = mi->pixelSize->height; /* ** Get the map coordiante of pixel 100, 100. */ r = 100; c = 100; x = xul + c*xsize; y = yul - r*ysize; /*
16
Coordinate Systems
** x and y are in the units of the map header. To convert to meters, ** do the following: */ ecvt_UnitsConvertByName(&x, mi->units.data, &xm, meters, 1, &err); ecvt_UnitsConvertByName(&y, mi->units.data, &ym, meters, 1, &err); /* ** This is somewhat inefficient because it does the lookup of meter and ** the files units per number. Use ecvt_UnitSetByName to find the input ** and output units beforehand and then just use ecvt_UnitsConvert() to do ** the conversion. The x and y values can also be placed into arrays since ** the unit convert functions work on arrays. */ /* ** The following would be used to write a simple cartesian map system to ** file which is nrows by ncols. */ Eprj_MapInfo *mi; double xul, yul, xlr, ylr, xsize, ysize; /* ** Lets assume that the cellsize is 10 meters. */ xsize = 10.0; ysize = 10.0; xul yul xlr ylr = = = = 1000000.0; 1000000.0; xul + (ncols - 1) * xsize; yul - (nrows - 1)*ysize;
mi = eprj_MapInfoCreate(&err); eprj_MapInfoUpperLeftCenterSet(mi, xul, yul, &err); eprj_MapInfoLowerRightCenterSet(mi, xlr, ylr, &err); eprj_MapInfoPixelSizeSet(mi, xsize, ysize, &err); eprj_MapInfoUnitsSet(mi, meters, &err); eprj_MapInfoProjectionNameSet(mi, Unknown, &err); /* ** Now write it to the layer. */ eimg_MapInfoWrite(layer, mi, &err0;
Radial Units
If the image coordinate system is radial, i.e., it is given as latitude longitude, then the default units are decimal degrees (given as dd). A file with a projection name of Geographic has radial units. The units package can be used to convert dd to radians just as it is used to convert feet to meters. However, there is nothing which forces the radial coordinate image file to be in decimal degrees. It could be in radians as well. The programmer must check the units.
17
Coordinate Systems
Geographic Coordinates (Projections)

The MapInfo object also contains the name of the projection which is used to convert from the map system to geographic latitude / longitude coordinates. If the projection name is Unknown then the map system is a simple cartesian system which cannot be converted to lat/lon. However, if the name is other than Unknown then the map coordinates x and y can be converted to lat/lon using the projection package.
Eprj_ProParameters *pp; Eprj_MapProjection *mapp, geop; Eprj_Point pin, pout;
if (estr_Eq(mi->proName.data, Unknown)... /* No Projection Info */ pp = eimg_ProParametersRead(layer, NULL, &err); if (pp==NULL)... /* No projection info */ /* ** Convert the xm, ym to lat/lon (xm,ym must be in meters. The projection package ** expects all map coordinates in meters and all angle (lat/lon) in radians. */ geop = eprj_ProjectionInit(eint_GetInit(), eprj_ProParametersCreate(&err), &err); mapp = eprj_ProjectionInit(eint_GetInit(), pp, &err); pin.x = xm; pin.y = ym; eprj_Project(&pin, mapp, &pout, geop, 1, &err); /* ** pout.x is now the longitude in radians. ** pout.y is now the latitude in radians. ** ** ecvt can be used as above to convert to degrees. */
Calibration
An IMAGINE image file can also have a Calibration Record. This calibration record can contain a polynomial which is used to convert from r,c to x,y and vice versa. This allows an arbitrary coordinate system to be established on the image. This transformation converts from row column to map x and map y. The calibration has a MapInfo object which is used to assign units to the coordinates and which is used to indicate whether there is an associated Map Projection. If there is a map projection it is used as described above.
18
Coordinate Systems This calibration node is accessed using the erec_CalibrationNode functions. erec_CalibrationNodeRead is used to read the calibration node. If the node is present then this functions returns the rc->xy polynomial, the xy->rc polynomial, the MapInfo and the ProParameters to be used with the calibration. The function efga_PolyTransCoords is used to apply the polynomial to the coordinate pairs. NOTE: Calibrated files are discouraged at this point because the only application which deals effectively with them is the viewer. The calibration mechanism was created so that measurements could be taken directly from a file which had not been resampled. Using them effectively in applications such as Modeler or Mosaic requires on the fly Nth order polynomial resampling, which is not yet implemented throughout IMAGINE.
19
Image File Access
Image File Access

The eimg package is used to access raster data from disk files. Because data in IMAGINE files is stored in a flexible, hierarchical, tree-structured format, it is essential that the Toolkit be used for file access. Using eimg, the individual pixels in an image may be accessed, as well as map and projection information, image statistics, histogram data, color tables, and other descriptor tables. Raster data is stored in layers, which are two-dimensional arrays of data where each element of the array corresponds to a data file value. For example, a true color RGB image contains three layers, one for each band. Each layer in a file has a unique name which is used to access it. The various layer names in a file may be found using the eimg_LayerGetNames function. Individual layers may be opened in much the same way as files: they may be opened as read-only, etc. In order to manipulate raster data, the Eimg_PixelRect structure is used. This is a buffer into which a layer or rectangular subset of a layer may be read. Using an Eimg_PixelRect, data may be manipulated at the pixel level, or arithmetic functions may be applied to the entire area. The discussion of ERDAS IMAGINE .img Files explains how to import and export image files in the IMAGINE format.
20
ERDAS IMAGINE .img Files

ERDAS IMAGINE uses .img files to store raster data. These files use the ERDAS IMAGINE Hierarchal File Format (HFA) structure. Figure 1, below, shows the different objects of data stored in a .img file. The contents of the .img file is not fixed. Many of the items shown below are optional. In addition, because of the open nature of the file format, other developers may create and add new types of items to the file. The Developers Toolkit provides programmers with the functions needed to read and write ERDAS IMAGINE .img files. Even though the file format is documented in the HFA Object Directory chapter, it is recommended that you read this section because it will greatly reduce development time. In addition, it will guarantee compatibility with future versions of the .img file format.
.img le
File Info.
Ground Control Points
Sensor Info.
Layer_1
Layer_2
Layer_n
Layer Info.
Attribute Data
Statistics
Map Info.
Projection Info.
Pyramid Layers
Data File Values
compression
block size
Figure 1: Examples of Objects Stored in a .img File
File Information
Each .img file stores basic information about the file, including:
o file name o layer name
21
o number of layers o date the file was last modified

This information applies to all of the layers.
Sensor Information
When you import satellite imagery from a tape or CD-ROM, there is usually a header file preceding the image data on the input medium which is extracted by the import program and stored as an object in the .img file. This object contains ephemeris information about the sensor, such as:
o date and time scene was scanned o calibration information of the sensor o orientation of the sensor o original dimensions for data o data storage format o number of bands
The data presented are dependent upon the sensor. Each sensor provides different types of information. The sensor object is named: <format type>_Header Sensor ADRG ADRI DEM DTED Landsat TM Landsat MSS NOAA AVHRR SPOT Sensor Object ADRG_Header ADRI_Header DEM_Header DTED_Header TM_Header MSS_Header AVHRR_Header SPOT_Header
22
Raster Layer Information

Each raster layer within a .img file has its own ancillary data, including the following parameters:
o height and width (rows and columns) o layer type (continuous or thematic) o data type (signed 8-bit, floating point, etc.) o compression (see below) o block size (see below)
This information is usually the same for each layer. Compression When you import a file into ERDAS IMAGINE you have the option to compress the data. Currently, ERDAS IMAGINE uses the run-length compression method. The amount that the data are compressed depends on data in the layer. For example, if the layer contains large homogenous areas (e.g., blocks of water) then compressing the layer would save you disk space. However, if the layer is very heterogenous, then run-length compression would not save you much disk space. Data will be compressed only when it is stored. ERDAS IMAGINE automatically uncompresses data before the layer is run through a process. The time that it takes to uncompress the data is minimal. Block Size ERDAS IMAGINE software uses a tiled format to store raster layers. The tiled format allows raster layers to be displayed and resampled quickly. The raster layer is divided into tiles (i.e., blocks) when ERDAS IMAGINE creates or imports a .img file. You can define the size of these blocks when you either create the file or import it. The default block size is 64 pixels by 64 pixels.
The default block size is acceptable for most applications and should not need to be changed.
23
64 pixels 64 pixels
512 columns
512 rows
Figure 2: Example of a 512 x 512 Layer with a Block Size of 64 x 64 Pixels
24
Attribute Data
Continuous Raster Layer The attribute table object for a continuous raster layer, by default, includes the following information:
o histogram o contrast table

Thematic Raster Layer For a thematic raster layer, the attribute table object, by default, includes the following information:
o histogram o class names o class values o color table (red, green, and blue values).
Attribute data can also include additional information for thematic raster layers, such as the area, opacity, and attributes for each class.
Statistics
The following statistics are calculated for each raster layer:
o minimum and maximum data file values o mean of the data file values o median of the data file values o mode of the data file values o standard deviation of the data file values
You should create statistics for a layer if they do not exist. Certain Viewer functions (e.g., contrast tools) will not run without layer statistics. Rebuilding statistics for a raster layer may be necessary. For example, if you decide that you do not want to include zero file values in the statistics calculation (and they are currently included), you could rebuild the statistics without zero file values.
25
Map Information
Map information for a raster layer will be created only when the layer has been georeferenced. If the layer has been georeferenced, the following information will be stored in the raster layer:
o upper left X,Y coordinates o pixel size o map unit used for measurement (e.g., meters, inches, feet) Map Projection Information
If the raster layer has been georeferenced, then the following projection information will be generated for the layer:
o map projection o spheroid o zone number Pyramid Layers

ERDAS IMAGINE gives you the option to pyramid large raster layers for faster processing and display in the Viewer. When you generate pyramid layers, reduced, subsampled raster layers are created from the original raster layer. The number of pyramid layers that are created depends on the size of the raster layer and the block size. For example, a raster layer which is 4k x 4k pixels could take a long time to display when using the Viewer Fit To Window option.Using the Compute Pyramid Layers option in ImageInfo will cause ERDAS IMAGINE to create additional raster layers successively reduced from 4k x 4k, to 2k x 2k, 1k x 1k, 512 x 512, 128 x 128, down to 64 x 64. Then ERDAS IMAGINE would select the pyramid layer size most appropriate for display in your Viewer window.
Reading and Writing .img Files

This section describes each of the C Toolkit packages that are needed to read and write ERDAS IMAGINE .img files. The detailed format of the .img file is documented in Machine Independent Format and HFA Object Directory. ERDAS IMAGINE functions are grouped into packages named with four letter mnemonics that always begin with a lowercase e. Each package focuses on some specific area of functionality. The complete reference pages for each package are accessible from Developers Toolkit Packages.
26
ERDAS IMAGINE .img Files Each package has an associated header file whose name is constructed from the package name plus the .h extension. All of the data types and function prototypes for the package are defined in the header file. Most packages create one or more types of structures. There are functions provided in each package to free the specific data type. The name is either exxx_DataTypeFree or exxx_DataTypeDelete. This section gives an overview of each package. Click on the package name to open the reference pages for that package. eerr The eerr package is the ERDAS IMAGINE error handling system. Most functions take a pointer to an Eerr_ErrorReport *. The Eerr_ErrorReport is a structure which contains an error code and an error message. If a NON-NULL value is returned for this argument then an error has occurred. The code can be checked and the message can printed. Whether or not the error report is printed, it is the callers responsibility to free it. emif The lowest level of the I/O packages is the emif (ERDAS Machine Independent Format) package. Emif provides tools for creating definitions of C structures so that they can be written to a file on one machine and read back on another with a different architecture. The emif package works with designs which reside in dictionaries. Each design is a description of a C structure. The design tells the emif package how to pack and unpack the data between the computers host memory and the storage medium. Each design is created and placed in a dictionary. The dictionary can be written out in a compact form. The details of the emif disk file format and dictionary format are given in the Machine Independent Format chapter. ehfa The ehfa (ERDAS Hierarchal File Architecture) package is built on top of the emif package. It provides the tools to create a tree structured collection of objects in a single file which can be written and read as named objects. Every node in an HFA file has a name. The full HFA node path name is formed by enumerating a colon separated list of all direct ancestors of that node starting from the root node. For example lanier.img(:Layer_1:Descriptor_Table:Histogram) is the name of the table which contains the histogram information for Layer_1 in the file lanier.img. A directory of the objects stored in an IMAGINE .img file are given in the HFA Object Directory chapter.
27
ERDAS IMAGINE .img Files edsc The edsc package is used to create and maintain descriptor tables. A descriptor table is a node in the file which contains one or more columns of information. The main descriptor table in a .img file is used to store information which is specific to each pixel value, such as histograms or contrast tables. At other times, they are simply used to store a variable list of objects that have common attributes such as ground control points. Each column in a descriptor table can be though of as an array of integers, floats, or strings. All columns in a given table must have the same number of elements. eprj The eprj package provides the functions used to create, manipulate, and maintain map and projection information. The map information describes the map origin and cell size for the pixels in an image which are used to convert from pixel row column to map x, y. The projection information is used to convert from map x,y to latitude, longitude. The HFA Object Directory chapter contains a description of the information found in the projection record in the file. esta The esta package provides the functions used to create, manipulate, and maintain image statistics. These include single layer statistics such as mean, maximum, minimum, standard deviation, and multilayer statistics such as the covariance matrix. eimg The eimg package is the main interface to ERDAS IMAGINE .img files. It is built upon the previously described packages and, for the most common operations of reading and writing image data, it provides the complete interface to the ERDAS IMAGINE .img files. estr The estr (string) package provides a number of functions for manipulating strings of characters and arrays of strings of characters. emap The emap package contains functions for reading and writing map composition files.
28
Hardcopy Device Drivers
Hardcopy Device Drivers Introduction

The IMAGINE Developers Toolkit can be utilized by a hardware distributor to develop a device driver that will read image files in ERDAS IMAGINE format and output the raster data to one of the distributors hardcopy output devices. This chapter discusses the elements of the map creation process in ERDAS IMAGINE that are relevant to the development of a device driver of this sort. To fully integrate a distributors hardware with ERDAS IMAGINE software, the following four items must be provided by the distributor to those clients who wish to use the distributors hardware from within ERDAS IMAGINE:
o a Preference Definition File - describes the hardware parameters o a device setup file - incorporates the printer into the print job spooling system o a raster filter - converts data from ERDAS IMAGINE format o an installation script - places the files above in the appropriate directories
This documentation includes instructions for creating these four files.
Roles of Map Composer, Mapmaker, and Printmanager

Map Composer is a program within ERDAS IMAGINE that enables users to create maps. Maps are created graphically on the screen but the actual file created (.map extension) is an HFA file containing a description of the map. Mapmaker is a program within ERDAS IMAGINE that transforms a map composition from a multi-file form where each file represents all of the graphics for a specific element or set of elements of a map, to a different multi-file form where each file represents all of the graphics for a specific area of the map. Printmanager is a program within ERDAS IMAGINE that delivers panel files created by Mapmaker to a printer.
Running Map Composer, Mapmaker, and Printmanager

The Mapmaker program is invoked when you select the Print Map Composition option from Map Composer. During execution, Mapmaker creates the following files:
o one or more panel files - containing bitmapped data for the map
29
o one or more name files - each containing the full path name of a panel file o one plot file - containing the list of name files o one configuration file - containing replacement values for hardware parameters specified at
the time of printing The following table shows the file naming convention: File Type map le plot le conguration le panel le name le PDF raster lter device setup script File Name Structure filename.map filename.plt printers.filename.plt.cfg filename.plt.panel_# filename.plt.panel_#.name
printername.pdf
vf_printername printer_printername
Mapmaker handles all of the rendering details including conversion of graphics (lines, polygons, text, etc.) into a raster form. It also handles the use of halftoning to approximate continuous tones on a binary device. Mapmaker reads the map file created by Map Composer, and renders it into one or more panels according to a Preference Definition File (PDF). A panel is a generic term for a section of the map that will fit onto a single piece of paper. The PDF defines, among other things, the paper size available in the selected printer. The output product from the example .map file above contains a grayscale image, a vector data layer, and an annotation layer. The basic structure is depicted in Figure 1.
30
7.5 inches
5.0 inches
map clip
ATLANTIS 5.0 inches 10.0 inches
1.3 in map origin 3.0 inches
plot origin Figure 1: Example Plot Layout Mapmaker reads the PDF file which describes the characteristics of the selected printer. (See Preference Definition File for details.) Mapmaker uses these characteristics to determine the number of panels it needs to fully cover the map composition, the panel file data type (1-bit, or 8-bit), and the halftone details (if it renders to 1-bit). It also passes all of the PDF values that were modified at the time of printing to the configuration file, printers.filename.plt.cfg, that is associated with the plot.
31
Hardcopy Device Drivers The panel file into which it renders is named filename.plt.panel_#. The # in the panel file name denotes the panel number. Panel numbers begin with 0. Panels are numbered from left to right and top to bottom. A six panel map would be arranged as shown in Figure 2.
0 2 4
1 3 5
Figure 2: Panel Arrangement Each individual panel file is no different from a .img file (the file format used to store raster data in ERDAS IMAGINE). Mapmaker also creates a name file which records the full path and name of all files associated with a panel file. This is especially useful for devices such as Postscript printers, where fonts can be downloaded to the printer separately. The naming convention for the name file is filename.plt.panel_#.name. If the correct argument is specified, Mapmaker will invoke Printmanager when each panel is complete. After Mapmaker finishes all of the panels, it makes a plot file, filename.plt, which contains all of the paths of the name files it has generated. This file allows the user to print selected panels at a later time via the Plotfile program by using the Print Plot File option in the Map Composer dialog box. Figure 3 below, and Figure 4 show how these pieces of software fit together.
32
Map Composer
PDF
plot file
configuration file map file Mapmaker name file
panel file IMAGINE files associated with map file
Figure 3: The ERDAS IMAGINE Map Composer and Mapmaker processes
33
plot file Mapmaker Plotfile
configuration file, panel file, name file Print manager
configuration file, panel file, name file
System Queue with IMAGINE Print Accelerator
System Queue
JetDirect or Calcomp981
control data file
converted panel data file
converted panel data file
printer job spooling system
printer job spooling system
raster filter
printer
printer
Network printer
Figure 4: Relationship of Vendor Software and Hardware to the ERDAS IMAGINE Plotfile and Printmanager processes 34
The Preference Definition File

Device driver developers must define a Preference Definition File which describes the parameters of the I/O device which they wish to drive. In conjunction with special facilities in ERDAS IMAGINE, the Preference Definition File (PDF) provides the user with a graphical way of modifying the values of parameters used to output maps to the hardware associated with the PDF. The PDF is read by ERDAS IMAGINEs Configuration Manager which uses the information to allow the Configuration Editor to generate a graphical display similar to the one in Figure 5. Some of the parameters specified in a PDF are used by Mapmaker. These parameters have fixed names which must be used if Mapmaker is to identify the appropriate parameter values for the parameters it seeks. For example, media size, number of colors, number of copies, and dot density are all determined by Mapmaker by seeking from the Configuration Manager the values of certain reserved preference names. Other parameters of the PDF are used by the Configuration Editor to tie the printer into the workstations printer job spooling system. These parameters, like the ones used by Mapmaker, have reserved names. Parameters other than these two types may be specified in a PDF. These additional parameters would be specific to the hardware associated with the PDF and they would by placed in a PDF so the raster filter created to drive the hardware could access their configured values at the time of printing. The PDF should have the name printername.pdf where printername is a name similar to the name of the hardware that the PDF governs. The complete syntax of the PDF is described below. In brief, the PDF syntax supports the definition of the following types of parameters:
o character string
Example:
model (Printer Model) : Kodak XL7700 Printer manufacture and model;
o enumerated
Example:
color (Color Options): RGB Printer color paths enums { RGB Red green Blue Black Black Only };
o numeric
Example:
35

numcopies (Number of Copies) : 1 Number of copies to print min 1 max 1000;
o boolean
Example:
mirror (Use a Mirrored Image) : false Is the image mirrored? boolean true false;
The Preference Definition File syntax is described by the following BNF. A complete example is given in a Preference Definition File Example.
<PDF File> <PD List> <PD> <Boolean Dflt> <True Dflt> <False Dflt> <String Dflt> <Number Dflt> <Enum Dflt> <Boolean Info> <String Info> <Number Info> <Number Min> <Number Max> <Enum Info> <Enum Data> <Enum> <Enum Choice> <Enum Help> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> -> <PD> <PD List> <PD> <PD List> | NULL : ; NAME ( STRING ) | NULL <Boolean Dflt> | <String Dflt> | <Number Dflt> | <Enum Dflt> <True Dflt> | <False Dflt> yes | on | true STRING expand STRING | STRING NUMBER STRING STRING <Boolean Info> | <String Info> | <Number Info> | <Enum Info> boolean STRING STRING maxlength NUMBER | NULL <Number Min> <Number Max> min NUMBER | NULL max NUMBER | NULL ENUMS { <Enum> <Enum Data> } <Enum> <Enum Data> | NULL <Enum Choice> <Enum Help> STRING STRING
If we use regular expression syntax of the type used by egrep, we can define the terminal symbols as follows:
NAME[a-zA-Z] [a-zA-Z0-9_]*
(i.e., any sequence of alphanumeric characters beginning with an alphabetic character. NAMEs are not case sensitive so Name, NAME and name will all be recognized as the same NAME.)
STRING([^]*(\\)?)*
(i.e., any sequence of characters between double quotes. Quoted double quotes should be protected by backslashes)
NUMBER-?([0-9]*\.?[0-9]+|[0-9]+\.?[0-9]*)([Ee]([-\+])?[0-9]+)? NULLis null
36
Hardcopy Device Drivers Once a parameter has been defined in the PDF, the value of that parameter can be modified to a preferred value by the user through the ERDAS IMAGINE Configuration Editor. For this reason, the parameters described by a PDF are referred to as preferences. The dialog box that is automatically generated by ERDAS IMAGINEs Configuration Editor for the example PDF is shown in Figure 5, below. The numbered key can be used to match a portion of the PDF syntax with its corresponding graphical display.
Figure 5: Preference Dialog Example 37
Hardcopy Device Drivers 1 The preference title allows the user to identify the values that he would like to modify during printer configuration. In this example, the preference title of the model preference (Printer Model) is reflected in the graphical display. Numeric preferences are displayed in an editable textnumber field. The user can change this value by typing or by clicking the small nudgers on the right side of the field. In this example, the default value of the mediawidth preference is reflected as 8.5000 in the graphical display. String preferences are displayed in an editable text field. The user can change the value by typing in this field. In this example, the default value for the model preference (Kodak XL7700) is reflected in the graphical display. Enumerated preferences are displayed as a popup list of the enumerated choices. The user can change the value by selecting a different option from the popup list. The default value of the unittype preference (BSD) is currently selected in this example. Boolean preferences are displayed as a shaded box. The true, yes, or on state is indicated by a black box that appears depressed. The false value is indicated by a gray box that appears raised. The user can change the value by clicking on the box. In this example, the value for the mirror preference is set to false, the default setting. The help string(s) provided in a preference definition is displayed in the single line help status bar of the Configuration Editor dialog box as the user moves the mouse over the preference titles. The enumerated help string corresponding to the currently selected enumerated choice is concatenated to the main help string in the case of enumerated preferences.
<Number Dflt>
<String Dflt>
<Enum Dflt>
<Boolean Dflt>
{:<Enum Help>}
The table below shows a complete list of the preference names reserved by ERDAS IMAGINE. This table also indicates which preferences MUST be present in any new PDF created to support an output device (footnote a).
preferencename acceleratora
Preference Title Use Imagine Print Accelerator
Example Value yes
38
preferencename additivecolor autofont colora connectiona densitya densitywidtha densityheighta devicea directoryname dotsunittypea lename imaginenamea intenselevela mediawidth mediaheight mirror model numcopiesa othercommand plotpath postscriptlevel postscriptversion queuehosta queuetypea screenangle_black screenangle_cyan screenangle_magenta screenangle_yellow
Preference Title Use Positive Paper Send fonts to printer instead of plot le? Color Options Printer Connection Transparent Density Horizontal Dot Density Vertical Dot Density Local Device Output Directory Dot Units Output File Imagine Print Queue Name Color Intensity Level Media Width Media Height Use a Mirrored Image Printer Model Number of Copies Other Command ServeWare Plot Directory PostScript Level PostScript Version Printer Host Name Queue Type Black Screen Angle Cyan Screen Angle Magenta Screen Angle Yellow Screen Angle
Example Value "True" "False" "RGB" b System Queue Normal 203c 203d /dev/bpp0 $HOME "inch" <template>.out xl7700 256 8.5 11 "False" "Kodak XL7700" 1 lpr /usr/plots/imagine_plots 1 52.3 $HOSTNAMEd BSD 45 15 75 0
39
preferencename screenfrequency totalpixelheighta totalpixelwidtha unittype
Preference Title Halftone Screen Frequency Total Vertical Pixels Total Horizontal Pixels Media Units
Example Value 60 1536 2048 "inch" e
a. This preference MUST be present in any new PDF created to support an output device. b. Colors are limited to red(R), green(G), blue(B), cyan(C), magenta(M), yellow(Y), and black(K) and certain combinations of 2 to 4 of these colors.You may use the color name with an initial capital letter or simply the capital letter designated beside the color name above. c. Zero (0) in this eld indicates no limit. d. This name is expanded to be the name of the host on which you are conguring the printer. e. Units of measure may be anything that is dened in <IMAGINE_HOME>/etc/units.dat.
The Device Setup Script

The function of the device setup script is to incorporate a printer that a user has defined in ERDAS IMAGINE into the print job spooling system of the workstation. An overview of the printer configuration process in ERDAS IMAGINE will make the necessary contents of the device setup script more understandable. Before a printer can be configured in ERDAS IMAGINE and used to print maps, the printer should be physically connected to a workstation or network and tested to ensure that data can be successfully sent to the device. The instructions for doing this are usually provided by the hardware vendor. To enable access to the printer from within ERDAS IMAGINE the user must:
o Use the ERDAS IMAGINE Configuration Editor to create a new printer device o Set the preferences of the newly created device to the desired values o Create a print queue for the new printer device on every workstation from which the user
wishes to access the printer To create a printer device, the user chooses a template of preferences for the device and gives the device a name. The name of the device is the name that will be used throughout ERDAS IMAGINE to refer to this printer configuration. The template of preferences is one of the PDF files that apply to printers. PDF files distributed by hardware vendors may be among the templates from which the user can choose.
40
Hardcopy Device Drivers As mentioned in the previous section, there are several preferences that pertain to printer device setup that must exist in each PDF that applies to a printer device. These preferences must be set by the user to appropriate values after the printer device is created in ERDAS IMAGINE and before the user attempts to create a print queue for the new printer. These preferences and their meanings are: imaginename - The ERDAS IMAGINE Configuration Editor allows any manner of name to be used for the printer device. For instance, the user could call a printer device LaserJet by Bobs desk. UNIX print queue names, on the other hand, are usually restricted in the form that they can take. In addition, for some devices that have their own internal queueing mechanism, the queue name must be fixed. The value of this preference will be used to construct the name of the UNIX queue for the printer. connection - The ERDAS IMAGINE Printmanager now supports several connection types, including local and remote system queues, network printers, and files. For third party device drivers, this option should always be set to System Queue so that the external printer driver is used. accelerator - This preference controls the delivery method used with printers connected to system queues. When it is off, the Printmanager spools the translated file. When it is on, the translating filter is run by the system queue and the Printmanager spools a small control file. For third party device drivers, this option should always be set to Yes so that the external printer driver is used. queuehost - This preference should be set to the host on which the local print queue for the printer resides. This is usually the machine to which the printer is actually attached. device - This preference should be set to the name of the device file through which the printer may be accessed. For printers that attach directly to the network, this preference is usually defined in the PDF with a default value of /dev/null. After setting the parameters appropriately, the user will attempt to create a print queue through the Configuration Editor. The Configuration Editor passes the printer name and the three preference values mentioned above, along with the name of the template on which the parameter definitions for this printer were based (the PDF file name) to a shell script called install_printer. This shell script produces another shell script that, when executed as the root user, will change the system files on the users workstation so that an appropriate print queue is created for this printer. This two stage process allows system administrators to examine the commands which will be run by IMAGINE, before executing scripts that change system configuration files.
41
Hardcopy Device Drivers The actual name of the queue created for the printer will depend on the queuehost, accelerator and imaginename preferences, along with the version of IMAGINE. If the printer is on a remote host, the first 3 letters from the queuehost value will be used as a prefix for the UNIX queue name. If the accelerator preference value is Yes (as it should be for all 3rd party drivers), the version of IMAGINE will be appended to the end of the UNIX queue name. So creating a queue on host oak to point to a printer named lp served on host spruce would result in a queue named sprlp. If this queue uses the accelerator, the queue would be named sprlp830 (assuming the user is using IMAGINE version 8.3). In order to be able to create a script that will modify the system configuration files appropriately for this particular printer, the install_printer script calls on a function named printer_create_printername where printername is the template name (PDF file name) passed to the install_printer script. This function may be defined externally because the install_printer script will source any file that it finds that is called printer_printername. Therefore, the device setup script that a hardware vendor must deliver with the PDF file and raster filter is a script called printer_printername. The script must contain at least one function definition, printer_create_printername, which defines a function capable of generating script commands that will add the printer to the printer control files of the host platform (e.g., /etc/printcap on the SUN). If the script cannot serve all architectures on which the printer is intended to be supported, override scripts must be provided for each supported architecture. These scripts must be named o_printer_printername_arch where arch is one of the architecture names recognized by ERDAS IMAGINE. ARCH Name decosf hp700 rs6000 sgi sun4 sun4sol Company Name Digital Equipment Corp. Hewlett-Packard Co. International Business Machines Corp. Silicon Graphics, Inc. Sun Microsystems, Inc. (Sunos 4.1.4) Sun Microsystems, Inc. (Solaris2.5)
The install_printer script is distributed with the IMAGINE Developers Toolkit. It contains many examples of printer_create_printername function definitions representing the printer devices supported for ERDAS IMAGINE by ERDAS.
42
The Raster Filter

The raster filter is the actual device driver which can convert a .img formatted panel file to the format expected by the printer. This executable must be designed as a UNIX filter, i.e., it must read from the standard input and write to the standard output. The filter must be named vf_printername. Inside the Printmanager program of ERDAS IMAGINE, a control file is queued to the UNIX system queue. The control file will contain the specific control information listed below, with each item on a separate line.
Control Parameter verbose ag lter name xoffset yoffset number of copies data source lenames
Value Range 0 or 1 Name of output lter to be used integer integer integer les list of panel data le names, one per line
Therefore, in normal operating mode, the standard input for raster filter will receive control information similar to the example below from the printer job spooling system.
0 yourfilter 0 0 1 files /full/path/to/panel/file/on/nfs/mounted/drive/filename.plt.panel_#
The example C program, fxhardcopy.c, demonstrates one way to read raster data into a raster filter. Use the following command to output an ASCII representation of a 20X20 data value area of band 2 of the input image starting at row 30, column 40. This output may also be piped to more or redirected to an ASCII file. The file size will be about 108 Kilobytes. % runex fxhardcopy -in -x40 -y 30 -w 20 -h 20 -f 2 -t 2 <IMAGINE_HOME>/ examples/hardcopy_data.img
43
Hardcopy Device Drivers The program also shows how the preference values of preferences associated with the output device might be obtained. To enable the portion of code that obtains preference values, perform the following steps after the sample programs have been built (dire c tory name represents the full directory path into which the Developers Toolkit was installed, including the imagine830tk postfix): % cd directoryname % ln -s <IMAGINE_HOME>/examples/hardcopy_data.img hardcopy.plt.panel_0 % runex fxhardcopy -in -w0 -h0 directoryname/hardcopy.plt.panel_0 These steps simulate the environment within which a raster filter runs. The printers.hardcopy.plt.cfg file may be altered to simulate changes to the preference values during subsequent print jobs. Any preference values that are not mentioned in the printers.hardcopy.plt.cfg file have their default values taken from the / devices/printers/kodak.pdf file. Certain configuration information may also be obtained via the plotfileheader. This method of obtaining configuration information is becoming obsolete, however, and should be avoided where possible.
The Installation Script

An installation script is recommended. The installation script should copy the following files as shown:
o the raster filter vf_printername compiled for each architecture to be supported should be
place in the <IMAGINE_HOME>/bin/<ARCH> directory
o the PDF printername.pdf should be placed in the <IMAGINE_HOME>/devices/

printers directory
o the device setup script printer_printername and any override scripts named
o_printer_printername_<ARCH> should be place in the <IMAGINE_HOME>/bin directory and should be accessible through symbolic links from the <IMAGINE_HOME>/ install directory.
User Installation
After a hardware vendor installation script has been run, an IMAGINE user must:
o Start ERDAS IMAGINE o Configure the printer using the Configuration Editor
44
o Create a print queue creation script using the Configuration Editor and the print queue
creation script generated by the install_printer script. The newly configured printer will then be accessible from the various Map Composition dialog boxes and the user will be able to print maps to the printer.
Instructions for the user may be modeled after the example printer configuration instructions
in the ERDAS IMAGINE Installation Guide.
45
Machine Independent Format
Machine Independent Format MIF Data Elements

ERDAS IMAGINE uses the Machine Independent Format (MIF) to store data in a fashion which can be read by a variety of machines. This format provides support for converting data between the IMAGINE standard data format and that of the specific host's architecture. Files created using this package on one machine will be readable from another machine with no explicit data translation. Each MIF file is made up of one or more of the data elements explained below. EMIF_T_U1 (Unsigned 1-bit Integer) U1 is for unsigned 1-bit integers (0 - 1). This data type can be used for bitmap images with yes/ no conditions. When the data are read from a MIF file, they are automatically expanded to give one value per byte in memory. When they are written to the file, they are automatically compressed to place eight values into one output byte.
7 U1_7 byte 0
6 U1_6
5 U1_5
4 U1_4
3 U1_3
2 U1_2
1 U1_1
0 U1_0
(8 bits)
EMIF_T_U2 (Unsigned 2-bit Integer) U2 is for unsigned 2-bit integers (0 - 3). This data type can be used for thematic data with 4 or fewer classes. When the data are read from a MIF file they are automatically expanded to give one value per byte in memory. When they are written to the file, they are automatically compressed to place four values into one output byte.
7 U1_7 byte 0
5 U2_2
3 U2_1
2 1 U0_0
(8 bits)
46
Machine Independent Format EMIF_T_U4 (Unsigned 4-bit Integer) U4 is for unsigned 4-bit integers (0 - 15). This data type can be used for thematic data with 16 or fewer classes. When these data are read from a MIF file, they are automatically expanded to give one value per byte. When they are written to the file they are automatically compressed to place two values into one output byte.
7 U4_1 byte 0 (8 bits)
3 U4_0
EMIF_T_UCHAR (8-bit Unsigned Integer) This stores an 8-bit unsigned integer. It is most typically used to store characters and raster imagery
integer byte 0
EMIF_T_CHAR (8-bit Signed Integer) This stores an 8-bit signed integer.
integer byte 0
EMIF_T_USHORT (16-bit Unsigned Integer) This stores a 16-bit unsigned integer, stored in Intel byte order. The least significant byte (byte 0) is stored first.
47
15
integer (16 bits) byte 1 byte 0
EMIF_T_SHORT (16-bit Signed Integer) This stores a 16-bit twos-complement integer, stored in Intel byte order. The least significant byte is stored first.
15
EMIF_T_ENUM (Enumerated Data Types) This stores an enumerated data type as a 16-bit unsigned integer, stored in Intel byte order. The least significant byte is stored first. The list of strings associated with the type are defined in the data dictionary which is defined below. The first item in the list is indicated by 0.
15
EMIF_T_ULONG (32-bit Unsigned Integer) This stores a 32-bit unsigned integer, stored in Intel byte order. The least significant byte is stored first.
48
31 integer byte 3 (32 bit) byte 2 byte 1
0 byte 0
EMIF_T_LONG (32-bit Signed Integer) This stores a 32-bit twos-complement integer value, stored in Intel byte order. The least significant byte is stored first.
0 byte 0
EMIF_T_PTR (32-bit Unsigned Integer) This stores a 32-bit unsigned integer, which is used to provide a byte address within the file. Byte 0 is the first byte, byte 1 is the second, etc. This allows for indexing into a 4-Gigabyte file, however most UNIX systems only allow 2-Gigabyte files.
Currently, this element appears in the data dictionary as a EMIF_T_ULONG element. In future versions of the file format, the EMIF_T_PTR will be expanded to an 8-byte format which will allow indexing using 64 bits which allow addressing of 16 billion Gigabytes of file space.
0 byte 0
49
Machine Independent Format EMIF_T_TIME (32-bit Unsigned Integer) This stores a 32-bit unsigned integer, which represents the number of seconds since 00:00:00 1 JAN 1970. This is the standard used in UNIX time keeping. The least significant byte is stored first.
0 byte 0
EMIF_T_FLOAT (Single Precision Floating Point) Single precision floating point values are IEEE floating point values.
s = sign (0 = positive, 1 = negative) exp = 8 bit excess 127 exponent fraction = 24 bits of precision (includes
1 implied bit)
31 30 s exp byte 3
23 22 fraction byte 2 byte 1 byte 0
EMIF_T_DOUBLE (Double Precision Floating Point) Double precision floating point data are IEEE double precision.
1 implied bit)
63 62 s exp byte 7
52 51 fraction byte 6 byte 5 byte 4 byte 3 byte 2 byte 1
0 byte 0
50
Machine Independent Format EMIF_T_COMPLEX (Single Precision Complex) A complex data element has a real part and an imaginary part. Single precision floating point values are IEEE floating point values.
1 implied bit)
Real part: first single precision
31 30 s exp byte 3
Imaginary part: second single precision
31 30 s exp byte 7
EMIF_T_DCOMPLEX (Double Precision Complex) A complex data element has a real part and an imaginary part. Double precision floating point data are IEEE double precision.
1 implied bit)
Real part: first double precision
51
63 62 s exp byte 7
0 byte 0
Imaginary part: second double precision
63 62 s exp byte 15
0 byte 8
EMIF_T_BASEDATA (Matrix of Numbers) A BASEDATA is a generic two dimensional array of values. It can store any of the types of data used by IMAGINE. It is a variable length object whose size is determined by the data type, the number of rows, and the number of columns. numrows: This indicates the number of rows of data in this item.
0 byte 0
numcolumns: This indicates the number of columns of data in this item.
0 byte 4
52
Machine Independent Format datatype: This indicates the type of data stored here. The types are: Data Type 0 1 3 4 5 6 7 8 9 10 11 12 13 EMIT_T_U1 EMIF_T_U2 EMIT_T_U4 EMIF_T_UCHAR EMIF_T_CHAR EMIF_T_USHORT EMIF_T_SHORT EMIF_T_ULONG EMIF_T_LONG EMIF_T_FLOAT EMIF_T_DOUBLE EMIF_T_COMPLEX EMIF_T_DCOMPLEX BytesPerObject 1/8 1/4 1/2 1 1 2 2 4 4 4 8 8 16
15
objecttype: This indicates the object type of the data. This is used in the IMAGINE Spatial Modeler. The valid values are: 0 1 2 SCALAR. This will not normally be the case, since a scalar has a single value. TABLE: This indicates that the object is an array. The numcolumns should be 1. MATRIX: This indicates the number of rows and columns is greater than one. This is used for Coefcient matrices, etc.
53
RASTER: This indicates that the number of rows and columns is greater than one and the data are just a part of a larger raster object. This would be the case for blocks of images which are written to the le.
15
data: This is the actual data. The number of bytes is given as: bytecount = numrows x numcolumns x BytesPerObject EMIF_M_INDIRECT (Indication of Indirect Data) This is used when the following data belongs to an indirect reference of data. For example, when one object is defined by referring to another object. The first four bytes provide the object repeat count.
0 byte 0
The next four bytes provide the file pointer which points to the data comprising the object.
0 byte 4
54
Machine Independent Format EMIF_M_PTR (Indication of Indirect Data) This is used when the following data belong to an indirect reference of data of variable length. For example, when one object is defined by referring to another object. This is identical in file format to the EMIF_M_INDIRECT element. Its main difference is in the memory resident object which gets created. In the case of the EMIF_M_PTR the count and data pointer are placed into memory. Whereas only the data gets placed into memory when the EMIF_M_INDIRECT element is read in. (The size of the object is inherent in the data definitions.) The first four bytes provide the object repeat count.
0 byte 0
The next four bytes provide the file pointer which points to the data comprising the object.
0 byte 4
55
MIF Data Dictionary

IMAGINE HFA files have a data dictionary that describes the contents of each of the different types of nodes. The dictionary is a compact ASCII string which is usually placed at the end of the file. A pointer to the start of the dictionary is stored in the header of the file. Each object is defined like a structure in C, and consists of one or more items. Each item is composed of an ItemType and a name. The ItemType indicates the type of data and the name indicates the name by which the item will be known. The syntax of the dictionary string is: Dictionary
ObjectDenition[ObjectDenition...] . The dictionary is one or more ObjectDenitions terminated by a period. This is the complete collection of object type denitions.
{ItemDenition[ItemDenition...] }name , An ObjectDenition is an ItemDenition enclosed in braces {} followed by a name and terminated by a comma. This is a complete denition of a single object. num ber :[*|p]ItemTy pe [EnumData]name , An ItemDenition is a number followed by a colon, followed optionally by either an asterisk or a p, followed by an ItemType, followed optionally by EnumData, followed by an item name, and terminated by a comma. This is the complete denition of a single Item. The * and the p both indicate that when the data are read into memory, they will not be placed directly into the structure being built, but that a new structure will be allocated and lled with the data. The pointer to that structure is placed into the initial structure. The asterisk indicates that the number of items in the indirect object is given by the number in the item denition. The p indicates that the number is variable. In both cases, the count precedes the data in the input stream.
ObjectDenition
ItemDenition
56
EnumData
number :name ,[<name>,...] EnumData is a number, followed by a colon, followed by one or more names each of which is terminated by a comma. The number denes the number of names which will follow. This is the complete set of names associated with an individual enum type.
Any sequence of alphanumeric characters excluding the comma. A positive integer number. This composed of any sequence of these digits: 0,1,2,3,4,5,6,7,8,9. 1| 2| 4| c| C| s| S| l| L| f| d| t| m| M| b| e| o| x This is used to indicate the type of an item. The following table indicates how the characters correspond to one of the basic EMIF_T types.
name number
ItemType
This table describes the single character codes used to identify the ItemType in the MIF Dictionary Definition. The Interpretation column describes the type of data indicated by the item type. The Number of Bytes column is the number of bytes that the data type will occupy in the MIF file. If the number of bytes is not fixed, then it is given as dynamic. ItemTyp e 1 2 4 c C e s S t l L f Interpretation EMIF_T_U1 EMIF_T_U2 EMIF_T_U4 EMIF_T_UCHAR EMIF_T_CHAR EMIF_T_ENUM. EMIF_T_USHORT EMIF_T_SHORT EMIF_T_TIME EMIF_T_ULONG EMIF_T_LONG EMIF_T_FLOAT Number of Bytes 1 1 1 1 1 2 2 2 4 4 4 4
57
ItemTyp e d m M b o
Interpretation EMIF_T_DOUBLE EMIF_T_COMPLEX EMIF_T_DCOMPLEX EMIT_T_BASEDATA Previously dened object. This indicates that the description of the following data has been previously dened in the dictionary. This is like using a previously dened structure in a structure denition. Dened object for this entry. This indicates that the description of the following data follows. This is like using a structure denition within a structure denition.
Number of Bytes 8 8 16 dynamic dynamic
dynamic
58
HFA Object Directory

The following section defines the list of objects which comprise ERDAS IMAGINE image files (.img extension). This is not a complete list because users and developers may create new items and add them to any ERDAS IMAGINE file. The image files created and used by ERDAS IMAGINE are stored in a hierarchical file architecture (HFA). This format allows any number of different types of data elements to be stored in the file in a tree structured fashion. This tree is built of nodes which contain a variety of types of data. The contents of the nodes (as well as the structural information) is saved in the file in a machine independent format (MIF) which allows the files to be shared between computers of differing architectures.
Hierarchical File Architecture

The hierarchical file architecture maintains an object-oriented representation of data in an ERDAS IMAGINE disk file through use of a tree structure. Each object is called an entry and occupies one node in the tree. Each object has a name and a type. The type refers to a description of the data contained by that object. Additionally each object may contain a pointer to a subtree of more nodes. All entries are stored in MIF and can be accessed directly by name.
Header
Dictionary
Root Node
Node_1 Data
Node_2
Node_3
Data
Data
Node_4 Data
Node_5
Data
Figure 6: HFA File Structure
59
HFA Object Directory Nodes and Objects Each node within the HFA tree structure contains an object and each object has its own data. The types of objects in a file are dependent upon the type of file. For example, a .img file will have different objects than an .ovr file because these files store different types of data. The list of objects in a file is not fixed. Objects may be added or removed depending on the data in the file (e.g., not every .img file with continuous raster layers will have a node for ground control points). Figure 9, below, is an example of an HFA file structure for a thematic raster layer in a .img file. If there were more attributes in the ERDAS IMAGINE Raster Attribute Editor, then they would appear as objects under the Descriptor Table object.
Layer_1 Eimg_Layer
Statistics Esta_Statistics
Descriptor Table Edsc_Table
Projection Eprj_Pro Parameters
#Bin Function# Edsc_Bin Function
Red Edsc_Column
Green Edsc_Column
Blue Edsc_Column
Class_Names Histogram Edsc_Column Edsc_Column
Figure 7: HFA File Structure Example
60
Pre-defined HFA File Object Types

There are three categories of pre-defined HFA File Object Types found in .img files:
o Basic HFA File Object Types o .img Object Types o External File Format Header Object Types
These sections list each object with two different detailed definitions. The first definition shows you how the object appears in the data dictionary in the HFA file. The second definition is a table that shows you the type, name, and description of each item in the object. An item within an object can be an element or another object.
If an item is an element, then the item type is one of the basic types previously given with the EMIF_T_ prefix omitted. For example, the item type for EMIF_T_CHAR would be shown as CHAR.
If an item is a previously defined object type, then the type is simply the name of the previously defined item. If the item is an array, then the number of elements is given in square brackets [n] after the type. For example, the type for an item with an array of 16 EMIF_T_CHAR would appear as CHAR[16]. If the item is an indirect item of fixed size (it is a pointer to an item), then the type is followed by an asterisk *. For example, a pointer to an item with an array of 16 EMIF_T_CHAR would appear as CHAR[16] *. If the item is an indirect item of variable size (it is a pointer to an item and the number of items), then the type is followed by a p. For example, a pointer to an item with a variable sized array of characters would look like CHAR p.
If the item type is shown as PTR, then this item will be encoded in the data dictionary as a ULONG element.
61
Basic Objects of an HFA File

This is a list of types of basic objects found in all HFA files:
o Ehfa_HeaderTag o Ehfa_File o Ehfa_Entry

Ehfa_HeaderTag The Ehfa_HeaderTag is used as a unique signature at the beginning of an ERDAS IMAGINE HFA file. It must always occupy the first 20 bytes of the file. {16:clabel,1:lheaderPtr,}Ehfa_HeaderTag, Type CHAR[16] PTR Name label headerPtr Description This contains the string EHFA_HEADER_TAG The le pointer to the Ehfa_File header record.
Ehfa_File The Ehfa_File is composed of several main parts, including the free list, the dictionary, and the object tree. This entry is used to keep track of these items in the file, since they may begin anywhere in the file. {1:Lversion,1:lfreeList,1:lrootEntryPtr,1:SentryHeaderLength,1:ldictionaryPtr,} Ehfa_File, Type LONG PTR Name version freeList Description This denes the version number of the ehfa le. It is currently 1. This points to list of freed blocks within the le. This list is searched rst whenever new space is needed. As blocks of space are released in the le, they are placed on the free list so that they may be reused later. This points to the root node of the object tree.
PTR
rootEntryPtr
62
Type SHORT
Name entryHeaderLength
Description This denes the length of the entry portion of each node. Each node consists of two parts. The rst part is the entry which contains the node name, node type, and parent/child information. The second part is the data for the node. This points to the starting position of the le for the MIF Dictionary. The dictionary must be read and decoded before any of the other objects in the le can be decoded.
PTR
dictionaryPtr
Ehfa_Entry The Ehfa_Entry contains the header information for each node in the object tree, including the name and type of the node as well as the parent/child information. {1:lnext,1:lprev,1:lparent,1:lchild,1:ldata,1LdataSize,64:cname,32:ctype, 1:tmodTime,}Ehfa_Entry, Type PTR Name next Description This is a le pointer which gives the location of the next node in the tree at the current level. If this is the last node at this level, then this contains 0. This is a le pointer which gives the location of the previous node in the tree at the current level. If this is the rst node at this level, then this contains 0. This is a le pointer which gives the location of the parent for this node. This is 0 for the root node. This is a le pointer which gives the location of the rst of the list of children for this node. If there are no children, then this contains 0. This points to the data for this node. If there is no data for this node then it contains 0. This contains the number of bytes contained in the data record associated with this node.
PTR
prev
PTR
parent
PTR
child
PTR LONG
data dataSize
63
Type CHAR[64]
Name name
Description This contains a NULL terminated string that is the name for this node. The string can be no longer then 64 bytes including the NULL terminator byte. This contains a NULL terminated string which names the type of data to be found at this node. The type must match one of the types found in the data dictionary. The type name can be no longer then 32 bytes including the NULL terminator byte. This contains the time of the last modication to the data in this node.
CHAR[32]
type
TIME
modTime
64
Objects of a .img File

This is a list of types of pre-defined objects commonly found in .img HFA files:
o Eimg_Layer o Eimg_Layer_SubSample o Eimg_NonInitializedValue o Ehfa_Layer o Edms_VirtualBlockInfo o Edms_FreeIDList o Edms_State o Edsc_Table o Edsc_BinFunction o Edsc_Column o Eded_ColumnAttributes_1 o Esta_Statistics o Esta_Covariance o Esta_SkipFactors o Esta_ExcludedValues o Eprj_Datum o Eprj_Spheroid o Eprj_ProParameters o Eprj_Coordinate o Eprj_Size o Eprj_MapInfo o Efga_Polynomial
65
o Calibration_Node
Eimg_Layer An Eimg_Layer object is the base node for a single layer of imagery. This object describes the basic information for the layer, including its width and height in pixels, its data type, and the width and height of the blocks used to store the image. Other information such as the actual pixel data, map information, projection information, etc., are stored as child objects under this node. The child objects that are usually found under the Eimg_Layer include:
o RasterDMS (an Edms_State which actually contains the imagery) o Descriptor_Table (an Edsc_Table object which contains the histogram and other pixel value
related data)
o Projection (an Eprj_ProParameters object which contains the projection information) o Map_Info (an Eprj_MapInfo object which contains the map information) o Ehfa_Layer (an Ehfa_Layer object which describes the type of data in the layer)
{1:lwidth,1:lheight,1:e3:thematic,athematic,fft of real valued data, layerType,1e13:u1,u2,u4,u8, s8,u16,s16,u32,s32,f32,f64,c64,c128,pixelType, 1:lblockWidth,1:lblockHeight,} Eimg_Layer, Type LONG LONG ENUM Name width height layerType Description The width of the layer in pixels. The height of the layer in pixels. The type of layer. 0=thematic 1=athematic
66
Type ENUM
Name pixelType
Description The type of the pixels. 0=u1 1=u2 2=u4 3=u8 4=s8 5=u16 6=s16 7=u32 8= s32 9=f32 10=f64 11=c64 12=c128 The width of each block in the layer. The height of each block in the layer.
LONG LONG
blockWidth blockHeight
Eimg_Layer_SubSample An Eimg_Layer_SubSample object is a node which contains a subsampled version of the layer defined by the parent node. The node of this form are named _ss_2, _ss_4, _ss_8, etc. This stands for SubSampled by 2, SubSampled by 4, etc. This node will have an Edms_State node called RasterDMS and an Ehfa_Layer node called Ehfa_layer under it. This will be present if pyramid layers have been computed. {1:lwidth,1:lheight,1:e3:thematic,athematic,fft of real valued data, layerType,1e13:u1,u2,u4,u8, s8,u16,s16,u32,s32,f32,f64,c64,c128,pixelType, 1:lblockWidth,1:lblockHeight,} Eimg_Layer_SubSample, Type LONG LONG ENUM Name width height layerType Description The width of the layer in pixels. The height of the layer in pixels. The type of layer. 0 =thematic 1 =athematic
67
Type ENUM
Name pixelType
Description The type of the pixels. 0=u1 1=u2 2=u4 3=u8 4=s8 5=u16 6=s16 7=u32 8=s32 9=f32 10=f64 11=c64 12=c128 The width of each block in the layer. The height of each block in the layer.
LONG LONG
blockWidth blockHeight
Eimg_NonInitializedValue The Eimg_NonInitializedValue object is used to record the value that is to be assigned to any uninitialized blocks of raster data in a layer. {1:*bvalueBD,}Eimg_NonInitializedValue, Type BASEDATA * Name valueBD Description A basedata structure containing the excluded values
Ehfa_Layer The Ehfa_Layer is used to indicate the type of layer. The initial design for the IMAGINE files allowed for both raster and vector layers. Currently, the vector layers have not been implemented.
68
HFA Object Directory {1:e2:raster,vector,type,1:ldictionaryPtr,}Ehfa_Layer, Type ENUM Name type Description The type of layer. 0=raster 1=vector This points to a dictionary entry which describes the data. In the case of raster data, it points to a dictionary pointer which describes the contents of each block via the RasterDMS denition given below.
ULONG
dictionaryPtr
RasterDMS The RasterDMS object definition must be present in the EMIF dictionary pointed to by an Ehfa_Layer object that is of type raster. It describes the logical make-up of a block of raster data in the Ehfa_Layer. The physical representation of the raster data is actually managed by the DMS system through objects of type Ehfa_Layer and Edms_State. The RasterDMS definition should describe the raster data in terms of total number of data values in a block and the type of data value. {<n>:<t>data,}RasterDMS, Type <t>[<n>] Name data Description The data is described in terms of total number, <n>, of data le values in a block of the raster layer (which is simply <block width> * <block height>) and the data value type, <t>, which can have any one of the following values: 1 - Unsigned 1-bit 2 - Unsigned 2-bit 4 - Unsigned 4-bit c - Unsigned 8-bit C - Signed 8-bit s - Unsigned 16-bit S - Signed 16-bit l - Unsigned 32-bit L - Signed 32-bit f - Single precision oating point d - Double precision oating point m - Single precision complex M - Double precision complex
69
HFA Object Directory Edms_VirtualBlockInfo An Edms_VirtualBlockInfo object describes a single raster data block of a layer. It describes where to find the data in the file, how many bytes are in the data block, and how to unpack the data from the block. For uncompressed data the unpacking is straight forward. The scheme for compressed data is described below. {1:SfileCode,1:loffset,1:lsize,1:e2:false,true,logvalid,1:e2:no compression,ESRI GRID compression,compressionType,1:LblockHeight,}Edms_VirtualBlockInfo, Type SHORT Name leCode Description This is included to allow expansion of the layer into multiple les. The number indicates the le in which the block is located. Currently this is always 0, since the multiple le scheme has not been implemented. This points to the byte location in the le where the block data actually resides. The number of bytes in the block. This indicates whether the block actually contains valid data. This allows blocks to exist in the map, but not in the le. 0=false 1=true This indicates the type of compression used for this block. 0=no compression 1=ESRI GRID compression No compression indicates that the data located at offset are uncompressed data. The stream of bytes is to be interpreted as a sequence of bytes which denes the data as indicated by the data type. The ESRI GRID compression is a two stage run-length encoding.
PTR LONG ENUM
offset size logvalid
ENUM
compressionType
For uncompressed blocks, the data are simply packed into the block one pixel value at a time. Each pixel is read from the block as indicated by its data type. All non-integer data are uncompressed. The compression scheme used by ERDAS IMAGINE is a two level run-length encoding scheme. If the data are an integral type, then the following steps are performed:
70
o The minimum and maximum values for a block are determined. o The byte size of the output pixels is determined by examining the difference between the
maximum and the minium. If the difference is less than or equal to 256, then 8-bit data are used. If the difference is less than 65,536 then, 16-bit data are used, otherwise 32-bit data are used.
o The minimum is subtracted from each of the values. o A run-length encoding scheme is used to encode runs of the same pixel value. The data
minimum value occupies the first 4 bytes of the block. The number of run-length segments occupies the next 4 bytes, and the next 4 bytes are an offset into the block which indicates where the compressed pixel values begin. The next byte indicates the number of bits per pixel (1,2,4,8,16,32). These four values are encoded in the standard MIF format (ULONG). Following this is the list of segment counts, following the segment counts are the pixel values. There is one segment count per pixel value.
No compression scheme is used if the data are non-integral. min num segments data offset numbits per value data counts data values
Each data count is encoded as follows: next 8 bits next 8 bits next 8 bits byte count byte 0 high 6 bits
byte 3
byte 2
byte 1
There may be 1, 2, 3, or 4 bytes per count. The first two bits of the first count byte contains 0,1,2,3 indicating that the count is contained in 1, 2,3, or 4 bytes. Then the rest of the byte (6 bits) represent the six most significant bytes of the count. The next byte, if present, represents decreasing significance.
This order is different than the rest of the package. This was done so that the high byte with the encoded byte count would be first in the byte stream. This pattern is repeated as many times as indicated by the numsegments field.
The data values are compressed into the remaining space packed into as many bits per pixel as indicated by the numbitpervalue field.
71
HFA Object Directory Edms_FreeIDList An Edms_FreeIDList is used to track blocks which have been freed from the layer. The freelist consists of an array of min/max pairs which indicate unused contiguous blocks of data which lie within the allocated layer space. Currently this object is unused and reserved for future expansion. {1:Lmin,1:Lmax,}Edms_FreeIDList, Type LONG LONG Name min max Description The minimum block number in the group. The maximum block number in the group.
Edms_State The Edms_State describes the location of each of the blocks of a single layer of imagery. Basically, this object is an index of all of the blocks in the layer. {1:lnumvirtualblocks,1:lnumobjectsperblock,1:lnextobjectnum, 1:e2:no compression,RLC compression,compressionType, 0:poEdms_VirtualBlockInfo,blockinfo,0:poEdms_FreeIDList,freelist, 1:tmodTime,}Edms_State, Type LONG LONG LONG Name numvirtual blocks numobjectsper block nextobjectnum Description The number of blocks in this layer. The number of pixels represented by one block. Currently, this type is not being used and is reserved for future expansion.
72
Type ENUM
Name compressionType
Description This indicates the type of compression used for this block. 0=no compression 1=ESRI GRID compression No compression indicates that the data located at offset are uncompressed data. The stream of bytes is to be interpreted as a sequence of bytes which denes the data as indicated by the data type. The ESRI GRID compression is a two stage run-length encoding. This is the table of entries which describes the state and location of each block in the layer. Currently, this type is not being used and is reserved for future expansion. This is the time of the last modication to this layer.
Edms_VirtualBolckInfo p
blockinfo
Edms_FreeIDList p
freelist
TIME
modTime
Edsc_Table An Edsc_Table is a base node used to store columns of information. This serves simply as a parent node for each of the columns which are a part of the table. {1:lnumRows,} Edsc_Table, Type LONG Name numRows Description This denes the number of rows in the table.
Edsc_BinFunction The Edsc_BinFunction describes how pixel values from the associated layer are to be mapped into an index for the columns.
73
HFA Object Directory {1:lnumBins,1:e4:direct,linear,logarithmic,explicit,binFunction Type, 1:dminLimit,1:dmaxLimit,1:*bbinLimits,} Edsc_BinFunction, Type LONG ENUM Name numBins binFunction Type Description The number of bins. The type of bin function. 0=direct 1=linear 2=exponential 3=explicit The lowest value dened by the bin function. The highest value dened by the bin function. The limits used to dene the bins.
DOUBLE DOUBLE BASEDATA
minLimit maxLimit binLimits
The following table describes how the binning functions are used. Bin Type DIRECT Description Direct binning means that the pixel value minus the minimum is used as is with no translation to index into the columns. For example, if the minimum value is zero, then value 0 is indexed into location 0, 1 is indexed into 1, etc. Linear binning means that the pixel value is rst scaled by the formula: index = (value-minLimit)*numBins/(maxLimit-minLimit). This allows a very large range of data, or even oating point data, to be used to index into a table. Exponential binning is used to compress data with a large dynamic range. The formula used is index = numBins*(log(1+(value-minLimit)) / (maxLimit-minLimit). Explicit binning is used to map the data into indices using an arbitrary set of boundaries. The data are compared against the limits set in the binLimit table. If the pixel is less than or equal to the rst value, then the index is 0. If the pixel is less than or equal to the next value, then the index is 1, etc.
LINEAR
EXPONENTIAL
EXPLICIT
Edsc_Column The columns of information which are stored in a table are stored in this format. 74
HFA Object Directory {1:lnumRows,1:LcolumnDataPtr,1:e4:integer,real,comples,string,dataType, 1:lmaxNumChar,} Edsc_Column, Type LONG PTR Name numRows columnDataPtr Description The number of rows in this column. Starting point of column data in the le. This points to the location in the le which contains the data. The data type of this column 0=integer (EMIF_T_LONG) 1=real (EMIF_T_DOUBLE) 2=complex (EMIF_T_DCOMPLEX) 3=string (EMIF_T_CHAR) The maximum string length (for string data only). It is 0 if the type is not a String.
ENUM
dataType
LONG
maxNumChars
The types of information stored in columns are given in the following table. Name Histogram Data Type real Description This is found in the descriptor table of almost every layer. It denes the number of pixels which fall into each bin. This is found in the descriptor table of almost every thematic layer. It denes the name for each class. This is found in the descriptor table of almost every thematic layer. It denes the red component of the color for each class. The range of the value is from 0.0 to 1.0. This is found in the descriptor table of almost every thematic layer. It denes the green component of the color for each class. The range of the value is from 0.0 to 1.0. This is found in the descriptor table of almost every thematic layer. It denes the blue component of the color for each class. The range of the value is from 0.0 to 1.0.
Class_Names
string
Red
real
Green
real
Blue
real
75
Name Opacity
Data Type real
Description This is found in the descriptor table of almost every thematic layer. It denes the opacity associated with the class. A value of 0 means that the color will be solid. A value of 0.5 mean that 50% of the underlying pixel would show through, and 1.0 means that all of the pixel value in the underlying layer would show through. This is found in the descriptor table of most continuous raster layers. It is used to dene an intensity stretch which is normally used to improve contrast. The table is stored as normalized values from 0.0 to 1.0. This is found in the GCP_Table in les which have ground control points. This is the table of names for the points. This is found in the GCP_Table in les which have ground control points. This is the X coordinate for the point. This is found in the GCP_Table in les which have ground control points. This is the Y coordinate for the point. This is found in the GCP_Table in les which have ground control points. This is the name of the color that is used to display this point.
Contrast
real
GCP_Names
string
GCP_xCoords
real
GCP_yCoords
real
GCP_Color
string
Eded_ColumnAttributes_1 The Eded_ColumnAttributes_1 stores the descriptor column properties which are used by the Raster Attribute Editor for the format and layout of the descriptor column display in the Raster Attribute Editor CellArray. The properties include the position of the descriptor column within the CellArray, the name, alignment, format, and width of the column, whether the column is editable, the formula (if any) for the column, the units (for numeric data), and whether the column is a component of a color column. Each Eded_ColumnAttributes_1 is a child of the Edsc_Column containing the data for the descriptor column. The properties for a color column are stored as a child of the Eded_ColumnAttributes_1 for the red component of the color column.
76
HFA Object Directory {1:lposition,0:pcname,1:e2:FALSE,TRUE,editable, 1:e3:LEFT,CENTER,RIGHT,alignment,0:pcformat, 1:e3:DEFAULT,APPLY,AUTO-APPLY,formulamode,0:pcformula,1:dcolumnwidth, 0:pcunits,1:e5:NO_COLOR,RED,GREEN,BLUE,COLOR,colorflag,0:pcgreenname, 0:pcbluename,}Eded_ColumnAttributes_1, Type LONG Name position Description The position of this descriptor column in the Raster Attribute Editor CellArray. The positions for all descriptor columns are sorted and the columns are displayed in ascending order. The name of the descriptor column. This is the same as the name of the parent Edsc_Column node, for all columns except color columns, Color columns have no corresponding Edsc_Column. Species whether this column is editable. 0 = NO 1 = YES Alignment of this column in CellArray. 0 = LEFT 1 = CENTER 2 = RIGHT The format for display of numeric data. Mode for formula application. 0 = DEFAULT 1 = APPLY 2 = AUTO-APPLY The formula for the column. The width of the CellArray column The name of the units for numeric data stored in the column. Indicates whether column is a color column, a component of a color column, or a normal column. 0 = NO_COLOR 1 = RED 2 = GREEN 3 = BLUE 4 = COLOR
CHAR P
name
ENUM
editable
ENUM
alignment
CHAR P ENUM
format formulamode
CHAR P DOUBLE CHAR P ENUM
formula columnwidth units colorag
77
Type CHAR P
Name greenname
Description Name of green component column associated with color column. Empty string for other column types. Name of blue component column associated with color column. Empty string for other column types.
CHAR P
bluename
Esta_Statistics The Esta_Statistics is used to describe the statistics for a layer. {1:dminimum,1:dmaximum,1:dmean,1:dmedian,1d:mode,1:dstddev,}Esta_Statistics, Type DOUBLE Name minimum Description The minimum of all of the pixels in the image. This may exclude values as dened by the user. The maximum of all of the pixels in the image. This may exclude values as dened by the user. The mean of all of the pixels in the image. This may exclude values as dened by the user. The median of all of the pixels in the image. This may exclude values as dened by the user. The mode of all of the pixels in the image. This may exclude values as dened by the user. The standard deviation of the pixels in the image. This may exclude values as dened by the user.
DOUBLE
maximum
DOUBLE DOUBLE
mean median
DOUBLE DOUBLE
mode stddev
Esta_Covariance The Esta_Covariance object is used to record the covariance matrix for the layers in a .img file
78
HFA Object Directory {1:bcovariance,}Esta_Covariance, Type BASEDATA Name covariance Description A basedata structure containing the covariance matrix
Esta_SkipFactors The Esta_SkipFactors object is used to record the skip factors that were used when the statistics or histogram was calculated for a raster layer or when the covariance was calculated for a .img file. {1:LskipFactorX,1:LskipFactorY,}Esta_SkipFactors, Type LONG LONG Name skipFactorX skipFactorY Description The horizontal sampling interval used for statistics measured in image columns/sample The vertical sampling interval used for statistics measured in image rows/sample
Esta_ExcludedValues The Esta_ExcludedValues object is used to record the values that were excluded from consideration when the statistics or histogram was calculated for a raster layer or when the covariance was calculated for a .img file. {1:*bvalueBD,}Esta_ExcludedValues, Type BASEDATA * Name valueBD Description A basedata structure containing the excluded values
Eprj_Datum The Eprj_Datum object is used to record the datum information which is part of the projection information for a .img file.
79
HFA Object Directory {0:pcdatumname,1:e3:EPRJ_DATUM_PARAMETRIC,EPRJ_DATUM_GRID, EPRJ_DATUM_REGRESSION,type,0:pdparams,0:pcgridname,}Eprj_Datum, Type CHAR ENUM Name datumname type Description The datum name. The datum type which could be one of three different types: parametric type, grid type and regression type. The seven parameters of a parametric datum which describe the translations, rotations and scale change between the current datum and the reference datum WGS84. The name of a grid datum le which stores the coordinate shifts among North America Datums NAD27, NAD83 and HARN.
DOUBLE
params
CHAR
gridname
Eprj_Spheroid The Eprj_Spheroid is used to describe spheroid parameters used to describe the shape of the earth. {0:pcsphereName,1:da,1:db,1:deSquared,1:dradius,}Eprj_Spheroid, Type CHAR p Name sphereName Description The name of the spheroid/ellipsoid. This name is can be found in: <IMAGINE_HOME>/etc/spheroid.tab. The semi-major axis of the ellipsoid in meters. The semi-minor axis of the ellipsoid in meters. The eccentricity of the ellipsoid, squared. The radius of the spheroid in meters.
DOUBLE DOUBLE DOUBLE DOUBLE
a b eSquared radius
Eprj_ProParameters The Eprj_Parameters is used to define the map projection for a layer.
80
HFA Object Directory {1:e2:EPRJ_INTERNAL,EPRJ_EXTERNAL,proType,1:lproNumber, 0:pcproExeName,0:pcproName,1:lproZone,0:pdproParams, 1:*oEprj_Spheroid,proSpheroid,}Eprj_ProParameters, Type ENUM Name proType Description This denes whether the projection is internal or external. 0=EPRJ_INTERNAL 1= EPRJ_EXTERNAL The projection number for internal projections. The current internal projections are: 0=Geographic(Latitude/Longitude) 1=UTM 2=State Plane 3=Albers Conical Equal Area 4=Lambert Conformal Conic 5=Mercator 6=Polar Stereographic 7=Polyconic 8=Equidistant Conic 9=Transverse Mercator 10=Stereographic 11=Lambert Azimuthal Equal-area 12=Azimuthal Equidistant 13=Gnomonic 14=Orthographic 15=General Vertical Near-Side Perspective 16=Sinusoidal 17=Equirectangular 18=Miller Cylindrical 19=Van der Grinten I 20=Oblique Mercator (Hotine) 21=Space Oblique Mercator 22=Modied Transverse Mercator The name of the executable to run for an external projection. The name of the projection. This will be one of the names given above in the description of proNumber. The zone number for internal State Plane or UTM projections. The array of parameters for the projection.
LONG
proNumber
CHAR p CHAR p
proExeName proName
LONG DOUBLE p
proZone proParams
81
Type Eprj_Spheroid *
Name proSpheroid
Description The parameters of the spheroid used to approximate the earth. See the description for the Eprj_Spheroid object, above.
The following table defines the contents of the proParams array which is defined above. The Parameters column defines the meaning of the various elements of the proParams array for the different projections. Each one is described by one or more statements of the form n: Description. n is the index into the array.
Name 0 1 2 3 Geographic(Latitude/ Longitude) UTM State Plane Albers Conical Equal Area
Parameters None Used 3: 1=North, -1=South 0: 0=NAD27, 1=NAD83 2: Latitude of 1st standard parallel 3: Latitude of 2nd standard parallel 4: Longitude of central meridian 5: Latitude of origin of projection 6: False Easting 7: False Northing 2: Latitude of 1st standard parallel 3: Latitude of 2nd standard parallel 4: Longitude of central meridian 5: Latitude of origin of projection 6: False Easting 7: False Northing 4: Longitude of central meridian 5: Latitude of origin of projection 6: False Easting 7: False Northing 4: Longitude directed straight down below pole of map. 5: Latitude of true scale. 6: False Easting 7: False Northing.
Lambert Conformal Conic
Mercator
Polar Stereographic
82
Name 7 Polyconic
Parameters 4: Longitude of central meridian 5: Latitude of origin of projection 6: False Easting 7: False Northing 2: Latitude of standard parallel (Case 0) 2: Latitude of 1st Standard Parallel (Case 1) 3: Latitude of 2nd standard Parallel (Case 1) 4: Longitude of central meridian 5: Latitude of origin of projection 6: False Easting 7: False Northing 8: 0=Case 0, 1=Case 1. 2: Scale Factor at Central Meridian 4: Longitude of center of projection 5: Latitude of center of projection 6: False Easting 7: False Northing 4: Longitude of center of projection 5: Latitude of center of projection 6: False Easting 7: False Northing 4: Longitude of center of projection 5: Latitude of center of projection 6: False Easting 7: False Northing 4: Longitude of center of projection 5: Latitude of center of projection 6: False Easting 7: False Northing 4: Longitude of center of projection 5: Latitude of center of projection 6: False Easting 7: False Northing 4: Longitude of center of projection 5: Latitude of center of projection 6: False Easting 7: False Northing
Equidistant Conic
Transverse Mercator
10
Stereographic
11
Lambert Azimuthal Equalarea
12
Azimuthal Equidistant
13
Gnomonic
14
Orthographic
83
Name 15 General Vertical Near-Side Perspective
Parameters 2: Height of perspective point above sphere. 4: Longitude of center of projection 5: Latitude of center of projection 6: False Easting 7: False Northing 4: Longitude of central meridian 6: False Easting 7: False Northing 4: Longitude of central meridian 5: Latitude of True Scale. 6: False Easting 7: False Northing 4: Longitude of central meridian 6: False Easting 7: False Northing 4: Longitude of central meridian 6: False Easting 7: False Northing 2: Scale Factor at center of projection 3: Azimuth east of north for central line. (Case 1) 4: Longitude of point of origin (Case 1) 5: Latitude of point of origin. 6: False Easting 7: False Northing. 8: Longitude of 1st Point dening central line (Case 0) 9: Latitude of 1st Point dening central line (Case 0) 10: Longitude of 2nd Point dening central line. (Case 0) 11: Latitude of 2nd Point dening central line (Case 0). 12: 0=Case 0, 1=Case 1 4: Landsat Vehicle ID (1-5) 5: Orbital Path Number (1-251 or 1-233) 6: False Easting 7: False Northing
16
Sinusoidal
17
Equirectangular
18
Miller Cylindrical
19
Van der Grinten I
20
Oblique Mercator (Hotine)
21
Space Oblique Mercator
84
Name 22 Modied Transverse Mercator
Parameters 6: False Easting 7: False Northing
Eprj_Coordinate An Eprj_Coordiante is a pair of doubles used to define X and Y. {1:dx,1:dy,}Eprj_Coordinate, Type DOUBLE DOUBLE Name x y Description The X value of the coordinate. The Y value of the coordinate.
Eprj_Size The Eprj_Size is a pair of doubles used to define a rectangular size. {1:dx,1:dy,}Eprj_Size, Type DOUBLE DOUBLE Name width height Description The X value of the coordinate. The Y value of the coordinate.
Eprj_MapInfo The Eprj_MapInfo object is used to define the basic map information for a layer. It defines the map coordinates for the center of the upper left and lower right pixels, as well as the cell size and the name of the map projection. {0:pcproName,1:*oEprj_Coordinate,upperLeftCenter, 1:*oEprj_Coordinate,lowerRightCenter,1:*oEprj_Size,pixelSize, 0:pcunits,}Eprj_MapInfo, Type CHAR p Eprj_ Coordinate * Name proName upperLeftCenter Description The name of the projection. The coordinates of the center of the upper left pixel.
85
Type Eprj_ Coordinate * Eprj_Size * CHAR *
Name lowerRightCenter pixelSize units
Description The coordinates of the center of the lower right pixel. The size of the pixel in the image. The units of the above values.
Efga_Polynomial The Efga_Polynomial is used to store transformation coefficients created by the IMAGINE GCP Editor. {1:Lorder,1:Lnumdimtransforms,1:numdimpolynomial,1:Ltermcount, 1:*exponentList,1:bpolycoefmtx,1:bpolycoefvector,}Efga_Polynomial, Type LONG LONG LONG LONG LONG * BASEDATA BASEDATA Name order numdimtransform numdimpolynomial termcount exponentlist polycoefmtx polycoefvector Description The order of the polynomial. The number of dimensions of the transformation (always 2). The number of dimensions of the polynomial (always 2). The number of terms in the polynomial. The ordered list of powers for the polynomial. The polynomial coefcients. The polynomial vectors.
86
HFA Object Directory Calibration_Node An object of type Calibration_Node is an empty object it contains no data. A node of this type simply serves as the parent node of four related child objects. The children of the Calibration_Node are used to provide information which converts pixel coordinates to map coordinates and vice versa.There is no dictionary definition for this object type. A node of this type will be a child of the root node and will be named Calibration. The Calibration node will have the four children described below. Node Projection Map_Info Object Type Eprj_ProParameters Eprj_MapInfo Description The projection associated with the output coordinate system. The nominal map information associated with the transformation. This is the nth order polynomial coefcient used to convert from map coordinates to pixel coordinates. This is the nth order polynomial used to convert from pixel coordinates to map coordinates
InversePolynomial
Efga_Polynomial
ForwardPolynomial
Efga_Polynomial
87
External File Format Header Object Types

The following sections list the types of objects found in .img HFA files that have been imported from external data files:
o ADRG Header o ADRI Header o AVHRR Header o DEM Header o DOQ Header o DTED Header o MSS Header o SPOT Header o TM Header
88
External File Format Header Object Types ADRG Header The following table defines the contents of the record written to an IMAGINE .img file which has been read from an ADRG source. The fields are copied from the Volume Header file (TRANSH01.THF) and from the individual Distribution Rectangle (DR) headers. If the value is a string it is left unchanged. If the value is a number it is converted from ASCII to binary. All strings are NULL terminated. The description column indicates the source of the information. The three codes in the Description column represent the file name, field name, and subfield names. The filename codes are THF for Transmittal Header File and GEN for General Information File. For example, the description THF, VDR, URF means the URF subfield within the VDR field within the Transmittal Header File. It is assumed that the user has access to the ADRG documents. Type CHAR [Var. Length] CHAR[17] SHORT TIME CHAR ENUM Name Originator StockNum VolEdNum PubDate SecurityClassication AgencyDeterminationReqd Description THF, VDR, VOO Name & address of originator THF, VDR, URF DMA stock number THF, VDR, EDN Volume edition number THF, VDR, DAT Publication date THF, QSR, QSS Security classication THF, QSR, QOD Originating agencys determination required NO or YES THF, QSR, DAT Date of downgrading THF, QSR, QLE Releasability statement THF, QUV, SRC Specication identication for ADRG THF, QUV, DAT Specication date
TIME CHAR [Var. Length] CHAR [Var. Length] TIME
DowngradeDate Releasability SpecIdent SpecDate
89
Type CHAR[21]
Name SpecAmendmentNum
Description THF, QUV, SPA ADRG Specication amendment number THF, FDR, NAM Name of the DR directory GEN (OVERVIEW_RECORD),SPR,BAD or GEN (GENERAL_INFORMATION_RECORD ), SPR, BAD or SOU,SPR,BAD Name of the image le Type of image UNKNOWN, ZDR, LEGEND or OVERVIEW GEN, GEN, ZNA ARC Zone number
CHAR[9] CHAR[13]
DistRectName ImageName
ENUM
ImageType
SHORT
Zone
90
External File Format Header Object Types ADRI Header The following table defines the contents of the record written to an IMAGINE .img file which has been read from an ADRI source. The fields are copied from the Volume Header file and from the individual Distribution Rectangle (DR) headers. If the value is a string it is left unchanged. If the value is a number it is converted from ASCII to binary. All strings are NULL terminated. The description column indicates the source of the information. The three codes in the Description column represent the file name, field name, and subfield names. The file name codes are THF for Transmittal Header File, GEN for General Information File, and QAL for Quality File. For example, the description QAL, QUP, SPA means the SPA subfield within the QUP (Quality Up To Dateness) field within the Quality File. Additional comments are added when necessary to avoid ambiguity. It is assumed that the user has access to the ADRI documentation. Type CHAR[Var. Length] CHAR[17] SHORT TIME CHAR ENUM TIME CHAR[Var. Length] CHAR[Var. Length] TIME CHAR[21] ENUM CHAR[9] CHAR[13] SHORT DOUBLE DOUBLE SHORT Name Originator StockNum VolEdNum PubDate SecurityClassication AgencyDeterminationReqd DowngradeDate Releasability SpecIdent SpecDate SpecAmendmentNum ImageType DistRectName ImageName DataStructureType DataDensityEW DataDensityNS DataDensityUnit Description THF, VDR, VOO THF, VDR, URF THF, VDR, EDN THF, VDR, DAT THF, QSR, QSS THF, QSR, QOD NO or YES THF, QSR, DAT THF, QSR, QLE THF, QUV, SRC THF, QUV, DAT THF, QUV, SPA OVERVIEW or ZDR Name of the DR Directory Name of the Image File GEN, OVI, STR or GEN, GEN, STR GEN, GEN, LOD GEN, GEN, LAD GEN, GEN, UNI
91
Type DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE SHORT DOUBLE ENUM DOUBLE DOUBLE CHAR[Var. Length] struct BandInfo [Var. Length] CHAR[21] TIME TIME SHORT SHORT CHAR[Var. Length] TIME
Name Ulx Uly Lrx Lry Scale Zone GSD Rectied Asz Bs Text BandInfo
Description GEN, GEN, NWO GEN, GEN, NWA GEN, GEN, SEO GEN, GEN, SEA GEN, GEN, SCA GEN, GEN, ZNA GEN, GEN, PSP GEN, GEN, IMR NO or YES GEN, GEN, ARV GEN, GEN, BRV GEN, GEN, TXT GEN, BDF (See BandInfo Structure table below) QAL, QUP, EDN QAL, QUP, DAT (Creation date of ZDR) QAL, QUP, DAT (Date of revision/update) QAL, QUP, REC QAL, QUP, REV QAL, QUP, SRC QAL, QUP, DAT (ADRI product specication date) QAL, QUP, SPA QAL, QUP, DAT (Earliest date of source image in DR)
EditionNumber CreationDate RevisionDate RecompilationCount RevisionCount ADRIProduct ProductSpecDate
CHAR[21] TIME
ProductSpecNum EarliestDate
92
Type TIME
Name LatestDate
Description QAL, QUP, DAT (Latest date of source image in DR)
BandInfo Structure Type CHAR[6] LONG LONG Name BandColor LowerEdgeWavelength UpperEdgeWavelength Description GEN, BDF, BID GEN, BDF, WS1 GEN, BDF, WS2
93
External File Format Header Object Types AVHRR Header The following table defines the contents of the record written to an IMAGINE .img file which has been read from an AVHRR source. The fields are copied from the TBM and Data Set Headers. Note that not all AVHRR files contain a TBM header, so the TBM fields may be empty or zero. TBM header fields are indicated in the Description column by the TBM designation. All strings are NULL terminated. The description column indicates the source of the information. It is assumed that the user has access to the AVHRR documentation, NOAA Polar Orbiter Data Users Guide. Type CHAR[45] ENUM ENUM SHORT SHORT ENUM SHORT SHORT ENUM USHORT USHORT USHORT ENUM ENUM[20] CHAR[10] Name DataSetName TotalCopy LatitudeSelected BeginningLatitude EndingLatitude LongitudeSelected BeginningLongitude EndingLongitude TimeSelected BeginningHour BeginningMinute NumMinutes AppendedData ChannelsSelected SpacecraftID Description TBM Data Set Name TBM Total Copy? EMSC_FALSE or EMSC_TRUE TBM Latitude select option used? EMSC_FALSE or EMSC_TRUE TBM Beginning Latitude TBM Ending Latitude TBM Longitude select option used? EMSC_FALSE or EMSC_TRUE TBM Beginning Longitude TBM Ending Longitude TBM Time select option used? EMSC_FALSE or EMSC_TRUE TBM Beginning Hour of data set TBM Beginning Minute of data TBM Number of minutes in data set TBM Earth location data included? TBM EMSC_FALSE or EMSC_TRUE for 20 channels Satellite Name
94
Type ENUM
Name DataType
Description EIXM_AVHRR_DATATYPE_UNKNO WN, EIXM_AVHRR_LAC, EIXM_AVHRR_GAC, or EIXM_AVHRR_HRPT EIXM_AVHRR_TIPSOURCE_UNK NOWN, EIXM_AVHRR_EMBEDDED_TIP, EIXM_AVHRR_STORED_TIP, or EIXM_AVHRR_THIRD_CDA_TIP Time code from rst frame of data processed for the data set Number of data scans Time code from the last frame of data processed Processing Block ID Ramp/Auto Calibration eld Number of data gaps Number of input data frames with no frame sync word errors Number of DACS detected TIP parity errors Sum of all auxiliary sync errors detected in input data Identies the calibration parameter input data set Normal data = EMSC_FALSE, Pseudo Noise data = EMSC_TRUE Receiving station EIXM_AVHRR_TAPE_DIR_UNKNO WN, EIXM_AVHRR_REVERSE or EIXM_AVHRR_FORWARD
ENUM
TipSource
TIME ULONG TIME ULONG UCHAR USHORT USHORT USHORT USHORT UCHAR[2] ENUM CHAR[10] ENUM
StartTime NumScans EndTime ProcessingBlockID CalibrationByte NumDataGaps NoFrameSyncWordErrorsCount TipParityErrorsCount AuxiliarySyncErrorsCount CalibrationParameterID PseudoNoiseFlag DataSource TapeDirection
95
Type ENUM
Name DataMode
Description EIXM_AVHRR_DATAMODE_UNKO NWN, EIXM_AVHRR_TESTDATA or EIXM_AVHRR_FLIGHTDATA
96
External File Format Header Object Types DEM Header The following table defines the contents of the record written to an IMAGINE .img file which has been read from a DEM source. The fields are copied from the Type A and Type C records. All strings are NULL terminated. The description column indicates the source of the information. It is assumed that the user has access to the DEM documentation. Type CHAR[41] CHAR[41] CHAR CHAR[4] CHAR[5] SHORT SHORT SHORT SHORT DOUBLE[15] SHORT SHORT SHORT DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE Name FileName FreeText ProcessCode SectionalIndicato MCOriginCode DEMLevelCode ElevationPatternCode GroundRefSystemCode Zone ProjectionParams PlanimetricUnitCode ElevationUnitCode CoveragePolygonSides SWCornerX SWCornerY NWCornerX NWCornerY NECornerX NECornerY SECornerX Description DEM quadrangle name Free format descriptor eld 1=GPM, 2=Manual Prole, 3=DLG2DEM, 4=DCLASS Identies 1:100000-scale sections Mapping center origin code DEM Level 1=regular, 2=random 0=Geographic, 1=UTM, 2=State Plane State Plane or UTM Zone USGS projection parameters 0=rad, 1=ft, 2=m, 3=arcseconds 1=feet, 2=meters # polygon sides dening DEM coverage X Coordinate of SW corner Y Coordinate of SW corner X Coordinate of NW corner Y Coordinate of NW corner X Coordinate of NE corner Y Coordinate of NE corner X Coordinate of SE corner
97
Type DOUBLE DOUBLE DOUBLE DOUBLE SHORT DOUBLE DOUBLE DOUBLE SHORT SHORT SHORT SHORT SHORT SHORT CHAR[5] CHAR[5] CHAR SHORT SHORT
Name SECornerY MinElevation MaxElevation RotationAngle ElevationAccuracyCode SpatialResolutionX SpatialResolutionY SpatialResolutionZ ProleRows ProleCols LargestPrimaryContourInterval LargestPrimaryIntervalUnits SmallestPrimaryContourInterval SmallestPrimaryIntervalUnits DataSourceDate DataInspRevDate InspectionRevisionFlag DataValidationFlag SuspectVoidAreaFlag
Description Y Coordinate of SE corner Minimum coverage elevation Maximum coverage elevation CCW angle to local DEM reference system 0=unknown, 1=info in Type C record Spatial resolution in X direction Spatial resolution in Y direction Spatial resolution in Z direction Number of rows per elevation prole Number of columns per elevation prole Present only if 2 or more primary intervals exist 0=N.A., 1=feet, 2=meters Smallest or only primary contour interval 1=feet, 2=meters YYMM format YYMM format I or R See USGS manual 0=none, 1=suspect areas, 2=void areas, 3=suspect and void areas 1=local mean sea level, 2=NGVD 29, 3=NAVD 88
SHORT
VerticalDatum
98
Type SHORT
Name HorizontalDatum
Description 1=NAD 27, 2=WGS 72, 3=WGS 84, 4=NAD 83, 5=Old Hawaii Datum, 6=Puerto Rico Datum, 7=NAD 83 Provisional Primarily DMA Specic eld 1=available, 0=unavailable In PlanimetricUnitCode units In PlanimetricUnitCode units In ElevationUnitCode units 0=accuracy assumed to be estimated 1=available, 0=unavailable In PlanimetricUnitCode units In PlanimetricUnitCode units In ElevationUnitCode units 0=accuracy assumed to be estimated
SHORT SHORT SHORT SHORT SHORT LONG SHORT SHORT SHORT SHORT LONG
DataEdition DatumStatsAvailable DatumAccuracyX DatumAccuracyY DatumAccuracyZ DatumSampleSize DemStatsAvailable DemAccuracyX DemAccuracyY DemAccuracyZ DemSampleSize
99
External File Format Header Object Types DOQ Header The following table defines the contents of the record written to an ERDAS IMAGINE .img file which has been read from a USGS DOQ (Digital Ortho Quadrangle) source. The fields are copied from the four DOQ header records. All strings are NULL terminated. It is assumed that the user has access to the DOQ documentation. Type CHAR[39] CHAR[3] CHAR[3] CHAR[3] CHAR[3] CHAR[3] CHAR[3] CHAR[3] CHAR[4] CHAR[4] CHAR[4] CHAR[4] CHAR[4] CHAR[4] CHAR[4] CHAR[4] CHAR[4] CHAR[4] CHAR[4] CHAR[4] CHAR[4] CHAR[4] Name quadrangleName quadrant nation1 nation2 state1 state2 state3 state4 state1county1 state1county2 state1county3 state1county4 state1county5 state2county1 state2county2 state2county3 state2county4 state2county5 state3county1 state3county2 state3county3 state3county4 Description Authorized quadrangle name Quadrangle quadrant (SW, NW, NE, SE) FIPS nation code, primary nation FIPS nation code, secondary nation First state in le Second state in le Third state in le Fourth state in le First county in rst state Second county in rst state Third county in rst state Fourth county in rst state Fifth county in rst state First county in second state Second county in second state Third county in second state Fourth county in second state Fifth county in second state First county in third state Second county in third state Third county in third state Fourth county in third state
100
Type CHAR[4] CHAR[4] CHAR[4] CHAR[4] CHAR[4] CHAR[4] CHAR[24] CHAR[5] SHORT LONG LONG SHORT SHORT SHORT SHORT SHORT SHORT DOUBLE SHORT SHORT SHORT DOUBLE[2] DOUBLE[2] DOUBLE[2]
Name state3county5 state4county1 state4county2 state4county3 state4county4 state4county5 descriptiveText producerCode dataOrdering numLines numSamples bandTypesAndOrder elevationStorage bandAndElevationStorage verticalDatum primaryHorizDatum secondaryHorizDatum rotationAngle groundXYRefSystem groundXYZone groundXYUnits SWPrimaryGroundCoord NWPrimaryGroundCoord NEPrimaryGroundCoord
Description Fifth county in third state First county in fourth state Second county in fourth state Third county in fourth state Fourth county in fourth state Fifth county in fourth state Additional descriptive text Mapping center origin code Direction of lines and samples Number of lines (rows) in image Number of samples (columns) in image Number, types, and order of bands Elevation storage code Method of elevation storage Vertical datum used Primary horizontal datum Secondary horizontal datum Orthophoto rotation WRT primary datum Geographic, UTM or State Plane Zone number if UTM or State Plane Map units Map coords of SW primary quad corner Map coords of NW primary quad corner Map coords of NE primary quad corner
101
Type DOUBLE[2] DOUBLE[6] DOUBLE[2] DOUBLE[2] DOUBLE[2] DOUBLE[2] DOUBLE[2] DOUBLE[6] DOUBLE[2] LONG[2] LONG[2] LONG[2] LONG[2] LONG[2] LONG[2] LONG[2] LONG[2] DOUBLE[2] DOUBLE[2]
Name SEPrimaryGroundCoord primaryCoeff primaryCentroid SWSecondaryGroundCoord NWSecondaryGroundCoord NESecondaryGroundCoord SESecondaryGroundCoord secondaryCoeff secondaryCentroid SWPrimaryInternalCoord NWPrimaryInternalCoord NEPrimaryInternalCoord SEPrimaryInternalCoord SWSecondaryInternalCoord NWSecondaryInternalCoord NESecondaryInternalCoord SESecondaryInternalCoord rstPixelPrimary rstPixelSecondary
Description Map coords of SE primary quad corner Primary transform coefcients X and Y primary centroid Map coords of SW secondary quad corner Map coords of NW secondary quad corner Map coords of NE secondary quad corner Map coords of SE secondary quad corner Secondary transform coefcients X and Y secondary centroid File coords of SW primary quad corner File coords of NW primary quad corner File coords of NE primary quad corner File coords of SE primary quad corner File coords of SW secondary quad corner File coords of NW secondary quad corner File coords of NE secondary quad corner File coords of SE secondary quad corner Primary map coords of (1,1) le pixel Secondary map coords of (1,1) le pixel
102
Type SHORT FLOAT FLOAT FLOAT FLOAT FLOAT FLOAT FLOAT FLOAT LONG SHORT LONG SHORT SHORT FLOAT FLOAT SHORT SHORT CHAR[25] TIME CHAR[25] CHAR[25] SHORT
Name elevationUnits minElevation maxElevation groundResolutionX groundResolutionY groundResolutionZ pixelResolutionX pixelResolutionY pixelResolutionZ largestPrimaryContourInterval largestPrimaryContourIntervalU nits smallestPrimaryContourInterval smallestPrimaryContourInterval Units suspectAndVoidAreas horizDoqAccuracy verticalDoqAccuracy numDoqHorizTestPoints pixelProcessingAlgorithm productionSystem productionDate lmType sourcePhotoID mosaickedImage
Description DEM elevation units Minimum DEM elevation Maximum DEM elevation Ground X resolution of DEM Ground Y resolution of DEM Ground Z resolution of DEM X resolution of orthophoto Y resolution of orthophoto Z resolution of orthophoto Largest interval if DEM derived from graphic Units of Largest interval Smallest interval if DEM derived from graphic Units of Smallest interval Suspect and void areas in elevation or orthophoto data RMSE of image control points for X-Y RMSE of primary DEM used Number of DOQ horizontal test points Resampling method Description of hardware & software used Production date Manufacturer and ID of lm type Descrip. of photo, agency, roll #, etc. Number of chips composing image
103
Type ENUM TIME FLOAT LONG CHAR[25] FLOAT[2] FLOAT[2] SHORT FLOAT
Name leafOff sourcePhotoDate focalLength sourcePhotoFlyingHeight scannerType scanningResolution scannerSamplingResolution radiometricResolution resampledResolution
Description Leaves off trees FALSE or TRUE Date of source photo Calibrated camera focal length in mm Nominal ying height of photograph Scanner description (x,y) Aperture resolution, microns (x,y) Sampling resolution, microns 8 or 16 bits Resampled resolution
104
External File Format Header Object Types DTED Header The following table defines the contents of the record written to an IMAGINE .img file which has been read from a DTED source. The fields are copied from the File Header (HDR), User Header (UHL), Data Set Identification (DSI), and Accuracy Description (ACC) records. The description is preceded by the record indicator from which the field was derived. All strings are NULL terminated. The description column indicates the source of the information. It is assumed that the user has access to the DTED documentation. Type CHAR[18] TIME TIME CHAR[4] CHAR[13] SHORT CHAR CHAR[28] CHAR[6] CHAR[16] SHORT CHAR CHAR[5] CHAR[5] CHAR[9] CHAR[10] SHORT CHAR[5] CHAR[4] CHAR[6] CHAR[11] CHAR[5] Name FileName CreationDate ExpirationDate SecurityCode UHL_ReferenceNumber MultipleAccuracy SecurityClassication SecurityHandlingDescription SeriesDesignator DSI_ReferenceNumber DataEditionNumber MatchMergeVersion MaintenanceDate MatchMergeDate ProducerCode ProductSpecStockNum ProductSpecAmendmentNum ProductSpecDate VerticalDatum HorizontalDatumCode DigitizingCollectionSystem CompilationDate Description HDR File name HDR Creation date of tape HDR Expiration date of tape UHL Security Code UHL Unique reference number UHL 0=Single, 1=Multiple DSI Security classication code DSI Security handling description DSI DMA series designator DSI Unique reference number DSI Data edition number DSI Match/Merge version DSI Maintenance date (YYMM) DSI Match/Merge date (YYMM) DSI Producer code DSI Product specication stock number DSI Product spec. amendment number DSI Product specication date (YYMM) DSI Vertical datum DSI Horizontal datum code DSI Digitizing collection system DSI Compilation date (YYMM)
105
Type DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE
Name OriginLatitude OriginLongitude SWCornerLatitude SWCornerLongitude NWCornerLatitude NWCornerLongitude NECornerLatitude NECornerLongitude SECornerLatitude SECornerLongitude OrientationAngle LatitudeInterval
Description DSI Latitude of data origin DSI Longitude of data origin DSI Latitude of SW corner of data DSI Longitude of SW corner of data DSI Latitude of NW corner of data DSI Longitude of NW corner of data DSI Latitude of NE corner of data DSI Longitude of NE corner of data DSI Latitude of SE corner of data DSI Longitude of SE corner of data DSI Clockwise orientation angle of data with respect to true north DSI Latitude interval in tenths of seconds between rows of elevation values DSI Longitude interval in tenths of seconds between rows of elevation values DSI Number of latitude lines DSI Number of longitude lines DSI Partial Cell Indicator ACC Absolute horizontal accuracy of product ACC Absolute vertical accuracy of product ACC Point-to-Point horizontal accuracy of product ACC Point-to-Point vertical accuracy of product
DOUBLE
LongitudeInterval
SHORT SHORT SHORT SHORT SHORT SHORT SHORT
NumLatitudeLines NumLongitudeLines PartialCellIndicator AbsoluteHorizontalAccuracy AbsoluteVerticalAccuracy PointToPointHorizAcc PointToPointVertAcc
106
External File Format Header Object Types MSS Header The following table defines the contents of the record written to an IMAGINE .img file which has been read from a MSS source. The fields are copied from the Tape Directory (TD), Header (HDR), and Annotation (ANT) records. The description is preceded by the record indicator from which the field was derived. All strings are NULL terminated. The description column indicates the source of the information. It is assumed that the user has access to the MSS documentation. Type CHAR TIME USHORT ENUM USHORT ENUM CHAR[19] CHAR[8] CHAR[4] USHORT USHORT[26] USHORT USHORT USHORT USHORT USHORT USHORT ENUM ENUM Name MissionNum TapeCreationDate NumVolumes format RecordLength SourceHDT SceneID WRSDesignator SensorID OrbitNum ActiveDetectorStatus ActiveDetectorCount UncorrectedPixelsPerLine WRSScanLineNum WRSPixelNum NumAnnotationRecords NumAncillaryRecords GeoCorrectionsApplied GeoCorrectionDataPresent Description TD Byte 8 TD Bytes 12-16 TD Byte 20 TD Byte 31 NONE, BIL, BIP or BSQ TD Bytes 32-33 TD Byte 34 FALSE or TRUE TD Bytes 35-52 HDR Bytes 20-26 HDR Bytes 37-39 HDR Bytes 47-48 HDR Bytes 49-52 1 = Detector is Active HDR Byte 57 HDR Byte 58 HDR Bytes 73-74 HDR Bytes 75-76 HDR Bytes 101-102 HDR Bytes 105-106 HDR Byte 107 FALSE or TRUE HDR Byte 108 FALSE or TRUE
107
Type ENUM ENUM ENUM
Name RadiometricCorrectionsApplied RadiometricCorrectionDataPre sent ImageDataFormat
Description HDR Byte 109 FALSE or TRUE HDR Byte 110 FALSE or TRUE HDR Byte 117 UNKNOWN, UNFRAMED_RECTANGULAR_IMA GE, FRAMED_RECTANGULAR_IMAGE , or FRAMED_SQUARE_IMAGE HDR Byte 121 HDR Byte 122 HDR Byte 123 NONE, CUBIC_CONVOLUTION or NEAREST_NEIGHBOR HDR Byte 125-126 HDR Byte 131-132 HDR Byte 135 HDR Byte 144-145 HDR Byte 151 FALSE (Night pass) or TRUE (Day pass) HDR Byte 162 UNKNOWN, LOW_GAIN_LINEAR_TRANSMISS ION, LOW_GAIN_COMPRESSED_TRA NSMISSION, HIGH_GAIN_LINEAR_TRANSMISS ION, HIGH_GAIN_COMPRESSED_TRA NSMISSION HDR Bytes 183-184 HDR Bytes 185-186
USHORT USHORT ENUM
LineInterleavingCount BitsPerPixel ResamplingApplied
SHORT USHORT USHORT USHORT ENUM
WRSImageCenterOffset PixelsPerScanLine NumUsableImages NumTrailerRecords DayPass
ENUM
CalWedgeMode
USHORT USHORT
TempRegPt1CurImgScanLine TempRegPt1CurImgPixelNum
108
Type USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT USHORT
Name TempRegPt1RefImgScanLine TempRegPt1RefImgPixelNum TempRegPt2CurImgScanLine TempRegPt2CurImgPixelNum TempRegPt2RefImgScanLine TempRegPt2RefImgPixelNum TempRegPt3CurImgScanLine TempRegPt3CurImgPixelNum TempRegPt3RefImgScanLine TempRegPt3RefImgPixelNum TempRegPt4CurImgScanLine TempRegPt4CurImgPixelNum TempRegPt4RefImgScanLine TempRegPt4RefImgPixelNum OverlapMark1ScanLine OverlapMark1PixelNum OverlapMark2ScanLine OverlapMark2PixelNum OverlapMark3ScanLine OverlapMark3PixelNum OverlapMark4ScanLine OverlapMark4PixelNum OverlapMarkPixelOffset GeoModelQualityAssessment NumTickMarksTop NumTickMarksLeft NumTickMarksRight
Description HDR Bytes 187-188 HDR Bytes 189-190 HDR Bytes 191-192 HDR Bytes 193-194 HDR Bytes 195-196 HDR Bytes 197-198 HDR Bytes 199-200 HDR Bytes 201-202 HDR Bytes 203-204 HDR Bytes 205-206 HDR Bytes 207-208 HDR Bytes 209-210 HDR Bytes 211-212 HDR Bytes 213-214 HDR Bytes 215-216 HDR Bytes 217-218 HDR Bytes 219-220 HDR Bytes 221-222 HDR Bytes 223-224 HDR Bytes 225-226 HDR Bytes 227-228 HDR Bytes 229-230 HDR Byte 231 HDR Byte 232 HDR Byte 233 HDR Byte 234 HDR Byte 235
109
Type USHORT ENUM ENUM ENUM USHORT[8] FLOAT FLOAT CHAR[10] FLOAT FLOAT CHAR[8] ENUM
Name NumTickMarksBottom EdipsContrastEnhancement EdipsAtmScatterCompensation EdipsEdgeEnhancement DataPresentByBand FormatCenterLatitude FormatCenterLongitude NominalPathRowID NominalLatitude NominalLongitude SpectralBandIDCode TransmissionType
Description HDR Byte 236 HDR Byte 3583 FALSE or TRUE HDR Byte 3584 FALSE or TRUE HDR Byte 3585 FALSE or TRUE HDR Byte 3586 1 = Data Present ANT Bytes 17-22 ANT Bytes 24-31 ANT Bytes 32-40 ANT Bytes 43-48 ANT Bytes 50-57 ANT Bytes 58-64 ANT Byte 66 UNKNOWN, DIRECT or STORED_PLAYBACK ANT Bytes 68-81 ANT Byte 82 NONE, SYSTEM_CORRECTION, GEOMETRIC_GCP_CORRECTION , or RELATIVE_GCP_CORRECTION ANT Byte 83 185 km x 185 km, 99 km x 99 km, or 185 km x 170 km
CHAR[15] ENUM
SunAngles CorrectionType
CHAR[16]
ImageScale
110
Type Eixm_MssMapProjectio n
Name MapProjection
Description ANT Byte 84 NONE, UTM, POLAR_STEREOGRAPHIC, HOTINE_OBLIQUE_MERCATOR, SPACE_OBLIQUE_MERCATOR, or LAMBERT ANT Byte 87 UNKNOWN, PREDICTIVE, or DEFINITIVE ANT Byte 89 UNKNOWN, ABNORMAL, or NORMAL ANT Byte 91 UNKNOWN, HIGH_GAIN or LOW_GAIN ANT Bytes 94-106 ANT Bytes 107-121 ANT Bytes 405-548 See TickMark Structure table below. ANT Bytes 803-964 See TickMark Structure table below. ANT Bytes 1201-1263 See TickMark Structure table below. ANT Bytes 1599-1760 See TickMark Structure table below.
ENUM
EphemerisType
ENUM
ProcessingProcedure
ENUM
SensorGain
CHAR[14] CHAR[16] struct TickMark[16] struct TickMark[25] struct TickMark[25] struct TickMark[16]
AgencyProject FrameID TopTickMark LeftTickMark RightTickMark BottomTickMark
TickMark Structure Type USHORT CHAR[8] Name position label Description Number of pixels from top or left side Tick Mark Label
111
External File Format Header Object Types SPOT Header The following table defines the contents of the record written to an IMAGINE .img file which has been read from a SPOT source. The fields are copied from the SPOT Level 1A, 1B, and 2 headers, SPOTVIEW/GEOSPOT (GIS) headers, and the Canadian SPOT (RADARSAT) headers. If the value is a string, it is left unchanged. If the value is a number, it is converted from ASCII to binary. The description column indicates the source of the information. It is assumed that the user has access to the various SPOT documentation. MAX_INT: Maximum integer. It is the default uninitialized value for certain fields. MAX_DBL: Maximum double. It is the default uninitialized value for certain fields. SP: SPOT Level 1A, 1B, and 2. SV: SPOTVIEW 1.5 (GIS format). GS: GEOSPOT 4.0 (GIS format).1 CS: Canadian SPOT.2
1. GIS-GEOSPOT Format Reference Manual 2. Canadian SPOT documentation (RADARSAT).
& The Canadian SPOT header fields are not completely defined in this document. This will be
completed in a future edition of On-Line Help.
112
External File Format Header Object Types struct SpotHeader Type CHAR[15] Name scnname Description SP: based on Fields 13 and 14 of le 2 record 1. SV: This eld is empty. GS: This eld is empty. CS: SP: Field 13 of le 2 record 2. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: Field 14 of le 2 record 2. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: Field 17 of le 2 record 2. SV: This eld is 0.0. GS: tag NW_LAT in REP header le. CS: SP: Field 18 of le 2 record 2. SV: This eld is 0.0. GS: tag NW_LON in REP header le. CS: SP: Field 21 of le 2 record 2. SV: This eld is 0.0. GS: tag SW_LAT in REP header le. CS: SP: Field 22 of le 2 record 2. SV: This eld is 0.0. GS: tag SW_LON in REP header le. CS: SP: Field 25 of le 2 record 2. SV: This eld is 0.0. GS: tag NE_LAT in REP header le. CS: SP: Field 26 of le 2 record 2. SV: This eld is 0.0. GS: tag NE_LON in REP header le. CS:
DOUBLE
scncenlat
DOUBLE
scncenlon
DOUBLE
scncor1lat
DOUBLE
scncor1lon
DOUBLE
scncor2lat
DOUBLE
scncor2lon
DOUBLE
scncor3lat
DOUBLE
scncor3lon
113
Type DOUBLE
Name scncor4lat
Description SP: Field 29 of le 2 record 2. SV: This eld is 0.0. GS: tag SE_LAT in REP header le. CS: SP: Field 30 of le 2 record 2. SV: This eld is 0.0. GS: tag SE_LON in REP header le. CS: SP: Field 15 of le 2 record 2. SV: This eld is 0. GS: This eld is 0.0. CS: SP: Field 16 of le 2 record 2. SV: This eld is 0. GS: This eld is 0.0. CS: SP: Field 19 of le 2 record 2. SV: This eld is 0. GS: tag NW_Y_PIXEL in HDR header le. CS: SP: Field 20 of le 2 record 2. SV: This eld is 0. GS: tag NW_X_PIXEL in HDR header le. CS: SP: Field 23 of le 2 record 2. SV: This eld is 0. GS: tag SW_Y_PIXEL in HDR header le. CS: SP: Field 24 of le 2 record 2. SV: This eld is 0. GS: tag SW_X_PIXEL in HDR header le. CS: SP: Field 27 of le 2 record 2. SV: This eld is 0. GS: tag NE_Y_PIXEL in HDR header le. CS:
DOUBLE
scncor4lon
LONG
scncenline
LONG
scncenpixel
LONG
scncor1line
LONG
scncor1pixel
LONG
scncor2line
LONG
scncor2pixel
LONG
scncor3line
114
Type LONG
Name scncor3pixel
Description SP: Field 28 of le 2 record 2. SV: This eld is 0. GS: tag NE_X_PIXEL in HDR header le. CS: SP: Field 31 of le 2 record 2. SV: This eld is 0. GS: tag SE_Y_PIXEL in HDR header le. CS: SP: Field 32 of le 2 record 2. SV: This eld is 0. GS: tag NE_X_PIXEL in HDR header le. CS: SP: Field 35 of le 2 record 2. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: Field 36 of le 2 record 2.a SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: Field 37 of le 2 record 2. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: Field 38 of le 2 record 2. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: Field 40 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: SP: Field 42 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS:
LONG
scncor4line
LONG
scncor4pixel
DOUBLE
scnorientangle
DOUBLE
angleonc
DOUBLE
sunazimuth
DOUBLE
sunelevation
CHAR[17]
scncentime
CHAR[4]
sensorid
115
Type CHAR[3]
Name specmode
Description SP: Field 43 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: SP: Field 44 of le 2 record 2. SV: This eld is 0. GS: This eld is 0. CS: SP: Field 47 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: SP: Field 55 of le 2 record 2. SV: tag PRE_PROCESS_LEVEL in HDR header le or tag CORRECTION_LEVEL in HDR header le. GS: tag PRE_PROCESS_LEVEL in HDR header le or tag CORRECTION_LEVEL in HDR header le. CS: SP: based on Field 56 of le 2 record 2. SV: This eld is EMSC_FALSE. GS: This eld is EMSC_FALSE. CS: SP: Field 57 of le 2 record 2. SV: This eld is 0. GS: This eld is 0. CS: SP: Field 58 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: SP: This eld is 0. SV: tag ULXMAP from header le. GS: tag NW_X_COORD in REP header le. CS:
LONG
revolutionnum
CHAR[2]
playback
CHAR[9]
preprocesslevel
ENUM
correction
LONG
deconvolution
CHAR
resampling
LONG
ulxmap
116
Type LONG ulymap
Name
Description SP: This eld is 0. SV: tag ULYMAP from header le. GS: tag NW_Y_COORD in REP header le. CS: SP: This eld is 0. SV: tag LRXMAP from header le. GS: tag SE_X_COORD in REP header le. CS: SP: This eld is 0. SV: tag LRYMAP from header le. GS: tag SE_Y_COORD in REP header le. CS: SP: Field 59 of le 2 record 2. SV: tag XDIM in HDR header le. GS: tag XDIM in HDR header le. CS: SP: Field 60 of le 2 record 2. SV: tag YDIM in HDR header le. GS: tag YDIM in HDR header le. CS: SP: Field 63 of le 2 record 2. SV: tag XDIM from header le. GS: tag XDIM in HDR header le. CS: This eld is 0.0. SP: Field 62 of le 2 record 2. SV: tag YDIM from header le. GS: tag YDIM in HDR header le. CS: This eld is 0.0. SP: Field 61 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: SP: Field 50 of le 2 record 2. SV: tag NCOLS from header le. GS: tag NCOLS in HDR header le. CS:
LONG
lrxmap
LONG
lrymap
LONG
xpixelsize
LONG
ypixelsize
DOUBLE
mapxpixelsize
DOUBLE
mapypixelsize
CHAR[32]
mapprojid
LONG
numcols
117
Type LONG
Name numlines
Description SP: Field 51 of le 2 record 2. SV: tag NROWS from header le. GS: tag NROWS in HDR header le. CS: SP: Field 9 of le 3 record 1. SV: tag NBANDS from header le. GS: tag NBANDS in HDR header le. CS: SP: Field 52 of le 2 record 2. SV: This eld is empty. GS: tag LAYOUT in HDR header le. CS: SP: Field 72 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: SP: Field 79 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: SP: This eld is empty. SV: tag MAPUNITS from header le. GS: tag MAPUNITS in HDR header le. CS: SP: This eld is empty. SV: tag PROJECTION from header le. GS: tag PROJ_ID in REP header le. CS: SP: This eld is empty. SV: tag UTM_ZONE from header le. GS: tag PROJ_ZONE in REP header le. CS: SP: This eld is empty. SV: tag UL_UTMEAST from header le. GS: This eld is MAX_INT. CS:
LONG
numbands
CHAR[4]
interleave
CHAR[33]
cartcoord
CHAR[16]
suncal
CHAR[8]
mapunits
CHAR[35]
mapproj
LONG
utmzone
LONG
utmeast
118
Type LONG
Name utmnorth
Description SP: This eld is empty. SV: tag UL_UTMNORTH from header le. GS: This eld is MAX_INT. CS: SP: This eld is empty. SV: tag UL_STPLANE_EAST from header le. GS: This eld is MAX_INT. CS: SP: This eld is empty. SV: tag UL_STPLANE_NORTH from header le. GS: This eld is MAX_INT. CS: SP: This eld is empty. SV: tag ST_PROJ_CODE from header le. GS: tag PROJ_ZONE in REP header le. CS: SP: This eld is empty. SV: tag HORIZONTAL_DATUM or tag DATUM from header le. GS: tag HORIZ_DATUM in HDR header le. CS: This eld is empty. SP: Defaults to 123. SV: tag BAND_RGB from header le. GS: tag BAND_RBG in HDR header le. CS: Defaults to 123. SP: Field 9 of le 2 record 2. SV: This eld is 0. GS: This eld is 0. CS: SP: Field 9 of le 2 record 2. SV: This eld is 0. GS: This eld is 0. CS: SP: Field 34 of le 2 record 2. SV: This eld is 0.0. GS: This eld is 0.0. CS:
LONG
stplaneeast
LONG
stplanenorth
LONG
stplanecode
CHAR[6]
hdatum
CHAR[4]
rgborder
LONG
GRSk
LONG
GRSj
DOUBLE
satlongnadir
119
Type DOUBLE
Name satlatnadir
Description SP: Field 33 of le 2 record 2. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: Field 68 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: SP: Field 45 of le 2 record 2. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: Field 46 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: SP: Field 41 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: SP: Field 9 of le 2 record 3b. SV: These elds contain 0.0s. GS: These elds contain 0.0s. CS: SP: Field 9 of le 2 record 3b. SV: These elds contain 0.0s. GS: These elds contain 0.0s. CS: SP: Field 9 of le 2 record 3b. SV: These elds contain 0.0s. GS: These elds contain 0.0s. CS: SP: Field 9 of le 2 record 3b. SV: These elds contain 0.0s. GS: These elds contain 0.0s. CS:
CHAR[17]
missionid
DOUBLE
pointingmirror
CHAR[7]
telmode
CHAR[6]
satelliteid
DOUBLE[9]
xcoord
DOUBLE[9]
ycoord
DOUBLE[9]
zcoord
DOUBLE[9]
xvelocityvector
120
Type DOUBLE[9]
Name yvelocityvector
Description SP: Field 9 of le 2 record 3b. SV: These elds contain 0.0s. GS: These elds contain 0.0s. CS: SP: Field 9 of le 2 record 3b. SV: These elds contain 0.0s. GS: These elds contain 0.0s. CS: SP: Field 9 of le 2 record 3b. SV: These elds contain 0s. GS: These elds contain 0s. CS: SP: Field 9 of le 2 record 3b. SV: This eld contains 0s. GS: CS: SP: Field 12 of le 2 record 3. SV: This eld is empty. GS: This eld is empty. CS: SP: Field 14 of le 2 record 3b. SV: These elds contain 0s. GS: These elds contain 0s. CS: SP: Field 14 of le 2 record 3b. SV: These elds contain 0s. GS: These elds contain 0s. CS: SP: Field 14 of le 2 record 3b. SV: These elds contain 0s. GS: These elds contain 0s. CS: SP: Field 14 of le 2 record 3b. SV: This eld contains 0s. GS: CS:
DOUBLE[9]
zvelocityvector
LONG[9]
julianday
LONG[9]
timeofday
CHAR[27]
scenecentertime
LONG[73]
rawimageline
LONG[73]
yawspeed
LONG[73]
avgrollspeed
LONG[73]
avgpitchspeed
121
Type DOUBLE[4]
Name lookangles
Description SP: Field 15-18 of le 2 record 3b. SV: This eld contains 0.0s. GS: CS: SP: Field 20 of le 2 record 3b. SV: These elds contain 0.0s. GS: These elds contain 0.0s. CS: SP: Field 21 of le 2 record 3b. SV: These elds contain 0.0s. GS: These elds contain 0.0s. CS: SP: Field 22 of le 2 record 3b. SV: These elds contain 0.0s. GS: These elds contain 0.0s. CS: SP: Field 23 of le 2 record 3b. SV: These elds contain 0.0s. GS: These elds contain 0.0s. CS: SP: Field 24 of le 2 record 3b. SV: These elds contain 0.0s. GS: These elds contain 0.0s. CS: SP: Field 77 of le 2 record 2. SV: This eld is empty. GS: This eld is emtpy. CS: SP: Field 78 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: SP: Field 84 of le 2 record 2. SV: This eld is 0. GS: This eld is 0. CS:
DOUBLE[4]
polynomial1
DOUBLE[4]
polynomial2
DOUBLE[4]
polynomial3
DOUBLE[4]
polynomial4
DOUBLE[4]
polynomial5
CHAR[17]
level2quality
CHAR[17]
dateofdarkcal
LONG
ephemerislength
122
Type LONG
Name ephemerisnumber
Description SP: Field 83 of le 2 record 2. SV: This eld is 0. GS: This eld is 0. CS: SP: Field 64 of le 2 record 2. SV: This eld is 0. GS: This eld is 0. CS: SP: Field 66 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: SP: Field 69 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: This eld is empty. SP: Field 70 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: This eld is empty. SP: Field 71 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: See eld preprocesslevel. SP: Field 74 of le 2 record 2. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: Field 75 of le 2 record 2. SV: This eld is 0. GS: This eld is 0. CS: SP: Field 10 of le 2 record 2. SV: This eld is empty. GS: This eld is empty. CS: This eld is empty.
LONG
numberofgcps
CHAR[17]
GRSdesignator
CHAR[17]
referencesensorid
CHAR[17]
referencespecmode
CHAR[17]
referenceprocesslevel
LONG
numberlostlines
LONG
numberlostdetectors
CHAR[17]
sceneidentication
123
Type DOUBLE
Name GRSlatdelta
Description SP: Field 11 of le 2 record 2. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: Field 12 of le 2 record 2. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: Field 48 of le 2 record 2. SV: This eld is 0. GS: This eld is 0.0. CS: See eld xpixelsize. See eld ypixelsize. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag NE_X_COORD in REP header le. CS: SP: This eld is 0.0. SV: This eld is 0.0. GS: tag NE_Y_COORD in REP header le. CS: SP: This eld is 0.0. SV: This eld is 0.0. GS: tag SW_X_COORD in REP header le. CS: SP: This eld is 0.0. SV: This eld is 0.0. GS: tag SW_Y_COORD in REP header le. CS: See eld hdatum. See GeoSpot Header Table below. See Spot Canadian Header Table below.
DOUBLE
GRSlondelta
LONG
gainnumber
DOUBLE DOUBLE DOUBLE
xpixelsized ypixelsized urxmap
DOUBLE
urymap
DOUBLE
llxmap
DOUBLE
llymap
CHAR * struct struct
datum[] GeoSpotHeader SpotCanHeader
a. First character of string is either L or R depending on how satellite passed over scanned area (L = negative; R = positive) b. Refer to the SPOT Standard CCT Format Document
124
External File Format Header Object Types GeoSpot Header Tablea Type ENUM Name geospotformat Description SP: This eld is EMSC_FALSE. SV: This eld is EMSC_TRUE. GS: This eld is EMSC_TRUE. CS: This eld is EMSC_FALSE. SP: This eld is empty. SV: This eld is 1.5. GS: This eld is empty.b CS: This eld is empty. SP: This eld is 0.0. SV: tag BANDROWBYTES in header le. GS: tag BANDROWBYTES in HDR header le. CS: This eld is 0.0. SP: This eld is empty. SV: tag BYTEORDER in header le. GS: tag BYTEORDER in HDR header le. CS: This eld is empty. SP: This eld is 0. SV: tag NBITS in header le. GS: tag NBITS in HDR header le. CS: This eld is 0. See eld preprocesslevel. SP: This eld is 0.0. SV: This eld is -MAX_DBL. GS: CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is -MAX_DBL. GS: CS: This eld is 0.0.
CHAR *
geospotversion[]
LONG
bandrowbytes
CHAR
byteorder
LONG
numbits
CHAR * DOUBLE
correction_level[] deltax_origin
DOUBLE
deltay_origin
125
Type CHAR *
Name contact_info[]
Description SP: This eld is empty. SV: This eld is empty. GS: tag CONTACT_INFO in REP header le. CS: This eld is empty. SP: This eld is empty. SV: This eld is empty. GS: tag EASTING_SIZE argument 2 in REP header le. CS: This eld is empty. SP: This eld is empty. SV: This eld is empty. GS: tag NORTHING_SIZE argument 2 in REP header le. CS: This eld is empty. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag GRID_DECLINATION in REP header le. CS: This eld is 0.0. SP: This eld is empty. SV: This eld is empty. GS: tag JOB_ID in REP header le. CS: This eld is empty. SP: This eld is empty. SV: This eld is empty. GS: tag LOCATION in REP header le. CS: This eld is empty. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag MAGNETIC_DECLINATION in REP header le. CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag MAG_DECL_ANNUAL_CHG in REP header le. CS: This eld is 0.0.
CHAR *
easting_size_units
CHAR *
northing_size_units
DOUBLE
grid_declination
CHAR *
job_id[]
CHAR *
location[]
DOUBLE
magnetic_declination
DOUBLE
mag_decl_annual_chg
126
Type CHAR *
Name mag_decl_date[]
Description SP: This eld is empty. SV: This eld is empty. GS: tag MAG_DECL_DATE in REP header le. CS: This eld is empty. SP: This eld is empty. SV: This eld is empty. GS: tag MAP_NAME in REP header le. CS: This eld is empty. SP: This eld is empty. SV: This eld is empty. GS: CS: This eld is empty. SP: This eld is empty. SV: This eld is empty. GS: tag MERIDIAN_NAME in REP header le. CS: This eld is empty. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag MERIDIAN_ORIGIN in REP header le. CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag ORIGIN_X_COORD in REP header le. CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag ORIGIN_Y_COORD in REP header le. CS: This eld is 0.0. SP: This eld empty. SV: This eld is empty. GS: tag PRODUCTION_DATE in REP header le. CS: This eld is empty.
CHAR *
map_name[]
CHAR *
map_number[]
CHAR *
meridian_name[]
DOUBLE
meridian_origin
DOUBLE
origin_x_coord
DOUBLE
origin_y_coord
CHAR *
production_date[]
127
Type CHAR *
Name product_id[]
Description SP: This eld empty. SV: This eld is empty. GS: tag PRODUCT_ID in REP header le. CS: This eld is empty. SP: This eld empty. SV: This eld is empty. GS: tag PROJ_CODE in REP header le. CS: This eld is empty. SP: This eld empty. SV: This eld is empty. GS: tag PROJ_ID in REP header le. CS: This eld is empty. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag PROJ_LAT_TRUE_SCALE in REP header le. CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is -MAX_DBL. GS: tag PROJ_MERIDIAN in REP header le. CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is -MAX_DBL. GS: tag PROJ_PARALLEL in REP header le. CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag PROJ_SCALE_FACTOR in REP header le. CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is -MAX_DBL GS: tag PROJ_STD_PARALLEL_I in REP header le. CS: This eld is 0.0.
CHAR *
proj_code[]
CHAR *
proj_id[]
DOUBLE
proj_lat_true_scale
DOUBLE
proj_meridian
DOUBLE
proj_parallel
DOUBLE
proj_scale_factor
DOUBLE
proj_std_parallel_I
128
Type DOUBLE
Name proj_std_parallel_II
Description SP: This eld is 0.0. SV: This eld is -MAX_DBL GS: tag PROJ_STD_PARALLEL_II in REP header le. CS: This eld is 0.0. SP: This eld is 0. SV: This eld is 0.0. GS: tag PROJ_ZONE in REP header le. CS: This eld is 0. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag RASTER_X_ORIGIN in REP header le. CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag RASTER_X_SIZE in REP header le. CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag RASTER_Y_ORIGIN in REP header le. CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag RASTER_Y_SIZE in REP header le. CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is empty. GS: tag SHEET_RECT_ELEVATION in REP header le. CS: This eld is 0.0.
LONG
proj_zone
DOUBLE
raster_x_origin
DOUBLE
raster_x_size
DOUBLE
raster_y_origin
DOUBLE
raster_y_size
DOUBLE
sheet_rect_elevation
129
Type CHAR *
Name sheet_rect_type[]
Description SP: This eld empty. SV: This eld is empty. GS: tag SHEET_RECT_TYPE in REP header le. CS: This eld is empty. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag SPHEROID_FLAT in REP header le. CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag SPHEROID_MAJ_AXIS in REP header le. CS: This eld is 0.0. SP: This eld is 0.0. SV: This eld is 0.0. GS: tag SPHEROID_MIN_AXIS in REP header le. CS: This eld is 0.0. SP: This eld empty. SV: This eld is empty. GS: tag SPHEROID_NAME in REP header le. CS: This eld is empty.
DOUBLE
spheroid_at
DOUBLE
spheroid_maj_axis
DOUBLE
spheroid_min_axis
CHAR *
spheroid_name[]
a. Compiled from SPOTVIEW 1.5 and GEOSPOT 4.0 documentation. b. If geospotversion is EMSC_TRUE, an empty eld implies GEOSPOT version 4.0.
Spot Canadian Header Table Type DOUBLE Name nom_interpixel_dist Description SP: This eld is 0.0. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: This eld is 0.0. SV: This eld is 0.0. GS: This eld is 0.0. CS:
DOUBLE
mon_interline_dist
130
Type DOUBLE
Name image_skew
Description SP: This eld is 0.0. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: This eld is 0.0. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: This eld is 0.0. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: This eld is 0.0. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: This eld is 0.0. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: This eld is 0.0. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: This eld is 0.0. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: This eld is 0.0. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: This eld is 0.0. SV: This eld is 0.0. GS: This eld is 0.0. CS:
DOUBLE
orbital_inclination
DOUBLE
sat_ascending_node
DOUBLE
sat_altitude
DOUBLE
sat_ground_speed
DOUBLE
satellite_heading
DOUBLE
satellite_latitude
DOUBLE
satellite_longitude
DOUBLE
acrosstrackFOV
131
Type DOUBLE
Name semi_major_axis
Description SP: This eld is 0.0. SV: This eld is 0.0. GS: This eld is 0.0. CS: SP: These elds contain 0.0s. SV: These elds contain 0.0s. GS: These elds contain 0.0s. CS: SP: This eld is EMSC_FALSE. SV: This eld is EMSC_FALSE. GS: This eld is EMSC_FALSE. CS: This eld is EMSC_TRUE.
DOUBLE[ 16]
bandgain
ENUM
LGSOWG
132
External File Format Header Object Types TM Header The following table defines the contents of the record written to an IMAGINE .img file which has been read from a Landsat source. The fields are copied from the TM Fast Format headers. If the value is a string it is left unchanged. If the value is a number it is converted from ASCII to binary. All strings are NULL terminated. The description column indicates the source of the information. The term FF indicates the EOSAT Fast Format Header, and the term SF indicates EOSAT Standard Format Header, it is assumed that the user has access to the EOSAT documents. SF: Landsat Technical Working Group (LTWG) FF: EOSAT Fast Format Document for TM Digital Products, Version B Type LONG LONG LONG CHAR[13] CHAR CHAR[9] CHAR[3] CHAR[5] CHAR[12] CHAR[15] CHAR[11] CHAR[77] Name imageheight imagewidth numbands eosatsceneid rev acqdate satellitenum instrumenttype productnum producttype productsize mapsheetname Description FF: Field 61. SF: table 8 bytes237-244. FF: Field 59. SF: table 8 bytes 281-288 FF: based on Fields 94 and 35. SF: table 5 bytes 1413-1428. FF: NO SCENEID. SF: table 3 bytes 91-117 FF: Field 117. SF: blank. FF: Field 6. SF: blank. FF: Field 8. SF: blank. FF: Field 10. SF: blank. FF: Field 2. SF: blank. FF: Field 12. SF: blank. FF Field 14. SF: blank. FF: Field 15. SF: blank.
133
Type CHAR[4] CHAR[5] CHAR[21] LONG LONG CHAR[5] LONG LONG DOUBLE DOUBLE[15] DOUBLE DOUBLE DOUBLE
Name interleaving scenesize earthellipsoid orbitalpath orbitalrow usgsprojection usgsprojectionnum usgsmapzonenum pixelsize usgsprojparms upperleftlong upperleftlat upperlefteasting
Description FF: BSQ. SF: table 3 bytes 131-154. FF: blank. SF: based on table 3 bytes 118-130. FF: Field 51. SF: blank. FF: Field 4. SF: table 5 bytes 165-180. FF: Field 4. SF: table 5 bytes 165-180. FF: Field 43. SF: table 5 bytes 1557-1572. FF: Field 45. SF: 0. FF: Field 47. SF: 0. FF: Field 56. SF: table 6 bytes 365-380. FF: Field 49. SF: 0.0s. FF: Field 63. SF: 0.0. FF: Field 65. SF: 0.0. FF: Field 67. SF: calculated from table 5 bytes 85-100, 101-106; pixelsize, scenesize. FF: Field 69. SF: calculated from table 5 bytes 85-100, 101-106; pixelsize, scenesize. FF: Field 71. SF: 0.0. FF: Field 73. SF: 0.0.
DOUBLE
upperleftnorthing
DOUBLE DOUBLE
upperrightlong upperrightlat
134
Type DOUBLE
Name upperrighteasting
Description FF: Field 75. SF: calculated from table 5 bytes 85-100, 101-106; pixelsize, scenesize. FF: Field 77. SF: calculated from table 5 bytes 85-100, 101-106; pixelsize, scenesize. FF: Field 79. SF: 0.0. FF: Field 81. SF: 0.0. FF: Field 83. SF: calculated from table 5 bytes 85-100, 101-106; pixelsize, scenesize. FF: Field 85. SF: calculated from table 5 bytes 85-100, 101-106; pixelsize, scenesize. FF: Field 87. SF: 0.0. FF: Field 89. SF: 0.0. FF: Field 91. SF: calculate from table 5 bytes 85-100, 101-106; pixelsize, scenesize. FF: Field 93. SF: calculated from table 5 bytes 85-100, 101-106; pixelsize, scenesize. FF: Field 107. SF: 0.0. FF: Field 105. SF: 0.0. FF: Field 113. SF: table 5 bytes 85-100. FF: Field 112. SF: table 5 bytes 101-106.
DOUBLE
upperrightnorthing
lowerrightlong lowerrightlat lowerrighteasting
DOUBLE
lowerrightnorthing
lowerleftlong lowerleftlat lowerlefteasting
DOUBLE
lowerleftnorthing
DOUBLE DOUBLE LONG LONG
scenecenterlat scenecenterlong scenecenterline scenecenterpixel
135
Type DOUBLE DOUBLE CHAR[11] CHAR[3] DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE
Name scenecenternorthing scenecentereasting geodproctype resampalgorithm semimajoraxis semiminoraxis radgainband1 radgainband2 radgainband3 radgainband4 radgainband5 radgainband6 radgainband7 radbiasband1 radbiasband2 radbiasband3 radbiasband4
Description FF: Field 111. SF: table 6 141-156. FF: Field 109. SF: table 6 bytes 157-172. FF: Field 17. SF: blank. FF: Field 19. SF: table 5 bytes 1541-1556. FF: Field 53. SF: 0.0. FF: Field 55. SF: 0.0. FF: Field 21. SF: 0.0. FF: Field 23. SF: 0.0. FF: Field 25. SF: 0.0. FF: Field 27. SF: 0.0. FF: Field 29. SF: 0.0. FF: Field 31. SF: 0.0. FF: Field 33. SF: 0.0. FF: Field 21. SF: 0.0. FF: Field 23. SF: 0.0. FF: Field 25. SF: 0.0. FF: Field 27. SF: 0.0.
136
Type DOUBLE DOUBLE DOUBLE CHAR[17] CHAR[17] LONG LONG DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE DOUBLE
Name radbiasband5 radbiasband6 radbiasband7 wrsdesignator wrscycle sunelevation sunazimuth orientationangle nominterlinedist nominterpixeldist nomaltitude nomgroundspeed crosstrackFOV displayrotangle scenecenterheading sensorscanrate sensorsamplerate nomorbitinclincation
Description FF: Field 29. SF: 0.0. FF: Field 31. SF: 0.0. FF: Field 33. SF: 0.0. FF: blank. SF: FF: blank. SF: FF: Field 101 FF: Field 103 FF: Field 41 FF: 0.0. SF: table 6 bytes 61-76. FF: 0.0. SF: table 6 bytes 45-60. FF: 0.0. SF: table 6 bytes 493-508. FF: 0.0. SF: table 6 bytes 509-524. FF: 0.0. SF: table 6 bytes 557-572. FF: 0.0. SF: table 6 bytes 445-460. FF: 0.0. SF: bytes 525-540. FF: 0.0. SF: table 6 bytes 573-588. FF: 0.0. SF: table 6 bytes 589-604. FF: 0.0. SF: 0.0.
137
Type CHAR[6] LONG
Name datum offset
Description FF: blank. SF: blank. FF: Field 115. SF: 0.0.
138
Preference Definition File
Preference Denition File

The PDF below is one of the files supplied with IMAGINE. A few additional comments have been added for clarity. This file and others like it are found in <IMAGINE_HOME>/devices/printers and <IMAGINE_HOME>/defaults. They have the .pdf file extension.
/**************** Kodak XL7700 ********************************/ /* ** Model -- Substitute Kodak XL7700 with the name of your printer. */ model(Printer Model): Kodak XL7700 Printer manufacture and model; queuename(Print Queue Name): xl7700 Print queue name for printer; queuehost(Print Queue Host): expand $HOSTNAME Host to which the printer is attached; device(Device): /dev/sip0 Device name of printer; systemfive(Print Queue Type) : BSD Queue host use system V or BSD print daemon? enums { BSD BSD type of printing, lpr SYSTEM V SYSTEM V type of printing, lp }; /* ** Color. Mapmaker creates 3 layers for RGB, 4 layers for CMYK, and 1 layer ** for Black. The first line is default. Enums includes other options. */ color(Color Options): RGB Printer color paths enums { RGB Red Green Blue Black Black Only }; /* ** Density. */ density(Transparent Density): Normal Output transparent density enums { Normal Normal density High High density Low Low density };
139
/* ** size - You can set other min, max values here to minimize mistakes. */ mediawidth(Media Width) : 8.5 The given media width min 0; mediaheight(Media Height) : 11 The given media height min 0; /* ** Type. */ unittype(Media Units) : inch Unit Type enums { inch English system meter Metric system centimeter Metric system millimeter Metric system }; densitywidth(Horizontal Dot Density) :203 Dots per unit horizontal (e.g. DPI) min 0; densityheight(Vertical Dot Density) :203 Dots per unit vertical (e.g. DPI) min 0; /* ** Type. */ dotsunittype(Dot Units) : inch Printer Density Unit Type enums { inch English system meter Metric system centimeter Metric system millimeter Metric system }; /* ** Put the correct min, max here to minimize user error. ** Use 0 for unlimited, e.g. set totalpixelheight to 0 for roll paper. */ totalpixelwidth(Total Horizontal Pixels) :2048 Total number of pixels horizontal (e.g. DPI) min 0;
140
totalpixelheight(Total Vertical Pixels) :1536 Total number of pixels vertical (e.g. DPI) min 0; mirror(Use a Mirrored Image) : false Is the image mirrored? boolean true false; /* ** Number of copies. */ numcopies(Number of Copies) : 1 Number of copies to print min 1 max 1000; /* ** Color intensity level for each layer. For example, a dye-sub has 256 for ** each layer, an electrostatic plotter only has 1. */ intenselevel(Color Intensity Level) : 256 The printer color intensity level (max 256) min 256 max 256;
141
Installing, Compiling, and Running the Example Files

If you are setting up the toolkit for UNIX, see Under UNIX.
Under Microsoft Windows

Installation The IMAGINE Toolkit for Windows 98/NT installer is a single executable file. When the installer is run it creates a directory called toolkit in the IMAGINE install directory. This directory contains library files, C header files, and a set of programming examples to demonstrate the use of the toolkit. Help files are also installed into the IMAGINE help directory. Requirements The IMAGINE Toolkit for Windows 98/NT was created for use with the Microsoft Visual C++ development environment version 5.0. Programs created with the toolkit that utilize EML will require an installed and licensed version of IMAGINE to operate. Using the Example Projects In the $IMAGINE_HOME/toolkit/examples directory there is a Microsoft Visual C++ workspace file called examples.dsw which can be used to load all of the example projects. The workspace handles the dependency of each project upon the ewin_main project, ensuring that the ewin_main library is compiled and available for linking with the examples. Each example project creates the executable in the $IMAGINE_HOME/bin/NTx86 directory. After they are compiled they can be run from the IMAGINE commands window. This window is accessed with the Commands... item in the Session menu on the IMAGINE toolbar. Many of the examples require command line options as explained in the sources and some depend upon example data in the $IMAGINE_HOME/examples directory. Compatibility Limitations These examples and most of IMAGINE itself are based upon common source shared between the UNIX and Windows 95/NT environments. To achieve this the use of the ANSI C libraries and Win32 libraries has been avoided whenever possible (except for the math libraries). There are many packages in the elib library that were created to support this with the foremost being efio, estr, and emsc.
& Note that when specifying explicit pathnames under Windows, you must place quotes around
the pathname and you must use forward slashes (/) when running examples from the Session Command History dialog.
142
Installing, Compiling, and Running the Example Files Structure Packing The IMAGINE Toolkit libraries have been compiled using the /Zp4 compiler option. This places structure members on 4 byte boundaries. The default for the Microsoft compiler is /Zp8. This option is necessary because of the way in which the emif toolkit package interprets the data dictionaries in HFA files. To understand why, you have to understand what the packing is all about. For reasons of performace, some systems impose memory alignment requirements on primitive data types. For example, longs may be required to begin on a 4 byte boundary and doubles may be required to begin on an 8 byte boundary. When we say that address a is on an n byte boundary we mean that a mod n is 0. In C a structure member is an offset that begins from the base address of the structure. To say that a structure member is aligned to a given bounday means that its offset is so aligned. The Microsoft compiler has an option (/Zpn) that provides control over the alignment of structure members. It chooses the smaller alignment of the argument (n) and the native aligment of the datatype. So, for example, if /Zp4 is used and a double is placed in a structure this double will be aligned on a 4 byte boundary instead of the native 8 byte boundary because 4 is smaller than 8. While the /Zpn option controls the alignment of structure members, it does not control the alignment of data in memory. This causes emif a problem because it is based on the assumption that data and structure members are subject to the same alignment rules. The Microsoft compiler appears to use 4 byte alignment rules for data in memory, so the /Zp4 option makes the data and structure member alignment work for emif. For users of the toolkit (elib, emllib, etc.) this means that they must insure that IMAGINE structures are compiled with 4 byte alignment. This can be done in several ways. The source file can be compiled with /Zp4, or the includes for the IMAGINE headers can be bracketed with the pragmas which guarantee the 4 byte alignment. An example of this is below:
/* ** Force the aligment for the imagine includes to 4. */ #pragma pack(push, imagine_pack, 4) /* ** Include the imagine include files. */ #include <emsc.h> #include <emif.h> : #include <eimg.h> /* ** Return the packing to whatever it was. */ #pragma pack(pop, imagine_pack)
143
Under UNIX
The IMAGINE Developers Toolkit for UNIX comes with a shell script which will create a subdirectory in your home directory containing example source code along with makefiles. This will allow a beginning Toolkit programmer to have some working examples to begin modifying and experimenting with. To invoke this script, give the following command: <IMAGINE_HOME>/install/setup_toolkit where <IMAGINE_HOME> is the directory where IMAGINE was installed. This will create the directory $HOME/imaginetk<version> (where <version> is a three digit number representing the version of IMAGINE - e.g. 831 or 840) and copy several source files and a makefile into it. Now make the example files with the following command: cd $HOME/imaginetk<version> make all
Be sure to use the version of make that came with your system, and not a variant such as
GNU make.
144
Example File Descriptions

This list summarizes the C Programmers Toolkit example files. For more detailed information, click the file name. Also, remember to examine the source code for additional comments.
o read80descrip reads and prints the descriptors (statistics, contrast table, color tables,
etc.). of an IMAGINE image file (demonstrates reading and manipulating IMAGINE descriptor tables)
o copy80layer copies a selected layer of an IMAGINE image file to a very simple raster
format (demonstrates reading and manipulating IMAGINE raster data)
o RasterAccessprints the pixel value for selected image layer, row, and column
(demonstrates accessing individual pixels in IMAGINE raster layers)
o subset1 opens an IMAGINE image file and writes a subset of the image into an output file
(demonstrates the argument parsing package)
o subset2 similar to subset1, but includes full error checking and reporting (demonstrates
the error reporting package)
o subset3 adds the session manager and a graphical user interface to subset2
(demonstrates the session manager and progress meter packages, and writing graphical front ends to IMAGINE functions)
o eemlsample explains how to write a simple GUI application using the EML toolkit. Use the
Makefile.example to compile the program. This sample application demonstrates the use of simple EML API functions. For a more complete example see table program.
o readmssephemeris reads the ephemeris (sensor) data structure from an IMAGINE file
imported from a LANDSAT MSS (Multispectral Scanner) tape. The data is read into a C structure, and selected members of the structure are printed to standard output.
o degrad degrades an input raster image to get a lower resolution output. o digview digitize image points from viewer. o eprj_sample demonstrates how to write a program that IMAGINE can use to perform your
own map projection. Because it communicates with IMAGINE via pipes, it cannot be run stand-alone.
o fonttablemaker creates a map composition that is a table of ASCII values and associated
characters (demonstrates writing annotation layers).
145
o table explains how to write a complex GUI application using the EML toolkit. Use the
Makefile.example to compile the program. For a simple example see eemlsample program.
o importex demonstrates import functions available in eixlib by creating a simple importer

which reads ERDAS 7.5 LAN files.
o exportex demonstrates export functions available in eixlib by creating a simple exporter

which writes ERDAS 7.5 LAN files.
o chartdemo demonstrates the functionality of the Eeml_Chart and CellArray packages. o fxgeneral illustrates most of the major points of reading and writing an ERDAS IMAGINE
.img file. The IMAGINE libraries look for a series of environment variables which are normally defined by the imagine startup script. Under UNIX, these programs can be run stand-alone. Use the script called runex (run example) which sets the needed environment variables and then runs the specified program. For example, to run the eemlsample program type runex eemlsample.
146
Example File Descriptions Example: read80descrip.c The file read80descrip.c shows how to access descriptor data from an IMAGINE image file. This example and the two that follow, copy80layer.c and RasterAccess.c, are good examples to follow if you primarily want to access IMAGINE data for use in other programs. Using these examples as guides, you can also write programs to export IMAGINE files into any desired file format. Due to the convention used to name Toolkit functions and data structures, the Toolkit Include files needed are very easy to identify. All functions in the eimg package, for example, are declared in the file eimg.h. In addition to the four packages discussed above, the header file emsc.h is included as well. This file contains a series of useful macros and enumerated data types. For example, the enumerated type Emsc_Boolean provides a standard method of representing boolean (true/false) data as either EMSC_TRUE or EMSC_FALSE. There are also definitions for EMSC_MIN and EMSC_MAX, the minimum and maximum of two numbers, and EMSC_PI, among others. read80descrip.c declares two global variables,
static EintToolkitData *erdinit = NULL;
which is necessary for all toolkit programs, and

static Eerr_ErrorReportingMode reportingmode = EERR_DEBUG;
which states that error reports will list each function in the calling sequence, rather than just the top-level function call. In order to focus on the capabilities of the eimg package, most of the error checking and reporting available through eerr has been omitted. (It will therefore be easy to crash!) The reportingmode variable is included in case you want to extend the error reporting. After initializing the toolkit, the program finds the names of the layers of the input file via eimg_LayerGetNames. This function returns a pointer to an Estr_StringList structure, which contains an array of character strings along with the value count containing the number of strings in the array. The layer names are used in the function eimg_LayerOpen, which opens a single layer. Each layer in the input file is opened as read-only by including EIMG_LAYER_OPTION_READONLY in the variable argument list. The pixels of a raster layer are partitioned into rectangular blocks, with all blocks having the same width and height (in pixels). Pixels are read from or written to the layer through the eimg_LayerRead or eimg_LayerWrite functions. A partial listing of the Eimg_layer structure is shown below:
typedef struct EIMG_LAYER { long width; long height; Eimg_LayerType layerType; Egda_PixelType pixelType;
/* /* /* /*
Width (in pixels) of the layer */ Height (in pixels) of the layer */ Type of this layer (e.g., thematic) */ Type of pixels in this layer (e.g., unsigned
147

8-bit) */ /* Width (in pixels) of each block in the layer */ /* Height (in pixels) of each block in the layer (in pixels) */ /* Other structure elements */
long blockWidth; long blockHeight; } Eimg_Layer;
The layer width, height, type (thematic or continuous) and pixeltype are easily accessed once eimg_LayerOpen is called. The eimg package contains a number of high-level function calls for reading and writing descriptor data. In read80descrip.c, each type of descriptor data is accessed similarly. First, a pointer to the appropriate descriptor table is declared and initialized to NULL. Next, a function of the form eimg_XXXXRead is called (i.e. eimg_StatisticsRead, eimg_HistogramRead, eimg_ColorTableRead, eimg_ClassNamesRead, eimg_MapInfoRead, and eimg_ProParametersRead). The second argument of each function is a pointer to the type of descriptor to be returned. If this argument is NULL, then a descriptor table of the proper type is allocated within the function if the descriptor exists. If the second argument is not NULL, the function assumes that the table has already been created, with the second argument pointing to it. In this program, we are only accessing each descriptor table once, so in each case NULL is passed as the second argument. If the descriptor table does not exist in the layer, the returned pointer is NULL. Otherwise, the data in the table is printed to standard output, and the table is deallocated. The Esta_Statistics, Esta_Histogram, Esta_ColorTable, Esta_ClassNames, Eprj_MapInfo and Eprj_ProParameters structures are shown in the documentation under the esta and eprj packages.
148
Example File Descriptions Example: copy80layer.c The next example, copy80layer.c, shows how to access raster data in IMAGINE files. This program copies a selected raster layer from an IMAGINE file to a simple raster file format. As in the previous example, the idea is to show how to access IMAGINE data rather than to create a truly useful application. As before, the program begins by initializing the Toolkit, and finding the layer names of the input file. Next, the desired layer is opened and the layer width and height are queried.
Note that a file containing n layers has layers indexed from 0 to n-1. The IMAGINE user
interface must be designed to handle the discrepancy between layer number and layer index by subtracting one from the users input before it is passed to the application. IMAGINE raster data is stored in a Eimg_PixelRect structure. The Eimg_PixelRect structure is the same as the Egda_BaseData structure, shown below:
typedef struct { long numrows; long numcolumns; Egda_PixelType datatype; Egda_ObjectType objecttype; Egda_Byte *data; /* pointer to the data array */ Egda_Byte *currentData; /* can be set to point to anywhere within data array */ long pitch; /* Number of bytes between rows */ Emsc_Boolean derivedFlag; /* indicate data array is derived or not */ long numelements; /* total elements in data array */ long numbytes; /* number of bytes per-pixel */ Emsc_Opaque *userdata; /* user specified data pointer */ } Egda_BaseData;
The Eimg_PixelRect buffer is allocated using the function eimg_PixelRectCreate, which requires the number of rows and columns and the data type as arguments. In this example, the data type for the buffer, and hence the output file, is that of the input layer. The layer information is read into the buffer with the function eimg_LayerRead. An output file is created, and the number of rows and columns in the image are written as long integers to the beginning of the file as a simple header. Since the raster data for the layer is stored contiguously beginning at pixelblock->data, it may be written to the output file with a single fwrite function. The output file may be examined using the View Binary Data... option from the Tools menu. Open the file and set the Data Type to match the source file.
149
Example File Descriptions Example: RasterAccess.c RasterAccess.c demonstrates how to access individual pixels in an IMAGINE file. The program prompts the user for the layer number and the column and row within the layer, and returns the pixel value. Unlike copy80layer.c, we dont want to be limited to a single layer. To manage more than one layer within a file, the Toolkit provides a datatype, Eimg_LayerStack, which is simply a collection of related layers. The calling syntax for the function eimg_LayerStackOpen is very similar to eimg_LayerOpen. Since only one pixel is read at a time, an Eimg_PixelRect is created which holds only one pixel. It is created with a floating point data type (EGDA_TYPE_F32), so all data types (except complex) may be read. After the layer, column and row are entered by the user, the appropriate pixel is read into the Eimg_PixelRect variable using eimg_LayerRead. Note that opening a layerstack opens each of the layers in the layerstack, so operations may be performed on each layer individually as well as on the layerstack as a whole. The pointer to an individual pixel in a pixelrect may be found using the macro EIMG_DATAPTR, which takes as arguments a pointer to the pixelrect, and the column and row of the pixel. The macro is defined in eimg.h as
#define EIMG_DATAPTR(RECT,COLUMN,ROW) / (((RECT)->currentData) + (ROW)*((RECT)->pitch) + (COLUMN)*((RECT)->numbytes))
Since the pixelrect contains only one pixel, the column and row values for the pixelrect are both zero. The macro returns an Egda_Byte pointer, and must be cast to the data type of the pixelrect, in this case 32-bit floating point (Egda_F32). This program is run from the Session Command History dialog with the following syntax:
rasteraccess <filepath> <layer_number> <column_number> <row_number>
Results are returned to the Session Log window. For example, rasteraccess C:/imagine/examples/lanier.img 2 90 40 returns the value 23. This can be verified by opening the file in a viewer and using the inquire cursor to view pixel values. Be sure to set File cordinates before entering 90 in the X cell and 40 in the Y cell. Then read the pixel value for the layer of interest under the FILE PIXEL column. An alternate method of accessing pixels is to read the entire raster contents of a file into an Eimg_PixelRectStack object, and then access pixels one at a time from the pixelrectstack. The following code fragment illustrates the technique. It requires much more memory since the entire image is read, and there may be a delay while the data is read, depending on the size of the image.
Eimg_LayerStack *inlayerstack; Eimg_PixelRectStack *pixelrectstack; Eimg_PixelRect *pixelrect; Egda_F32 *pixelptr;
150

... /* ** Allocate space for the pixel to be read */ pixelrectstack = eimg_PixelRectStackCreate (nlayers, ncols, nrows, EGDA_TYPE_F32, &errorreport); /* ** Read the layerstack into the pixelrectstack */ eimg_LayerStackRead(inlayerstack, 0, 0, ncols, nrows, pixelrectstack, &errorreport); /* ** Get the layer, column and row value from the user ** and read the appropriate pixel value. Keep looping ** until user enters a value of -1 */ while (1) { printf (Enter layer, column, row: ); scanf (%d %d %d, &layer, &column, &row); if (layer != -1) { pixelrect = pixelrectstack->datalayer[layer]; pixelptr = (Egda_F32 *) (EIMG_DATAPTR (pixelrect, column, row)); printf (Pixel value = %g\n, *pixelptr); } else break; } /* ** Deallocate pixel storage */ eimg_PixelRectStackDelete (pixelrectstack, &errorreport); /* ** Close the input layerstack */ eimg_LayerStackClose (inlayerstack, &errorreport);
151
Example File Descriptions Example: display_anno.c This example shows how to open and display an annotation layer (.ovr file). The accompanying EML script provides the canvas for display.
152
Example File Descriptions Example: draw_demo.c The draw_demo example is intended to show how the different draw modes can affect the display of various objects in a canvas. It makes use of a dialog to select draw mode, object., and object color. The result is displayed on a canvas containing red, green, and blue rectangles in the dialog. It also shows an example of using ButtonDown events to gather coordinate information and returning this info via a Message Dialog.
153
Example File Descriptions Example: convolve.c This example program performs a convolution on the specified IMAGINE file (.img) using the specified kernel. The result is written to the specified output file. Optional command-line arguments include meter which displays a job progress meter while the program is running and boundaryvalue which sets the value for pixels outside the image or specified window. The optional window specification allows you to extract and process a subset of the original image. The calling syntax is:
convolve <infile> <outfile> -k <X_size> <Y_size> <k1,1> ... <kX_size,Y_size>
Where X_size and Y_size define the size of the filter kernel and kx,y are the coefficients of the filter kernel matrix. Optional arguments are described in the source file, convolve.c.
154
Example File Descriptions Example: canvas_test.c This is a demonstration of how to display various kinds of objects on a canvas. The types of objects are hard coded and some parameters are pseudo-randomly generated. Each time the canvas is refreshed, much of it changes due to the random nature.
155
Example File Descriptions Example: subset1.c The subset1.c example program demonstrates the use of the argument parsing package. This program writes a rectangular subset of an image, specified by the file coordinates of the upperleft and lower-right corners of the rectangle, to a new file. This program is run from the Session Command History dialog with the following syntax:
subset1 <inputfile> <outputfile> <ulx> <uly> <lrx> <lry>
For example, under Windows:

subset1 C:/temp/lanier.img C:/temp/lanier_AirPort.img 178 340 257 404
creates the new image file lanier_AirPort.img containing only the region of the air port. The Earg_Cmd array is specified as
static Earg_Cmd format[] = { subset_subset, subset1 %s %s %d %d %d %d, , EARG_NO_ERR, EARG_END };
This specifies that the name of the program, subset1, must be followed by two string arguments and four integer arguments. These six arguments are passed to the function subset_subset via the *argv array. Since there are no optional arguments, any deviation from this calling syntax returns an error. Function main merely initializes the Toolkit and parses the command line with the function earg_DoArgs. earg_DoArgs checks the calling syntax and then calls the subset_subset routine, which is where the real work of the program is done. If there is an error in the call to earg_DoArgs, such as incorrect command line syntax, errorreport returns a non-NULL value, causing the Eerr_ErrorReport structure to be printed and then deleted before exiting the program. The subset_subset function first finds the names of the layers of the input file via eimg_LayerGetNames. Next, the corner points of the subsetted image are converted from argument-string form to long ints, and width and height of the subsetted image are found. Each layer in the input file is then opened as read-only, and the output layer is given a name which is similar to the input layer name. For example, if the input file layer name is mobbay.img(:Layer_1) and the output file name is mobbay_subset.img, then the output file layer name is mobbay_subset.img(:Layer_1). Once the output layer name is derived, the output layer is created using the function eimg_LayerCreate. This function has a variable-length argument list which allows various characteristics and properties of the layer to be defined. In this case, the option EIMG_LAYER_COMPUTE_STATS_ON_CLOSE is enabled, which, as its name indicates, instructs the layer to compute it statistics when the layer is closed.
156
Example File Descriptions Next, the data buffer pixelblock is allocated using eimg_PixelRectCreate, and is made to be the same size as the subset. The data is read from the input layer into the buffer, and then written to the output layer using eimg_LayerRead and eimg_LayerWrite. Both the input and output layers are closed, with statistics calculated on the output layer, and the data buffer is deallocated.
157
Example File Descriptions Example: subset2.c Example subset2.c example program builds on subset1.c by adding full error-checking, and by adding an optional argument to the command line. The data type of the output file may now be chosen using the -p option. Note that a new function, set_pixeltype, has been added, and a new entry describing the calling syntax for the -p option is added to the Earg_Cmd structure. In addition, two new global variables, logpixeltypeset and pixeltypeout, have been added. logpixeltypeset is a boolean variable which, when true, indicates that a non-default value is to be used for the output pixeltype. The pixeltypeout variable stores the output pixeltype. One consequence of the command format structure in the earg package is that functions called by earg_DoArgs must use global variables to communicate with one another. Since the number of command-line options is fairly small for most programs, this is not a major limitation. This program is run from the Session Command History dialog with the following syntax:
subset1 <inputfile> <outputfile> <ulx> <uly> <lrx> <lry> -p <data type>
For example, under Windows:

subset2 C:/temp/lanier.img C:/temp/lanier_AirPort.img 178 340 257 404 -p s16
creates the new image file lanier_AirPort.img as in the previous example but changing the data type from unsigned 8-bit to signed 16-bit.. Error Reporting The other major addition in subset2.c is complete error reporting. As stated earlier, its a good idea to check the returning error pointer after each call to a toolkit function, and subset2 does just that. Since much of the code pertaining to error reporting is similar, two macros, ErrorCreate and ErrorExit, are included to reduce typing and improve readability. The macros may be used if the following conditions hold: the error is considered Fatal, the error string is a constant, there is a string variable named functionname which contains the name of the current function, and the pointer to the error reporting structure is called errorreport. The ErrorExit macro is used when no additional cleanup, such as freeing allocated memory, needs to be done before exiting. If such cleanup does need to be done, the ErrorCreate macro may be called, which simply calls the eerr_CreateErrorReport function, and the subsequent printing of the error message, cleanup, and exiting must be performed by hand. In some cases, such as if the error message is not constant, the macros are not used.
158
Example File Descriptions Example: subset3.c The next example uses an EML script that sets up a graphical user interface to the subsetting program. This program is run from a DOS command window with the following syntax:
<install drive>:\<imagine home>\bin\ntx86\eml subset3.eml
For example:
D:\imagine\bin\ntx86\eml subset3.eml
To open the dialog under UNIX, type the command

<IMAGINE_HOME>/bin/arch/eml subset3.eml
where arch is one of sun4, decux, sgi, hp700, rs6000 or aviion. First, examine the subset3.c example program. It allows the program to connect to the IMAGINE Session Manager, producing a small dialog which tracks the progress of the program, and provides a Cancel button allowing the user to interrupt the process at any time. This is exactly what happens during resampling, importing/exporting, running the modeler, etc. The functions pertaining to the Session Manager are in the esmg (Session Manager) and emet (Progress Meter) packages. In order to use the Progress Meter, you must declare a global pointer to an Emet_MeterInfo structure. In function main, call the function esmg_JobInit, which connects the program to the session manager if it is running. The meter information structure is initialized inside the function set_meter, which is called only if the command line contains the -m[eter] option. The progress meter functions used in subset3.c are:
o emet_MeterInfoChangeTaskName o emet_MeterInfoPrint o emet_MeterInfoSet
159
Example File Descriptions The function emet_MeterInfoChangeTaskName is used to print a string representing the current status of the operation to the progress box. emet_MeterInfoPrint sets the percentage completion of the operation. If there are several subtasks involved in the operation, emet_MeterInfoSet makes reporting of the correct percentage easier. emet_MeterInfoSet maps the 0-100% completion range of a subtask to a smaller range. For example, suppose there are four layers in an image. The processing of each layer should advance the progress meter 25%. Using emet_MeterInfoSet, the progress of each layer may be reported from 0% to 100%, but the progress meter will advance from 0% to 25% for the first layer, 25% to 50% for the second layer, etc. Using the layer option EIMG_LAYER_OPTION_PROGRESS_METER_ON_CLOSE, the progress meter may be instructed to advance during any operations which are performed when a layer is closed, such as computing statistics. In the subset_subset function, half of the progress for each layer is set aside for copying the image block, and half for computing statistics of the newly-created layer. Note that the reading and writing of raster data is done one line at a time in this example rather than in a single block. This makes the motion of the progress meter smoother, since it is updated after each line. EML Scripts The Session Manager and Progress Meter functions are not useful unless the application is called from an EML (ERDAS Macro Language) script. As stated earlier, EML provides a convenient method of producing easy-to-use graphical user interfaces (GUIs). With a little practice, even complex dialog may be produced without undue effort. Two items are necessary to produce a graphical user interface using EML: the EML interpreter and an EML script. An EML script provides a description of the various dialogs and menus of an interface, and the interpreter produces the interface from the description. The interpreter itself is simply called eml, and resides in the directory <IMAGINE_HOME>/bin/arch, where arch is one of sun4, decux, sgi, hp700, rs6000 or aviion. EML uses a syntax similar to the C language. Each dialog or window on the screen produced by EML is called a frame. The various buttons, menus, etc. with which the user interacts are called frameparts. Groups of related frames (all of the frames used for one application, for example) are known as components. All frames must reside inside a component. The subset3.eml example script describes the user interface for the subset3 program. Since the functionality of the program is simple and straightforward, only one frame is needed. After declaring a component called subset3, the frame subsetdialog is declared within the subset3 component. The title keyword describes what appears on the top bar of the dialog, and the at keyword governs the position of the dialog with respect to the upper left corner of the screen. Next, any frameparts which are referred to before they are defined must be declared.
160
Example File Descriptions The subsetdialog frame contains five frameparts: a group containing two filename frameparts, corresponding to the input and output filenames, a popuplist which determines the pixel type of the output image, a group containing four textnumber frameparts which control the corner points of the subsetted image, and two buttons labelled Cancel and OK. Each framepart has a name, similar to a variable name, and a value, which is generally set by the user. Each framepart also contains a generic description (title, location, size), and other framepart-specific attributes. A framepart position may be described relative to a previously defined framepart. Finally, most frameparts contain one or more event handlers which describe the effect of the framepart. The subset3 program (created by subset3.c) is invoked by clicking on the OK button. The job keyword is used here, which begins an application as a background process. If the application connects itself to the Session Manager, then a progress meter appears. Event Handlers An event handler describes which user actions are important to the dialog and what steps to take when such user actions are triggered. An event handler consists of the on keyword followed by one of the standard Event Messages and an action to take. Different frameparts have different types of event handlers. For example, the only event handler which may be used with a button framepart is ON MOUSEDOWN, which is triggered whenever the button is clicked. A textnumber framepart, on the other hand, contains the event handlers ON INPUT, which is triggered when a user enters a number, and ON VALUECHANGED, which is initiated when the value of the textnumber framepart changes. Note that components and frames may also contain event handlers, which are typically used to set initial conditions. In subset3.eml, the component event handler ON STARTUP is used, which instructs the eml interpreter to display the subsetdialog frame immediately after parsing the EML script. The frame event handler ON FRAMEDISPLAY may be used to initialize variables in a frame; it is not used in this example, however.
161
Example File Descriptions Example: readmssephemeris.c The program readmssephemeris.c shows how to read ephemeris or header data information from IMAGINE files. Many IMAGINE raster importers, in particular LANDSAT TM and MSS, SPOT, and AVHRR, transfer the ephemeris data from the source image into the IMAGINE file. This example shows how to read the ephemeris data into a C structure from a file imported from an MSS tape. All that is necessary is to declare a pointer to an Eixm_MssHeader structure (defined in Eixm_Mss.h), initialize the toolkit package, and then call eixm_MssHeaderRead. The return value points to the filled-in C structure containing the ephemeris data values. Once the ephemeris data is loaded into the C structure, several of the fields are then printed to standard output. The sample file mssdata.img containing an MSS ephemeris data node is in the examples directory. Once the program is compiled, it may be run by typing
readmssephemeris <IMAGINE_HOME>/examples/mssdata.img
162
Example File Descriptions Example: degrad.c The program degrad.c can be used to degrade an input raster image to get a lower resolution output by using the average of original pixel values instead of by resampling the original data. Such a degradation has been proved to be appropriate for layered correlation matching processes. degrad <inputname> <outputname> [<meter>] [<size>] [<exclude>]
inputname %s
Name of input file.
outputname %s
Name of output file.
meter -m[eter]
Display progress meter during execution.
size -s[ize] xsize ysize -s[ize] %d %d

Specify size in x and y direction for degrade. The default is 2 in both directions. If the input file size is ncolumns by nrows, the output file will be: ncolumns / xsize by nrows / ysize
exclude -e[xclude] excludevalue -e[xclude] %f

Set value to exclude in computing statistics in the output file. This program, once compiled and linked, may be run by itself (see command-line syntax above) or it can be invoked through EML to open a dialog. To open the dialog, run this program from a DOS command window with the following syntax:
<install drive>:\<imagine home>\bin\ntx86\eml degrad.eml
For example:
D:\imagine\bin\ntx86\eml degrad.eml
To open the dialog under UNIX, type the command

<IMAGINE_HOME>/bin/arch/eml degrad.eml
where arch is one of sun4, decux, sgi, hp700, rs6000 or aviion.
163
Example File Descriptions Example: digview.c The program digview.c can be used to digitize image points from a viewer. In order to be able to communicate with a viewer, digview must be run under the same session as the viewer. The program digviewpt.c contains the actual digitizing subroutine that is called by digview.c. These examples show you how to establish connection with viewer, how to create and update a cellarray, how to digitize points from a viewer, and how to display points in a viewer. The user interface code related to this example can be found in digviewpt.eml. Digitized points can be moved within the viewer or selected and deleted from the cellarray.
164
Example File Descriptions Example: eprj_sample.c The program eprj_sample.c is an example of an executable that IMAGINE can use to perform map projection calculations external to IMAGINE. The file eprj_sample.c shows the functions that you must provide to do the actual calculations. Your functions must be named exactly as they are named in eprj_sample.c, but you may name your executable whatever you like. You must link your functions with the eprj_ExternalMain.o provided in <IMAGINE_HOME>/usr/lib/ <arch>. This is the engine that communicates with IMAGINE and calls your functions. You must then add your projection to the end of the <IMAGINE_HOME>/etc/mapprojections.dat file. A sample mapprojections.dat file is provided in the imaginetk820 directory created in your home directory when you ran setup_toolkit. Your executable and the modified mapprojections.dat file (usually located in <IMAGINE_HOME>/etc) must be located on the path defined by EPRJ_PROJECTIONS_PATH in <IMAGINE_HOME>/bin/imagine_environment.
165
Example File Descriptions Example: fonttablemaker.c The program fonttablemaker can be used to create a two-page map composition that is a table of ASCII values and their associated characters. It demonstrates creating an IMAGINE annotation layer and creating most of the various kinds of annotation elements and annotation styles, as well as creating a simple map composition. After making the fonttablemaker application it can be run under IMAGINE by running IMAGINE from the directory where fonttablemaker was built and accessing fonttablemaker through the existing menu item in the Utilities Menu of the IMAGINE icon panel. This source and script for fonttablemaker are the same as those used for the fonttablemaker application that is distributed as part of IMAGINE. Under UNIX, it can be run stand-alone as follows: $IMAGINE_HOME/examples/runex fonttablemaker [-b[lob]] where -b[lob] will create at the upper-left corner of the map composition an example annotation group of various annotation elements of various annotation styles When you run fonttablemaker you will be presented with a dialog from which you can specify the map composition name, the size of one page of the map and the font for which you want the table generated.
166
Example File Descriptions Example: eemlsample.c This program eemlsample.c, demonstrates how to write a GUI application using the EML API toolkit. It uses the eemlsample.eml (an EML script) to build its GUI. The API calls used in this example are sufficient enough to write a GUI application, however, to get more in-depth detail on available API functions see the table program. To understand this application you do not need any prior knowledge/experience in writing GUI applications. However, having such experience will be very useful for understanding the EML API toolkit. This program is run from the Session Command History dialog with the following syntax:
eempsample
There are no arguments. Under Unix it can be run with the runex script (found in $IMAGINE_HOME/examples directory) as follows or it can be run under IMAGINE by adding it to the icon panel by modifying a local copy of imagine.eml.
$IMAGINE_HOME/examples/runex eemlsample
167
Example File Descriptions Example: table.c This program table.c, demonstrates how to write a GUI application using the EML API toolkit. It uses the table.eml (an EML script) to build its GUI. The API calls used in this example are sufficient enough to write a complete and complex GUI application. If you have trouble understanding this application see the simple GUI application - eemlsample. To understand this application you need to have some knowledge of EML API toolkit and how to create custom EML parts etc. Before you begin see the simple example mentioned above (eemlsample program) to familiarize yourself with the EML Toolkit. This table program demonstrates not only the EML API functions but also the interaction of a C program with an EML script. Examples here will show how to provide a callable function defined in your C program for use in an EML script. These are called application functions in EML. It will also show how to install one of the custom EML parts (CellArray) in an EML script and it provides examples to create all the data types supported by the CellArray and explains how to use many of the CellArray access API functions. You will also learn how to create a Document fame, menubar, statusbar, toolbar etc. as described in the EML Reference Manual. This program is run from the Session Command History dialog with the following syntax:
table
There are no arguments. Under UNIX it can be run with the runex script (found in $IMAGINE_HOME/examples directory) as follows or it can be run under IMAGINE by adding it to the icon panel by modifying a local copy of imagine.eml.
$IMAGINE_HOME/examples/runex table
168
Example File Descriptions Example: importex.c The importex.c program is an example of an IMAGINE importer. Although it doesnt contain an EML front end or have preview capabilities, it does support all other options that are normally found in IMAGINE importers, such as subsetting by band and area, and selection of output pixel type, block size, compression type, etc. The input and output files and other options are specified via an Earg_Cmd structure, with exactly the same format as is found in the IMAGINE importers. A typical command line would be something like importex -in C:/usr/data/myimage.lan -out C:/usr/data/myimage.img -meter pct The functions eixm_SetBands, eixm_SetBlocksize, etc. specified in the Earg_Cmd structure automatically set the fields in the global Eixm_Options structure eopt. In addition to containing program options specified on the command line, the Eixm_Options structure also contains many other useful fields pertaining to the input and output files which are derived later. The LAN header is read by defining a 128-byte structure which corresponds exactly to the LAN header structure. See ERDAS Ver. 7.X File Formats for header structure details.The header can then be read in using a single efio_ReadSeq function call. However, since the LAN file format is based on a least-significant byte (LSB) architecture, we must perform a byte swap on any multibyte fields in the structure. In the ImportData function, additional options structure fields are populated based on values in the LAN header, and the band and geographic subsetting is set up. After the output layerstack is created, the characteristics of the input data structure are specified in the Eixm_Descrip structure. This is similar in some ways to the Eixm_Options structure, but contains only items which describe the input data. Here we have decided to import data in 64-pixel-high strips. Next, eixm_ImportInit is called to initialize low-level buffers which are used during subsequent calls to eixm_LayerStackImport. The eixm_LayerStackImport function does all of the work, once the Eixm_Descrip structure has been set up and eixm_ImportInit has been called.
169
Example File Descriptions Example: exportex.c The exportex.c program is an example of an IMAGINE exporter. Like importex.c, it doesnt contain an EML front end, but is included to demonstrate that raster data may be easily transferred via the eixm toolkit package. Much of the discussion for importex.c applies to exportex.c as well. This program is run from the Session Command History dialog with the following syntax:
exportex -in imgfile -out lanfile -meter pct
If the output file already exists, it will not be overwriten.
170
Example File Descriptions Example: chartdemo.c The chartdemo program demonstrates how to use the Eeml_Chart package for graphically displaying data in an XY line graph as well as displaying it in a CellArray. The CellArray can be edited and the results are immediately displayed in the Chart. This program is run from the Session Command History dialog with the following syntax:
chartdemo
171
Example File Descriptions Example: fxgeneral.c While the Developers Toolkit On-Line Help provides a description of each function in each package the best way to learn is by example. This example program illustrates most of the major points of reading and writing an ERDAS IMAGINE .img file. The following sections illustrate the steps in creating an ERDAS IMAGINE file. These are drawn from the fxgeneral.c example. Also included in the examples directory is a sample ERDAS IMAGINE image file for this program. It is a small subset of a Landsat Thematic Mapper scene named small_tm.img. This program is run from the Session Command History dialog with the following syntax:
fxgeneral small_tm.img stretch.img
This command will stretch the layers of the input file and write the results to the output file. It will also create a TM Header node in the output file. Initialize the Toolkit Before any functions in the IMAGINE Developers Toolkit can be called, the toolkit must be initialized. The value returned must be passed to many of the toolkit functions so it should be kept in a global variable. /* ** Initialize the ERDAS toolkit */ eInit = eint_InitToolkit( (Emsc_Opaque**)&err ); SHOW_ERROR( return ( 1 ) );
Determine the Layers Most applications will operate on each of the layers in the toolkit. This can be done sequentially or in parallel. In either case the list of names of image layers must be known before processing begins. The following illustrates how to get names of the layers. /* ** Determine the names of all the layers in the input file */ layerNames = eimg_LayerGetNames( inputFile, eInit, &err );
172
Example File Descriptions The return is a pointer to an Estr_StringList. This is a structure which contains a count and an array of pointers to chars. Each pointer points to the name of a layer. This structure must ultimately be freed by the application using a call to estr_StringListDelete. Open the Input Layer The input layer name is contained in the Estr_StringList. /* ** Open up the input layer */ inLayer = eimg_LayerOpen( inLayerName, eint_GetInit(), &err, EIMG_LAYER_OPTION_READONLY, EIMG_LAYER_OPTION_END );
Create the Output Layer In this case the output layer name is constructed from the input layer name plus the output file name. /* ** Determine this input layer EHFA node name */ eimg_LayerNameParse( layerNames->strings[layer], NULL, NULL, &inLayerNode, &err ); SET_ERROR( __LINE__, eimg_LayerNameParse failed, break ); /* ** Form the output layer name */ outLayerName = eimg_LayerNameCreate( outDir, outBase, inLayerNode, &err ); /* ** Create the output layer ** The compute stats option will compute statistics and histogram ** for the layer when the layer is closed. */ outLayer = eimg_LayerCreate( outLayerName, inLayer->layerType, p, w, h,
173
Example File Descriptions eint_GetInit(), &err, EIMG_LAYER_OPTION_COMPUTE_STATS_ON_CLOSE, EIMG_LAYER_OPTION_END );
Allocate Pixel Array Data is read from and written to an Eimg_PixelRect. The PixelRect is a structure which defines a rectangular array of pixels. The pixel may be any of the 13 types of data supported by ERDAS IMAGINE. The types are: Name EGDA_TYPE_U1 EGDA_TYPE_U2 EGDA_TYPE_U4 Description Single bit data. In memory there is one signicant bit per pixel (byte). In the le it is packed 8 pixels to a byte. Two bit data. In memory there are two signicant bits per pixel (byte). In the le it is packed 4 pixels to a byte. Four bit data. In memory there are four signicant bits per pixel (byte). In the le it is packed two pixels to a byte. 8 bit unsigned data. There is one pixel per byte. 8 bit signed data. There is one pixel per byte. 16 bit unsigned data. There are two bytes per pixel. 16 bit signed data. There are two bytes per pixel. 32 bit unsigned data. There are four bytes per pixel. 32 bit signed data. There are four bytes per pixel. 32 bit oating point data (single precision). There are four bytes per pixel. 64 bit oating point data (double precision). There are 8 bytes per pixel. 64 bit complex data. There are two 32 bit oats per pixel, the real and imaginary parts. 128 bit complex data. There are two 64 bit oats per pixel, the real and imaginary parts.
EGDA_TYPE_U8 EGDA_TYPE_S8 EGDA_TYPE_U16 EGDA_TYPE_S16 EGDA_TYPE_U32 EGDA_TYPE_S32 EGDA_TYPE_F32 EGDA_TYPE_F64 EGDA_TYPE_C64 EGDA_TYPE_C128
The following example uses a double precision floating point type since all of the integer and floating point types can be handled this way. The read and write functions will automatically cast the data to the type of the PixelRect.
174
/* ** Create a buffer to contain a block of pixels from the input layer ** We declare the pixels to be double precision floating point ** numbers. eimg_LayerRead will automatically convert the input ** for us. */ pixels = eimg_PixelRectCreate( inLayer->blockWidth, inLayer->blockHeight, EGDA_TYPE_F64, &err ); SET_ERROR( __LINE__, eimg_PixelRectCreate failed, goto cleanup ); Read Data Data is read from an ERDAS IMAGINE layer as a rectangular region. If one wished to read a single line, then a wide rectangle of height one would be read. If the data type of the file is different from the data type of the PixelRect then the data will be converted on the fly. /* ** Read this block from the input file */ eimg_LayerRead( inLayer, column, row, bWidth, bHeight, pixels, &err );
Modify the Data The PixelRect contains a pointer called currentData. This is a void pointer which points to the beginning of the data in memory. There is another member in the structure called pitch which represents the number of bytes from the start of one row to the next. This should be used because it is not guaranteed that each row is an even number of data type units wide. /* ** Rescale data values */ for ( j = 0; j < bHeight; j++) { rowJcolumn = (double*)(pixels->currentData+j*pixels>pitch); for ( i = 0; i < bWidth; i++ ) 175
Example File Descriptions { rowJcolumn[i] *= mult; rowJcolumn[i] += add; } } Write the Data As with reading, the data is written to the file as a rectangular subset. This subset may be any size and may begin at any point in the file. If the data in the PixelRect is of a different type than that of the file then it is converted on the fly. The conversion from a larger type to a smaller is a simple truncation against the limits of the type. For example if 4096.345 is written to an unsigned 8-bit file then the output pixel is 255. /* ** Write this block to the output file */ eimg_LayerWrite( outLayer, column, row, bWidth, bHeight, pixels, &err ); Close the Layers The layers must be closed when processing is complete. Closing the output file will cause all necessary support information to be written to the file. In addition it will compute the statistics for the layer if that option was set. /* ** Close the input layer (if opened) */ if ( inLayer != (Eimg_Layer*)NULL ) eimg_LayerClose( inLayer, &err ); SHOW_ERROR( ; ); /* ** Close the output layer (if created) */ if ( outLayer != (Eimg_Layer*)NULL ) eimg_LayerClose( outLayer, &err ); SHOW_ERROR( ; ); /* ** Delete the pixel storage 176
Example File Descriptions */ eimg_PixelRectDelete( pixels, &err ); Create the Design For the Special Object Before writing an object such as the TM Header to a file, a design must be created. This is an example of creating a design for the TM Header in an IMAGINE file. The information about the header can be found in the HFA Object Directory chapter. design = emif_DesignCreate( NULL, TMHeader, &err, EMIF_T_LONG, imageheight, EMIF_T_LONG, imagewidth, EMIF_T_LONG, numbands, EMIF_T_CHAR|EMIF_M_ARRAY,eosatsceneid,13, : EMIF_T_LONG, offset, EMIF_T_END ); Write the Object to the File This example will write a node to the file which contains an object called TM_Header. The type of the object is TMHeader. When the file is closed its dictionary will contain the definition of the TMHeader type. /* ** Copy the design to the data dictionary of the output file */ emif_AddDesignToDictionary( oFile->dictionary, TMHeaderDesign, &err ); SET_ERROR( __LINE__, emif_AddDesignToDictionary fail, goto cleanup ); /* ** Write the TM Header data object to the file */ ehfa_ObjectWrite( oFile, EHFA_ROOT_NODE, TM_Header, TMHeader, EHFA_WRITE_FIRST_CHILD, TMHeader_Data(), TMHeaderDesign, &err );
177
Example File Descriptions Example: imagecopy.c This is a very straight-forward example in which all raster layers are copied from one file to another. This program is run from the Session Command History dialog with the following syntax:
imagecopy <inputfile> <outputfile>
178

ERDAS - Developers Toolkit Examples on-LineManual&#39;

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ERDAS - Developers Toolkit Examples on-LineManual&#39;

Încărcat de

Drepturi de autor:

Formate disponibile

DevelopersToolkitExamples'

Image File Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 ERDAS IMAGINE .img Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

eerr . emif . ehfa . edsc . eprj . esta . eimg . estr . emap .

Hardcopy Device Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Machine Independent Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

MIF Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

HFA Object Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

External File Format Header Object Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Under UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Example File Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Purpose of the Toolkit

Purpose of the Toolkit

Digital Unix 4.0E

Silicon Graphics R4000 and up Intel Pentium

Microsoft Windows NT 4.0

o eint: Toolkit Initialization

Developers Toolkit Packages

Developers Toolkit Packages

Rules for using the Developers Toolkit

Rules for using the Developers Toolkit Introduction

Error Logging and Reporting

Error Logging and Reporting

The following are incorrect:

Functions governed by the Earg_cmd structure are assumed to be defined as:

Coordinate Systems Raw Coordinate System

Upper Left Map

Map Origin CellSize X

Lower Right Map

Map Coordinate Systems

x X ul c = ---------------X size y + Y ul r = ---------------Y size Units Conversion

Geographic Coordinates (Projections)

Image File Access

Image File Access

ERDAS IMAGINE .img Files

ERDAS IMAGINE .img Files

Ground Control Points

Data File Values

Figure 1: Examples of Objects Stored in a .img File

o file name o layer name

ERDAS IMAGINE .img Files

o number of layers o date the file was last modified

ERDAS IMAGINE .img Files

Raster Layer Information

ERDAS IMAGINE .img Files

Figure 2: Example of a 512 x 512 Layer with a Block Size of 64 x 64 Pixels

ERDAS IMAGINE .img Files

o histogram o contrast table

ERDAS IMAGINE .img Files

o map projection o spheroid o zone number Pyramid Layers

Reading and Writing .img Files

Hardcopy Device Drivers

Hardcopy Device Drivers Introduction

Roles of Map Composer, Mapmaker, and Printmanager

Running Map Composer, Mapmaker, and Printmanager

Hardcopy Device Drivers

Hardcopy Device Drivers

ATLANTIS 5.0 inches 10.0 inches

1.3 in map origin 3.0 inches

Hardcopy Device Drivers

configuration file map file Mapmaker name file

panel file IMAGINE files associated with map file

Figure 3: The ERDAS IMAGINE Map Composer and Mapmaker processes

Hardcopy Device Drivers

plot file Mapmaker Plotfile

ERDAS - Developers Toolkit Examples on-LineManual'

ERDAS - Developers Toolkit Examples on-LineManual'