computer visualisation of the moving human lumbar spine

Computers in Biology and Medicine 31 (2001) 451–469www.elsevier.com/locate/compbiomed

Computer visualisation of the moving human lumbar spineRichard Coopera, Cosmin Cardanb, Robert Allenb; ∗

aDepartment of Mechanical Engineering, University of Southampton, Southampton SO17 1BJ, UKbInstitute of Sound and Vibration Research, University of Southampton, High%eld, Southampton SO17 1BJ, UK

Received 2 March 2001; accepted 2 April 2001

Abstract

Disorders of the spine which lead to back pain are often mechanical in origin and, despite extensiveresearch, diagnosis of the underlying cause remains problematical, yet back pain is one of the most commonrheumatological symptoms presented to the general practitioner. Diagnosis must frequently be based uponevidence gathered at the segmental level which invariably means that imaging is used in the process. Inaddition, surgical /xation is increasingly used when the spinal column is considered to exhibit instability.A solid model of the spine creates the possibility of visualising spine motion, of assessing the e0ects ofloading of the spinal column in conjunction with /nite element analysis to investigate the consequencesof vertebral fusion, and of planning surgical intervention. Such a model could also be valuable in medicaleducation and for demonstrating spine motion to a patient to highlight abnormalities or the e0ects of treatment.

This paper describes a three-dimensional visualisation of the human lumbar spine which runs on a personalcomputer operating under the Windows environment. The user interface enables the clinician to select theviewpoint for the spine model to allow the motion to be studied from di0erent angles. Motion data arecurrently acquired from 6uoroscopic image sequences but the model could be used to display data fromdi0erent imaging modalities when they are developed su7ciently for spine motion studies. c© 2001 ElsevierScience Ltd. All rights reserved.

Keywords: Spine motion; 3-D model; Animation; Fluoroscopic images

1. Introduction

Every year many billions of pounds are lost in industrialised countries due to back pain. Despiteextensive research, back pain continues to be one of the most common yet least understood com-plaints in physical medicine, the precise diagnosis remaining unknown in 80–90 percent of patients[1]. Many spinal disorders are thought to be of mechanical origin, although it is usually di7cultfor the clinician to con/rm this without detailed segmental analysis between pairs of vertebrae. The

∗ Corresponding author. Tel.: +44-2380-593082; fax: +44-2380-593190.E-mail address: [email protected] (R. Allen).

0010-4825/01/$ - see front matter c© 2001 Elsevier Science Ltd. All rights reserved.PII: S 0010-4825(01)00016-6

452 R. Cooper et al. / Computers in Biology and Medicine 31 (2001) 451–469

Fig. 1. Typical set of DVF images from a sequence of sagittal 6exion–extension.

inaccessibility of the spine obstructs segmental analysis of mechanical damage by traditional means.Non-invasive measuring techniques have been developed for use in the clinic and can give valuablequantitative information about range of motion or back shape, for example, but unfortunately mea-surements made using such methods have been shown to have a poor correlation with the positionsof the vertebrae measured radiographically [2].

Many methods and models have been developed to increase understanding of the mechanicaloperation of the spine and the e0ects of damage, using kinematics or force-dependent techniquessuch as /nite element analysis (FEA) (e.g. [3–5]). Such methods may provide a useful overview andcontribute to knowledge but are of limited use when attempting to diagnose spinal damage clinically.The clinician requires a method of performing a segmental analysis which provides reliable data withminimal invasion. Currently, the only method, which provides measurements upon which such ananalysis can be based, is digital video 6uoroscopy (or DVF) [6]. DVF image sets are sequences oflow-dose, two-dimensional X-ray images taken as the subject performs simple bending movementsin front of the image intensi/er. A typical set of lateral view images from a sequence of sagittal6exion–extension is shown in Fig. 1. The low radiation dose used results in relatively poor qualityimages but image-processing techniques can be used to enhance the vertebral features and enablekinematics to be calculated over a motion sequence. The development of this technique has beenreported previously [6–8] and is beginning to be used by other research groups [9,10]. The techniques

R. Cooper et al. / Computers in Biology and Medicine 31 (2001) 451–469 453

under development have the potential to be transported to di0erent imaging modalities, such as MRI,once developed to a level which will allow open access, motion images of the spine to be captured.

