Menu
▾
▴
MDPP Installation & Startup Guide
Data Storage
Home
The Biozentrum Micrograph Data Processing Program
Introductory Information
Description:
MDPP is a fully-featured general purpose image processing package originally written to support research in structural biology requiring electron microscopy and image processing. It has focused on the analysis of images using Fourier techniques, particularly periodic images, but has extensive tools for other processing options (e.g. DNA sequencing, point-counting, image quantitation and display). Three-dimensional reconstruction methods are supported, including iterative deconvolution schemes for light micrographs. Color images are supported with both color pallet and RGB options.
The package is easy to install and use, even by the novice user. Extensive documentation is included and is accessible from within the program as on-line HELP and also as HTML documentation. Care has been taken to support interfaces to other image processing packages, e.g. Macintosh applications via the TIFF, PNG and JPEG image formats, and other EM-targeted image processing packages such as Spider, Semper, PIC and the MRC package. The basic package is command-line driven, but the user can choose to write sophisticated command scripts and use a menu-driven full-screen or MOTIF interface to call them. Foreground and background operation is supported.
Version: The current version of MDPP is v17.272. Version numbers indicate the approximate date that the last significant changes or bug fixes were made to the program.
Operating Systems: MDPP runs on UNIX-type systems such as macOS and Linux in a 64-bit environment. OpenVMS is no longer supported.
Required Installed Packages: MDPP is linked against four packages. 1) X11, 2) libpng, 3) libjpeg and 4) libfftw3f. On a Mac the png, jpeg and fftw packages can be installed and kept up to date using "fink". If you do not have fink you can download it from the fink project download page. Installation is straightforward, but please read all instructions. Generally, MDPP is linked against the most recent versions of these packages and this may require you have installed these versions too. On Linux the chances are that the required packages are already available, but the same caviate holds. Speak to the sysadmin who should have no problems providing the packages and their updates.
There is an issue with "libpng". If it is updated you may need to re-compile "png_io.c", add the object modue to "mdppo.a" and re-link. This is becuase "libpng" uses the version header to determin whether the library is usable. Updates such as from 1.6.12 to 1.6.13 should not require a relink; from 1.5.4 to 1.6.0 will.
Requirements: MDPP is a "Terminal Application"; it runs from the command-line in a terminal window. Hosts: macOS and Linux. (Obsolete: HP VAX, AXP and IA64 with OpenVMS). Displays: Any X-Windows/R6 Server (Motif for full functionality under UNIX). On a Mac, start the X11 application and run MDPP from inside an xterm window for best results. Compilers: FORTRAN V7.0 or later is required for OpenVMS systems; Absoft v9.2 or later or Intel 10.1 or later for Mac/Linux.
Distribution: MDPP has been made into a SourceForge project.
Availability: MDPP is available from the SourceForge project web site.
Getting Started: The MDPP code and pre-linked executables for macOS and Linux are included in the "git" archive on SourceForge. Consult the installation information on the "Installation" tab on this page.
Support: The development of this software has been supported in part by the NSF through grant 9410750 to P.R. Smith and through the generous provision of hardware resources by Hewlett-Packard Corp. and Intel Corp, for which we are very grateful.
MDPP Installation & Startup Guide
Basic Installation Information
The current distribution method for MDPP is through SourceForge. Support is provided for macOS and Linux on 64-bit Intel processors. The distribution contains the executable tasks, and the sources (FORTRAN & C) and the command files to permit the end user to modify MDPP to incorporate alternative output display devices and add new commands to the basic set are provided.
All older distributions are now obsolete.
Requirements: macOS
FORTRAN is a licensed product for most UNIX platforms. For the Mac under macOS we have used the Intel compiler (use v10.1 or newer) which you will need to buy should you want to modify the code: MDPP will not compile with g77/g90 and I doubt that there is any rationale to try to make it do so.
macOS has a full BSD UNIX core. Since the Mac does not use X11 as its display you
need to start the X server before you try to run MDPP and display an image.
Apple no longer distributes X11 as a Utility, so you first need to download and install XQuartz which provides the latest X11 software for the Mac environment.
Click on the XQuartz icon to start X11; when the X server starts it opens its default "xterm"
window. While it is not necessary, it makes things easier to run MDPP from the xterm
rather than another terminal window. I have modified the definition for the xterm in
the X11 "Customize Application Menu" to be
xterm -rightbar -s -sb -sl 5000 -kt vt220
This gives you a more useful window that can be scrolled, which the default
window can't. But with these modest actions MDPP behaves identically to other UNIXes and
delivers excellent performance. Note that the MDPP image distributed on the web is
built for the latest version of macOS on the Intel platform. The code can be recompiled
using the Absoft compilers for the G4 and G5 boxes, and should run well.
Requirements: Linux
Linux installation is essentially identical to the macOS installation. The version included in the distribution was compiled with the Intel compiler and may need access to the FORTRAN shared libraries provided with that compiler to run (which means you'd have to buy a copy). The Linux version should run identically to the macOS version. Let me know if you try to use it.
Requirements: Other UNIX
I don't have access to other UNIX boxes, so I can't comment directly on the difficulty of getting MDPP running. Tru64 UNIX is not a problem since the sources already contain modifications to support it, but that OS is now obsolete. I'd be surprised if a SUN posed a problem, since the starting point for the OSX version was an obsolete SUN port of MDPP and Macs have the same floating point and "endian" formats.
Requirements: Running MDPP on a remote machine
You can, of course, telnet or ssh into another machine (e.g. mdpp-server.uni.edu) and run MDPP using the machine you are logged in to (e.g a laptop) as an X server to view the images. If you do this you need to do two things:
(1) You must authorize the remote machine to put X-windows on the local machine (your
laptop) using the xhost command on your laptop as follows:
my-laptop$ xhost mdpp-server.uni.edu
(2) Before you start MDPP on the remote machine you must direct the X11 windows
on that machine to your laptop:
mdpp-server$ setenv DISPLAY my-laptop.uni.edu:0.0
Now you can start MDPP and when you display an image it will appear on your laptop.
The easiest way to run MDPP is from an "xterm" window. If you are running remotely,
ssh to the remote machine from an xterm, which guarantees that X11 is awake and
functioning when you need it to field incoming images.
ssh -X user_name@remote.machine.edu
The "-X" should allow images to be sent to your local machine; user_name is your account name on the remote machine. You won't need to set DISPLAY in this case.
Your local machine has to be configured to act as an X server. Be sure that the file /etc/sshd_config contains the line:
X11Forwarding yes
The first task: Downloading the distribution
Using SourceForge:
The recommended method is to use "git" to create a clone of the MDPP distribution.
Continuing the Installation
The next task is gaining access to the on-line documentation. Start a WWW browser
(e.g. Safari, Netscape, IE ..) and open the
Installation page. If you are opening it
locally, use the file
MPP:[HTMLDOC]INSTALLATION.HTML for VMS or
$MPP/htmldoc/installation.html for UNIX.
Note that this requires MPP to
be defined to point to the location of the root of the MDPP files.
Code Base
At this point MDPP has a single integrated code base that contains merged VMS and UNIX code. If the VMS or UNIX command files are used to re-compile the code a working version of MDPP should be built. This is achieved by compile-time (#ifdef) statements inside each routine that needs different code for VMS vs. UNIX. Obviously, if you want to modify the code and have it re-compile on all systems you will need to insert appropriate conditional compilation directives and not break the ones that are there.
Sources
The distribution contains MDPP sources that can be used to re-build MDPP or as a source of sample code for extending other systems. The material downloaded with git should provide everything.
The "sources" directory contains the code for most of the components of the MDPP.
The sub-directories are as follows: -
uvms-new - contains most of the analytic software. The code here should be platform independent.
usou copy - contains some analytic software but is mainly focused on I/O and control
that differs for each platform. Most of this code contains "#ifdef" blocks
that direct different compilation on different hosts (VMS and UNIX, mostly).
fft (& fftw3) - the code for the FFT implemetation.
display - contains code for interaction with screen images, cursor control and
line drawing. These routines interface with the screen via a driver, different for each video output device. For the Mac and Linux right now this is the "UNIX Driver (for X11)" found in "/drivers/unix". You will see other drivers there as well, notably the Lexidata driver where most of the development was done (and why many routines are called "lex_xxx"). The next step was to create an "OpenGL" driver, but that didn't happen yet.
jp - contains the package of fortran programs for performing correspondence
analysis.
tsb - contains the original I/O routines for images created using s/w from the Baker Lab. Versions that are used are in the "uvms-new" directory; this directory is obsolete.
jpeg - contains an older version of the JPEG library (do not use).
plot10 - contains software for the "PLOT10" plotting package.
source - contains older VMS version of analytic software.
utilities - software for various utilities; not that helpful in the 21st centuary.
uwin - contains VMS terminal screen management software. Not used any more.
Step-by-Step Installation of the Software
Installation and updates are simple. If you are using the clone from SourceForge then the command
git pull origin
will pull down the newest version of the distribution and update the local copy. Note that if you have modified any of the files you may have to restore then to the original versions before the update will work. (see git checkout -- <file>). If you plan on using the unmodified MDP distribution then the files you change should be outside the MDPP directory tree.
Customizing Features.
Including your own commands.
You may also need to customize MDPP for your own site to include special routines you need for image output, and also to add new commands.
In the UNIX version, to install your own routines simply edit and load the new or modified routines into the library (mdpp.ls or mdppo.ls). Remember to KEEP a copy of the unmodified libraries safely somewhere before messing with them. Re-link using the command provided.
If you need to add a new command you will need to follow a more complicated procedure. This is outlined in the file "[MDPP.DOC]NEW_CMD_xxxx.DOC" which you should read before attempting to add your own command. Note that this procedure is automated to a degree for VMS, but not for UNIX as yet.
Customizing for Individual Users: The file MDPP.DFL
Basic customization of MDPP for each user at your site can be achieved by means of the file MDPP.DFL, which each user places in his/her directory. This file allows you optionally to define how you wish to obtain display output, and the characteristics of the display device.
The user give MDPP access to this file by defining the logical MDP_USRDFL to point to the file which provides the appropriate default definitions. If he does not have special requirements then he can omit this definition, and MDP will use the MDP_SYSDFL definition to get system-wide definitions.
The MDPP mode switch allows the user to switch between keyboard (0), display screen oriented (1) and terminal screen MENU driven (2) input modes.
In keyboard mode all commands come from the keyboard, display screen options are available, but are not selected automatically, the user must enter the appropriate command to activate screen input.
In display screen oriented mode the input is from the keyboard but the screen options of each command are selected automatically, if there are any. This option has not been fully implemented, and should not be used.
In menu driven mode MDPP is driven entirely from user-defined menu screens. These menus are user programmable, as are their functions, via the PROCEDURE driver. If you wish to use MODE=2 (MENU) you should be aware that you have to write your own menu file and the procedures called by it. If the user wants to use MODE=2, then he must also define the logical MDP_MENU, which must point to his menu file. There is no system-wide default for MDP_MENU, since menus are expected to be user-specific. The user may also wish to write his own MENU help files. The logical MDP_MENU_HELP, for which there is no system-wide default, needs to be defined in order that such help be available. The user's individual definitions should be placed in his LOGIN.COM file, after the call to MDPP.COM.
X-Server Font Problems: The MDPP attempts to get fonts for the display of cursor locations, etc., using a wild-card font request. Some servers (the box driving the screen that you look at) respond with a choice of font that is unappealing or just plain wrong (like: shows odd symbols rather than nice characters). If this happens to you, there are two ways to fix it.
System wide: If you can
identify a particular font that looks good on all the servers you need to run
MDPP on, then you can define it in MDPP.COM with a statement
like:
$ DEF MDP_DECW_FONT -
$_ "-MISC-FIXED-MEDIUM-R-NORMAL--13-120-75-75-C-80-ISO8859-1"
This line is already in the MDPP.COM file. Just un-comment it and edit it, if ncessary, to point to the font you require.
For each user individually: If you cannot get consensus on a good font that everyone can use, then each user can define the MDP_DECW_FONT logical in their own LOGIN.COM file, AFTER MDPP.COM has been executed.
The Utilities: MDPP.COM (VMS) contains a call to the file UTILITIES.COM that sets up several useful utility programs. Check this file to see if these overlap with routines you are already using. If they do, you may wish to edit this file and update the information in it. The utilities are not a part of MDPP and are not supported as a part of it. However, we do try to ensure that they are kept current and will update any that we can find in a straight-forward manner. Let us know if any utilities are busted and we'll try to help.
HELP: The manual for the system is the same for both the VMS and UNIX versions of the system. There is now an extensive set of 'HELP' files located in the directory [MDPP.DOC] which is pointed to by the logical name MDPDOC:. These files can be printed out and constitute the manual for the system. MDPP accesses the HELP files using its own internal reading system to provide on-line help. Obtain on-line help by typing "HELP <command_name>" (e.g. "HELP VF") from within MDPP in command mode, or a "?" at any prompt for input. Note that a system level HELP entry for VMS can be obtained by loading the file MDPP.HLP into the system help library file using the command "LIBR/HELP SYS$HELP:HELPLIB MDPP". We have not tried to make a "man" file for UNIX.
Web-based HELP files have not been maintained; sorry about that. Avoid them.
Note also that the plotting program subroutine library its own help library which can be accessed using the appropriate system HELP command.
MDPP Directory Structure
The following is a sketch of the (minimal) directory structure of the VMS/UNIX version of MDPP.
MDPP | +--- GENERAL The MacOSX programs/executables. +--- GENERAL-Linux The Linux programs/executables. | +--- LIB The VMS/UNIX Libraries and some .COM files | |---- RGB The color tables | |---- MENU Some examples of user menus | +---- PROC Some examples of procedures | +--- DRIVERS The Driver libraries | +---- UNIX The X11 driver (VMS and UNIX) | +--- DOC The text docs +--- HTMLDOC The docs in HTML | +--- EXAMPLES Some examples. +---- HELICES | +------- STRAIGHTEN +---- MOVIE +---- PLANE_LAYER_FILTERING +---- PLANE_LAYER_RECONSTRUCTION
Differences between MacOSX and Linux
There are no differences of significance between OSX and Linux versions.
Getting Started with MDPP
Once you have installed the MDPP you need to figure out how to use it. The MDPP can be started on the VAX by typing 'MDPT', if the approproiate task has been installed. The program will begin by printing a series of messages to you which you answer as follows:
.IS OUTPUT FOR A CRT (1=NO):> x
.ENTER NAME OF OUTPUT FILE (A20):> out/O/I/S
.ENTER NAME OF INPUT FILE (A20):> inp
If the output device is not a CRT then enter '1'; otherwise enter a <cr>. The output file name is entered in response to the next prompt; the default is 'SYS$OUTPUT:'. Output processing is controlled by the switches '/O', '/I' and '/S'. Using the '/I[NPUT_LOG]' switch causes an input log to be generated containing all commands and data entered to MDP. This logfile, called 'INPUT.LOG', should be able to be re-submitted to MDP to re-create the current session. Note that it is only useful to use this switch if you are logging a terminal session. The '/O[UTPUT_LOG]' switch controls whether an output log, called 'OUTPUT.LOG', is to be generated. There is no point in requesting an output log if a general output file is being created. If a general output file is request then the '/S[POOL]' switch controls the spooling of this output file. If the file is to be spooled then append '/S' to the file name (e.g. 'MYFILE.OUT/S'). If just '/S' is entered then a default filename is assigned (MDPPSPL.DMP) and the output is spooled at the end of the run and the file deleted. The input file is to be entered; the default is 'SYS$INPUT:'. If an input file name is entered input will come from that file. The default extension is '.INP'. If an input file is entered then MDPP will ask if MACRO processing is to be done (see the write-up for the MACRO and LOOP processors). The prompt is:-
.ENTER '1' FOR MACRO PROCESSING: m
Entering '1' will cause the MACRO processor to be invoked and an ex panded input file will be generated.
.FILES OPENED SUCCESSFULLY
indicates that processing, if requested, is complete and all further input will be from the designated input file. For the beginer, this will be the terminal.
This tedious input can be simplified considerably and the input all placed on a single line in a comma-separated list, as follows:-
$ MDPT x,out,inp,sw (for VMS)
mcgcr0-14> mdp x,out,inp,sw (for UNIX)
As before, 'x' is either "1" for the 'dumb terminal' mode or blank for the SMG screen managed output., and 'sw' is either "1" to activate the MACRO processor (only if you have an input file please) or blank to skip MACRO processing.
The program will now clear the screen and be ready to start work. The actual response will depend on the manner that it has been started.
The ":>" or "Command:>" prompts indicate that the program is ready to receive input from the terminal and the user, by now in a frenzy of excitment, will comply.
Use Of The MDPP
Prompts (e.g. ':>') indicate that the system expects a command. These commands consist of a two letter command name usually reminiscent of the procedure one wants to perform (e.g. 'rd' means read, 'sv' means save, etc.). The table in the MENU shows which commands are available. The typing of a command not part of the system leads to an error message; three incorrect entries one after the other causes the program to terminate.
Commands are read in the FORTRAN format (A2,2I2). Spaces are therefore significant. The 2I2 allows two numbers to be read in which provide extra information for the commands: the user is advised to respect the formating as failure to do so will lead to disaster.
Description of the Interactive Commands
The descriptions of the commands are organized in help files and in the on-line documentation. The purpose of the command is given and the general description of it is included. Text in small letters is typed on the console; capital letters indicate the computer response. Descriptions and explanations are interposed when necessary. Examples are sometimes included as is a "Remarks" section containing further information about the command of which the user should be aware.
In some of the simpler subroutines errors are not explicitly indicated by an error message but the expected output is suppressed (very rare in this version of MDPP). All commands should terminate with a confirmatory message: if this message is missing and the console simply types the prompt asking for the next command, something has probably gone wrong. It's up to the bright intelligent user to spot his silly mistake.
Basic Program Structure & Philosophy
The fundamental problem in system design from a practical programming point of view is data organization and storage. All these programs are organized around the choices which were made, for better or worse, as to the 'best' way of doing this job, way back in 1973 when work was begun and then again in the 1980's when the program was ported to PDPs and the VAX.
Data involved in processing steps is read from a permanent disk file into a core buffer; the buffer is extended as needed but if it can't be allocated the a disk buffer is used. Once the data are in the program buffer (the so-called current file) the user can perform operations on these data using the MDPP's commands. At the end of each step (command) in the analysis the data is left stored in the buffer. When the user is finished, the modified data can be written back out to disk. Output is very flexible: the user can write out data after each and every step, after a small series of steps, at the end of the entire chain of processing operations, or not at all. (Note that this is different from some other packages which return the data to disk after each step. Some other packages retain the original data used at each step: MDPP does not, unless the data has been saved by the user explicitly). In the MDPP data read from a disk file is transformed by each command and then returned to the buffer, ready for the next step.
(Generally speaking it is not necessary for the user to pay particular attention to the particular type of buffer being used in a calculation. There are exceptions however when the arrays being used are 'stacks' of pictures or data, and when data arrays are in core. This is sometimes important because some of the routines will work only on data held in core: usually however, these are output processes or those designed for use on processed data.)
To reiterate, analysis of the data is performed by a series of subroutines which are called in the order required by the user, the main program acting as a 'shunting yard' passing the data between each of the subroutines which actually do the work. The order in which the subroutines are called is controlled by the user who generates a so-called 'command list'. The command list consists of a series of two-letter commands, which specify the operation (subroutine) the user wishes to utilize, followed by a series of data lines, should these be needed.
The computational work done by each subroutine is called a job-step. Each job-step is, up to a point, independent of those steps preceding it and those which follow. The programs have been written to permit a reasonable amount of flexibility in organizing the analysis but the user should bear in mind that the order is not really variable if sensible results are to be obtained.
Memory Management
Memory is allocated on the fly as it is needed for the main arrays and buffer arrays. MDPP starts with a relatively small core buffer and this is expanded as required when arrays are read and manipulated. Only when expanding virtual memory for the application fails is the disk buffer used. The problem is that disk array management has not been written for some of the newer routines, so if a virtual memory allocation request fails some commands will not work.
Data Storage
As noted, data is read from disk with the 'RD' command and saved to disk with 'SV'. MDPP's default file format is the so-called BMD (Binary Micrograph Data) format which is generally optimized for read/write speed and to carry the metadata needed properly to identify it. This format is not used by other packages so MDPP allows files to be read and written in MRC/CCP4, TIFF, PNG and JPEG formats. e.g. "RD actin-map.mrc" will cause the file "actin-map" to be read assuming that it is indeed in MRC format. If the file name extension is omitted BMD is assumed and if such a file does not exist a search is done for files with extensions: .MAP, .MRC, .TIF, .PNG and .JPG. Files from other packages (e.g. Spider, PIC) can be read and written using the "XX" (external exchange) command.
Image Visualization
NOTE: Image output (via 'DV') is directed to the X-Windows display device (usually your desktop main screen). Other output methods, such as 'DP', are now esentially obsolete and may no longer work without customization and programming I don't plan to do...
That said, however, image output can be obtained using the commands 'DP' (DisPlay) and 'DV' (Display_Visual). In the version of MDPP distributed here DP sends output to a FACIT 4542 or 4544 color printer. Note that there are routines to generate output for a SIXEL (DEC) printer or terminal. (Current options "DP 3" to the terminal VT330/340, "DP 4" to the SIXEL printer e.g. (LA100).
Output from 'DV' is directed to the terminal, or to a display device. The command causes a file to be output to the device designated by the line 'Display type' in the file 'MDPP.DFL' (see below for a description of this file). At NYU we set this to '1' which designates a video display device. If you have a video display you must have (or write) a driver for it which interfaces MDPP with the device. (See above.)
'DV 3' puts up a very crude picture on the screen of any terminal. 'DV' also uses ReGIS to plot images on the screen of a VT125 or VT240 series terminal; 'DV 1' is quite quick; 'DV 2' is slow, but the quality is surprisingly good (these two programs were provided by Dr. Michael Rademacher in Albany, NY).
The 'DG' command (display graphically) is used to draw line graphs of one-dimensional data, such as lines in an image.
Interacting with the Display
Note that your interaction with the MDPP display is different from the interaction with a Macintosh, for example, since the images are not part of an integrated UI. To use the tools that work with the displayed image you need to start a program which uses displayed image data, like the 'VD' command (e.g. 'VD 8' which can be used to inspect both real & Fourier images). Once the program has been started, the cursor changes to the MDP cross-hair cursor within the image window, and the mouse keys can be used to control the program. If a program is not running, the workstation cursor is the same both inside and outside the MDP image window and mouse keys have no effect, as far as MDP is concerned. For user convenience (and contrary to the Motif style-guide!) the cursor is moved into the image window center when a program is started.
Many programs (but not all) which require the cursor position to be marked inside the image window allow you to double-click inside the window (or hit <Cntl-E>, VAX only). This causes a sub-window to be created with an enlargement of the area within it. This is to allow the user to position the cursor to within a sample point in the image: this is generally impossible to do on the main display since the MDP images of large areas are displayed at a resolution too low to permit cursor positioning at the single pixel level. This sub-window automatically extinguishes itself if a mouse key is clicked, or the cursor is moved outside the displayed area. A subwindow is not displayed if the magnification of the original image is already sufficient to allow single-pixel positioning.
The Mouse Button Order
A significant issue with the usability of the package is the disposition of mouse keys. On the Lexidata (from our standpoint, the 'father' of all displays, existing well before X-Windows or Aqua) the key order was right-to-left, with the RH key being the 'busy' key that got most of the work. On DECwindows the opposite is true: the LH key is the key you use most for your work on the workstation. When MDPP was ported to DECwindows we switched the key order to make the LH key the 'busy' key, but for all sorts of bad reasons the messages on the screen which told the user which button to use were not changed. In the V93.200 version of MDPP the 'RH-busy' order has been restored so that the mouse-key order corresponds to the messages. Since most long(er) time users of MDPP are now accustomed to the LH order there is a new logical called 'MDP_REVERSE_MOUSE_BUTTONS', which if defined to 'TRUE' reverses the button order and gives them back the LH order they have been using for the last few years. Note that the key to be double-clicked to POP windows remains the LH button which is not a good choice, but thats the way it is for now, at least.
Plotting
Plotting routines have been provided and are used by MDPP for displaying images via contour plots, etc. The best method available at present is to use the GKS option in the 'PL' command. This permits both full screen and hard copy (on a LA100 type printer) plotter output. Read the documentation. Other options include the generation of contour files suitable for re-input, or transport to MOVIE-BYU. The generation of contours on an image on the current display device is a powerful method for displaying graphical output such as contours. Alternatively, plotting can be done using a ReGIS plotting device designated 'PL0:', which the user must assign. The plotting device is initially assigned to 'NL:' (VMS) or '/dev/null' (UNIX), the null device, which is satisfactory for GKS use, but which you will need to re-assign if you need pure ReGIS plotting. If you have no plotting device at all (i.e. no VT240, VT125, TEK4010....) then select ReGIS plotting in programs which require plotting output; the plotter output will be dumped in the null device and cause no problem. Additionally, plotter output can be obtained for the FACIT printer by re-linking MDP with the appropriate library (available for V86.100 or later). This is a fairly clumsy method to obtain hard copy graphics, but due to the relative scarcity of these printers, an alternative seems inappropriate at this time. If you have a ReGIS hard copy device, then that can be used without modification, of course. Using dump_graphics from the VT125 screen, is another option.
Communications, 1990s style
The communications utility KERMIT has been provided but is entirely unnecessary in 2016 and beyond. KERMIT is a terminal emulation package which permits 'error-free' data transmission. In addition we have provided three programs which act as encoders/decoders to permit binary (e.g. .EXE, .OLB, etc.) files to be transfered by KERMIT and/or the MAIL programs. These are CODE, SEND_FILE and MFTU. CODE is inefficient, but is available at many sites which support PMDF, SEND_FILE is good for text file transmission, and MFTU is to be preferred for binary (although all file types can be used as input to all the programs). Documentation has been provided in the [DOC] directory. You may need these programs to update MDPP remotely from NYU. Note that file compression/ decompression can be performed using LZCMP and LZDCM programs, considerable reductions in size can be achieved in some cases, which is useful for data transmission and for long-term storage of images on line: these two programs are compatible with UNIX also. TAR2VMS is a program to read TAR tapes from UNIX.
Defaults (or: What am I going to do NOW!!?)
The MDPP is a complex program. The documentation is idiosyncratic and there are going to be many times when figuring out what to do will be well-nigh impossible. As an aid to the confused (and to make life easier for the cognoscenti) MDPP tries to have acceptable defaults available for all the inputs requested by the various commands. The correct thing to do when faced with a confusing situation, is to just hit <cr> and see what MDPP thinks the right answers are. Now obviously this is not going to work all the time. So if you are confused and you have not saved the last step, back off from the command by hitting <cntl-Z> (VMS) or <cntl-D> (UNIX) to exit to the command prompt, save the file, and then restart the command. Now you can play: if you get the input arguments wrong just re-read the file and try again. If the file is saved from the previous step, there is really nothing that can get seriously screwed up..
Getting HELP
You can get help at any time input is requested by typing '?' and then <cr>. Help for a given command is obtained by typing 'HELP XX' at the command prompt, where 'XX' is the command of interest.
Using the Examples
The outline here for the usage of the MDPP is undoubtedly less adequate for a user that needs to get started than it might be. Unfortunately, there is no good way to communicate the 20-odd years that have gone into program development and the thinking (and sometimes the lack of it) that has influenced the growth of this package.
For the most part, MDPP deals best with the problems it was designed to tackle, EM images and structural biology. Some of the tools here are unique and have never been successfully reproduced on other integrated packages (the helix stuff is an example, shadowed particle processing is another). We are very happy with the 2-D filtering tools as well and the 3-D reconstructions from tilted views of 2-D crystals.
However, if you are looking for a package to do general image processing of color images, or morphing, etc. MDPP is not the tool for you. There are a few tools, but sophisticated stuff isn't there, and never will be, probably. If you want to slice and dice 3-D images at high speed, you need a SGI and something like AVS as your IP package, not MDPP. My guess is that the tools for analyzing radiological data are probably all there, but we do not have the experience or expertise to recommend MDPP in this application.
Getting started is tough. But the only way to come to grips with the programs is to use them. Play around! Read in one of the example files (e.g. DONNA.BMD, or MANDRIL.BMD), get maximums and minimums (MM), generate noise images (GN), display them on the workstation (DV), slice their values (SL), add noise to DONNA (SU), smooth the result (SO), compute a total image power (TP), renormalize (NR), draw some contours (PL), warp the image (WA), etc, etc... Look thought the "Menu of commands" and try some things you like the look of (maybe they will work [our fault], maybe not [your fault] :-). But don't get scared off and if you have a major problem, feel free to call or E-mail for help.
Finally, when you have built up a bit of confidence, look at the examples in the area MPP:[EXAMPLES]. This are contains complete sets of data and command lists to allow you to see the MDPP in action for several of the major problem areas where the MDPP works well. Don't screw up the files in that area! Rather, copy them over to your own space and play with them. Change the command lists, use the commands interactively, fiddle. Report the bugs if you find any! Don't accept stuff you do not understand, and don't accept anomalies in the processing (that is how we have found some key errors).
Finally, good luck! We have fun making MDPP (for the most part that is) and think it is a really great product. Your use of it can make it better. Keep in touch!
The Mandatory Disclaimer In tiny print
Users of this software package, which includes MDPP and the utilities, accept
full responsibility for its possession and use. Users understand that this is
an unsupported package provided at no charge consisting of experimental
software intended for research purposes only. The package is provided as-is
without any warranty of any kind expressed or implied as to its fitness to
perform any function or meet any specification. No warranty is made that the
contents of this package or the use of this package will not infringe on any
patent, copyright, trade secret or trade mark of any third person. None of
the contributing authors, nor the institutions where they currently work or
have worked in the past, nor HEWLETT-PACKARD CORPORATION (HP)
accept any liability for the contents of the package, the use of this package
or any fragment of it, or the consequences of using the package or any of the
utility programs. A user of this package accepts full legal liability for
the possession of the package, its components and any and all use thereof. A
user accepts all costs of legal defense for any and all legal actions which
may arise from use of the package. A request for distribution components of the
package, or their use, is understood to be construed that user undertakes to
defend the authors and their institutions, at the users own cost, in any
legal actions which may arise from the possession or use of the package by
that user. Use of this package in conjunction with medical patient care
is not recommended. Use of this package in a clinical environment is
the sole responsibility of the Chief of Service of the relevant clinical
department who must establish on his own authority that the package is free
from errors which could affect any aspect of patient care. It is recommended
that patient "informed consent" be obtained from all individuals whose
clinical data is to be analyzed with this package, appraising them of these
conditions of use. The package is believed to be free from extraneous code
which would constitute a 'Virus', 'Worm', 'Trojan Horse' or similar code
which would damage a computer or its files: however, no specific checks have
been made for such extraneous code and no guarantees can be made that such
code has not been inserted, unknown to the authors. Therefore, the authors
and their institutions accept no responsibility for damage to data or
equipment, loss of use of any system, disruption of programmers time or any
other disaster or difficulty arising from the use of MDPP or any of the
utility programs.