Computer Methods and Programs in Biomedicine, 27 (1988) 229-240

Elsevier

229

CPB 00933

Section II. Systems and programs

QSH: a minimal but highly portable image display and handling toolkit

Marilyn E. Noz ’ and Gerald Q. Maguire, Jr. 2

’ Department of Radiology, New York University, New York, NY 10016, U.S.A., and ‘Department of Computer Science,

Columbia University in the City of New York, New York, NY 10027, U.S.A.

We describe a software system developed to handle images obtained from different sources, namely, computer-assisted tomography, positron emission tomography, single photon emission tomography and magnetic resonance imaging. In

developing the system, it was necessary to address the following points. (1) The types of values that were encountered

in both the header information and the pixel elements, namely, integers, floating point numbers, complex numbers and

strings. (2) The use of domain-dependent sets of keys, that is, how to choose keys and how to stabilize the use of keys

among the user population. This is, for example, how information such as the patient name, or the activity in becquerel

is kept. It is necessary to keep both the key values and the units. (3) The development of a method for providing a

database using flat files, i.e. linear text. (4) The maintenance of a history of values and operations. This is necessary in

order to address the problem of determining from an image how that image was produced. The connection between an

image and how it was derived is analogous to describing how a secondary standard is derived from a primary one.

Image processing; Image data base; Image format; Portable image software

1. Introduction

In any medical environment in which different types of images are produced, there are many common tasks which are required to handle these images. Following image production (either in analog or digital form), there may be a need to enhance (or otherwise process) the image, make it available for use (e.g., viewing), store it for later retrieval, and transmit it to different locations. In radiology, the conventional approaches to the per- formance of these tasks has led to workable but inefficient solutions. Most of these solutions re- volve about the use of film. However, film retrie- val (for comparison or research use) is often

Correspondence: Marilyn E. Noz, Department of Radiology,

New York University, 550 First Avenue, New York, NY

10016, U.S.A.

hampered by film misplacement and the high per- sonnel cost of filing, retrieving and transporting the film; radiologists and clinicians often have to physically travel to the image source locations; space requirements bften dictate that older films be stored off-site, and sending films to other in- stitutions involves reproduction, shipping cost and delays. In the case of imaging modalities which are inherently digital, such as computer-assisted tomography (CT), positron emission tomography (PET), single photon emission tomography (SPECT), nuclear magnetic resonance imaging (NMRI) and digital radiography (DR) in its vari- ous forms, the situation is worse: there is repli- cation of hardware costs in having separate view- ing systems for each modality, there is loss of image information when these images are archived on film, the image formats are all incompatible and once the machine producing the image is retired as obsolete, those images obtained on it are

0169-2607/88/$03.50 0 1988 Elsevier Science Publishers B.V. (Biomedical Division)

230

often (nearly always) no longer available in digital form.

The present authors started to grapple with these problems toward the end of the last decade. We realized that the problem existed on many levels. First, we needed a common image format to exchange images inter- and intramurally. We needed a common image format to display and manipulate images from different modalities on the same viewing console, i.e., so one set of appli- cation programs would apply to any image, as well as so that further application programs could be developed as new information was obtained from the images. Furthermore, we needed to support different display systems, we needed to obtain the data and we needed a method of taking advantage of hardware upgrades without having to re-write all the software. Note that our solutions apply to any type of images and are not limited to the medical environment.

The first step toward resolving the image for- mat problem was the publication of the American Association of Physicists in Medicine (AAPM) report, ‘A Standard Format for Digital Image Exchange’ [2] *. At the first meeting sponsored by the Society of Photo-Optical Instrumentation En- gineers (SPIE) on Picture Archiving and Com- munication Systems (PACS) in medical imaging [lo], the authors [5] along with many others pro- posed that the acquisition and storage problems be solved by implementing a network to intercon- nect imaging facilities and by encouraging broad cooperation which would lead to industry-wide standards. (Since that time the ACR-NEMA Dig-

* The publication of AAPM Report No. 10 was the first

attempt to standardize iniage formats in the medical imaging

community. Since then, two other groups have formed (CART, the Scandinavian collaboration for Computer Assisted Radia-

tion Therapy treatment planning, and ACR-NEMA, a col-

laboration whose purpose is to formulate a standard digital

interface to medical imaging equipment). The AAPM format

uses key-value pairs in plain text to keep track of all informa-

tion associated with a particular image. The radiation oncology

community in the U.S.A. [4] has been defining key-value pairs

for use with CT, nuclear medicine and NMRI images. Ad-

ditionally, both ACR-NEMA and CART have been defining

fields for use with the same types of images.

ital Imaging and Communications Standard 300 had been published [l].) The image format de- scribed in this paper can be easily adapted to any standard format which is adopted in the future. We took advantage of the UNIX ** operating system (which has been ported to many different CPU-s) to give us hardware independence and chose to program in a high level language (in our case C) so as to easily go from one hardware environment to another. (Presently our routines support UNIX System V and UNIX BSD 4.x as well as EUNICE.)