The 2-D nature of DVF images is currently a limitation in that coupled motion cannot be measuredand, indeed, it could create problems of identifying landmarks on the images of the vertebrae uponwhich kinematic analysis can be based. In addition, having described the 2-D motion of the vertebraeusing kinematic parameters, the problem remains as to how to best relate this to the clinician. Com-puter graphics are now developed to a level which creates the opportunity of displaying anatomicalmovements using graphical models of isolated anatomical bony structures for visualisation withoutthe distorting e0ects of soft tissue. This paper presents a computer visualisation of the human lumbarspine, which can be scaled geometrically to DVF images of a subject and animated to follow themotion captured. This provides a means of extending 2-D image data into a 3-D visualisation forthe clinic and the model could also have potential for visualisation of spine motion when 3-D imagedata are available.

It is not the intention to replicate the anatomical detail of the individual vertebrae of a subject, butto visualise the 2-D motion computed from anatomical landmarks identi/ed on the vertebral bodies(usually the body corners). Any abnormal movement resulting from, say, asymmetry in the shapeof one or more vertebrae that could cause articular binding may be indicated at the segmental leveland the source of the problem identi/ed from other imaging modalities in the normal way. Indeed,abnormal anatomical features would probably have been recognised by skilled clinical interpretationof plain image data prior to motion analysis. Any laxity in the holding elements, however, is notusually clearly apparent from static images and for such problems motion analysis has a role toplay. The model presented here provides a method of displaying kinematic data in a visual manner,in addition to the loci of centres of rotation or the intervertebral angles that are currently presented(e.g. [6–10]).

Wider, and perhaps more important, applications of the model could be in the investigation ofloading of the spinal column, in conjunction with FEA, and in surgical planning. Assessment of theconsequences of spinal fusion on the vertebral segments, for example, would be valuable prior tosurgery. Demonstrations of spine motion to patients and to medical students could also bene/t fromsuch a model.

2. Overview

The software developed processes two sources of data to create a 3-D animation of the lumbarspine. The /rst data source is a surface mesh representation of the lumbar vertebrae; the secondis the motion data used to manipulate the mesh to form a personalised animation. Since the samesurface mesh will be used for all patients, it was essential that a data source was identi/ed thatdepicted healthy vertebrae with little or no abnormalities or defects. The mesh was generated usingdata from the Visible Human Data Set [11], due to the clarity of the computed tomography (CT)scans available and the relatively young age of the male subject from which they were taken.A typical image of a slice of one of the lumbar vertebrae is shown in Fig. 2. Similar data setsfrom a middle-aged female cadaver have been compiled, from which it would be equally possibleto generate a similar mesh. The second source of data, used to animate the mesh, is measuredfrom in vivo DVF image sequences of a patient as rotation, translation and scaling (RTS) factors


Fig. 2. Typical CT image slice of a human lumbar vertebra.

around=along the three principal axes. The RTS factors are measured for each of the vertebrae in allof the images comprising the motion sequence. True vertebral rotation cannot, however, currentlybe obtained directly from the 2-D DVF images and this is discussed below.

The software to parse the mesh and animation data /les, and to generate an interactive 3-Danimation, was designed with several important considerations in mind. The /rst was simplicityof use; minimising time spent learning to use the program. The program was required to have acomprehensive and intuitive graphical users interface (GUI), such as those seen on the XWindowsand Windows platforms. The second consideration was to achieve real-time animation. Researchshowed that this did not necessarily require specialised computer equipment, and could be achievedon modern PC machines running Microsoft Windows 95=NT or DOS. The third consideration wascost, which was to be kept to a minimum. Due to the widespread use and relatively low cost ofWindows 95=NT it was concluded that this platform was the most suitable, with the added advantagethat a GUI was available. Proprietary animation packages were available but expensive, and all thosetested failed to satisfy real-time animation requirements. Hence, the necessity to create a programthat not only parsed the data /les, but also produced and animated the image on the screen, andallowed user interaction for full 3-D viewing.

3. Methods of 3-D representation

As with most methods of 3-D–2-D transformation, the /rst step is to build a surface mesh ofthe objects to be drawn using planar polygons. The use of triangles naturally satis/es the planarrequirement. In this case the surface mesh describes four independent vertebrae, and is generated


from CT images. Before the 3-D–2-D transformation can take place, it is necessary to position eachof the vertebrae according to the measurements of rotation angles, translations and scale from theDVF images. Once the /nal 3-D positions of each vertebra, and hence the component facets, havebeen calculated, the co-ordinates of each vertex are transformed using a camera model method [12] toarrive at 2-D screen co-ordinates ready for shading. Ray tracing [13] was deemed too computationallyexpensive for this application, and true 3-D output using a voxel display device is still in the earlystages of development; it was therefore most appropriate to use the method described above. Thismethod, unlike ray tracing, draws each mesh facet to the screen in turn, hence estimating what canbe seen from an arbitrary viewpoint and direction (the camera model).

