Golf-Swing Analysis Tool (G-SAT)

James Clark

Computing2005/2006

The candidate confirms that the work submitted is their own and the appropriate credit has been given

where reference has been made to the work of others.

I understand that failure to attribute material which is obtained from another source may be considered

as plagiarism.

(Signature of student)

Summary

This project aims to develop a piece of software that can be used for golf swing analysis. The golf

swing is a very technical action and many teaching professionals now use video cameras to assist them

in fault diagnosis. The software developed in this project is designed to assist the professional further

by providing a range of video analysis tools.

The project aims to distinguish itself from existing commercial solutions with the implementation of a

’Video Overlay Tool’; which allows one golf swing to be superimposed on top of another so that a direct

comparison between the two swings can be made.

The software was evaluated by two members of the Professional Golfers Association, the results of

which can be found in the Evaluation section.

i

Acknowledgements

I would like to thank my project supervisors Ken Brodlie and Chris Needham for their advice and help

throughout. I also wish to thank my project assessor, Roy Ruddle, for the helpful comments and feed-

back he gave during the final progress meeting.

Special thanks also to PGA Professionals Frank Houlgate and Michael Harrington for evaluating the

software.

ii

Contents

1 Project Overview 1

1.1 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Minimum Requirements and Deliverables . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 3

2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 The Golf Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 The Components of a Good Golf Swing . . . . . . . . . . . . . . . . . . . . . 4

2.2.2 Speeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.3 Margins For Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 The Use of Video in Golf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.1 The Limitations of Using a Video Camera in Swing Analysis . . . . . . . . . . 6

2.4 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Evaluation of Existing Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.1 C-Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.1.1 Strengths of cSwing . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5.1.2 Weaknesses of cSwing . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5.2 V1 Golf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.2.1 Strengths of V1 Golf . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.2.2 Weaknesses of V1 Golf . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.3 Summary of Existing Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 15

iii

2.6 Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6.2 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6.3 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.7 Development Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7.1 The Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7.1.1 Advantages of the Waterfall Model . . . . . . . . . . . . . . . . . . 18

2.7.1.2 Disadvantages of the Waterfall Model . . . . . . . . . . . . . . . . 19

2.7.2 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.7.2.1 Advantages of Prototyping . . . . . . . . . . . . . . . . . . . . . . 20

2.7.2.2 Disadvantages of Prototyping . . . . . . . . . . . . . . . . . . . . . 20

2.7.3 Incremental Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.7.4 Choice and Justification of Methodology . . . . . . . . . . . . . . . . . . . . 21

3 Analysis 24

3.1 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.1 Basic Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.1.1 Acquire video from an external device . . . . . . . . . . . . . . . . 24

3.1.1.2 Load multiple golf-swings . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1.3 Playback swings at a range of speeds . . . . . . . . . . . . . . . . . 25

3.1.1.4 Draw on/annotate recorded swings . . . . . . . . . . . . . . . . . . 25

3.1.2 Advanced Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.2.1 Crop Recorded Swings . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.2.2 Mirror swings to make the golfer appear ’opposite-handed’ . . . . . 27

3.1.2.3 Superimpose one swing over another . . . . . . . . . . . . . . . . . 27

4 Development of the Solution 28

4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Component: Video Acquisition Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.1 First Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3 Component: Video Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.1 First Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

iv

4.3.1.1 Loading video files . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.1.2 Displaying the swing(s) . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.1.3 Controlling video playback . . . . . . . . . . . . . . . . . . . . . . 32

4.3.1.4 Unloading a swing . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.2 Second Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.3 Final Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.4 Component: Playback at various speeds . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4.1 First Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4.1.1 Playback at full speed . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4.1.2 Playback at half and quarter speeds . . . . . . . . . . . . . . . . . . 38

4.4.2 Second Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5 Component: Drawing Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5.1 First Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.6 Component: Video Cropping Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.6.1 First Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.6.2 Second Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.7 Component: Mirror Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.8 Component: Video Overlay Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.8.1 First Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.8.2 Second Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.8.3 Third Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Evaluation 44

5.1 Evaluation Against Minimum Requirements . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 Evaluation of G-SAT by Teaching Professionals . . . . . . . . . . . . . . . . . . . . . 46

5.2.1 Observations made during evaluation . . . . . . . . . . . . . . . . . . . . . . 46

5.2.2 Feedback from Teaching Professionals . . . . . . . . . . . . . . . . . . . . . 48

5.2.2.1 Benefits of using the software . . . . . . . . . . . . . . . . . . . . . 48

5.2.2.2 Usability of the software . . . . . . . . . . . . . . . . . . . . . . . 49

5.2.2.3 Evaluation of overlay tool . . . . . . . . . . . . . . . . . . . . . . . 49

5.2.2.4 Evaluation of other features in the software . . . . . . . . . . . . . . 50

v

5.2.2.5 Features they would like to see included . . . . . . . . . . . . . . . 51

5.2.2.6 Summary and conclusions of evaluation feedback . . . . . . . . . . 51

5.3 Future Project Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.3.1 General Improvements to the Software . . . . . . . . . . . . . . . . . . . . . 52

5.3.2 Improvements to the Video Overlay Tool . . . . . . . . . . . . . . . . . . . . 53

5.3.3 Frame deinterlacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.3.4 Implementation of an ’Auto-Crop’ Feature . . . . . . . . . . . . . . . . . . . 55

5.3.5 Use of software in other sports . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.4 Evaluation of Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Bibliography 57

A Personal Reflection 59

B Project Schedule 61

C Glossary of Golf Terminology Used in Report 62

D Questions Asked During Evaluation Interviews 63

vi

Chapter 1

Project Overview

1.1 Aim

The aim of this project is to produce a piece of software that can be used to analyse golf swings recorded

on video. This software could be used by a teaching professional to provide him and his his client with

visual information that will facilitate the analysis and comparison of golf swings.

1.2 Motivation

My motivation for undertaking this as my final year project came from the fact that I am myself, an avid

golfer and have spent many an hour on the practice-ground trying to improve my swing. I have also

worked at Sand Moor Golf Club in Leeds, teaching junior group golf lessons.

This project seemed like the ideal way to fuse two of my main interests; golf and computing (particularly

software development). I anticipated that not only would I enjoy working on such a project, but also

that I would (hopefully) be left with a piece of software which I could use to assist me in my practice.

Furthermore, I aimed to produce something which my local golf professional and, hopefully many

others, would wish to use in their lessons; this provided me with the motivation to complete the work to

my highest standards.

1

1.3 Minimum Requirements and Deliverables

The following minimum requirements must be met in order for the project to be considered a success:

• (Deliverable) Produce a system for analysing golf swings with the following features:

– The system will allow the user to connect to an external device (such as a video camera) and

acquire video from it.

– The system will allow the user to load and play several swings simultaneously.

– The system will allow the user to synchronise loaded swings.

– The system will allow the user to draw (e.g. lines, dots, circles etc.) on top of swings.

– The system will have a friendly user-interface so that relatively little computer literacy will

be required to operate it.

• (Deliverable) The results of an evaluation by (a) qualified PGA Professional(s).

Possible extensions for the project are:

• Implementation of a feature in the system which allows one golf swing to be ’superimposed’ on

top of another. This would be very useful in highlighting key differences/similarities between the

two swings.

1.4 Schedule

A project schedule was submitted in December as part of my Mid-Project Report. This schedule (which

can be found in the form of a Gannt Chart in Appendix B) was, for the most part, followed accurately.

However, for reasons discussed in the Evaluation section, there were occasions when my progress fell

out of sync with the schedule. Fortunately, the flexibility of the schedule, my development methodology

and the fact that many of the initial phases of the project had been completed ahead of schedule, meant

that these discrepancies did not negatively affect the success of the project.

2

Chapter 2

Background

2.1 Overview

This chapter discusses the background to the problem being solved, beginning with the technical nature

of golf before moving on to the problems faced by teaching professionals and and evaluation of existing

attempts at solving these problems. Finally, we explore the choice of development tools methodologies.

2.2 The Golf Swing

Golf is a very technical sport1. The mechanics of a player’s action (known has his ’swing’) are funda-

mental to hitting good golf shots. From the moment a new player takes up the game, a huge emphasis is

placed on learning the correct technique; starting with sound fundamentals. This is due to the fact that

it is almost impossible to hit consistently good golf shots with a poor technique. Literally hundreds of

books have been written specifically on the golf swing, containing different and often conflicting theo-

ries. It is unequivocally agreed however, that the golf swing is a complex mechanical action consisting

of many individual moving parts, and utilising all of the larger muscle groups.

1A glossary of golfing terminology can be found in Appendix C

3

2.2.1 The Components of a Good Golf Swing

Ultimately, the purpose of the golf swing is to hit the golf ball as far as possible2 toward the player’s

target. To achieve this, the swing must:

• drive the club face straight through the ball towards

• make the club face aim square towards the player’s target

• swing the club head through impact as fast as he can manage to while still achieving both of the

first two prerequisites

• return the middle of the club face (known as the sweet-spot) to the middle of the ball

2.2.2 Speeds

A typical golf swing lasts between 1 and 1.5 seconds. During the downswing, which lasts for roughly

one fifth of the total swing time, a golfer may accelerate his club head about one hundred times as fast

as the fastest sports car3 can accelerate: from rest at the top of the backswing, to 100 miles per hour at

impact, all in as little as one-fifth of a second.[13] At these speeds, it is practically impossible for the

golfer to correct any part of the swing whilst he his actually making it. As Cochran et. Al state:

At the moment of impact, the club head might just as well be connected to the player’s

hands by a number of strings holding it to the rough circle of it’s orbit, for all the effect he

can have on it.[13]

2.2.3 Margins For Error

When we consider that a club face misalignment of just 2.5◦ at impact is enough to send a 200 yard

shot, 25 yards off-line; consistently returning the club squarely to the ball at these speeds is extremely

difficult. It is this that makes golf such a difficult and, often frustrating game and therefore it is crucially

important that a golfer grooves his swing so that it can repeat itself on a consistent basis.

2This is only true for shots played from the tee. Approach shots played into the green require precise distance control.

3It should be noted that the book from which this fact has been referenced was written in 1968 and therefore, will not hold

quite as true with modern sports cars.

4

2.3 The Use of Video in Golf

Since the golf swing lasts for such a short time (see 2.2.2), it is extremely difficult to identify faults

’by eye’; particularly in the downswing, where the club can travel at up to 130mph. This is even more

prevelant with better players, as their faults tend to be far more subtle and therefore harder to spot.

The pioneer of the technical approach to golf was Ben Hogan, who not only recognised the huge impor-

tance of swing mechanics but also the use of cameras in swing analysis. Being a successful player in

the 1950’s and 1960’s, when video cameras were not the household commodity they are today, Hogan

relied mainly on the use of still photographs, taken whilst he was practicing (Fig. 2.1). Using these