The networking aspects of the problem have been discussed at length in many papers and most notably in the review paper [9]. Additionally, a generic approach to frame buffers by use of a small set of easily programmed primitive functions has also been described [8]. The purpose of this paper is to describe the mature formulation of the image format and its use in application programs. This is similar to what the Utah Raster Toolkit [ll-131 has provided for 8-bit gray scale and 24-bit real color raster images, but applies to a much broader range of images.

2. Data handling

The format of images is a very important consid- eration, because each device that needs to manipulate them needs to know the file format. Image processing programs are generally useless for application on images other than those for which they were written simply because of this dependence on image format. Additionally, as an image is processed, information regarding the past state of the data as well as the present, i.e., a history of the image, is generated and should be kept. It is often cumbersome to associate this knowledge with the image in an obvious way.

Hence, it would be convenient if the file format chosen could also act as a database for the data associated with the image. This system [7] was also developed for the purpose of incorporating data generated as a result of image processing on the

** UNIX is a trademark of Bell Laboratories.

231

images into a PACS. We considered the frequently encountered situation where the acquisition of the images was performed in one location, while the medical analysis of these images was performed at another, physically remote location.

An adaptation of the AAPM standard image format was used for the image file structure and the University of North Carolina vsh [14] (visual shell) was used as a model for developing the image analysis software. The vs h names for the image access functions (imopen, i mc reat, i m- close, imdim, imbounds, imgetpix, im- putpix) have been retained to facilitate the use of the new image format by existing programs written to use the UNC routines. Not all of the UNC routines are supplied; however, these (i m- error, imgetinfo, imputinfo, iminfoids) can be written in terms of ImageGet Value and ImagePut Value. As standards for PACS are adopted, this system can be adapted to conform to them.

3. The IMAGE format

The file format IMAGE provides a header file as text in the form of sets of standard key-value pairs (KVP) for the non-numeric data and a second separate file composed of the N-dimensional array of numeric values (image data) which compose the actual pixel values.

1. 2. 3.

Examples of the non-image data might include: date of image creation; type of instrument producing this data; all the parameters necessary to convert the N-dimensional array of values to the represen- tation required for interpretation (which may include viewing). This non-numeric data will be referred to as

header information [2,3,6]. This header informa- tion is in the form of key value pairs as ASCII character strings, with a key beginning a line, possibly with leading spaces or tabs, followed by a colon equal (:=), followed by the value and terminated by a newline character. Fig. 1 il- lustrates the type of non-image or header informa- tion that can be stored, and shows those key value pairs which are essential for reading the image.

Pixel Format:= 8 Bytes per pixel := 2 Number of dimensions := 2 Size of dimension [0] := 128 Size of dimension [l] := 128

Institution := NYU Medical Center Department := Radiology Division := Nuclear Medicine Date created := 1980.10.17

Date written := 1980.10.20 Patient name := Sam Jones Exam Type := Liver spleen study

The following key value pairs are required to access the image data:

Pixel Format := Bytes per pixel := Number of dimensions := N Size of dimension [0] := Size of dimension [ 1 ] :=

Size of dimension [N-l] :=

Fig. 1. QSH header.

The date is written in ACR-NEMA format; two’s complement integer format for the numeric data is indicated by the first line (Pixel Format := 8) of the header file.

Suppose a simple image consists of a three-di- mensional array of small (in the range - 128.. .127) integers. The array happens to be a 3 by 4 by 5 array. Consequently, the header infor- mation when placed into the directory, could be used by a program to put the sequential bytes of image data into a 3 by 4 by 5 array. The header information for the image data would thus be stored as illustrated in Fig. 2.

The information associated with an image thus always includes the dimensions of the image where, for a three-dimensional image dimension CO1 is the number of slices (views, frames) and dimen- sion C 11 and dimension C21 are the rows and

Header:

Pixel Format := 8 Bytes per pixel := 1 Number of dimensions := 3 Size of dimension 101 := 3 Size of dimension [lj := 4 Size of dimension [2] := 5 <EOF>

Fig. 2. Header information.

232

columns. The maximum and minimum pixel val- ues for the entire image and for each slice of the image are automatically added to this header when a command file (known in UNIX terminology as a shell script) which might be called mm is run. (This command file, as well as others are kept in the directory file . ..qsh/scripts.)

Although bounded by a constant specified in the include file ‘i mage. h’, arbitrary length fields can be defined in the header file where comments on the image, processing information, and other user-defined information can be stored, added, extracted or modified in key-value pair format using an editor, command file or program (such as a w k). Qs h includes procedures which allow the insertion and extraction of key-value pairs from a program. Additionally, any program which calls the procedure to create an IMAGE file, automati- cally generates a header file which contains the standard information.

The numeric data is stored in a separate binary file in order. The size of each datum item is kept at its original value, i.e., byte data is stored in bytes, 16-bit data is stored in 16-bit (short) in- teger, floating point data is stored in floats. (Since byte order and floating point representations are not at present standard, for interchange between heterogeneous systems, network byte order and IEEE floating point format (for floats) should be used.) There is absolutely no compression al- gorithm applied to the data. The user is free to use any compression algorithm of his/her choosing for storage, but must uncompress the file before using any of the programs provided with QSH. If a compression algorithm must be used, it should be lossless (i.e., the image data when uncom- pressed should be precisely as it was before the compression algorithm was applied to it) *.

Since each image consists of two separate files, we must have a convention to handle this. Both files are given the same root filename, but differ- ent extensions are used: ‘. qhd' or ‘. QHD' is used for the header file and ‘ . q i m' or ‘ . QIM’ for the

* This is particularly important in the case of medical images

as we do not know what effects added noise will have on

algorithms which manipulate the data.

data file. Both of these files must be present to access an image. Since the ‘ . q h d' or ‘ . QH D’ file is much smaller than the ‘ . q i m' or ‘ . Q I M’ file and also provides all the descriptive data about an image, it is possible (and reasonable) to keep the ‘ . q hd' or ‘ . QHD' file on-line to serve as a simple data base for the off-line image data. When the entire image file is referred to, the user need not

type the extension. However, when only the header file is referred to, the user must type the extension. All programs which process or display an image manipulate both files, thus the user need not type the extension. While QSH provides explicit capa- bilities for creating IMAGE files, it is the job of the operating system under which the QSH programs are invoked to provide the file management facili- ties.

The ability to have arbitrary key-value pairs is so useful, that one user (Jonathan Stockley) has modified the image access routines to only deal with header files if the key ‘Number of dimen- sions := ’ is set equal to ‘0’. He has constructed a server process which- reads values from a header file, answers requests for values, updates values, adds new key-value pairs and when terminated, updates the header file. This provides the facilities of environment variables (which many operating systems provide) with the added power of being able to update these values. Typical values which users might want to update are ‘Current color scale’, ‘Background’, ‘Saturation’, etc.

4. Application programming for IMAGE files

QSH offers a library of I/O subroutines for the use of the application programmer. The purpose of these routines is to provide a standard interface to a standard file format for the images. It is required within the QSH system that all images be in this standard format and that all input/output be done by means of these standard subroutines. In all cases where an error occurs within a QSH subroutine, an error key, whose value is declared in the file i mage . h is returned. An error message may then be written to an appropriate place which under a UNIX type operating system is usually ‘standard error’. Since the routines imopen and

233

information m

1) number of dimensions 2) pixel value format