Clipping backward facing and non-visible parts of the mesh at any arbitrary view position is es-sential for correct display. It would not be correct to draw all facets to the screen in turn, since thisis likely to result in a mixture of physically visible and invisible parts of the mesh being displayed.Clipping of invisible surfaces with the method described above can be achieved using a modi/edPainter’s algorithm [13], or the Z-Bu0er method [12]. Investigation of these methods indicated thatthe Z-Bu0er method was fast enough for real-time animation without being unnecessarily complexto implement. The Z-Bu0er technique uses two arrays, each with the pixel dimensions of the outputscreen. The /rst array is used to store the current pixel colour calculated from the re6ection model de-scribed below; the second to store the current shortest 3-D distance from the viewpoint to each pixel.The depth array, or Z-Bu0er, is tested for each pixel drawn to the screen array to establish whethera pixel is visible (in front), or invisible (behind), any pixels already drawn at that screen position.

Two further considerations are necessary to achieve a realistic 3-D output. The /rst is to clip thetransformed facets to the limits of the screen. This can be achieved with the transformed data usingsimple limit checks, but is much more e7ciently achieved using a system of the so-called outcodes[13] before transformation. The second is to achieve a 3-D shaded output. The Phong re6ectionmodel [12], which uses the relative directions of a de/ned light source, the viewpoint, the re6ectedray and the surface normal, as well as material and light properties to calculate a surface colour,o0ered the best reality without being too computationally expensive. Realistic smooth shading withthe Phong model is achieved by /rst calculating and storing the average surface normal of thesurrounding facets at each mesh vertex. A surface normal can then be calculated at any point on afacet from the average surface normals at each of its component vertices, giving the surface a curvede0ect. This gives good reality but can lead to sharp edges being given a rounded e0ect. Althoughthe colour can be calculated at any point from the interpolated surface normal, it is found to bemore e7cient to calculate a colour value at each vertex, using those values for interpolation.

4. The surface mesh

The surface mesh generated from the Visible Human Data Set was entered manually by selectingvertices on the perimeter of each vertebra in the CT images. Automatic mesh generation usingthe Marching Cubes Algorithm [14] was not appropriate due to the resulting density of the facets.Excessive mesh density increases image generation times, hence requiring more computational powerto achieve real-time animation. Investigation showed that manual mesh entry, whilst slow, allowedmore facets to be de/ned at high detail areas, with less being required overall to achieve the samee0ect, hence optimising image generation speed and accuracy.


Fig. 3. De/nition of triangle strip entry convention.

To enable independent animation of the four vertebrae under investigation, separate surface mesheswere generated; the data of which were entered into one /le for parsing by the software developed.Data /le editing was carried out in a proprietary spreadsheet package, assisting batch operationson the data and stored in comma delimited or .CSV format. The comma delimited format can beviewed and edited even in a text editor, and is more simple to parse than an application speci/c /leformat. The mesh data were stored using begin and end statements in a hierarchical manner, easingdata parsing and ensuring 6exibility for future development.

Vertices were measured from every second, third or fourth CT scan taken in the horizontal plane,depending on the accuracy required. To ease interconnection of the vertices, they were selected inprede/ned positions between similar CT images so as to be vertically opposite, allowing e7cienttriangular facet description. To minimise redundant data storage, the lists of vertices and facets weremaintained independently, eradicating multiple de/nitions of the same vertex, but necessitating theuse of vertex reference numbers. For much of the mesh, triangle strip surface de/nitions were used,which further minimise vertex de/nitions. Triangle strips were particularly useful for this applicationdue to the horizontal CT slices. Further 6exibility with triangle strips can be achieved by makingrepetitive de/nitions of the same vertex to change direction.

To allow correct calculation of the average surface normals for use with the Phong re6ectionmodel, it was necessary to enter the mesh facets using a prede/ned directional convention. Thethree points of each triangle for the surface mesh were de/ned in an anticlockwise manner whenviewed from the outside of the vertebra. Triangle strips were also entered using a /xed conven-tion. The direction of reading triangle strip vertices when calculating the surface normal of eachcomponent triangle must be anticlockwise. Following the same convention allows triangle stripsand triangles to be mixed on the same mesh. If we de/ne the triangle strip as continuing to theright and up from the /rst vertex when viewing from the outside of the mesh (Fig. 3), the parsercan be designed accordingly. The anticlockwise convention must be adhered to, although clockwisemesh entry would be equally valid, as long as the same convention was maintained for the wholemesh.

