This defines C-shell aliases for each KAPPA command, includes the help information, and shows the version number. It need only be issued once per login session. Thus you will see
KAPPA commands are now available -- (Version 1.0) Type kaphelp for help on KAPPA commands
Let's run a KAPPA application. CADD adds a scalar constant to an NDF file--the Starlink standard data format--to make a new NDF file (usually called an NDF for short). In this case ten is added to the pixels in $KAPPA_DIR/comwest.sdf to create test.sdf in the current directory.
% cadd $KAPPA_DIR/comwest 10 test
There are three parameters qualifying the CADD command: the names of the input and output NDFs and the constant. Notice that these parameters are separated by spaces. Most applications have a few of these positional parameters, usually the most commonly used. Parameters given on the command line are not subsequently prompted for by the application. Also you see that the NDF file extensions are not given. The .sdf extension indicates that it was created by the Hierarchical Data System , or HDS for short. Note that an arbitrary .sdf file is not necessarily an NDF.
Next we run the statistics task. Here we have not given any parameters. In this case the application will ask for the values of any parameters it needs.
The only parameter required is called NDF, and STATS prompts us for it.
NDF - Data structure to analyse /@test/ >
In this example, STATS wants to know for which NDF we require statistical data. The text between the // delimiters is the suggested default for the parameter. By pressing the carriage return we accept this default as the parameter's value. Here the suggested default is the name of the NDF created by CADD. (Ignore the @ for the moment--it just tells the application that it is a file.) KAPPA remembers the last NDF used or created, and uses it for the suggested default to save typing. Since test is the NDF whose statistics we want we just hit the return key. Again we exclude the .sdf extension. Here is the output from STATS.
Pixel statistics for the NDF structure /home/scratch/mjc/test Title : Comet West, low resolution NDF array analysed : DATA Pixel sum : 11851773 Pixel mean : 180.8437 Standard deviation : 63.47324 Minimum pixel value : 13.89063 At pixel : (59, 83) Co-ordinate : (58.5, 82.5) Maximum pixel value : 255.9375 At pixel : (248, 45) Co-ordinate : (247.5, 44.5) Total number of pixels : 65536 Number of pixels used : 65536 (100.0%)
Of course, in your case the current directory will not be /home/scratch/mjc. The NDF title is the unchanged from the $KAPPA_DIR/comwest NDF. This is the normal behaviour for tasks that create a new NDF from an old one; they do, however, have a parameter for changing this default. To alter a defaulted parameter you supply its new value on the command line. Defaulted parameters exist to prevent a long series of prompts where reasonable values can be defined, and hence save time. (However, there is a way of being prompted for all parameters of a command should you wish.)
NDFs may contain three standard arrays--the data array, the data variance and quality. STATS can calculate statistics for any of these. By default, STATS uses the data array, as indicated here.
Next we wish to smooth our data. GAUSMOOTH performs a Gaussian smooth of neighbouring pixels.
Again we are prompted with the same suggested default, since we have not created any new NDFs within STATS. Say we don't want to smooth that NDF, but the original one. We just enter the name of the NDF at the prompt. Notice that we don't need the @ prefix, since Parameter IN expects a file. (One occasion where you would need it is when the filename is a number, e.g. if your NDF was called 234 you must enter @234, otherwise the parameter system will think you are giving the integer 234. Yes ...I know ...the parameter system is trying to be too clever.)
IN - Input NDF /@test/ > $KAPPA_DIR/comwest
The description of Parameter FWHM is too brief for us to select a value. So we obtain some help on this parameter, and then GAUSMOOTH reprompts for a value. The smoothed NDF is written to the NDF called testsm in the current directory.
FWHM - Gaussian PSF full-width at half-maximum /5/ > ? GAUSMOOTH Parameters FWHM FWHM() = _REAL (Read) This specifies whether a circular or elliptical Gaussian point-spread function is used in smoothing a two-dimensional image. If one value is given it is the full-width at half-maximum of a one-dimensional or circular Gaussian PSF. (Indeed only one value is permitted for a one-dimensional array.) If two values are supplied, this parameter becomes the full-width at half-maximum of the major and minor axes of an elliptical Gaussian PSF. Values between 0.1 and 10000.0 pixels should be given. Note that unless a non-default value is specified for the BOX parameter, the time taken to perform the smoothing will increase in approximate proportion to the value(s) of FWHM. The suggested default is the current value. will increase in approximate proportion to the value of FWHM. FWHM - Gaussian PSF full-width at half-maximum /5/ > OUT - Output NDF > testsm
Next we want to look at the result of our image processing. The first thing to do is to select an graphics device. The xwindows device becomes the current graphics device and remains so until the next GDSET command. (You may need to enter the xdisplay command (SUN/129) to redirect the output from the host computer to the screen in front you.)
% gdset xwindows
Now we actually display it on the screen. Some applications have many parameters, and it would be impractical to have to specify all those preceding the ones we wanted to alter. The solution is to specify the parameter by keyword. Here we have requested that the scaling of the data values to colour indices within the graphics device uses the current percentile range. Note that you may abbreviate the options of a menu, such as offered by Parameter MODE, to any unambiguous string.
% display mode=pe accept Data will be scaled from 78.38278 to 235.3536.
If you have just created the window, the image will not look much like the comet, because the existing colour table is poor. If we replace the table with a grey-scale ramp from white to black,
what happens depends on your workstation hardware and settings. If your graphics system is set to 256 colours (technically, an 8-bit pseudo-colour visual), then the effects of the above LUTNEG command will be immediately visible, and you will see a blurred image of the ubiquitous Comet West on the screen. If, on the other hand, your graphics system is set to 16-bit or 24-bit graphics, then the effects of the LUTNEG command will only become visible when you next display an image. In this case, re-invoking the above DISPLAY command will make the image appear correctly with the requested grey-scale colour table.
The ACCEPT keyword is a very useful feature.
It tells an application to accept all the suggested defaults. In this
case DISPLAY uses the current NDF and scales
between the current percentile limits--10 and 90. The keyword can be
abbreviated to double backslash from the shell. Aside: the parameter
system actually requires a single backslash. From the shell, however,
backslash is a metacharacter, and so must be `escaped' to
treat the character literally. One way is to place a
before each metacharacter. You can escape a series of
characters by placing them inside single quotes ' '. Other
metacharacters to watch out for when using KAPPA include
Next we want to make the image colourful. There are a number of predefined lookup tables, or you may create and modify your own. Here we've given the X-window a `warm' brown-yellow colour table1:
If you are not happy with this colour table, you may want to explore a wider range of colour tables using the LUTEDIT command which provides a complete graphical user interface for manipulating and viewing colour tables.
% lutedit image=$KAPPA_DIR/comwest
KAPPA --- Kernel Application Package