3) size of each dimension

subroutines

imdim

imbounds

4) pixel values imgetpix imputpix

5) auxiliq information ImageGetValue ImageGetFloatValue ImageGetlntegerValue ImageCetVectorValue ImageGetFloatVectorValue ImageGetIntegerVectorValue ImagePutValue ImagePutFloatValue ImagePutIntegerValue ImagePutVectorValue ImageFUFloatVectorValue ImagePutlntegerVectorValue

Fig. 3. IMAGE subroutines.

i mc rea t return a structure, error cannot be indi- cated by a return value, and so a global variable ErrorState is set to the error number.

To get a rough idea of how to use the IMAGE subroutines in applications programs, it is useful to group them according to the type of informa- tion that they access in an IMAGE file (see Fig. 3). In addition to the above-mentioned functions, three others, imcreat, imopen and imclose, handle the creation and disposition of IMAGE files. Application programs which access IMAGE

files need to know both IMAGE data structures and IMAGE subroutines.

A simple example (Fig. 4) written in the C-pro- gramming language can help tie these ideas to- gether. Some things to notice in the sample pro- gram: - the include file, i mage . h, contains the declara- tions of IMAGE files and IMAGE routines. For example, both imcreat0 and imopen0 are declared in image. h. - i mage. h contains other useful constants such as DEFAULT, which means that the owner of the IMAGE file is the only person with permission to update the file, but others can read it.

4.1. Example constants for use in applications pro- grams (defined in i mag e . h)

Constant Meaning

IMAGE the type of file used to store images READ used to open file for reading UPDATE used to open file for updating GREY pixel format: two bytes per pixel FLOAT pixel format: four bytes per pixel