The mesh was de/ned within a right-handed co-ordinate system, commonly used for computergraphics, with the local origin of each vertebra at the centre of the lower vertebral body endplate.The animation information must manipulate each vertebra with reference to this co-ordinate system.The manipulation of data from the CT image dimensions to this co-ordinate frame was made easierwith the use of a spreadsheet package as an editor.

The x-, y- and z-axis follow the planes in which the CT slices were taken and not the horizontalplane of the vertebral body, although the two almost coincide. The x- and z-axis follow the horizontaland vertical directions, respectively, on each CT image as viewed on the screen, the y directionrepresenting the inter-slice distance (Fig. 4). It is essential that the same convention be followed


Fig. 4. Axis de/nitions for the vertebra mesh showing CT cross-section.

when calculating rotation, translation and scaling information for the animation sequence. Additionalspeci/cations for the mesh are discussed as required below.

5. Animation data

Data were measured from the subject’s DVF images to position the mesh in each frame ofthe animation sequence. The required data, as introduced above, is rotation, translation and scalingfor each vertebra. The vertebrae are scaled from pixel dimensions of the CT derived mesh, to pixeldimensions of the DVF images. After scaling to pixel dimensions of the DVF images, it is possible totranslate the mesh of each vertebra in the plane of the DVF images, using dimensions in appropriateunits.

A /le format very similar to that used to store the mesh data is well suited to storing theanimation sequence. The animation sequence is speci/ed as a set of frames, each with a list ofvertebra locations. The nine data requirements for each object in each frame are rotation, translationand scaling in each of the x; y and z orientations. Instead of giving CT to DVF scaling factors inthe data /le, which requires prior knowledge of distances from the mesh, the required dimensionsof each vertebra in DVF units in the x; y and z directions are given. Additional data in the formof mesh vertex numbers, chosen to de/ne the distances along which scaling factors are measured,allows the program to automatically scale the mesh in CT dimensions to DVF units.

Dimensions a and b in Fig. 5 equate to dimensions c and d, respectively. Distances c and d canbe calculated from the mesh since vertex numbers are speci/ed for this task in the animation /le.Dividing a and b by c and d, respectively, gives scaling coe7cients for the mesh in each of thex; y and z directions, which are used to multiply all vertex co-ordinates. Performing this operationassumes that the vertebra mesh entered from the CT data has horizontal, sagittal and coronal planescoincident with the local x-, y- and z-axis. This requirement is approximately met by the CT datawithout introducing signi/cant directional scaling errors.

The vertices to scale must be speci/ed for each vertebra unless they share a common positionon each vertebra mesh, which is the most e7cient solution for this application. Each vertebra meshwas entered using set vertex reference numbers around the top and bottom of the vertebral body;


Fig. 5. Scaling the mesh to DVF units.

the convention is shown in Fig. 6. When measuring translations from the DVF images, the bottomcentre of the vertebral body is de/ned as the local origin, following the same convention as themesh. The vertebra origin is de/ned by vertex 41, Fig. 6. Setting the origin at the centre of thelower vertebral body endplate reduces errors when angles are measured from the DVF images. Usingthe front of the vertebral body as the origin would accentuate errors of rotation angles at the rearof the vertebral body.


Fig. 6. Vertex numbering convention for the vertebra endplate mesh.

Rotation angles must be calculated following the same axis direction conventions as the mesh.Rotation angle measurement on the DVF images can be made to the lower endplate of the vertebralbody, although compensation must be made for vertebra angles in the CT mesh data for correctanimation. The vertebra angles in the CT mesh data do not match up with the co-ordinate systemde/nition. This mismatch requires that the animation angles measured from the DVF horizontal axisis compensated by the small di0erence in angle between the vertebral body and the x–z plane.

The two-dimensional nature of the DVF images allows positioning of the vertebrae during anima-tion in the plane of the DVF image only. It must be assumed that out of plane motion is negligible.Scaling data can only be gained in two dimensions, hence assumptions must be made due to thenecessity of scaling the vertebrae in all three dimensions. The DVF images always contain infor-mation in the y (up) direction, although no information may be available for one of the x or zdirections. If a zero is entered in the animation /le for scaling in the x or z directions, the /leparsing function must use the scaling factor that is supplied for both the x and z directions. Thisis a valid assumption since scaling in the horizontal vertebral plane is likely to maintain the sameaspect ratio between subjects of di0erent size.

The assumption that rotation and translation in the out of image plane(s) is negligible may or maynot hold depending on the orientation of the images and the direction of spinal motion. Movementin the sagittal plane, with images taken from the side of the subject, satis/es the requirements.Movement in the coronal plane causes rotation of the vertebrae about their y-axis, which can bedi7cult to identify on DVF images. Intelligent vertebra location mechanisms used on enhanced DVFimages may allow these restrictions to be overcome in future.