photographs, Hogan was able to diagnose the faults in his swing that he had previously been unaware

of and, as a result, build one the finest swings ever seen in professional golf.

Figure 2.1: An example of the still photographs used by Ben Hogan for swing analysis

With the birth of the camcorder in 1983 [16], some teaching professionals4 began to use recorded video

in their lessons to assist them with fault detection and correction. It was not until the mid 1990’s, as

camcorder prices fell and shutter speeds increased, that the use of video in golf lessons became common

practice.

By having the ability to record and then slow down the swing to a fraction of it’s full speed, it became

possible to identify swing faults that would have been undetectable to the naked eye. In an article written

4Teaching professionals (such as Leadbetter and Harmon) differ from playing professionals (such as Hogan and Faldo) in

that they teach how to play golf rather than actually playing it for a living. Most playing professionals are not actually qualified

to teach golf.

5

by Mark Harman, the Course Director of the United States Golf Teachers Federation, he states:

Video is an indispensable tool in monitoring the golf swing...If youre not using video, Ill be

honest and tell you it may be very hard to spot a flaw without it, especially if you dont have

much experience working with better players. [8]

Until the introduction of video analysis, relatively little was known about the mechanics of the

downswing - particularly the impact position (where the club is travelling at it’s fastest), which had

remained somewhat of a mystery. As a result, professionals were able to give ’better’ golf lessons; the

professional was able to not only explain to the client what was going wrong with his swing, but also

show him exactly where the faults were occurring. This in itself was enormously beneficial to the client,

as most people learn best visually.

Since the time that golfers first started to use video cameras for swing analysis, the quality of the

swings on the professional circuit (and thus professional golf in general) have increased dramatically -

opitimised by players such as Tiger Woods.

2.3.1 The Limitations of Using a Video Camera in Swing Analysis

Whilst the advantages of employing a video camera for golf swing analysis are clear, there a certain

problems which arise from their use:

• Time is wasted rewinding/fast-forwarding to the desired position

A problem with using video cameras is that once the professional has recorded his client’s swing

(usually from different angles; face-on and side-on), time is often wasted rewinding and/or fast-

forwarding to the start of the swing. The video cassette mechanism even on modern video cameras

does not react instantly to commands such as pause, rewind, fast-forward. As a result, it can take

some ’fiddling around’ before the professional manages to get the tape to the correct position at

the start of the swing. This is far from ideal, especially when one considers that the professional

could be charging the equivalent of £1 per minute for his time!

• Cannot display more than one swing at a time

It would be very useful to be able to display two (or more) swings side-by-side so that they

can be easily compared and contrasted. For example it would be beneficial to the client for the

professional to show him his swing and a swing taken in the previous lesson. This would allow

6

both the client and professional to see how the client’s swing has improved (or worsened) since the

previous lesson. Similarly, it would be helpful for the client to see his swing alongside the swing

of a world-class player such as Tiger Woods. This allows the client to see his faults more clearly,

reinforcing the professional’s diagnosis. For example, the professional could say something along

the lines of:

”Look how Tiger is tipped over at the waist whereas you’re stood in a far taller position; which

is why your swing is a lot flatter than Tiger’s.”

This sort of feedback is very useful to someone having a lesson, especially as many golfers aspire

to swing to the club in a similar fashion to particular playing professional. Unfortunately, no

video camera provides this sort of functionality. Only one clip can be played at a time.

• Small screen on which to show the client his/her swing

Another limitation with using video cameras is that the display device on which to playback the

recorded video tends to be very small. The standard for modern video cameras is to use an LCD

screen (typically no larger than 2.5 inches) attached to the side of the video camera. This can make

it very difficult for the professional to show, and the client to see, what the fault is, and where it

is occurring (Fig. 2.2). Some professionals attempt to overcome this problem by attaching the

camcorder to a television and displaying the recorded video through that instead. This is not

possible for most professionals however, as it is impractical to bring a television onto the practice

ground with them.

Figure 2.2: The professional (left) playing back his client’s swing recorded on video. Notice the small

LCD screen on which the video is being displayed.

• Cannot draw onto the LCD display of a camera

7

It can be very useful to draw ’on top’ of a recorded swing as a way of highlighting faults or

illustrating a technical explanation. For example, dots may be drawn onto the swing as points of

reference to highlight excessive or unwanted body movement. This is also common in football

commentary, where pundits use arrows and markers drawn onto the recorded footage to highlight

important points in the game.

The few professionals who use a television in their lessons (see previous point), are able to draw

on top of television in non-permanent marker pen. It is not possible to do this however, with the

LCD display devices attached to modern video cameras. Even if it were, the LCS screens are too

small to be able to accurately draw anything of real significance. Instead, the professional may

use a golf club held out in front of him (like an artist using a pencil as a guide) or an object in

the distance as a reference point, whilst the client is actually hitting shots (Fig. 2.3). This has the

obvious drawbacks of being far less accurate and only useful to the professional holding the club,

not the client.

Figure 2.3: The professional (right) using a golf club held in front of him as a reference point whilst his

client (left) hits shots.

• Cannot show ’how Tiger does it’

Often, clients wish to see how the top playing professionals swing the club and take pointers from

them. Similarly, professionals often find it useful to show their client how a playing professional

(usually of similar height and build) swings the club so that they can get a visual idea of what

the professional would like them to practice. Obviously, most teaching professionals do not have

world-class players recorded on their video cameras and therefore showing their client how Tiger

Woods or Nick Faldo swing the club can be difficult. It is not uncommon for teaching profes-

8

sionals to record swings from the television onto their video cameras. Clearly, the quality of the

recordings are usually very limited and one is faced with the same problems mentioned in the first

point; finding the recorded swing on the video tape can be difficult and it would be very easy to

accidentally record over the swing.

2.4 Proposed Solution

The purpose of this project is to develop a piece of swing analysis software which:

1. Provides a computerised solution the problems stated above.

2. Improves, where feasible, on existing commercial solutions.

The software will be given the name G-SAT (Golf-Swing Analysis Tool).

2.5 Evaluation of Existing Solutions

There are several pieces of commercially available software that provide a computerised solution to the

problems listed above (see 2.3.1). As part of my research for this project, I obtained trial versions5 for

a couple of the most popular of these and evaluated them using swings recorded by myself on a Sony

MiniDV Handycam Camcorder.

2.5.1 C-Swing

The most popular of the existing commercial solutions is cSwing c©, which according to the product

website is:

...an advanced video swing analysis program for avid golfers and golf professionals. It

captures video from your camcorder or web cam to your PC. You can easily analyze your

swing with its powerful drawing and comparison tools. Seeing your swing alongside pro

swings provides immediate visual feedback that will result in lower scores.[1]

5The trial versions for the commercial software that I evaluated were fully-featured but had limited licenses which expired

after a certain length of time

9

2.5.1.1 Strengths of cSwing

• Ability to deinterlace frames of video captured from a DV camcorder

Interlacing is essentially a compression method used by camcorders to reduce the amount of

storage space required for a video recording. A typical camcorder will record 50 frames (or

fields) per second and intermix every 2 consecutive fields into one frame, reducing the required

storage space (bandwidth) by half. So a single interlaced frame actually consists of two captures

of two different moments in time.[12]

The effects of interlacing are almost undetectable to the naked eye when playing back video at full

speed but when the playback speed is reduced or the video is paused, as would be the case with

video analysis, interlaced lines can be clearly seen (Fig. 2.4). This distorts the frame, making it

difficult to see what is actually happening. For example, an interlaced frame of a golf swing may

appear to contain two golf clubs.

(a) Original interlaced frame (b) Same frame after deinterlacing

Figure 2.4: The effects of interlacing

cSwing will automatically deinterlace interlaced video so that the individual frames comprising a

swing will be clearer. This is particularly useful when analysing the impact area of the golf swing

where the club is travelling at it’s fastest and the effects of interlacing are most intrusive.

• Ability to load up to four swings at a time

cSwing allows you to have as many as four swings loaded and displayed simultaneously. Whilst

this requires a rather powerful computer for smooth simultaneous playback, it is a very useful

feature as many swing comparisons can be made at the same time; for example, between 4 swings

of the same client from various lessons or between the client and 3 top-class playing professionals.

10

• Excellent range of drawing tools

A particularly strong point in cSwing is the wide array of drawing tools that can be used to

annotate and illustrate loaded videos. As well as the basic tools such as straight lines and ellipses,

cSwing also provides some more advanced tools such as curves, triangles and a ’clock face’ tool.

Teaching professionals often refer to positions in the golf swing by the relative position of the

hands on a clock face. For examples, the golfer in Fig. 2.5 is between 10 and 11 o’clock as this

is the position of his hands relative to a clock face. Using a clock face drawing tool like this is an

effective way of explaining to a client where in the swing a fault is occurring.

Figure 2.5: A screenshot from cSwing with a clock face drawn on the golfer

• Ability to calculate angles in the swing

When analysing a golf swing, a teaching professional will look at the angle of certain body parts

at particular points in the swing. For example, at the top of the backswing, the player’s shoulders

should have rotated 90◦ and the hips less than 40◦. The differential between the hip and shoulder

turn, which has been labelled by some professionals as the ’x-factor’, is key to generating power

and in turn being able to hit the golf ball large distances. The greater the differential i.e. the

more a player can turn his shoulders without turning his hips, the greater the power generated.[9]

Another important angle in the golf swing is that created by the spine and shoulder plane, which

should be at a perpendicular, 90◦ angle at the top of the player’s backswing[3]. It is therefore

useful to be able to measure such angles and cSwing provides the facility for this. cSwing will

calculate and display the angle between user-drawn lines, as well as displaying the internal angles

11

of a user-drawn triangle. This provides the user with an exact angle measurement - far more

accurate than the traditional estimate that a teaching professional will make by eye.

2.5.1.2 Weaknesses of cSwing

• Outdated looking and unintuitive user-interface

I found the user-interface for cSwing to be rather cluttered and unintuitive. The main GUI for

cSwing contains an overwhelming number of buttons, none of which have tooltip captions to

explain the function of the button when the user hovers the mouse over it. Many of the button

icons are irrelevant to the button’s actual function and I the general colour scheme of the interface

to be garish (Fig. 2.6). The interface also looks outdated, making use of early MFC components.

My observations regarding the cSwing software were confirmed when I spoke with Mark Pinkett,

Head Teaching Professional at Cookridge Hall Golf Club in Leeds. I was aware that Mark used

cSwing in his lessons and thought it would be a good idea to ask him about his thoughts on the

software. Mark told me that whilst he found cSwing to be a valuable to aid in his teaching, he

uses only a small portion of the features and was actually unsure about the purpose of some of

the GUI buttons. Mark also told me that the swings would skip frames if two or more were being

played simultaneously, and he thought the reason for this was his laptop being dated.