for floating point numbers GREYTYPE type definition for GREY pixel FLOATTYPE type definition for FLOAT pixel

The protection modes used by i mc rea t ( 1 are the same as those used by the C-subroutine treat(2). However, imcreatc 1 accepts only those modes which allow updating by the owner. Therefore, an acceptable mode is any mode con- sisting of UOWNER alone or UOWNER OR’d with another protection mode such as RGROUP. DE-

FAULT is an example of such a composite mode.

Mode UOWNER

UGROUP

RGROUP

UOTHER

ROTHER DEFAULT

Meaning

update by owner update by group read by group update by others read by others update by owner and read by all others

4.2. Other types of data structures QSH is flexible enough that by the use of other header file definitions and a small set of sub- routines which use these definitions, other file types can be defined. For example, we have de- fined a file type for saving (x, y) coordinate pairs such as are produced when regions of interest (ROIs) are defined as polygons. The ROIs are stored in IMAGE format as simple contours upon which the usual operations of editing, moving, overlaying on different images, etc., can be per- formed. Additionally, mask files in IMAGE format can be derived from these regions for purposes of numerical analysis. In the same manner, (x, y) pairs in the form of curves are also supported. These are treated essentially as one-dimensional images. Similarly, video lookup tables (i.e., color scales) are treated as two-dimensional images

234

#include “image. h”

#define QshCheck(expr, if ((expr, <= 0) errorterm0: #define PAT KEY "Patient Name" int ErrorSGte; ,* global storage for error number +/

endpts = (i"t*) malloc(sieeofli"t)*(d~~~Z)); newendpta - lint*) malloclsireof(int)*ldimc'2)); coarseness = tint*) malloc(sizeof,i"t)*dimc);

/* verify that the above allocations are all successful l / if ~~dimv-=N"LL,,,~e"d~ts==NULL,,,~coarseness==N"LL,,

c fpri"tf(stderr,"Allocatio" error\"'); exit(l): ,

one slice from a" IMAGE file. a" IMAGE file containing a processed picture of the same slice. find the sire, etc., of the incoming IMAGE file, create a new IMAGE file to bold modified picture,

QshCheck(imbounds (qshim, dimvl):

and the" call a wcrro‘Uinc to do the actual processing. Note: 'oldname', 'newname (which may contain directory specifications) and slice "umber must be read from standard incut, i.e., from the command line.

"evdimv~0,=1: "ewdimv[ll-dimv[l]: "evdim"[21-dim"[21; rumpixels - dimvlll * dimvL21: olddata - (GREYTYPE*lmallac(sizeof(GREYTYPE)*"umpixels); newdata = (GREYTYPE*)malloc(sizeof(GREYTYPE,*"umpixels); fOL

I I /* declarations for existing IMAGE file '/

IMAGE *oldImage; /* pointer to a" existing IMAGE file. +/ IMAGE *'newImage; /+ pointer to a new IMAGE file */ char old"ame[80]: /* name of image file */ char "ev"ame(801 /* name of newimage file */

/* string to hold header values '/ char tempStri"g(MaximumValueLe"gth1:

endpts[2*il - 0; newendpts[2*i] - 0; e"dpts[2*i+ll - dimv[il-1: "ewe"dpts[2*i+ll - "evdimv[il-1: coarse"ess[il - 1

int dime: int neudimc; int *dim"; int *"eudimv; int pixelformat: int *endpts; int *nevendpts; int *coar.¶e"ess: int "urnpixels: int SliceNumber: GREYTYPE *olddata; GREYTYPE *newdata; char *mallocO;

I* number of old dimensions +/ /* "umber of new dimensions l / /* bounds of each dimension l / /* bounds of each dimension l / /+ type of pixels used */ /* end points used for retrieval /* end points used for storage /* coarseness used for both /* number of pixels /* image slice to use

1

I* "ox create the "ew IMAGE file with the same pixel format, l "umber of dimensions and dimension sires, */

neuImage-imcreatlnevname,DEFAULT,pixelfo~at,nevdimc,nevdimvj; if 1 ErrorState =- 01