6. Software description

The animation program was developed under the Windows 95=NT platform, making full use ofthe graphical users interface (GUI) available. Although implementing a 3-D graphics engine fromscratch was a viable option, it was considered more e7cient to make use of the OpenGL applicationprogramming interface (API) to perform the basic display functions. Unlike proprietary animationpackages, OpenGL provides a set of routines with which a program communicates to perform 3-Dgraphical output, and is available free of charge as an add-on for 32-bit Windows. OpenGL uses


the Z-Bu0er method with the Phong re6ection model, as described previously. After initialisation,OpenGL accepts the vertex and surface de/nitions, as well as rotation-translation-scaling (RTS)factors, to perform the 3-D–2-D transformation, minimising the amount of coding required. Foranimation, the data must be repetitively transferred to OpenGL, with varying RTS factors, to achievethe required motion.

Since a Windows GUI was required and OpenGL lends itself to development in C, Microsoft’sVisual C++ was chosen as the programming language. Visual C++ is supplied with the Microsoftfoundation classes (MFC) [15] to assist programming windows. Microsoft has encapsulated mostWindows functions in the MFC, making it much quicker and easier to create and customise a basicapplication. In this respect the MFC act as a Windows abstraction layer, separating the program-mer from programming Windows directly. The availability of an Application Wizard further assistsdevelopment of the application.

Code written using Visual C++ and the MFC parses mesh and animation data from /les anddisplays it by calling the appropriate OpenGL graphical output routines. The /rst requirement wasto create a Windows interface through which OpenGL could draw. A multiple document interface(MDI) program was chosen since more than one window may be open at a time, in this caseallowing several animations to be viewed simultaneously, assisting segmental motion comparisons.

Each window in the MDI has two view elements separated by a resizing splitter bar. The left-handview is used as an object linking and embedding (OLE) container, in which it will be possible torun any OLE server application. OLE is a standard Windows component that allows the viewing ofdata loaded within a third party server application, in a container, which in this case is the spineanimation program. The principal use of the container view is for easy editing of input data /leswithin a spreadsheet application. The right-hand view shows the animation output from OpenGL. Thisview’s implementation class is subdivided into two sets of functions. The /rst set of functions load,parse and pre-process the mesh and animation data into storage structures in memory. The secondclassi/cation of function traverses the data structures for each screen update, sending informationto OpenGL for rendering and printing to the screen. Additional support functions are required tocomplete essential tasks within the Windows environment, as well as initialising OpenGL and takinginput from the user through menus, toolbars, the mouse and the keyboard.

7. Memory storage structures

It was essential that the storage methods used within the program were appropriate to the datastored and the type of access required. The mesh data /le has a vertices section and triangle=trianglestrip sections. The vertex section is subdivided into independent objects, each object representingone vertebra. The exact numbering of vertebrae and their related vertices indicated that an orderedarray storage method was most appropriate, especially since random access to any of the objects andattached vertices was required when reading data from the structures. Consideration was given to thehierarchical nature of the object-vertex data when designing a storage structure. Each vertebra hasa unique set of vertices, deeming 6at storage structures unsuitable. It was more e7cient to utilise ahierarchical system of MFC dynamic arrays and data objects as shown in Fig. 7.

Triangle and triangle strip data does not need to be accessed randomly and requires no ordering.Although the use of hierarchical data structures implemented with dynamic arrays was viable, linked


Fig. 7. Mesh vertex data structure.

Fig. 8. Animation frames data storage structure.

lists o0ered an easier alternative. Data are only read from the lists when they are traversed to sendall the facets to OpenGL, suggesting that linked lists are a suitable storage method. The triangleand triangle strip data can be stored in any order, since order of rendering is unimportant. The dataobjects used in the list require member variables for object and vertex number storage.

Two separate linked lists are used, one for triangles (polygons), the other for triangle strips, thedata objects used in each varying by the number of vertices they have to store. Triangles have a/xed number of vertices (three), enabling /xed array storage of the vertex numbers. Triangle stripshave a variable number of vertices with no natural upper limit on their length. Fixed array storageof triangle strip vertex reference numbers would impose an upper limit on the length. If dynamicarrays are used the limit is removed. As a result, each data object for triangle strips has an attachedMFC dynamic array object, a pointer data member in the triangle strip object storing the array’sposition.

The animation data must also be stored in an appropriate data structure for e7cient access whendrawing the scene. Data structures similar to those used to store the vertices for the mesh werefavoured (Fig. 8). The animation data consist of a series of frames, each of which contains a listof positions for each of the objects in the scene. Using a hierarchical data structure with the parentarray representing frame numbers, pointing to child arrays holding animation object locations foreach frame, data can be extracted with ease.