Figure 2.6: The main cSwing toolbar

• No facility for cropping loaded video(s)

Much to my surprise, I found that cSwing does not provide any method of cropping video files to

remove unwanted frames. When a teaching professional is recording his client on video, he will

usually begin recording a few seconds before the client begins his swing and will finish recording

a few seconds after the client has completed it. This is to ensure that the entire swing is captured,

as there is often a short delay between pressing the ’Record’ button and the video camera actually

starting to record while the tape mechanism activates. Similarly, when video is being captured

from an external device such as a video camera to a computer, the user will begin the video capture

12

a few seconds before the start of the desired footage. This tends to result in excess frames either

side of the actual swing which will potentially complicate matters when two (or more) swings

are being compared; for example, if two swings are being played simultaneously for comparison

and each has a different number of unwanted frames (before the swing commences and after it

completes), they will immediately be out of sync as they will not start at the same time.

It would be useful to be able to remove these frames when the swing is being analysed on com-

puter so that the swing starts at the beginning of the video and finishes at the end of the video.

• Limited video file format support

cSwing only allows the user to load video files of the AVI (Audio Video Interleaved) format.

Whilst it does support compressed AVI files; MPEG and WMV file types are unsupported which

means that if the user wishes to analyse a swing saved in one of these types, it must be converted

to AVI using 3rd-party software. AVI compression is inferior to MPEG and WMV compression

which means that an AVI video will occupy far more storage space than the same video encoded

using the MPEG standard. This could be an issue if the user wishes to store many golf swings

on his hard drive but has a limited amount of storage. Obviously, any video captured from an

external device such as a camcorder using cSwing, can be saved as an AVI file.

2.5.2 V1 Golf

V1 Golf is a piece of swing analysis software, similar to cSwing, and is probably the second most

popular of such systems among teaching professionals. The V1 Golf Website states:

V1 Golf allows you to view, analyze, and diagnose faults with your swing simply and pre-

cisely. All the uncertainty is removed when you see your swing compared to a PGA profes-

sional.

V1 Golf gives you a clear understanding of your current golf swing and how to improve it

the key to lower scoring and less frustration!

[6]

2.5.2.1 Strengths of V1 Golf

• Attractive, user-friendly interface

In contrast to the cSwing software, I found the the V1 Golf user-interface to be attractive and easy

13

to use. The function of the buttons are generally clear and tooltip captions are used on all of the

GUI components. Overall, the user-interface has a very polished feel to it.

Figure 2.7: A screenshot of the attractive user-interface of V1 Golf

2.5.2.2 Weaknesses of V1 Golf

• Cannot play two swings simultaneously

Although two swings both be loaded at the same time, they cannot be played (at any speed)

simultaneously. Each swing must be controlled independently which can be awkward if you are

trying to get both swings to the same position. It is essential rather than useful to be able to

advance (or reverse) both swings frame-by-frame so that direct comparisons can be easily made.

cSwing allows you to ’lock’ two swings together so that any operations (such as play, pause,

advance) will be applied to both swings.

• Limited selection of playback speeds

V1 Golf only allows swings to be played at two different speeds - full and half motion. With

advanced players swinging the golf club at over 120mph through the impact position, even half

speed playback can be too fast for the naked eye. cSwing offers seven playback speeds; from

14

double the full speed (presumably for advancing rapidly through the swing, similar to a fast-

forward function) down to a sixteenth of the full speed.

2.5.3 Summary of Existing Systems

Clearly there areas in both of the evaluated systems that could be improved upon whilst combining

the individual strengths of each. I found the cSwing software to contain more in the way of tools and

functionality but at the cost of cluttering the user-interface and appearing to be less user-friendly in

comparison to V1 Golf. V1 Golf had an attractive, less intimidating (to the less advanced computer

user) interface but was limited in terms of functionality and being unable to play more than one swing

at a time made this the inferior system.

There are certain desirable features that are not present in either of the program that I evaluated:

• Firstly, neither system allows the user to crop video files to remove unwanted frames. As dis-

cussed above, this would be a very practical facility to have and certainly a feature that should be

included in my program.

• It occurred to me whilst evaluating these programs that it would be enormously beneficial if the

common side-by-side swing comparison could be taken a step further by allowing swings to be

superimposed on top of one another so that more direct comparisons can be made. This would

mean that more subtle differences between the swings could be identified.

Neither of the two systems, or indeed any swing analysis systems that I found, provide a feature

such as this.

2.6 Development Tools

A large portion of my research time was spent looking into which tools would be most appropriate for

developing the software component of the project.

2.6.1 Java

My initial thought was to write the software in Java, as this is the programming language with which I

have had the most experience with. Furthermore, this is the language which I have been taught during my

time at University and I felt that it would be easy to find assistance within the School of Computing with

15

any technical problems (that I would almost certainly run into at some stage) during the development of

the software.

After consulting with Nick Efford, author of Digital Image Processing Using Java, it was apparent to

me that Java would be a poor choice for several reasons:

• The Java media libraries are out-dated due to neglect over recent years. No significant changes

have been made to them since the release of Java 1.3 in April 2000[10].

• In order to be platform and OS independent, Java utilises a ’Virtual Machine’ (JVM) which ex-

ecutes Java byte code.[15] All programs written and compiled in Java must run inside a JVM.

Therefore Java applications tend to have a large memory footprint compared with applications

written in languages such as C and C++. A larger memory footprint increases the probability that

parts of the application will be swapped out to the hard drive. Nick advised me that even on a

powerful computer, video processing for just a single stream of video would be slow.

2.6.2 C++

Nick suggested that I write my software in C++ which, from a performance perspective, would be a far

more feasible alternative. This seemed like even more attractive solution when I discovered that C++

libraries had already been written in the School of Computing which could do much of what I wanted.

However, being inexperienced with C++, I was reluctant to undertake such an ambitious project in a

language with which I am unfamiliar and which is inherently lower-level and thus more complicated

than Java.

2.6.3 C#

C# is relatively new language, developed by Microsoft, for developing applications that run on the .NET

Framework. Whilst C# is syntactically almost identical to Java, it has evolved from C and C++, and is

said to combine:

the best features of each and adding new features of its own.[4]

Microsoft claim that C# combines the power of C++ with the rapid application development capabil-

ities of Visual Basic. Benchmarking tests carried out by German hardware/software reviewers, Tommti

16

Systems[14], show that while C# is not as high-performance as C++, it does out-perform Java and with

much lower memory footprint of 111MB compared with 163MB (see Fig. 2.8.

Figure 2.8: Results of benchmarking tests comparing the speed at which C++, C# and Java performed a

variety of operations

A similar experiment was carried out in which a Java program and an identical implementation

written in C# written to solve the Tower of Hanoi problem, found that:

Java consistently takes about 1.8 times as long to execute as C# for a tower of a given

height.

This experiment was carried out by an independent developer and the results posted on Sun’s Java

forum and so should be used with caution. However, the results obtained do reflect a general consensus

that I found from researching the power of C#. Although programs written in C# (and any other of the

.NET languages) use a virtual machine in the form of the Common Language Runtime; unlike Java’s

virtual machine, it is designed to run exclusively on the Windows operating system. It is the lack of

platform independence that gives C# the edge over Java in terms of performance and since Windows is

the most popular OS among home-users by and overwhelming margin, I felt that it would be perfectly

acceptable for my software to run only on this platform.

In conclusion, I chose C# as the language in which to develop the software for several reasons:

• Syntactically very similar to Java, therefore the learning curve would be steep compared with

17

learning C++. This meant that I could begin coding far sooner than if I chose to write the software

in C++.

• More powerful than Java which I felt was important for a program involving video manipulation.

• C# applications can be written using Microsoft Visual Studio, which is excellent for quickly

producing rich, sophisticated user interfaces.

2.7 Development Methodologies

Research by the Standish Group, published in their 2004 annual CHAOS report, found that a stag-

gering 31% of software projects are cancelled before completion and that nearly 53% of all projects

will cost over 189% more than their original estimates.[7] There are many problems that can affect the

development of computerized systems. Such problems significantly reduce the success of a software

development project and it is crucial that a development strategy is adopted that will minimise their

occurrence. I will briefly discuss the range of feasible methodologies that I could use, before justifying

my final selection.

2.7.1 The Waterfall Model

The traditional waterfall method describes the development process in terms of a fairly rigid life cycle.

The development processes are subdivided into clear, individual tasks which must be completed in order

before moving onto the next phase in the life cycle. The life cycle is linear and one-way in the sense

that it is difficult and often infeasible to return to an earlier phase once it is completed.

2.7.1.1 Advantages of the Waterfall Model

• The tasks in a particular stage of the life cycle may be assigned to specialised teams. For example,

some teams may specialize in analysis, others in design and yet others in testing.

• The progress of the project can be evaluated at the end of each phase and an assessment made as

to whether the project should proceed.

• The controlled approach can be effective for managing the risks on large projects with potentially

high levels of risk.[11]

18

Figure 2.9: The traditional development process - The Waterfall Model. Progress flows from top to

bottom and the difficulty in returning to an earlier phase is comparable with swimming up a waterfall.

2.7.1.2 Disadvantages of the Waterfall Model

• Real projects rarely follow such a simple sequential life cycle. Project phases overlap and activi-

ties may have to be repeated.

• Iterations are almost inevitable, because inadequacies in the requirements analysis may become

evident during design, construction or testing.

• A great deal of time may elapse between the initial systems engineering and the final installation.

Requirements will almost inevitably have changed in the meantime.

• The waterfall model tends to be unresponsive to changes in requirements or technology during

the project. Once architectural decisions have been made (e.g. during systems engineering) they

are difficult to change.[11]

2.7.2 Prototyping

Prototyping is just one of several relatively recent approaches to software development which fall into

the Rapid Application Development (RAD) category. It involves rapidly producing disposable proto-

19

types that explore some aspect of the systems requirements. A prototype will typically lack full func-

tionality but are designed to give the intended user/customer a feel for the final solution. Prototyping will

often be carried for a variety of reasons, for example; to determine the most suitable form of interface

or to determine what should be captured form (or displayed to) the user.[11].

The main stages required to prepare a prototype are as follows:

• perform initial analysis

• define prototype objectives

• specify prototype

• construct prototype

• evaluate prototype and recommend changes

2.7.2.1 Advantages of Prototyping

• Early demonstrations of system functionality help identify any misunderstandings between devel-

oper and client

• Client requirements that have been missed are identified

• Difficulties in the interface can be identified

• The feasibility and usefulness of the system can be tested, even though, by it’s very nature, the

prototype is incomplete[11]

2.7.2.2 Disadvantages of Prototyping

• The client may perceive the prototype as part of the final system, may not understand the effort

that will be required to produce a working system and may expect delivery soon