/* Pointers to pixel values

(i-0; i<-2; i++)

*, ErrorStateCheck(Ca""ot create new image);

/* read standard in */ if(ssca"f(argv[ll, "%80s",old"ame, -41 "sageCheck0; if(ssca"f(argv[21, "%80s",neu"ame, ==Ol UsageCheckO; if(ssca"f(argvl31, "%d",CSliceNumber) -41 UsageCheckO;

/* open the IMAGE file for reading and get vital l information from existing file 50 that a new :/file can be created with the same characteristics.

aldlmage = imope"(old"ame, READ); if( ErrorState == 0)

ErrorStateCheck(Ca""ot open old image); QshCheck(imdim(qshim, hpixelformat, hdimc)); "evdimc - dime: dimv = "evdlmv(i"t*l mall oc(sireof(i"tj*dimc);

= lint*1 malloc(sizeof(intl*dimcl:

*/ */ */ */

*/

/* fill a buffer with the pixel data, call the user program, * write the returned date to the "ev file */

QshCheck(imgetpix(oldImage, endpts, coarse"ess.~char*lolddatall:

uscrro~'nclolddata,nevdatal; QshCheck(imputpix(neuImage, endpts.

coarse"ess,(char*,"eudata,,:

/* Insert information into the new image file header *\ if (ImageGetValue(aldImage. PAT-KEY, tempStri"g1 > 01

ImagePutValue("euImage, PAT-KEY, tempString): ImagePut"alue("ewlmage,"Parent Image", oldname,; ImagePutvalue("ewlmage,"Derived Using Algorithm",

"B-spli"e - Foley and Van Dam"); ImagePutValue("evImage,"0riginal Data was",

"Special Geriatric CT sequence"):

QshCheck(imclose(oldImage1 j; QshCheck(imclose("euImage));

exit(O): ,

Fig. 4. IMAGE sample program.

which have three columns (red., greeqblue - for a monochrome color scale these are all set to the same value) and n rows where n is the number of entries in the color scale. The pixel format for these color scales is floating point.

5. Reading and writing descriptive data

As the descriptive data for images are kept as key-value pairs which are stored simply as textual files, they may be processed using any of the text processing tools (edi tars, awk, grep, etc.).

5.1. Specific programs for obtaining information from IMAGE format files The program getva lue is used as:

getva Lue f i lename key where key is the key whose value in the named

file is desired. This at present simply looks up the key and outputs the associated value. The pro- gram writes its results to wherever is presently defined as the standard output. In a UNIX en- vironment ge tva lue simply prints on ‘standard out’.

The program m i nmax is used to compute the minimum and maximum pixel values and may be run as:

mi nmax f i lename

235

This program also writes its results to wherever is presently defined as the standard output. How- ever, the user often wants to store these results in the file header for later use. This set of operations could be placed in a command file (mm) and executed by saying:

mm filename where in a UNIX environment the command file

takes the form: minmax filename 1 tee -a

filename.qhd

5.2. Using header information obtained from non- IMAGE format files It is possible also to incorporate information from a non-IMAGE file into the header file, when refor- matting the original data into an IMAGE format file. If the information always has a fixed format, then the previous header information might be first put into a structure. The format of the infor- mation must be known, i.e., whether the item is an integer, an ASCII character or a floating point

number, as well as the order in which the informa- tion is presented. In the C programming language, such a structure might be stored in a file called ‘header.h'(see Fig. 5).

In order to insert this information into the IMAGE header file, a set of keys must be defined.

Fig. 5. Header information structure from non-IMAGE format files.

C_Station_ID_key "Station ID” Patient_Name_key "Patient Name” Physician Name_key “Referring Physician” Tech_initials_key “Operator ID” Exan_desc_key "Admitting Diagnosis" exam_start_date_key “Study Date” exan_start_time_key “Study Tine” source_to_detector_dist_key "Distance Source to Detector”

Pat_tYpe_W “Patient size-l=hd, 2-s, 3-m. 4-l” pat_orient_key “Patient Orientation-l=hd, *=ft” apgat_orient_key "AP-Patient Orient-l=pr,*=sup,

3-decu It, I-&c” Tt” contrast key “CO”traSt-O=no, l-yes” slice_thTckness_key "Slice Thickness - Zmm” preprocess_reco*_type_*ey “preprocess Recon Type-O=undef,

l-bone, P=soft. 3=quiLk Soft”

Fig. 6. Key definitions.

It is necessary to have one key for each piece of information that we wish to save, although the structure itself may have more elements in it. A set of key definitions might be stored in a file called ‘keys. h' and might take the form as shown in Fig. 6.

In order to insert these keys with their associ- ated values into the header file, a function might be written which takes the form presented in Fig. 7 (the conversion from the non-local floating point specification to the local one takes place in the

function designated as ‘dg_float_to_floatO').

If, on the other hand, the information is kept in

a flexible format, then the definitions of the keys might look like the listing in Fig. 8. In order to insert these keys with their associated values into the header file, a function might be written which takes the form presented in Fig. 9.

6. Overview of the directories in QSH

The entire QSH directory is rooted in ‘ . . . qs h', which in a UNIX-like environment could be ex-

pressed as ‘$qsh' where this is interpreted as a shell variable giving the name of the actual direc- tory used. In this directory there are two files, names.csh and names.ksh, whichcontainlogi- cal directory path names suitable for the file tree defined below. When the appropriate file is copied into the user’s home directory (under a UNIX-like operating system placed respectively in the . cshrc or . env file) the logical names can be used instead of specifying the entire path name. The main subdirectories of QSH are shown in Fig. 10.

236

Fig. 7. Function for key insertion.

The subdirectory d i sp lay contains further subdirectories which place images and overlays on the video screen. co lo r s is the subdirectory of d i sp Lay which contains floating point color scales in the IMAGE format which are suitable for loading the color table on any display. Since float- ing point representations may differ from machine to machine, there is an ASCII hex file distributed with each color scale. This may be used along with a program, also provided, to generate color scales in the local floating point format. ram L is the

subdirectory of d i s p L a y which contains all those subdirectories which address the Ramtek 9050 frame buffer. One subdirectory contains the bi- naries for display-related routines, another the

I* The following parameters all are given in binary l / +&fine P.F_k.q “Added Hardware Filter -

0-0,2-.25~u,4-.5,6-1.O,*-target” ldefine AN_lcey vantry Tilt - .I deg. - +-toward, --away- +&fine W-key "Profile-Accurate Relative Scan

Position-pulse-0.103S~,, *define ec_lw “BOX mars - X.Y” l&fine BP-key "Begin Position”

Fig. 8. Flexible format key definitions.

display programs source code, another the region of interest selection programs source code, another the landmark selection source code, another the graphical oblique plane selection source code and another the source code for the subroutine library specific to the framebuffer. Additionally, the manual pages for all the display-related programs and subroutines are kept in yet another subdirec- tory. dispLayIDis thesubdirectoryof display

which contains those subdirectories which address a specified frame buffer. The subdirectories here are the same as for in ram I, except that there is no subdirectory for the manual pages. This is the same for every frame buffer or raster display which is supported. The source code, except that for the sub L i b library, need not be specifically copied over for a particular frame buffer, but could be linked to the sources which exist in the ram L subdirectory.

The subdirectory dot Lib contains the refer- ence manual and articles pertaining to QSH.

The subdirectory conve r s i on contains subdi- rectories for converting images from other formats

231

/* i"putstuff2.c - put the appropriate value.5 into the image * header (*.qbd) file. *

l This file contains the appropriate imageput... routines l to store the values found in the slice header. The * keys have bee” chose” to Conform to the ACR-NEMA where * possible. II

l 88.03.29 Gerald Q. Maguire Jr. 6 M.E.No* * * Copyright (C, 1988 Maguire h NOT l

#include <stdio.h> Xinclude <fc”tl.h> tinc1u*e <sys/types.h> #include “keys.h” *include "image. h”

,’ Global variables *I static unsigned char stri"g[Haximum~alueLengthl; static short int buffer[MaximumValueLength/21;

,* Procedures l / unsigned char *Read_Value(le"gth,fd) unsigned short int length: int fd: , if Creadffd, string, ((le"gth)+sireof(char))) -- -1)

I fpri"tf(stderr,"Ca""ot read header value,""): ?CetIAI"; 1

retur"(stri"g1: t short int Read I"t_Value(length,fd) unsigned short-int length; int fd: (

if,(read(fd, LbufferIOl, ((le"gth/*)*sizeof(short))) -- -1)

fpri"tf(stderr,"Ca"not read header value\n"): return;

t returnCbuffer[Ol,; t

union length-buffer

unsigned char bufL21; unsigned Short le";

union length-buffer le"Buf;

void i"put=tuff*~image,Numb=rOfSlices~ IMAGE *image: int NumberOfSlicesi I ' int fd; char dir_name[801: char keybuf[801; char key[MaximumKeyLength,; char date_stri"g~Maxim~Valuelengthl;

Short int loc_b"f~Maxim"m"al"=L=ngth/2l; ""signed Short int length; int name; int i,j; ,* loop counter *, Static &al l mo"th_"am=,, - c ““0 mmth”, “3.N”.

sprintf(dir_name, “headerfile”,; ,* open directory file l ,

if ,(fd - o~="~dir_nam=, O_RDONLY,I -- -1) , fprintf(stderr, ~~annot open header file, *sin". dir_namel: 1

,’ Ineert the machine type ="d ""3dalitY '/ lmageP"t"al"e(imag=.""a""facturer~,~'Som=o"e"~~ ImaseP"t"al"=(imag=,~Modality~."CT"~; ~mageP"t"alue(imag=."Acc"rat= Slice Po=itio"*, ~15'Profile + Pulses"): lmag=Pvt"al"=(Imag=,~Slice Thick"===",

vosition[i+ll- Po=itio" Iil~):

I' LOOP OYer =I1 the header values ', while (TRUE)

, /* Read the header file code 'I if CreadCfd, keybuf, sireof~short~) -- -1) i fprintf,stde=r,“Cannot read header item key. *sin”, dir-name): return:

I* Read the header file code l , if (iead(fd, keybuf, =ireof(=hort)l -- -1) i fprintfrstderr,“Cannot read item key. %s\n”, dir-name); return;

.L if (stmcmp(*eybuf,“BP”.2, -- 0)

Imag=P"tl"t=ger"=lu=,image.B~_~ey.R=ad_l"t_"alu=~length,fd,~: /* end binary list l ,

else if ~str"cmp,*=yb"f,"AF",2, -- 0) lmagePut~"tes=r~alue~image.AF_lr=y,Read_I"t_Valu=~l="gth,fd~I:

1 /* end binary code list A/ I* end while loop *,

Fig. 9. Flexible format key insertion function.

238

_.qsh

sublib

I- man

Fig. 10. The QSH directory tree.

into the standard IMAGE format. At present this contains a subdirectory d rs, which contains the programs, executables, and command files needed to change d r s format image files into IMAGE format files. It also contains a subdirectory tprd which contains the programs, executables, and command files needed to read magnetic tapes produced by various image source machines into IMAGE format files.

The subdirectory ima contains some sample files in IMAGE format.

The subdirectory image contains the image processing programs; the subdirectory o b 1 i que contains the oblique reconstruction programs, and the subdirectory reg i s te r contains the image registration programs. All three subdirectories contain a subdirectory src which contains the sources for the programs, a subdirectory bi n

which contains the executables for the programs, and a subdirectory man which contains the manual pages for the programs.

The subdirectory s c r i p t s contains some sam- ple command files (in this case shell scripts for both the C and Bourne/Korn shells) for use with the QSH program commands.

The subdirectory sub 1 i b contains the subroutines necessary for image file manipulation such as i mopen, imc lose, etc. The manual pages for these subroutines are in a subdirectory man contained here.

Under a UNIX-like operating system, it is pos- sible to control the compilation of source code by use of a program called ‘make’. To take advantage of this facility, files exist in the various subdirecto- ries to compile and link all the programs, func- tions and libraries. Within these specific ‘make- f i 1 es’, the various directory references are all relative. The makefile in . ..qsh/sublib creates a library (1 i b i q . a) of the QSH image manipula- tion functions. This library is referenced by speci- fying either an absolute or relative pathname fol- lowed by the library name to the loader.

7. Displaying the image

At some point the user may wish to display an image. As this may involve using one of several displays, the user must indicate which display is to be used. This is done by putting either the name of the directory containing the executables for a particular display on the search path or connect- ing to the directory containing the executables. (The user can prefix display programs with the name of the chosen display directory.) 1

It is noteworthy that the first implementation of QSH was done at the Karolinska Institute in Stockholm, Sweden. The Clinical Neurophysi- ology group there had a Ramtek 9400 and a Ramtek 9050 display. All that was necessary to switch from the 9400 to the 9050 was to imple- ment a set of subroutines which knew the specifics of its respective display and then compile the programs using the appropriate subroutine library. Since then, implementations have been done for the Grinnell 270, Lexidata 3400, Hewlett-Packard

98710 and 98720, Nodecrest TVN 256 and TVN 512, Silicon Graphics IRIS 2400 and Pixar Image Computer. [8].

The display-related programs are as follows: alterlut

clear display

disp

dumplut fbclr fltcolor

getcol

getcoords Label LoadLut rowbar

savefb

setcol

tvnew

whitebar

Load and interactively alter a LUT (video Lookup Table). Clear a region of the screen. Display an IMAGE format image on the screen. Display an IMAGE format image on the screen - this program includes many display options. Print the contents of the LUT. Clear the screen. Read and existing integer color map and output a floating point version of this map. Get the r,g,b values of one entry in the LUT. Read the cursor repeatedly. Label the screen with a string. Load a specified LUT. Display a step wedge of color intensities. Save the contents of the frame buffer as an IMAGE format image. Set the r,g,b values of one entry in the LUT. Read from the standard input a sequence of RED, GREEN and BLUE values (in hex, separated by commas) which are to be stored into three vectors of floating point numbers, i.e., an image file with the dimensions C3lCNumber of Levels]. Alter colors such that all pixels in the range Coffset...off- set+widthl are displayed as the white color in the color ta- ble (allows interactive changes to offset and width).

Additional files include: coL0rs.c Procedures for reading, filling,

writing color tables. fb.h Indirect include file for special-

ized frame buffer definitions.

239

makefile Compilation and link command file.

8. Conclusions

QSH thus is a set of subroutines and programs which uses a common format for image data. It may profitably be viewed as a host for the user’s image applications programs. It accomplishes this by providing: 1. a common file format for images; 2. a set of low-level image handling subroutines;

and 3. structural restrictions on the way programs may

access images. The format is defined as a file of type IMAGE.

The standard format provides for the storage of auxiliary information, such as the history of the image. These standard images are then manipu- lated by a set of user-callable system procedures. The procedures reduce the need for programming the low-level input/output by providing these facilities. Hence, one of the principal uses for the QSH system is the provision of a structure for application programs written by the user. These programs operate upon images producing new images. In the QSH system, it is required that all files operated upon by application programs be in the standard IMAGE format.

Acknowledgements

This research was supported in part by an IBM Faculty Development Award and equipment grants from Hewlett-Packard and American Tele- phone & Telegraph Companies.

References

[l] ACR-NEMA Standards Publication No. 300-1985. Dig- ital Imaging and Communication (NEMA, Washington, DC, 1986).

[2] B.S. Baxter, L.E. Hitchner and G.Q. Maguire, Jr., A Standard Format for Digital Image Exchange, Report No. 10 (American Association of Physicists in Medicine Series,

New York, 1982).

[3] B.S. Baxter, L.E. Hitchner and G.Q. Maguire, Jr., Char-

acteristics of a protocol for the exchange of digital image

information, in: First International Conference on Picture

Archiving and Communication Systems (PACS) for Medi-

cal Applications, ed. A.J. Duerinckx, pp. 273-277 (Society

of Photo-Optical Instrumentation Engineers, Bellingham,

WA, 1982).

[4] M. Goitein, Specifications for tape format for exchange of

planning information amongst the members of the Par-

ticle Intercomparison Project and the High Energy Photon

External Beam Treatment Planning Project, in: Evalua-

tion of Treatment Planning for Particle Beam Radiother-

apy, ed. S. Zink, p. 5.11 (Radiotherapy Development

Branch, Radiation Research Program, Division of Cancer

Treatment, National Cancer Institute, Bethesda, MD

1987). [5] G.Q. Maguire, Jr., M.P. Zeleznik, S.C. Horii, J.H. Schimpf

and M.E. Noz, Image processing requirements in hospitals

and an integrated systems approach, in: First Intema-

tional Conference on Picture Archiving and Commumca-

tion Systems (PACS) for Medical Applications, ed. A.J.

Duerinkx, pp. 206-213 (Society of Photo-Optical Instru-

mentation Engineers, Bellingham, WA, 1982).

[6] G.Q. Maguire, Jr., B.S. Baxter and L.E. Hitchner, An

AAPM standard magnetic tape format for digital image

exchange, in: First International Conference on Picture

Archiving and Communication Systems (PACS) for Medi-

cal Applications, ed. A.J. Duerinkx, pp. 284-293 (Society

of Photo-Optical Instrumentation Engineers, Bellingham,

WA, 1982).

[7] G.Q. Maguire, Jr., and M.E. Noz, Images and their aux-

iliary data: a simple pictorial database, in: Microcom-

puter Applications in Medicine Bioengineering, ed. M.H.

Hamza, pp. 56-59 (International Society for Mini and

Microcomputers - ISMM, ACTA Press, 1984).

[8] G.Q. Maguire, Jr., and M.E. Noz, Standardizing the raster

display for medical images using a fixed set of frame

buffer primitives, J. Med. Syst. 10 (1986) 209-228.

[9] M.E. Noz, G.Q. Maguire, Jr. and W.A. Erdman, Local

area networks in an imaging environment, CRC Crit. Rev.

Med. Inform. l(1) (1986) 81-133.

[lo] A.J. Duerinckx, ed., Picture archiving and communication

systems (PACSI) for medical applications. in: Proceedings

of SPIE. Vol. 318, Parts I and II (The Society for

Photo-Optical Instrumentation Engineers, Bellingham,

WA, 1982).

[ll] S.W. Thomas, Design of the Utah RLE Format. Technical

Report, Alpha-l Project (University of Utah, CS Depart-

ment, Salt Lake City, UT, 1986).

[12] J.W. Peterson, R.G. Bogart and S.W. Thomas, The Utah

Raster Toolkit, in: Third Usenix Workshop on Graphics,

Monterey, CA (University of Utah, Department of Com-

puter Science, Salt Lake City, UT, 1986).

[13] J.W. Peterson, The Utah Raster Toolkit, IEEE Comput.

, Graph. Appl. 7 (1987) 57-58.

[14] J. Zimmerman, G. Entemnan, M. Fitzpatrick and J.

Whang, V Shell Reference Manual, Version 2 (Computer

Science Department, Chapel Hill, NC, 1982).