The animation data objects used within the structure require nine member variables to store scaling,rotation and translation information in all three dimensions.


Fig. 9. The two-stage positioning process for (1) user input and (2) animation.

8. Drawing to the screen using OpenGL

Data stored within the structures created when the mesh /le was loaded must be traversed to sendthe appropriate information to OpenGL. The frame position within any animation that is loaded mustbe considered, with appropriate placement of the vertebrae in the scene calculated each time meshdata is sent to OpenGL.

To position the individual vertebrae, rotation, translation and scaling (RTS) operations are required.The OpenGL system of RTS is implemented by pushing and popping position matrices using a stack.This permits hierarchical positioning relative to the initial camera model. Before each vertebra isdrawn, the current matrix is pushed onto the stack and appropriate vertebra RTS information is sentto OpenGL. As each vertebra is drawn, the matrix can be popped o0 the stack to restore the originaldrawing position.

Two levels of RTS operations are required to create a fully interactive viewer. The /rst is aglobal position the user can change to view the spine from any direction and orientation. At thesecond level, each vertebra is positioned within the co-ordinate system described by the user-inputposition, according to the animation data. The positioning process is shown in hierarchical form inFig. 9.

The animation data are assembled from a sequence of digital video 6uoroscopic (DVF) imagesfrom which the position data are measured. If each of the frames is shown one after the other,the quality of motion will be poor and the diagnostic power of the program will be limited. Toimprove quality some interpolation is required to smooth the motion. Interpolation can be achievedby a simple linear process or by curve /tting the data. Curve /tting using a /rst-order continuousB-spline connected through the animation data is likely to be more representative, but due to the


Fig. 10. The overall design of the main drawing function.

small amount of motion between successive frames, very little accuracy is lost using the linearmodel.

As well as the position operations carried out when each frame is drawn, the mesh data must besent to OpenGL. At present, the program supports two types of mesh data, triangles and trianglestrips. Each of these types of mesh data must be dealt with individually in the program, althoughthe same RTS operations are carried out in both cases. Fig. 10 shows the overall functional structureof the main drawing function and this entire process is called each time the user alters their view


Fig. 11. Pitch and yaw de/nitions in the Cartesian view system.

position or there is a change in animation frame number. This requires that the code is optimisedto achieve high frame rates. Error checking, which is an important part of the program, is carriedout whilst the data are read from the /le and parsed into storage structures, thus avoiding checkingoverheads in the main drawing routine.

9. Position control

The concept of two levels of position control was introduced above, where the /rst level is usedto specify the viewpoint and the second to control animation. The global movement allows the userto view the spine from any direction whilst animation is in progress, enhancing the diagnostic powerof the program. To implement the user control of position it is necessary to rotate and=or translateall objects drawn within the scene according to input commands taken from the keyboard, usingpredominantly the direction keys, the mouse, and the buttons on a toolbar.

The order in which rotation and translation is carried out is key to the process of producingrealistic 3-D movement. For a full view system, the user should be able to move forward regardlessof the direction in which they are pointing, and should always rotate naturally. To achieve this, aspherical polar view system was required. The spherical polar system uses two angles, horizontaland vertical, and a distance to represent a point in space (Fig. 11). The initial view direction looksalong the positive z-axis, which remains unaltered throughout the entire process. For user input(and animation), the whole scene must be rotated and translated about the global origin to imitatemotion, hence for clockwise rotation, the scene and all objects in it must be rotated anticlockwise.For horizontal and vertical rotation, the scene must be rotated about the y- and x-axis, respectively,in the opposite direction to that required.

The actions of horizontal and vertical rotation in the spherical polar system are referred to as yawand pitch, respectively, in the Cartesian system. Roll, rotation about the z-axis, was not implemented


Fig. 12. Translation elements for forward motion in a de/ned view direction.

to keep the viewing system simple. Rotations must be ordered as pitch (x-axis) /rst then yaw(y-axis) to allow rotation around the x-axis to represent pitch.

When motion within space is required, the yaw and pitch angles must be considered for movementin the expected direction (Fig. 12). The scene must be translated in the opposite direction to thatexpected, using a spherical polar system with the yaw and pitch angles as the horizontal and verticalangles, respectively, to calculate the x; y and z components.

The complete view system operates by translating the co-ordinate system to the new origin thenrotating according to the yaw and pitch angles required. The position of the user at any time mustbe a function of the previous position, hence /ve variables are used to store the yaw, pitch andposition in the x; y and z directions. The position variables are incremented or decremented asrequired.