• The prototype may divert attention from functional to solely interface issues

• Prototyping requires significant user involvement

• Managing the prototyping life cycle requires careful decision making

20

2.7.3 Incremental Development

The iterative, incremental approach is a method of development where the software is designed, im-

plemented and tested incrementally until the product is finished. [18] The basic idea behind iterative

enhancement is to develop a software system incrementally, allowing the developer to take advantage

of what was being learned during the development of earlier, incremental, deliverable versions of the

system. Learning comes from both the development and use of the system, where possible. Key steps

in the process are to start with a simple implementation of a subset of the software requirements and

iteratively enhance the evolving sequence of versions until the full system is implemented. At each

iteration, design modifications are made and new functional capabilities are added.[19]

Essentially, this approach combines the elements of the waterfall model with the iterative philosophy of

prototyping.

2.7.4 Choice and Justification of Methodology

Ultimately, a methodology must be chosen which gives the project the greatest possible chance of suc-

cess. I believe the biggest risk to the project is it’s complexity. Having relatively little technical ex-

perience with video and no previous experience at all with the chosen development tools, it would be

fair to say that there was a significant risk of not successfully completing the project and that it was

over-ambitious. Indeed, I was initially concerned that:

1. My technical skills were not strong enough to produce a such piece of software

2. I would be limited by the multimedia software development technologies that were available

to me:

Having carried out research on multimedia support in C#, I discovered that the functionality pro-

vided by the native C# multimedia libraries was not sophisticated enough for what I was intending

to develop; basic video display and playback (i.e. play, pause and stop) were supported but noth-

ing more advanced than this. The only other alternative I could find was to use the Microsoft

DirectShow libraries which provide more sophisticated audio and video functionality but unfortu-

nately, the routines can only be accessed through C++ code. Following further research, I learnt of

a public project called DirectShow.NET which has the aim of converting the DirectShow libraries

into libraries compatible with all Managed .NET languages. The project website states:

21

For developers who want the complete range of functionality of DirectShow in .NET,

this library provides the enums, structs, and interface definitions to access them.[2]

Many of the routines have not been tested by the DirectShow.NET developers and a disclaimer on

the website advises you to treat the software as alpha stage. There is little in the way of documen-

tation for DirectShow.NET apart from a few basic samples and the DirectShow documentation

written by Microsoft is intended for C++ programmers with no assistance on how to adapt the

code samples to work in C#.

I was strongly concerned that if I ran into difficulties with the development of the video-based

aspects of my software that it would be hard to find any assistance. The implementation of a design

being unfeasible is a big problem with software development projects. As Bennet et al state:

Some projects are over-ambitious in their technical aims, and this may not become evident

until an attempt is made to implement the system.[11]

I felt it would therefore be unwise to follow a methodology such as the Waterfall Model, that is

based on the idea of Big Design Up Front (BDUF)[20]. This essentially means that large amount

of time is spent early on making sure that requirements and design are absolutely correct before any

implementation is started. It would be very disappointing and ultimately fatal to the project if such a

large portion of time was spent generating analysis and design documentation, detailing exactly how the

software should be implemented; only to find that in practice, I was unable to implement the design due

to the reasons listed above. Furthermore, having completed both GCSE and A-Level Computing courses

(both with large coursework components) I had found that sticking rigidly to the Waterfall Model was

difficult. From experience, it is easy for the initial analysis and design phases to leak into the time

allocated for implementation, leaving you with less time for proper testing and evaluation; and the need

to ’retro-fit’ parts of the design were incomplete or had not been discovered until work commenced on

the implementation. Simply put, I found that the early ’documentation’ stages of the waterfall were

more of a hindrance than a help.

For this project, I needed to begin implementing the software immediately so that I could quickly assess

whether the project was realistic for me, feasible and could be a success. Therefore I decided that the

Incremental (iterative) Development methodology would be most suitable.

An incremental approach involves some initial analysis to scope the problem and iden-

tify major requirements. Those requirements that will deliver most benefit to the user are

22

selected to be the focus of a first increment of development and delivery.[11]

Using this methodology, I could treat the requirements identified in an initial analysis of the problem

as individual components (of functionality) of the software. The most important components, those

which were anticipated to be the most challenging, and those which would be required in order to meet

the minimum requirements of the project would be implemented first and then, time-permitting, the

remaining components added incrementally onto this ’base’. This would allow me to get ’hands-on’

with the implementation very quickly and therefore it would be apparent early on in the project whether

or not it was feasible.

23

Chapter 3

Analysis

3.1 Requirements Analysis

Using my knowledge of the problem domain outlined in the Background chapter, in combination with

the observations I made during the evaluation of some existing solutions; a list of user requirements for

the software solution I intend to develop can be compiled.

3.1.1 Basic Requirements

These requirements should be considered essential to a piece of golf swing analysis software and com-

prise the ’Minimum Requirements’ of the project in terms of the software functionality. They have been

captured using my knowledge of the problem domain outlined in Chapter 2.

3.1.1.1 Acquire video from an external device

The user needs be able to connect to an external device, namely a video camera, and capture video

footage from it. The user should be able to connect directly to a digital video camera using USB/Firewire

(provided the camera itself can support this) as well as cameras connected to the computer via a video

capture card.

The user should be able to capture ’live’ from the camera so that nothing necessarily needs to be recorded

onto video tape first.

24

3.1.1.2 Load multiple golf-swings

The user needs to be able to load and play more than one golf-swing at a time. This will allow the user

to load a client’s swing as well as the swing of a world-class professional so that the two swings can be

compared side-by-side. Similarly, the swing of a client from a previous lesson could be loaded next to

a more recent swing so that the client’s progress can be analysed.

The software should facilitate the playback of a variety of video file types so that swings acquired from

a variety of sources can be played without the need to be converted to a specific format using 3rd-party

software; as was the case with V1 Golf. The Internet is a good source for downloading the swings of

top-class professionals such as Tiger Woods and Phil Mickelson. A teaching professional may wish to

download a recent video of one of these professionals so that he can use it for swing-comparisons in

his lessons. It is therefore important that a range of video formats are supported. The most common

formats are mpeg, avi and wmv. All of these formats should be supported by G-SAT.

3.1.1.3 Playback swings at a range of speeds

The user needs to be able to play recorded swings at variety of speeds ranging from full-motion to a

quarter of the original speed. The user also needs to be able to pause a swing and advance (or reverse)

through it one frame at a time. If the user has loaded more than one swing, he/she should be able to

control their playback independently or simultaneously.

3.1.1.4 Draw on/annotate recorded swings

As discussed in Chapter 2, drawing on top of a swing recorded on video is very useful for detecting and

highlighting faults in the golfer’s technique. For example, if you draw a circle around the head of the

golfer at the start of the swing, an excessive1 head movement during the swing will be made very clear

as the head moves out of the circle (see Fig. 3.1).

1Contrary to the old fallacy ’keep your head still’, it is actually desirable for a player’s head and body to move a small

distance away from the target in the backswing and the same distance back towards the target in the downswing. This ’weight-

shift’ is to generate power and is comparable to a baseball pitcher, winding up onto his right foot before he throws the ball and

then stepping back down onto his left foot as he releases the ball.

25

Figure 3.1: The circle drawn around the player’s head at the start of the swing shows that he has moved

approximately 6 inches onto his right side by the time he reaches the top of the backswing

3.1.2 Advanced Requirements

These requirements are not considered essential but would increase the functionality of the software

and/or possibly distinguish it from any existing commercial solutions. The implementation of these

requirements should be considered as exceeding the minimum requirements of the project.

3.1.2.1 Crop Recorded Swings

When a professional uses a video camera during a lesson, he will usually start recording several seconds

before the client actually starts to swing the club to ensure that the entire swing is caught on tape. Also,

many golfers spend a few moments ’over the ball’ before actually commencing their swing. This means

that there are typically a few seconds between the start of the video and the start of the golfer’s swing

which are of no use in the analysis of the swing and make it difficult to synchronise several recorded

swings, so that they can start at the same time. Therefore, the user needs to be able to remove unwanted

frames at the start and end of the video.

26

3.1.2.2 Mirror swings to make the golfer appear ’opposite-handed’

According to the Professional Golfers Association, Over 93% of golfers play right-handed. Therefore,

it is often harder for a professional to teach a left-handed player as his eye is unaccustomed to looking

at players stood on the opposite side of the ball. Therefore it would be useful if the user could ’mirror’

a swing to make a golfer appear opposite-handed. This would particularly helpful when comparing a

left-handed golfer to a right-handed golfer as both swings could be made to appear right (or left) handed.

This is a feature I found when evaluating found cSwing and I intend to replicate this functionality in my

software.

3.1.2.3 Superimpose one swing over another

Although displaying golfing swings side-by-side provides an excellent way of drawing comparisons

between them, it would be better still if one swing could be superimposed on top of another. For

example, the swing of a world-class professional such as Tiger Woods could be superimposed on top

of the client’s swing so that the differences and similarities between the two swings can be clearly

seen. This would be especially useful for a professional to show his client what the world-class players

do differently, as the variation in technique would be even more apparent than with a side-by-side

comparison.

Neither of the commercial systems that I evaluated (see Chapter 2) provide a facility for superimposing

swings on top of each other. In fact, after looking at the specification for a variety of systems similar to

cSwing such as GASP and ComputerCoach2, it was apparent that no existing swing analysis software

on the market offers this feature.

2These systems were not evaluated as there are no trial versions available.

27

Chapter 4

Development of the Solution

4.1 Overview

This chapter discusses the development of the Golf-Swing Analysis Tool (G-SAT). In accordance with

the project methodology stated in section 2.7; following an initial analysis phase, each of the user

requirements that were identified were treated as individual components of the software’s functionality.

Components corresponding to the more important requirements in terms of the software’s functionality

and those which were anticipated to be the most difficult to implement were given a higher priority and

were therefore implemented first.

An iterative and incremental software development approach was then carried out on each of these

components in turn. After a component had been successfully completed, it would be ’plugged-in’ to

any other completed components and, in doing so, increment the overall functionality of the system

(Fig. 4.1).

This approach allowed me to complete the user requirements that were considered essential to the system

(and minimum requirements to the project) first, thereby increasing the chance of the project being

a success; before then going on to implement the more advanced user requirements which could be

regarded as exceeding the minimum requirements.

4.2 Component: Video Acquisition Tool

Requirement 3.1.1.1 states that:

28

Figure 4.1: Flowchart showing the development methodology of the project

The user needs be able to connect to an external device, namely a video camera, and

capture video footage from it.

4.2.1 First Iteration

Several options were looked at for the implementing this component of G-SAT. These included:

• Writing the component from scratch using the capture routines available in the DirectShow.NET

library

• Using existing .NET capture components

The DirectShow.NET library contains an interface called ICaptureGraphBuilder which facilities

