The MDPP Image file header (.BMD)

Variable Offset Length Type Descriptn Name (bytes) (bytes)(ricL)

T1 0 8 c Header-1 bytes 1-8
T2 8 8 c Header-1 bytes 9-16
T3 16 8 c Header-2 bytes 1-8
T4 24 4 c Header-1 bytes 17-20
IX 28 4 i Record length
ION 32 4 i InCore/OnDisk switch
IY 36 4 i Number of records
IS 40 4 i Data type
IR 44 4 i Disk buffer switch
IG 48 4 i Internal format type (real:0/word:1/byte:2)
KZ 52 4 c Job-step indicator
JBS 56 4 i Main buffer size
T5 60 2 c Header-2 bytes 9-10
ITX 62 4 i X-dimension
ITY 66 4 i Y-dimension
ITZ 70 4 i Z-dimension
XX_SCALE74 4 r X-scale
YY_SCALE78 4 r Y-scale
ZZ_SCALE82 4 r Z-scale
VERSYM 86 4 c Identifier for 'new' header/file format
MM_LOAD 90 4 L Logical- True if ama,ami defined
AMA 94 4 r Maximum of array
AMI 98 4 r Minimum of array
XMEAN 102 4 r Mean of array

IOFX 106 4 i Array offset X

IOFY 110 4 i Array offset Y

IOFZ 114 4 i Array offset Z

MAPTYP 118 4 c Color Map type

CLRMAP 1024 1024 b 4x 256-byte color maps/256 real RMAP

The MDPP header is 2048 bytes long. The image information begins with an offset

of 2048 and is written as a continuous stream of data with the X coord fastest, Y next and followed by Z.

File Header Versions

The MDPP header has been very stable for at least 10 years and probably longer. The earliest (currently readable) version has a header that terminates after `T5'. Then the 3-D info was added. Next a flag, `VERSYM', was added with a value of "1 " (the character "1" and 3 blanks) to indicate that new data was present after its position (the maximum and minimum, etc). The penultimate step was the addition of the `CMAP' option and the use of the high block of 1024 bytes for either a color map, or a `RMAP' (real map) for byte data.

The final step was the modification of `VERSYM' to indicate the internal format of the data within the file. Currently VERSYM can have its old value ("1 "), which means VAX G-Floating reals and normal (for the VAX) byte order for the integers. Additionally it can have the form "2mn ". Here the character "m" can be one of the following: 0-G-Floating reals (VAX), 1-IEEE reals (Ultrix, Alpha) or 2-IEEE reals, byte-swapped (Stardent, SUN, SGI...). The character "n" has the values 0-normal byte order (for the VAX, Ultrix, Alpha) and 1-swapped bytes (SGI...). The VAX would have an internal format flag of "200 ", but is written as "1 " for backwards compatibility. Ultrix and Alpha systems have flags of "210 ". There is one further character available in this flag field. Maybe one day we'll use it...

Contour File Format

The following is the contour file format for MDPP. The contour file format is essentially variable; access to an individual contour is obtained by stepping through the file to the required location.

The file consists of three levels of contol: 1) the FILE control block, 2) the LEVEL control block, and the 3) CONTOUR control block. Each control block defines elements of the contour which may be required. All control blocks are required, even if a single contour is to be stored. Note that all numbers are REAL*4 even though many values are integers.

The format is as follows:-

FILE Control block: length=14

Variable Offset Function

NLEV 0 Number of levels in file
TCONTR 1 Total number of contours in file
TPNT 2 Total number of contour points in file
TLENG 3 Length of file
XDIM 4 X-dimension of array
YDIM 5 Y-dimension of array
XSC 6 X aspect ratio
YSC 7 Y aspect ratio
FLAG 8 Flag (undefined)
TITLE 9 Title, 5 reals

LEVEL Control block: length=12

Variable Offset Function

LEV 0 Level ID (e.g. level number)
LCONTR 1 Number of contours on this level

LLENG 2 Length of this level
Z 3 Altitude of this level
LXDIM 4 X-dimension of array
LYDIM 5 Y-dimension of array
LXSC 6 X aspect ratio
LYSC 7 Y aspect ratio
FLAG1 8 Flag (undefined)
FLAG2 9 Flag (undefined)
FLAG3 10 Flag (undefined)
FLAG4 11 Flag (undefined)

CONTOUR Control block: length=10

Variable 	Offset	 Function
KNT		0	Current Contour ID (e.g. contour number)

CLENG		1	Length of segment

NPNT		2	Number of points on contour

FLAG		3	Contour type (closed 0; open 2)

LENGTH		4	Perimeter length of contour

AREA		5	Area of contour

CID		6	Unique contour ID

FLAG1		7	Flag (undefined)

FLAG2		8	Flag (undefined)

FLAG3		9	Flag (undefined)