10. The animated model display

The quality and realism of the animation were essential to maximise the diagnostic power ofthe program. The realism of the scene is assured by smooth rendering and imitation lighting,giving a good perception of depth. The speed of animation is adequate on Pentium class ma-chines, although a P133 or faster gives the best results, especially with high screen resolutions. Ananimation sequence is depicted in Fig. 13, which shows sagittal motion of lumbar vertebraeL2–L5. L1 was not featured on the digital video 6uoroscopy (DVF) image set used for thiswork due to the size of image intensi/er used, but could be included when a larger system isavailable.

The animation program must provide an accurate representation of the in vivo spine to be of useto a clinician. CT images from the Visible Human data set are of a high quality, although the DVF


Fig. 13. Four frames from an animation sequence of the lumbar spine model.

Fig. 14. (a) Lateral image from sequence of sagittal 6exion–extension. (b) Lateral image with automatically generatedlandmarks highlighted on vertebrae L2–L4.

images have poor de/nition and are susceptible to random variations in quality [16]. Considerablee0ort has, however, been directed towards obtaining accurate anatomical landmarks from the DVFimages and the use of template matching and cross correlation techniques can provide an automatedmethod of identi/cation [17].

Fig. 14(a) shows one image from a lateral image sequence of sagittal 6exion–extension and Fig.14(b) includes landmarks which have been automatically generated using a cross correlation methodbased upon template matching [17,18]. Since the vertebral corners are not well de/ned, a so-called/rst pixel algorithm has been developed to improve the repeatability throughout an image sequence[19].

Kinematic analysis [20] is based upon the sequence of landmarks that are used to de/ne theanimation sequence for the solid model for visualisation of the vertebral motion.


11. Further work

The current surface mesh is derived from the male images of the Visible Human data set.A similar mesh could be developed from the female image set. Future development of the methodcould completely automate the process from digital video 6uoroscopy (DVF) image to animation.The process is partially automated using an image viewer developed for entering mesh and anima-tion data. Work is in progress to automatically detect the positions of vertebrae in DVF images[17–19] and in particular to automate the initial de/nition of the vertebral templates upon whichcorrelation-based landmark identi/cation is based.

The two-dimensional nature of the DVF image sets makes estimation of out of plane rotation ofthe vertebrae impossible without intelligent shape /tting. This limits use of the process to spinalactivity that exhibits planar motion. Motion in the coronal plane causes the vertebrae to rotate inthe horizontal plane. With automatic image detection, shape /tting of the vertebrae may be ableto detect rotation, although it is likely that better image de/nition will be required. Eventually,three-dimensional kinematic analysis will be possible when functional, three-dimensional, open-accessimaging is su7ciently well developed for spine motion studies. For the present, a combination ofprojection techniques with the solid model could form the basis of estimating coupled motion.

The animation is currently limited to four lumbar vertebrae due to the scope of the current DVF im-ages. This could be readily extended to accommodate images from 6uoroscopes with larger image in-tensi/ers. It may also be possible to integrate the motion data with a /nite element model of the inter-vertebral discs in order to gain an indication of the stresses within the disc and areas of likely damage.

12. Conclusion

A fully functional, three-dimensional spine animation package has been developed, for use on theWindows 95 (and above) and NT 32-bit platforms. The spine animation is personalised for eachpatient, using kinematic data derived from DVF images taken during spinal motion. This has thepotential to assist clinicians in diagnosing abnormal vertebral motion, which may be symptomaticof back pain in the lumbar region, and provides a useful adjunct to the normal methods of clinicaldiagnosis based upon non-invasive surface methods and detailed static images. The animation packagehas an intuitive user interface, with additional features for e7cient operation and data manipulation.

The software is currently under assessment in a study of 30 volunteer subjects and the e0ectivenessof three-dimensional, solid-model image presentation in locating and visualising abnormal motion isbeing investigated. The model could also have potential in combination with FEA to investigate thee0ects of loading on the vertebral segments, typically for model-based assessment of the e0ects ofspinal fusion. Further applications are envisaged in medical education and in demonstrating spinemotion to patients to highlight abnormalities or the e0ects of treatment and, indeed, for visualisingnormal spine motion for the volunteer subjects in the current study.

Acknowledgements

The authors are very grateful to Mike Kondracki, Dr. Jen Muggleton and Dr. Alan Breen forproviding the DVF image sequences from which the spine motion data is determined. The sequences


were captured as part of a study of normal spine motion carried out at the Duke of Cornwall SpinalInjuries Unit; Salisbury Hospital which was kindly supported by Smith’s Charity whose support iswarmly acknowledged. Permission to use CT images of the lumbar spine from the Visible HumanProject is also gratefully acknowledged.