connecting to a video capture device. At the time of writing, this interface was untested by the Direct-

Show.NET development team.

I anticipated that this component would be difficult to write from scratch and therefore I looked at using

a third-party component. Pegasus Imaging Corporation have developed CapturePro - a video capture

component that can be used in .NET applications to facilitate video acquisition from external capture

devices, including USB/Firewire devices. Available on a shareware license, I decided to use this com-

ponent as it provides all the required functionality and considerable time could be saved by not coding

from scratch. Modifying example code from the CapturePro help file, I was able to develop the Video

Acquisition tool in less than half the scheduled time. Using a third-party component greatly simplified

29

the development of this tool and reduced the amount of testing needed. As a result, only one iteration

was required.

Figure 4.2: Screenshot of Video Acquisition Tool

4.3 Component: Video Playback

This is the most fundamental component of G-SAT and corresponds to requirements 3.1.1.2 (Load

multiple golf-swings).

4.3.1 First Iteration

It was decided for the first iteration of this component, that the number of videos that can be displayed

simultaneously should be limited to two. If, following testing, it was found that more than two videos

could be displayed without negatively affecting playback performance, then this number would be in-

creased in successive iterations.

30

4.3.1.1 Loading video files

After looking into the standard .NET AudioVideoPlayback component, I realised that it did not provide

sufficient functionality; only basic playback functions can be performed on a loaded video file and a

limited range of file formats are supported. The DirectShow.NET library provides an interface to the

video handling routines available in the Microsoft DirectShow library1. However, using DirectShow,

I discovered that even simple tasks such as loading and controlling the playback of a video file are

non-trivial and error messages returned by the Visual Studio compiler were often unintelligible, making

debugging a difficult task. This is due to the experimental nature of the DirectShow.NET project.

I developed a C# class called a Swing. An instance of this class is a representation of a recorded golf

swing, encapsulating basic properties such as:

• the filename of the video

• height and width of the video

• the number of frames

• the duration in seconds

Swing class methods were implemented for performing basic operations on the swing such as:

• load swing

• unload swing

• play

• pause

• stop

The swing class effectively provides a wrapper around the more complex code using the Direct-

Show.NET routines. Operations performed by the user on a swing are carried out by calling the swing

class methods from the user-triggered GUI event, rather than directly calling the DirectShow.NET rou-

tines. This allowed to keep the program design neat and modularised.

1DirectShow has been merged into DirectX since the release of DirectX Version 9.0

31

4.3.1.2 Displaying the swing(s)

Two GUI objects, in the form of a panel, were used to display the videos, side-by-side, on the main

application form. These were designed to grow/shrink with the size of the main form. Videos displayed

in the panels resize to the dimension of the panel, and do not maintain their original ratio. I chose this

over resizing the panels to maintain the aspect ratio of the video because I felt that it would be easier

to make comparisons against swings with the same video ratio. If two different swings with different

aspect ratios were both loaded, then the panels would be different sizes, making a comparison more

difficult and damaging the aesthetics of the GUI. All of the commercial software that I evaluated, also

uses fixed aspect ratios.

4.3.1.3 Controlling video playback

Video playback controls were implemented in the form of tool bar buttons2 (Fig. 4.3(a)) on the GUI

and a context menu attached to the corresponding display panel (Fig. 4.3(b)). In order to determine

which of the two swings (should there be more than one loaded) the playback controls are applied to,

the user selects the corresponding panel by clicking on it. The same applies to loading a swing; it will

be loaded into the selected panel. Selecting a panel causes it to become highlighted, with the user of a

blue border, making the user’s selection clear. In addition, a status bar at the bottom of the main form

indicates which swing is currently selected. To apply the playback controls to both videos, the user

must select both panels by clicking on the Select Both Swings menu item (on the Swing menu) or by

control-clicking on the unselected video. By default, the left video is selected.

4.3.1.4 Unloading a swing

The user can unload a swing by selecting Unload from the relevant panel’s context menu, or the Swing

menu on the main form. A swing will automatically be unloaded if a new swing is being loaded in it’s

place. Unloading a swing disposes that Swing object, releasing the memory allocated to it.

4.3.2 Second Iteration

Testing of the first iteration of this component involved:

2It should be noted that only the basic playback functions such as play, pause and stop were initially implemented, even

though the playback tool bar in the Fig. 4.3(b) contains buttons for the more advanced playback controls as well.

32

(a) Tool bar containing video play-

back controls

(b) Menu bar containing video playback controls

Figure 4.3: The two initial methods of playback control

• loading video files of different types; mpeg, avi and wmv

• performing basic playback operations on loaded swings

• testing performance of simultaneous playback

• unloading swings

During testing, the following issues became apparent:

• Unloading swings, or loading a new swing in place of an existing swing, resulted in a memory

leak

I found that the amount of available memory fell after loading a swing in place of an already-

loaded swing; and that unloading a swing did not free-up the allocated memory as expected.

After researching the problem, I discovered that garbage collection carried out by the CLR does

not work properly on the DirectShow.NET library routines, as they are written in unmanaged

code.

C# uses garbage collection to handle memory management. As a result, COM objects

which can hold both memory and threads, may not get released in a timely fashion.[2]

As a result, manual garbage collection must be carried out.

Resolution: The method for unloading a Swing object was amended to include manual garbage

collection.

33

• Poor simultaneous playback performance

To assess the performance of simultaneous playback of two loaded swings, I tested the software on

relatively low specification3 (by today’s standards) laptop computer and the School of Computing

machines. I felt that although playback performance was perfectly acceptable on my desktop

machine, this was an unfair test as the target users of G-SAT (namely teaching professionals) are

unlikely to use the software on powerful desktop computer. Ideally a teaching professional would

wish to run G-SAT on a laptop computer so that it can be used on the practice ground during a

lesson.

I found that when playing two swings simultaneously on the laptop (and, to a certain extent, the

School Of Computing machines) that the playback became jerky, stuttered and the two swings

quickly fell out of sync with each other. I found out that this was most likely caused by the fact

the the DirectShow video handling routines read the video file directly from the hard drive and

displays the video frames ’on-the-fly’. Slower hard drives are unable to keep up with the demand,

especially if more than one video file is being read at a time.

Resolution: The handling of videos by G-SAT was changed so that when a video file is loaded, it

is broken down and each frame is stored in an array of bitmaps in memory. 4 This array is a field

variable of the Swing class.

This solution effectively means that the entire swing is loaded into memory before being played.

As the image data can be passed from memory to the program, faster than it can from the hard

drive, playback is smooth - even on a low specification machine. The small drawback to this is that

the initial conversion from video file to bitmap array causes a slight delay to occur. As a result, a

progress bar was implemented to indicate to the user the advancement through the process (4.4).

4.3.3 Final Iteration

Whilst testing the changes made in the second iteration, I discovered that frames were being dropped;

and more worryingly, the program was crashing with unintelligible error messages; particularly when

3Pentium III 500Mhz, 192MB RAM, No 3D Accelerator

4Since a golf swing lasts for such a short period of time, a video of a swing typically only contains between 25 and 50

frames. Therefore excessive memory consumption is not an issue, even when tested on the laptop computer with just 192MB

of RAM.

34

Figure 4.4: Progress bar used to inform user of current progress in video file conversion

running G-SAT on lower specification computers. The frame-dropping problem would manifest itself in

the same frame appearing n times in succession before the next frame (n frames ahead of the recurring

frame) in the sequence was displayed. This meant that the frames in-between were missing.

The conversion from video file to bitmap array is shown in Fig. 4.5. As previously mentioned, the

error messages returned by the DirectShow.NET class are often very vague and mostly unhelpful. This

made debugging particularly difficult as it was hard to identify the cause of the problem. After extensive

debugging, I discovered that a buffer under run (or ’inverse bottleneck’) effect was occurring at the point

labelled on Fig. 4.5; i.e. the buffer was not being re-filled fast enough by the DirectShow.NET routine

reading in the video file. The method which converts the contents of the buffer into a bitmap object was

being called immediately after the call to the DirectShow.NET method (running on a separate thread of

execution) responsible for reading the video file in from the hard drive; irrespective of whether it had

completed it’s job. As a result, the latter method continued to read from the buffer to create new bitmap

objects even though the buffer either had not changed since the last time it was read from (resulting

in duplicate frames), or had not been completely filled yet (resulting in an application crash). This

’breakdown in communication’ highlights the problem of mixing unmanaged and managed .NET code.

Resolution: To fix this problem, a conditional statement was used to ensure that the buffer had changed

since it was previously read from, and was not empty. If either of these conditions were true, then the

application’s thread of execution would be put to sleep for a short amount of time, giving the buffer time

to be filled by the DirectShow routine. When the thread wakes, the check is performed again and if the

buffer is now ready, it is read from; otherwise the thread is put back to sleep again and so on.

35

Figure 4.5: The process of converting a video file held on the hard drive, to an array of bitmaps held in

memory

4.4 Component: Playback at various speeds

4.4.1 First Iteration

Before the design change was made to store videos as a bitmap array of frames in memory, the regular

video playback functions included in DirectShow.NET such as Play(), Pause() and Stop() were used.

Following this change, a different method of playback needed to be adopted. This was done using

a timer control, displaying the next/previous frame in the array each time the timer interval elapsed.

Every interval, the timer calls a method which updates the display frame with the next frame in the

video sequence.

36

Figure 4.6: Screen capture of final iteration of basic video playback component

37

4.4.1.1 Playback at full speed

To control the playback speed, the interval of timer was simply increased or decreased. The full motion

interval was calculated using:

number of frames in videolength of video (in seconds)

4.4.1.2 Playback at half and quarter speeds

The Half-motion and quarter-motion frame intervals were calculated by halving and quartering this

interval.

4.4.2 Second Iteration

Following testing of the first iteration, it was decided that some method of jumping directly to a specific

frame or section of the video should be implemented. This would allow the user to navigate to the top of

the backswing or impact position for example, without first needing to play through all previous frames.

This was done by inserting two track bar components, one for each video frame, onto the user-interface.

When a swing is loaded, the number of points on the corresponding track bar is set to the number of

frames in the video. The track bar’s slider can be dragged using the mouse cursor to move the video

directly to the desired frame. The timer used for controlling the rate of playback was modified, so that

the function called when the timer’s interval elapses updates the position of the slider.

4.5 Component: Drawing Tools

4.5.1 First Iteration

The facility for drawing over loaded swings was implemented using Microsoft GDI+. GDI+ is the

successor to GDI (Graphics Device Interface), one of the subsystems of Microsoft Windows responsible

for drawing in a 2D graphics environment[17]. The Microsoft .NET class library provides a managed

interface for GDI+ via the System.Drawing namespace.

Drawing tools are selected using buttons on a tool bar, displaying a graphical representation of their