Following each of the CONTOUR control blocks there is the contour data, consisting of NPNT coordinate-pairs defining the contour.

Fixing the FFT Program Parameters

Actually, I am not 100% sure. The programs were "delivered" set to run up to radix-19. I altered them, but did not keep track of what I did, and I have just tried to alter them again.

The 'main' program is CMPLFT. Inside this there is a paramter called PMAX, which is the maximum factor allowed, TWOGRP which is the highest power of two it can deal with as a single factor. Inside the subroutine SRFP there is a paramter called NEST (=14). This is the hard-wired maximum depth of the factors. You can not have a dimension that has more than 14 factors. This is probably not something you need to change, and it would be difficult to do this without a significant chance that you would screw up.

The place where a change is needed is inside RPCFTK, the prime-factor FT module. There is a parameter called HIPRIME (=53). Change this parameter to match the modified value of PMAX in CMPLFT and I think you are set.

Finally, if you are using MDPP (what else) you need to change the FCTSRC entry in GENORG. Alter this to reflect the increased prime factor, or FCTSRC will block attempts to use the increased prime-factor range that you just engineered.

This should be tested to ensure that these hard-wired buffer arrays do not go out of bounds. Try a few forward and reverse FFTs to make sure that you are always within the rounding errors.

MDPP Internal Data Formats The following are the internal formats for MDPP data types.

IMAGE (Type = 0)

The image data can be in any of REAL INTEGER*2 or BYTE formats. Data is stored in linear array with X as the fastest increasing dimension and Z as the slowest.

etc.....

CONTOUR (Type = 8)

Internal data is always REAL. Contour data is divided into LEVELS and CONTOURS, with a FILE BLOCK describing general information for the file. The general file structure is:-

The formats of the different blocks is:-

FILE BLOCK: Length 14 words. 1. Total No. of Levels 2. Total no. of contours 3. Total no of contoured points 4. Length of file 5-14. Reserved.

LEVEL BLOCK: Total length 12 words. 1. Level number 2. No of contours on this level. 3. Length of this level (including all the contours, obviously!) 4. Z altitude of this level. 5-12. Reserved.

CONTOUR BLOCK: Total length 10 words. 1. Contour number 2. Length of contour (L) 3. No. of points in the contour 4. Contour type. 5. Contour length 6. Contour area 7. Contour Specific identifier 8. Contour Class identifier 9-10. Reserved. Contour data for a given contour is: 11-L. Pairs of contour points.

Each file has one FILE BLOCK and at least one level. Each level has one LEVEL

BLOCK and an arbitary number of CONTOURS (including zero): each set of contour points is preceded by a CONTOUR BLOCK to identify it. (An empty level has no contours, and therefore no contour blocks).

The STORE paramters are 80,N where N is calculated as: ((Tot_leng-1)/80+1)

Making MENU Help (SMG Menus)

The menu system now permits HELP to be requested by the user. This help is requested in two ways: (1) By typing "H" in answer to the prompt the user gets help for the entire menu currently displayed, and (2) By entering either "?" or hitting the <HELP> key, help for the particular option selected by the highlight bar on the menu is provided.

The trick is to make the HELP files and identify them to MDPP. The help file system uses the standard VMS help library, and the system services to read them. The file to be read is identified by the logical definition MDP_MENU_HELP: e.g.

"$DEF MDP_MENU_HELP DISK:[USER]MY_MENU.HLB"

The help library, "MY_MENU.HLB", is created by the user, and the definition of the logical is made in the LOGIN.COM file, or wherever else the other logicals are defined.

Creating the help library file is simple. The user uses the editor to create a file called MY_MENU.HLP, and then creates the library from it with the VMS command:

"$LIB/HELP/CREATE MY_MENU MY_MENU"

which creates MY_MENU.HLB from the editor-generated file MY_MENU.HLP.

The structure of the HELP file is key, of course. General background reading should be the VMS manuals on HELP librarys and their creation and maintenance.

The help library is accessed via two keys, the menu title and the menu entry number. The menu title is defined by the line in the menu definition file begining with the MENU: command. The entry number is the number found in the first column of the body of the menu.