References

[1] M.H. Pope, J.E. Novotny, Spinal biomechanics, Trans. ASME: J. Biomech. Eng. 115 (1993) 569–574.[2] I. Portek, M.J. Pearcy, G.P. Reader, G.P. Mowat, Correlation between radiographic and clinical measurement of

lumbar spine movement, Br. J. Rheumatol. 22 (1983) 197–205.[3] M. Monheit, N.I. Badler, A kinematic model of the human spine and torso, IEEE Comput. Graph. Appl. 1 (1991)

29–37.[4] A.G. Patwardhan, A.H. Soni, J.A. Sullivan, M.R. Gudavalli, V. Srinvasan, Kinematic analysis and simulation of

vertebral motion under static load. Part II: simulation study, J. Biomech. Eng. 104 (1982) 112–118.[5] N. Yoganandan, S. Kumarasan, L. Voo, F. Pintar, A /nite element model of the human lower cervical spine:

parametric analysis of the C4–C6 unit, J. Biomech. Eng. 119 (1997) 87–92.[6] A.C. Breen, R. Allen, A. Morris, An image processing method for spine kinematics—preliminary studies, Clin.

Biomech. 3 (1988) 5–10.[7] A.C. Breen, R. Allen, A. Morris, A digital video6uoroscopic technique for spine kinematics, J. Med. Eng. Technol.

13 (1989) 109–113.[8] A.C. Breen, R. Allen, A. Morris, Spine kinematics: a digital video6uoroscopic technique, J. Biomed. Eng. 11 (1989)

224–228.[9] J. Cholewicki, S. McGill, R. Wells, H. Vernon, Method for measuring vertebral kinematics from video6uoroscopy,

Clin. Biomech. 6 (1991) 73–78.[10] A. Okawa, K. Shinomiya, H. Komori, T. Muneta, Y. Arai, O. Nakai, Dynamic motion study of the whole lumbar

spine by video6uoroscopy, Spine 23 (16) (1998) 1743–1749.[11] Visible Human Data http:==www.nlm,nih.gov=[12] E. Angel, Interactive Computer Graphics: A Top-Down Approach with OpenGL, Addison-Wesley, Reading, MA,

USA, 1997.[13] A. Watt, Fundamentals of Three-Dimensional Computer Graphics, Addison-Wesley, Reading, MA, USA, 1990.[14] W.E. Lorensen, H.E. Clive, Marching cubes: a high-resolution 3-D surface reconstruction, Comput. Graph. 30 (1987)

163–169.[15] C. Walnum, P. Robichaux, Using MFC and ATL, Que, USA, 1997.[16] P. Bifulco, Analysis of intervertebral kinematics using 6uoroscopic images sequences, Ph.D. Thesis, University of

Naples ‘Federico II’, Italy, 1998.[17] J.M. Muggleton, R. Allen, Automatic location of vertebrae in digitised video6uoroscopic images of the lumbar spine,

Med. Eng. Phys. 19 (1997) 77–89.[18] P. Bifulco, M. Cesarelli, M. Sansone, R. Allen, M. Bracale, Fluoroscopic analysis of intervertebral lumbar motion: a

rigid model /tting technique, Proceedings of World Congress on Medical Physics & Biomedical Engineering, Nice,France, 14–19 September 1997, Abstract published in Med. Biol. Eng. Comput. 35 (Suppl. Part 2) (1997) 714.

[19] C. Cardan, R. Allen, Tracking the movement of vertebrae for diagnosis of mechanical problems of the spine,Proceedings of 4th Annual National Conference of the IPEM, Brighton, 15–17 September 1998, p. 27.

[20] J.M. Muggleton, R. Allen, Insights into the measurement of vertebral translation in the sagittal plane, Med. Eng.Phys. 20 (1998) 21–32.

Richard Cooper graduated in 1998 in Mechanical Engineering from the University of Southampton, England. He is now software specialistat Logica, Cambridge.


Cosmin Cardan graduated in Romania in Mechanical Engineering and was recently awarded the degree of Ph.D. at the Institute of Sound& Vibration Research, University of Southampton for his research into automated analysis of digital video6uoroscopic images of thelumbar spine.

Robert Allen is Professor of Biodynamics & Control, ISVR, University of Southampton specializing in biomedical signal and imageprocessing. Particular areas of interest are spine kinematic analysis, cerebal circulation modelling and assessment of consciousness forcontrol of anaesthesia. He is a Fellow of the IMechE, IEE and IPEM and a member of the IEEE.

computer visualisation of the moving human lumbar spine

Documents