function. A straight line tool, rectangle tool and ellipse tool were implemented. When a user has

selected a tool from the tool bar, the selected shape can be drawn by clicking in the chosen swing’s

display frame, dragging the mouse across the panel and then releasing the mouse button to draw the

38

shape between the two points. The shapes are drawn using GDI+ functions in the System.Drawing

namespace. The user can change the colour of the pen that the shapes are drawn in by using a colour

selection dialog box, and similarly, the thickness of the pen.

Figure 4.7: Implementation of the Drawing Tools

4.6 Component: Video Cropping Tool

4.6.1 First Iteration

Cropping was implemented by providing the user with menu options to flag the frame currently being

displayed as the first/last frame in the swing; and then another option remove all frames either side of

these markers (Fig. 4.8(a).) A Crop() method was added to the Swing class which takes the frame

numbers of the start and end frames as parameters. A for loop is used to iterate through the array of

frames between these two positions and copy each frame into a new array. The original array is then

disposed and the new array containing only the desired frames assigned in it’s place. The corresponding

39

track bar on the user-interface is updated to reflect the changes in the swing’s length.

4.6.2 Second Iteration

During testing of the first iteration, it was made clear that validation was required to ensure that the ’end

frame’ selected by the user is greater than the ’start frame’, otherwise the program becomes trapped in

the for loop of the Crop() method. This validation was implemented in the second iteration (Fig. 4.8(b)).

(a) Context menu amended to

include options for cropping

video

(b) Cropping validation

Figure 4.8: Implementation of the Cropping Tool

4.7 Component: Mirror Tool

This tool is used to horizontally invert frames in a swing in order to make the golfer appear opposite-

handed. Two methods of doing this were considered:

• Unmanaged pointer code could be used to directly manipulate the image data of the frames.

Nested for loops could be used to iterate backwards through the columns of each frame, copying

each pixel value into a new image. This would produce a horizontally inverted copy of the original

frame. The advantage of using this method is that it is very fast.

• The FlipRotate() method of the C# Bitmap class could be used to ’flip’ the frames in the video.

40

Clearly the second method would be easier to implement but possibly at the cost of performance.

Both methods were implemented and tested in the form of prototype applications which simply mirror

an array of 100 images held in an array in memory and then output the time it took to complete the

operation. This was done so that the performance of the two methods could be compared. Results of

this test showed that the performance gained from using pointer code was fairly insignificant and did not

outweigh the added coding complexity and potential problems of using unmanaged code. Therefore,

the latter option was used for the mirror tool.

A method called MirrorFrames() was added to the swing class which iterates through all frames in the

swing and mirrors them. A progress bar, similar to the one in Fig. 4.4 was used to indicate to the user,

the advancement through the process. Mirroring is applied to a swing using a menu option added to the

context menu of the video panels.

4.8 Component: Video Overlay Tool

One of the most ambitious features of the software that was proposed as possible extension rather than

a minimum requirement was the video overlay tool (See 3.1.2.3). This feature allows the user to super-

impose one swing on top of another for direct comparison.

4.8.1 First Iteration

Overlaying was done by creating a new array of blank frames, with the dimensions of the swing on

which the overlay swing was being placed (the original swing). This means that the frames of the

original swing are not affected and therefore the overlay can easily be removed (by restoring the original

frames) should the user wish to do so.

The overlay effect was produced by taking each frame from the original swing, drawing it onto the

corresponding (i.e. same frame number) blank frame and then drawing the corresponding frame from

the overlay swing on top of this with a reduced alpha (intensity) value. An initial fixed alpha value of 0.6

was used, meaning that the overlay frames were drawn in just over half their original opacity. Frames

from the overlay swing are resized to match the dimensions of the swing being overlaid. If there are less

frames in the overlay swing than the original swing, then the final frame of the overlay swing is drawn

on all of the remaining frames in the original.

41

4.8.2 Second Iteration

In the first iteration, all frames were preprocessed rather than performing the overlay on-the-fly. This

was done so that although there would be a slight delay while the overlay is applied, there would

be no negative performance effects caused by the overlay operation being performed one each frame

transition. Testing of the first iteration revealed a key flaw in this approach to applying to the overlay;

if the original swing and the overlaid swing fell out of sync (i.e. the golfers were in different positions

due to differences in swing speed or rhythm) there was no way of correction.

Resolution: A second track bar was added for each swing panel with which the position of the overlay

swing could be adjusted. However, an alteration to the position of the overlay swing would require

processing all frames in both swings again in order to shift the overlay frames across. The overlay

method had to be changed so that the overlay operation is applied as the frames are displayed i.e. on the

fly. Changing the position of the overlay swing would merely involve re-applying the overlay operation

to a single frame - the one currently being displayed.

A Lock Trackbars menu option was added to the overlay track bar so that it can be locked with the

swing’s main track bar. If the track bars are not locked then the original and overlaid swings can be

controlled independently of each other so that adjustments can be made if they fall out of sync. If they

are locked, then they will move in sync with each other. This is done by updating the position of the

overlay track bar’s slider whenever the main track bar’s slider moves. This proved to be very difficult as

two swings are likely to have a different number of frames and therefore a different number of ’notches’

on their respective track bars.

As anticipated, testing on a low specification machine did reveal a slight drop in performance when

playing a swing that has been overlaid, at full speed. At lower speeds or on mid-range computers

however, this was unnoticeable. It might be useful to give the user the option of preprocessing frames if

he/she is using a low-end computer.

4.8.3 Third Iteration

Following further testing, it was decided that a method for cropping an overlay swing should be im-

plemented so that excess frames can be removed. This would done by adding the menu option ’Apply

Overlay From Opposite Swing Panel’ to the context menu on the swing panels. This takes the swing

loaded in the opposite panel and applies it as an overlay onto the currently selected swing. This allows

42

the swing in the opposite panel to be cropped first, before it is overlaid.

It was also decided that a method for adjusting the opacity of the overlaid swing should be implemented

so that it can be faded in or out as required. With the old method of preprocessing all frames when

applying the overlay, this would have mean re-processing all frames again with the new alpha value.

With the new method of overlaying on-the-fly however, this could be implemented easily; re-processing

only the frame currently being displayed with the new alpha value. The alpha value (or opacity) can be

increased or decreased by the user through controls on the tool bar (See Fig. 4.9).

Figure 4.9: Implementation of the Swing Overlay Tool

43

Chapter 5

Evaluation

5.1 Evaluation Against Minimum Requirements

The success of this project will be evaluated on several levels. Firstly, the initial aims of the project will

be reviewed and an assessment will be made on the extent to which these have been satisfied. Referring

back to the first chapter (See 1.1) we can see that the project aims and objectives were outlined as

follows:

• Aim: Produce a piece of software that can be used to analyse golf swings recorded on video.

This aim has been successfully realised as I have produced a piece of software that provides the

functionality to analyse golf swings. I would say that I have exceeded my initial expectations for

the software as I was able to include greater functionality than outlined in my December Mid-

Project report; and I believe I have exceeded the minimum requirements by producing a higher

quality product than originally anticipated. I invested a great deal of time in ensuring that the soft-

ware is as highly polished as possible. I believe that without too much extra work, the software

would be in a position where it could be made commercially available.

The software produced in this project makes improvements on existing solutions to the problem,

combining some of the better features found in the commercial software evaluations (2.5) and

with the video overlay tool, distinguishes itself from anything available on the market. The over-

lay tool was initially posed as a possible extension to the project and was not in the minimum

requirements. Implementing this feature means that I have exceeded the minimum requirements

44

stated for the project.

• Minimum Requirement: The system will allow the user to connect to an external device

(such as a video camera) and acquire video from it.

This minimum requirement has been met as the software provides a video capture tool which

allows the user to connect to a video capture card, or video camera via firewire or USB connection

and acquire recorded video from it.

• Minimum Requirement: The system will allow the user to load and play several swings

simultaneously.

This minimum requirement has been met as the software allows two swings to be loaded at the

same time (or four if both are overlaid) facilitating the direct comparison of golf swings.

• Minimum Requirement: The system will allow the user to synchronise loaded swings.

This requirement has been met: The software allows the position of an individual to be altered

through the use of a trackbar GUI component, or a variety of playback buttons. Once the user

has adjusted the position of two loaded swings as desired, they can be locked together so that any

playback operations will be applied to both swings. Should the swings fall out of sync (if one of

the swings has a faster rhythm for example), they can be re-synchronised by using the playback

controls or position trackbar to fine tune their individual positions.

A method of automatically finding the start of the swing (which is not necessarily at the start

of the video) has been proposed (See 5.3) but was not implemented due to time limitations. If

this were implemented in a future version of the software, then synchronisation (of the starting

position) of two swings could be done automatically.

• Minimum Requirement: The system will allow the user to draw (e.g. lines, dots, circles etc.)

on top of swings.

This minimum requirement has been met as the software provides drawing tools which can be

used to illustrate loaded swings. These include a line tool, rectangle tool and ellipse tool. The

colour and thickness of the drawing pen can easily be adjusted using controls on the GUI.

• Minimum Requirement: The system will have a friendly user-interface so that relatively

little computer literacy will be required to operate it.

This was evaluated by observing the use of the system by two PGA Professionals (See 5.2).

45

Vrendenburg et al (2001) state that a usability test should be performed by the users related to the

problem domain[5]. Therefore it made sense to assess the usability of the software by observing

it being used by the intended user audience. This observation allowed me to identify any HCI

issues with the software. Neither of the professionals involved in the software evaluation have

a great deal of experience with computers and could aptly be described as ’computer novices’.

The fact that they did not run into any problems whilst they were using the software indicates that

it is user-friendly. Observations revealed that the user-interface could be improved by assigning

keyboard shortcuts to certain tools in order increase the efficiency with which the software can be

used.

5.2 Evaluation of G-SAT by Teaching Professionals

In order to assess the real usefulness and usability of the software, it was evaluated by two PGA Pro-

fessionals. I felt that this would provide an objective evaluation of the software, and hopefully some

helpful feedback on how it could be improved.

Frank Houlgate and Michael Harrington both kindly agreed to use the software during their lessons in

the week beginning the 3rd of April. Frank qualified as a PGA Professional in 1997, and currently holds

the position of Head-Professional at Sand Moor Golf, Leeds. Michael is the Assistant-Professional at

Sand Moor and is currently in his final year of PGA training.

Following a morning of training on how to use the software, it was installed on both of the professionals’

laptop computers and used for the entire week in a total of fifteen golf lessons; equating to seven and a

half hours of teaching time.

5.2.1 Observations made during evaluation

I observed the use of the software by Frank and Michael for the first four of their lessons (two each).

This not only provided me with excellent feedback on the usability of the software, but also meant that

I was ’on-hand’ should either of them run into any problems whilst they became familiar with it. It was