Only the first word in the MENU definition is used, so this word must be unique for the entire menu: "The Main Menu" is a poor choice of menu defintion, particularly if a sub-menu is defined as "The Sub-Menu" (in this case there would be two key entries called "The" and the library would become confused, the program would crash, the computer would blow up, a truck would run over your dog and your aunt would leave all of her money to the milk-man: don't do it.) Pick nice action-packed words like "First", "Digitize", etc.

The .HLP file is written with a "1 " preceding the key words for the menu or sub_menu, and "2 " in front of the number defining the entry. The following is a sample file, as it would be created by the editor.

1 MAIN

This is the main menu for this MDP operation package. It offers four sub-menus as selection options providing DIGITIZATION, DISPLAY, AVERAGING and OUTPUT options. Generally, you would begin with image digitization. The menu system will guide you though the operations by positioning the cursor on the next most reasonable choice of operation.

2 1

This is the digitization menu. Use it to digitize images using the Eikonix digital camera and to prepare the data for saving on disk.

2 2

This is the Display menu. Use it to display your images in different ways for image recording.

.... (more)

1 DIGITIZATION

This is the digitization menu. Use it to digitize images using the Eikonix digital camera and to prepare the data for saving on disk.

2 1

This is the basic image digitization menu, including camera calibration. You must calibraet the Eikonix at the begining of every day, and preferably before every image digitization session.

2 2

Use this option once the camera is calibrated, and you are just digitizing images as part of the same series. .... (more)

Once the menu help file is complete, you can 'compile' it into the library, set up the defintions, and with luck a help request within the program will be answered!

Note that you may have several help libraries, one for each of the menu you have. Another method, however, is to build each individual menu package out of modular blocks of pre-tested, distinct sub-menus (i.e. if you need a DIGITIZATION sub-menu, always use the same one.). If all the sub-menus are distinct, then all the menu help can be loaded into a single .HLB library, and the system routines will extract the bits they need. This simplifies maintenance for user support (e.g. when running a course, etc.)

Adding a Command to the MDPP

The addition of new command names is a multi-step procedure. Follow the steps as outlined below:-

Write the code for the command. Hints as to how the command will interface to the system in general are provided in the file [.LOCAL]DISPLAY. FOR and you will need to understand them before continuing. Your new command will need to alter the values in the common block 'DISCDA' so get to know it. Please remember the most basic rules of computing (Examples: "If it is not worth doing, it is not worth doing on a computer either", "Bullshit is still bullshit even after it has been translated into FORTRAN", etc.). I recommend putting the new code in a new directory (pick a good name) separate from the directories provided by MDPP; this includes the directory called [.SOURCE].
Compile the code and load it into the MDPP library with the library utility with the '/NOREPL' switch on so that you do not replace one of the standard MDPP routines.
Select a new command name of two letters.
Edit the file [MDPP.GENERAL]LIST.RSP and add your command to the END of the list (that's right, at the VERY bottom). Use EXACTLY the same format. Check, incidentally, that there is not a command name the same as yours in there already; if there is, then pick another name!
Run the program 'HASHMAKE'.
The output of HASHMAKE is a file called 'HASH.FOR' which is a FORTRAN subroutine which contains your new command name (look for it!). Compile this file and load the object module into the library MDPP in [.LIB]. Once this has been done your command is 'installed' as far as MDPP is concerned, and will be recognised as a valid command.
Now edit MAIN.FOR and search for them string 'NEW_CMD'. Add the new statement number to the computed GOTO command, as instructed in the body of the program, and then add the new subroutine call in the appropriate place. This is also indicated in the comments in the program.
Now compile MAIN.FOR and load the object module into the library MDPP, just as you did for all the other object modules.
Execute the command procedure 'MDPPBLD'. This will build you your new MDPP, complete with your new command in place.
Debug the command: you are on your own!
If you get it working, send a copy of the code on a tape to me in NY and I will put it into MDPP permanantly for you.

Open Files in MDPP

The following is a list of files used by MDPP in operation. It should be complete, let me know if it is not!

UNIT NAME FUNCTION

1 * I/O for the saved images 2 FOR002.DAT Subsidary disc buffer 3 FILE3.DAT Unit 3 disc buffer (images)

4 FILE4.DAT Unit 4 disc buffer (stacks, FFT, etc)

5 * Input of commands to MDPP
6 * Output of prompts, data, info from MDPP
7 TT: Fixed to terminal for output.
8 TT: Fixed to terminal for input.
9-17 * LOOP processor (INPT n)
18 INPUT.LOG Input logging file

19 OUTPUT.LOG Output logging file

33 * Output log file from MACRO processor

(appended to 6)

Note that most files remain closed, in particular files 9-17 are nearly never used. Files 7 & 8 are used for executive control of MDP and are nearly never accessed, however, they must be open and should not be used for command control of MDP. In operation the maximum number of files actually open at once is 7 (i.e. 1,3,4,5,6,7,8).

Hope this is helpful!

Tips for Ultrix Users

These are anecdoctal comments about the Ultrix version of MDPP which may help you get started.

Printing

Many of the files to be printed are spooled automatically as the command exits. For this to happen, FORTRAN looks for a printer called 'lp'. If it can not find one it prints the message 'lpr: can not find printer lp', or some such stuff. To fix this, go to the /etc/printcap file and make sure that there is a printer in there called 'lp', as in this example.

# @(#)printcap 3.1 (ULTRIX) 4/20/90 lp|l0|local line printer:\

:lp=:\

:rm=mcclb0:\

:rp=sys$print:\

:sd=/usr/spool/l0:

This printer is attached to the VAX and is accessed via lpr.