important however, that I did not ’intrude’ on the lessons. Below are a summary of the observations I

made:

• The process of acquiring a swing from video camera and then loading it for display was

lengthy

46

A key problem that I observed with both professionals when using the software was that an ex-

cessive amount of time was taken just to load the client’s swing into G-SAT. First of all, the user

has to acquire the video from the camera using the video capture tool. Most frequently, the users

would save captured swings to the Windows desktop where they can be easily found. Then, the

capture component has to be closed and the swing loaded into G-SAT through the usual method

of File, Load Swing. By default, the file selection dialog opens with the My Documents folder

being displayed which means that the user then has to navigate to the desktop to locate the video

file that he has just saved. This can take a while, especially for users such as Frank and Michael

(who represent the target users of G-SAT) who are unfamiliar with file-system navigation.

Possible solution for further iterations: This could be alleviated by having the load file dialog

in the main program open, by default, in the same directory that any videos have recently been

saved into using the video capture tool. Better still, would be to allow captured swings to be

automatically loaded into the main form, perhaps by checking a box in the capture tool (e.g.

Automatically load swing following capture or including a menu option on the main form such as

Load Swing from External Device which would unify the two processes of capturing, then loading

a swing.

• Some of the mouse-driven commands are awkward to execute

This was raised as a potential problem during the project’s Final Progress Meeting and became

apparent during observation of the software being used. I noticed that using certain tools through

a sequence of mouse clicks could be awkward and again, lengthy. For example, to crop a loaded

swing, the user must:

– right-click on the swing to display the context menu

– then select Set As Start Frame

– right-click again to bring the context menu back up

– select Set As End Frame

– right-click again to bring the context menu back up

– finally, select Crop Video

This gives a total of six separate mouse-clicks needed to perform the cropping operation which,

again, equates to time wasted in the lesson.

47

Possible solution for further iterations: Keyboard shortcuts could be assigned to the tools in

G-SAT so that they could be executed faster. For example, pressing Ctrl + s could set frame

currently being displayed as the start frame. Cropping the swing could be done in a matter of

just 3 key presses. These could be done when playing the swing for the first time in full motion,

setting the start and end frames as they appear, before cropping the video between the selected

frames. Keyboard shortcuts could be assigned to almost all of the operations available in G-SAT

so that the more experienced user could use it more efficiently; thereby reducing the amount of

time spent using the software in a lesson.

• Clients appreciated the use of the software in their lessons

A positive observation I made was how much the client took pleasure in seeing his/her swing

compared directly with top-class players. One client in particular commented that he found it

enormously beneficial for the professional to draw on his swing as the illustration made it easier

for him to understand exactly what he was doing wrong; and the use of a side-by-side comparison

with a playing professional made it easier for him to understand how it ’should be done’.

5.2.2 Feedback from Teaching Professionals

The following feedback was obtained through means of an interview with the teaching professionals

who evaluated the software. The questions posed in the interview can be found in Appendix D.

5.2.2.1 Benefits of using the software

Both of the users who evaluated the software found that using it in their lessons was beneficial, not only

to them but also the clients. They agreed that displaying the clients’ swings on the laptop screen, as

opposed to the much smaller LCD on their cameras allowed them to see the swing more clearly and in

some cases, identify subtle swing flaws which they may not have not noticed normally.

They found the drawing tools useful for explaining technical swing details to the client which resulted

in a better understanding of the problem, on the client’s part.

I actually found that explaining something to them [the client] by drawing onto their swings,

helped them to understand what it was that they were doing wrong. And I think, because of

that, I saw better results when it came to fixing their [the clients’] swing faults. I think that

48

seeing yourself next to somebody like Tiger Woods gives you a visual image in your head of

what you should be trying to do. - FH

5.2.2.2 Usability of the software

The feedback from Frank and Michael regarding the usability of the software, confirmed my observa-

tion that certain tasks could be done quicker with the use of keyboard-shortcuts. Michael said that he

sometimes became ’lost’ in the menus and would prefer to be able to press a key on the keyboard for

certain tasks.

That aside, the feedback was positive. Frank said that he liked the ”clean, tidy” feel of the user-interface,

although he felt that the buttons for controlling the video playback should be larger. Both evaluators

commented that they found the trackbars useful for navigating through a swing.

Frank said in the interview that he liked being able to load two swings of the same client taken from

different angles; facing the golfer and facing the target. Some swing flaws can only be seen from one

particular angle. For example excessive lateral movement in the swing can only be seen from a face-on

shot of the golfer. Being able to play the swing from both angles simultaneously in slow motion is very

helpful to the professional and this is not possible just by using a video camera; the two swings would

normally have to be played consecutively.

5.2.2.3 Evaluation of overlay tool

As this was the first time the evaluators had used the software in their lessons, they did not have any

saved swings of their clients from previous lessons. This meant that the overlay tool was not used

with swings of the same client from different lessons. This is unfortunate as I believe this to be the

most useful comparison to make using the overlay tool, so that progress between lessons can be easily

seen. However, it was used with several swings of world-class players that I had downloaded from the

Internet.

Both evaluators were impressed with the overlay tool and found that their clients enjoyed being able to

compare their swings so closely with players such as Tiger Woods and Nick Faldo. Michael commented

in the interview that he liked how easy it was to adjust the position of the overlaid swing using the

overlay trackbar, should the two swings fall out of sync. Both evaluators found the ability of adjust the

intensity of the overlayed swing particularly useful.

Neither Frank nor Michael made any suggestions that it would be helpful to be able to remove the

49

background from the overlayed swing to reduce clutter in the video; however, when I suggested this as

a future improvement, they both agreed that it was a good idea in terms of aesthetics.

Frank reported that simultaneous playback performance fell when he attempted to play two overlayed

swings (totalling four swings) at the same time. This is unsurprising, especially as the software was

being used on a relatively low specification laptop1 However, this problem could be solved by pre-

processing all frames when applying an overlay, rather than producing overlayed frames ’on-the-fly’.

However, as discussed in 4, this would involve re-processing each time the synchronisation of the two

swings is adjusted.

I would like a chance to use the overlay tool in a future lesson with somebody I have taught

this week; so that I could overlay the swing from this week onto their ’new’ swing to see

how they have improved or regressed.-FH

A key piece of feedback that I received regarding the overlay tool, is that it is most effective when

the golfer in the overlay swing is in the same position (relative to to the camera) as the golfer in the

swing being overlayed. If the two golfers are in quite different positions, then comparisons are much

more difficult to make and the tool is less effective. It was suggested by one of the evaluators that it

would be useful to be able to move the overlay swing so that the two golfers could be better aligned if

they were not already.

This could be implemented so that the overlay could be repositioned either by clicking and dragging

with the mouse, or through use of the arrow keys. This would allow a better comparisons of swings in

which the camera positions were considerably different.

5.2.2.4 Evaluation of other features in the software

During the interview, I asked the evaluators which of the features they found to be the most/least useful.

They were asked in particular, about the usefulness of the swing overlay tool. Michael commented that

he found the drawing tools to be particularly useful:

With the better players that I taught this week, I liked being able to use the drawing tools

to reinforce something that I had a suspicion of. For example, when I was teaching James

Skirrow on Thursday, it looked like he might be losing height fractionally in the backswing

1Compared with the state of the art at the time of writing.

50

and I was able to use the software to confirm this with myself by drawing a marker on his

head. -MH

Having taught only right-handed players during the evaluation week, Frank did not use the mirror

tool on any of his clients’ swings. Michael however, did give a lesson to a left-handed golfer and found

using the mirror tool to be enormously helpful:

For me, one of the best things about the software is the mirror tool. I taught a left handed

player yesterday, and it was somebody who I’ve been teaching for quite some time so I’m

fairly well acquainted with their swing. But when I mirrored his swing using G-SAT, I was

shocked at how different it looked to me. It definitely helped me to assess his swing and

gave me a totally new perspective of it. For someone like me, who finds it a bit trickier to

teach left-handers, this really helps.-MH

5.2.2.5 Features they would like to see included

Frank said that there were times when he was using the software, where he would have liked to have

temporarily hidden the drawings he had made, without erasing them altogether, so that they can be un-

hidden without needing to re-draw them. Currently the software only facilitates the erasing of drawings

but the functionality for just hiding them could easily be implemented. Similarly, it was suggested that

an ’eraser’ tool be added to the existing drawing tools so that just certain parts of a drawing can be

erased.

Another suggestion by the evaluators for implementation in future versions, was a feature for printing

out frames of a loaded swing. They said that it would be useful to be able to produce a print out of a key

frame(s) in the swing, complete with annotations so that the client has a reminder of what was discussed

in the lesson and what they should be working on during their practice sessions.

Michael stated that it would be useful to be able to zoom in on certain areas of the video so that details

such as the golfer’s grip, for example, can be examined more closely.

5.2.2.6 Summary and conclusions of evaluation feedback

Overall, the feedback from the evaluators on the software was very positive. Both Frank and Michael

reported that they had not had any problems when using the software. This provides strong evidence that

testing during the development stages was thorough and that the software is free of any serious bugs,

51

as the software was used for approximately 5 to 8 minutes per lesson; totalling roughly 91 minutes of

constant use. This is not to say that every scenario was tested during normal use, but I am confident that

the testing performed following each iteration of the software development was exhaustive.

Neither of the evaluators have a great deal of experience with existing commercial solutions, although

Frank Houlgate has seen cSwing being used during a teaching convention. It would have been helpful to

receive feedback from the evaluators with regards to how they feel G-SAT compares with other systems

they have used.

During the interview with the evaluators, they were asked whether they would consider using the soft-

ware on a permanent basis. Both Frank and Michael said that they would, and at the time of writing,

Frank was consistently using G-SAT in his lessons. Even more encouragingly; European Tour Profes-

sional (attached at Sand Moor Golf Club), Ben Mason has been using the software for analysis of his

own swing and has made very positive comments with regards to its usefulness. Michael Harrington

stated that he probably would not use the software when teaching beginner and low-level golfers as their

swing faults tend to be very obvious and would not require advanced video analysis. Frank disagreed

with this to a certain extent, saying that golfers of all abilities can benefit from seeing their own swings,

especially when compared against a ’model’ swing.

Myself being a member at Sand Moor Golf Club, I have known Frank and Michael for several years.

I would like to think that this did not affect their feedback and prevent them from being critical of the

software. Perhaps a more stringent evaluation could be carried out by having the software assessed by

several PGA Professionals with whom I am less familiar.

5.3 Future Project Extensions

5.3.1 General Improvements to the Software

The most useful part of the evaluation by Frank and Michael was the feedback I received with regards to

how the software could be improved. The suggestions made could be implemented in future iterations

of the software. These include:

• Ability to hide drawings, as well as erase them completely

• Implementation of an eraser tool for ’rubbing-out’ specific parts of a drawing

• Ability to print selected frames of the swing, complete with any drawings

52

This could improved further by being able to print a single ’summary’ image containing several

overlayed frames from the same swing. This could be done with a simple adaption of the existing

code for overlaying one swing on top of another.

• Ability to zoom in on selected areas of the video

From my own observations of the software being used, I would improve the HCI aspect of the software

by implementing keyboard shortcuts to the functions in the software. These would provide a more

efficient way of using the software for more advanced users.

The initial analysis suggested that the software should possibly allow more than two swings to be loaded

at a time. From my experience of developing and testing the software, I think that this would present

performance issues for the majority of home computers. I think that it would be a good idea to facilitate

the comparison of more of than two swings at a time, but realistically, only high performance machines

would be able to cope with the processing demands.

Writing applications in managed .NET code has a negative affect on the software’s performance due

to the overheads of running in a virtual machine. The performance of G-SAT would be better if it was

written in unmanaged C++ code, and the implementation of a four-way swing comparison feature would

be realistic. However, I do not believe that I would have been able to learn and become adept enough

with C++ to produce the software had I chosen to write it in that language. Writing the software in C#

allowed me to begin coding far sooner and this was key to the project being a success, albeit at the cost

of some performance.

5.3.2 Improvements to the Video Overlay Tool

The overlay tool could be greatly improved by using a background subtraction on the overlay swing.

The problem with overlaying two swings that have been recorded with different backdrops is that the

backgrounds clash creating a rather cluttered image. This quality of the image would be enhanced if the

background of the video being overlayed could be removed, leaving just the golfer. I began working on

the background removal feature, with some success, but was unable to complete it in the available time.

The method for removing the background was to perform an image subtraction on consecutive frames in

the video to produce a new image containing only the difference. With the background remaining fixed

due to the static camera position, this difference should be caused by movements made by the golfer. A

problem I encountered was that only certain parts of the golfer would be visible in the differenced frame

53

as not all of the golfer moves during the swing. For example, at the start of the swing, the lower half

of the golfer remains relatively motionless. Fig. 5.1 shows the result of initial work on the background

subtraction feature.

Figure 5.1: Initial results of using proposed background subtraction method

Another improvement that could me made to the overlay tool would be to allow repositioning of the

overlay so that the two swings can be better aligned. A problem which occurs from overlaying a swing

that has been recorded from a slightly different position, is that the position of the two golfers relative

to the center of the frame are different. This makes comparing the swings more difficult. It would be

better if one could move the overlay swing through the use of the mouse or arrow keys, and this could

be implemented fairly easily.

5.3.3 Frame deinterlacing

Although DirectShow.NET does contain methods for deinterlacing video, they are untested and I did

not have any success with using them. Alternative methods for deinterlacing include using third-party

software such as AviSynth. A possible extension would be to implement deinterlacing capability so that

the clarity of video acquired from a camera would be improved.

54

5.3.4 Implementation of an ’Auto-Crop’ Feature

Another feature that could be implemented that would distinguish the software from any commercially

available solutions would be an auto-cropping feature. This would allow the start and end of the swing

to be located automatically when the video is loaded, and the excess video either side, removed. This

could be implemented using the image subtraction method mentioned above. A video of a golf swing

should have two areas where there is little movement, and therefore little difference between consecutive

frames; at the start of the swing before the golfer takes the club away from the ball, and at the end of

the swing as the golfer holds his finish position. The difference in the image data between consecutive

frames could be calculated and if it falls below a set threshold, then that could be flagged as the start/end

of the swing depending on it’s position relative to the length of the video.

5.3.5 Use of software in other sports

Golf is particularly well suited to video analysis because a golfer remains in the same position whilst

making a swing. Tennis players and particularly skiers are much harder to track with a video camera

making analysis more difficult.

Although the software has been developed for golf swing analysis, it could just as well be used in

other sports such as tennis, skiing (5.2), football (for tactical analysis) and any other ’technical’ sports.

Nevertheless, changes (such as different tools and user-interface details) could be made to G-SAT to

make it suitable for sports such as these. The user could even select his/her sport from a menu, and the

user-interface adapt accordingly.

5.4 Evaluation of Project Management

On the whole, I believe that my project management was strong. I very much enjoyed the software

development aspect of the project and my motivation remained high throughout, meaning that I was

able to get ahead of schedule during the implementation phase; as a result I was able to implement

features that were not in the minimum requirements. However, I do feel that I invested too much time in

ensuring that the software deliverable was as complete and polished as possible - more so than necessary

for meeting the minimum requirements. This meant that I was left with less time for writing the project

report than had initially been allocated in the project schedule. Also, the evaluation by Frank Houlgate

and Michael Harrington was delayed by a week. However, no other major adjustments to the project

55

Figure 5.2: G-SAT being used for skiing technique analysis

schedule were required which is evidence of a sound and realistic initial plan.

56

Bibliography

[1] cSwing. cswing golf swing analysis software. http://www.cswing.com/index.html, January 2006.

[2] DirectShowNet. Directshow.net library. http://directshownet.sourceforge.net/about.html, March

2006.

[3] Graham Wiren (Editor). The PGA Manual of Golf: The Professional’s Way to Play Better Golf.

Hungry Minds Inc, 1997.

[4] Harvey M. Dietel et al. C#: How to Program. Prentice Hall, 2002.

[5] Karol Vrendenburg et atl. User Centered Design: An Integrated Approach (Software Quality

Institute). Prentice Hall PTR, 2001.

[6] V1 Golf. V1 golf swing analysis software. http://www.v1golf.com/consumer/product tour.asp,

February 2006.

[7] The Standish Group. Chaos report. Technical report, The Standish Group, 2004.

[8] Mark Harman. Teaching low-handicap players. Golf Teaching Pro Magazine, October 2005.

[9] Michael Hebron. Golf Mind, Golf Body, Golf Swing. Smithtown Landing Country Club, 1999.

[10] Sun Microsystems. Java. http://www.sun.com/java.

[11] Ray Farmer Simon Bennet, Steve McRobb. Object Oriented Systems Analysis and Design.

McGraw-Hill, 2002.

[12] Tom Stafford. What is deinterlacing? facts, solutions, examples.

http://www.usgtf.com/articles/teaching low handicap.html, June 2005.

[13] A. Cochran & J. Stobbs. The Search for the Perfect Swing. Heinemann, 1968.

57

[14] Tommti Systems. Performance comparison c++, c# and java. http://www.tommti-

systems.de/main-Dateien/reviews/languages/benchmarks.html.

[15] various. Java virtual machine. http://en.wikipedia.org/wiki/JVM, November 2005.

[16] various. Camcorder. http://en.wikipedia.org/wiki/camcorder, March 2006.

[17] various. Gdi. http://en.wikipedia.org/wiki/GDI, January 2006.

[18] various. Incremental build model. http://en.wikipedia.org/wiki/Incremental build model, April

2006.

[19] various. Iterative and incremental development. http://en.wikipedia.org/wiki/iterative development,

April 2006.

[20] various. Waterfall model. http://en.wikipedia.org/wiki/Waterfall model, April 2006.

58

Appendix A

Personal Reflection

Choosing a project title can be a very difficult task. I believe that it is vitally important that a project is

chosen in which the student has a genuine interest. I found it easy to motivate myself to work on my

project as I have a strong interest in golf and the problem I was attempting to solve.

With software development projects such as this, it can be easy to get carried away trying to produce

a perfect, polished industry-standard piece of software; and in doing so, invest too much time in the

software deliverable. One must remember that only the project report is actually marked and therefore

sufficient time should be allocated to doing a proper job of it. I certainly feel that I fell into this trap

and as a result was unable to gain the benefit of getting feedback from my supervisors on the written

deliverables. The upside to this is that I feel that I have produced a piece of software of which I can be

proud and will certainly use in the future for personal benefit. I am certainly going to consider ’polish-

ing’ the software further and making the changes suggested in the evaluation section so that it can be

made commercially available.

My experience with this project has certainly strengthened my belief in the RAD approach to software

development. Using an iterative process allowed to me begin coding far quicker than if I was following

the traditional waterfall model of software development. This in turn, allowed me to assess whether the

59

project could realistically be a success as I had strong initial doubts as to whether my technical skills

were sufficient to take on an ambitious project. I would strongly advise students who take on bold tech-

nical projects to consider using a similar development process, rather than spending large amounts of

time producing wonderful designs only to find, for one reason or another, that it cannot be implemented.

I treated the user requirements as individual components of functionality in the software and applied

the iterative development methodology to each component in turn. This allowed to me make significant

design changes to one component without affecting any of the others. Several such design changes were

made when the testing of early iterations indicated that the initial design was unfeasible. The flexibility

of this approach was key to the project success.

The software produced in this project was evaluated by two professional golfers, who used the software

for a period of one week before providing me with feedback in the form of an interview. I have known

the evaluators used in this project for several years and whilst I hope that this did not influence their

comments made in the interview, I think that in order to get a more objective and frank opinion, students

should use third parties with whom they are unfamiliar or know only a professional level.

Having chosen to develop the software in C#, a language with which I had no previous experience,

I would now consider myself to be a competent C# programmer. I am particularly pleased with the

decision to leave my Java ’comfort zone’ as this allowed me to develop new skills as a programmer in a

language which I believe will become increasingly popular over the next few years. I would recommend

students who take on software development projects to consider using development tools with which

they are unfamiliar as more will be gained from the final year project experience.

60

Appendix B

Project Schedule

Figure B.1: Original Project Schedule

61

Appendix C

Glossary of Golf Terminology Used in

Report

approach shot A shot played from the fairway, to the green.

clubhead The part of the golf club at the end of the shaft which strikes the ball.

drive See tee shot.

hook Ball starts right of the target and curves to the left, finishing well to the left of

the target.

pull The ball start to the left of the target and flies without curvature in a straight

line, finishing to the left of the target.

push The ball starts to the right of the target and flies without curvature in a straight

line, finishing to the right of the target.

slice Ball starts left of the target and curves to the right, finishing well to the right

of the target.

tee shot A shot played from the tee (ideally) onto the fairway.

62

Appendix D

Questions Asked During Evaluation

Interviews

• Did you find using the software in your lessons to be beneficial? Why?/Why not?

• Did you find the software to be user-friendly and intuitive? How could this be improved?

• Did you make use of the ’overlay’ feature, and if so did you find it be useful?

• Which features of the software did you find to be the most/least useful?

• Are there any other features that you would like to see included in the software?

• Did you encounter any problems whilst using the software? Give details if so.

• How does G-SAT compare to other systems you have used in terms of both functionality and

usability?

• Would you consider using the software in your lessons on a permanent basis?

• Would you consider purchasing the software if it was commercially available?

If so, what sort of price do you think would be reasonable?

63