The Open Perimetry Interface: An enabling tool for clinical visual psychophysics

Abstract

Abstract

Abstract:

Abstract  Perimeters are commercially available instruments for measuring various attributes of the visual field in a clinical setting. They have several advantages over traditional lab-based systems for conducting vision experiments, including built-in gaze tracking and calibration, polished appearance, and attributes to increase participant comfort. Prior to this work, there was no standard to control such instruments, making it difficult and time consuming to use them for novel psychophysical experiments. This paper introduces the Open Perimetry Interface (OPI), a standard set of functions that can be used to control perimeters. Currently the standard is partially implemented in the open-source programming language R on two commercially available instruments: the Octopus 900 (a projection-based bowl perimeter produced by Haag-Streit, Switzerland) and the Heidelberg Edge Perimeter (a CRT-based system produced by Heidelberg Engineering, Germany), allowing these instruments to be used as a platform for psychophysical experimentation.

Introduction

Laboratory-based psychophysics has a long history of free, open-source software tools to enable experiments (for example, see Brainard, 1997; Peirce, 2007; Pelli, 1997; and others in Hans Strasburger's compiled list [Strasburger, 2012]). Combined with the low cost of computer hardware, these tools enable behavioral experiments to be easily constructed. However, it is often difficult to translate such experiments into a clinical setting. Some experiments rely on replicating clinical conditions as closely as possible, and so benefit from using actual clinical instruments. Often laboratory equipment is not readily portable, and so moving the equipment into a clinical setting is difficult. Finally, participants are often members of the general public, so their comfort and the appearance of the instrument and testing environment may be important to recruitment and retention. 

Consider visual field examinations, for example, which are key diagnostic and monitoring tools for disorders of the visual pathway used in the clinic. To date, nearly all reported experiments with novel stimuli or test algorithms have been performed on custom-built laboratory equipment. The barriers to using commercial instruments in novel, nontrivial experiments for visual functional assessment have been considerable. 

Using a perimeter, as these commercial instruments are known, for conducting psychophysical tests has several advantages. Depending on the instrument, the following may be possible: 

•  
  Presentation of high luminance stimuli (upwards of 3000 cd/m²)
•  
  Presentation of stimuli well into the peripheral visual field (up to ±90° from central fixation)
•  
  Pupil and fixation monitoring with built-in gaze tracking
•  
  Built-in calibration
•  
  Collection of accurate response times

Employing standard, mass produced instruments also facilitates standardization of test equipment across multiple sites, assisting collaborations and data collection. Apart from useful hardware, perimeters are designed to be used in professional medical clinics, and so are ergonomic and cosmetically appealing. 

The remainder of this paper describes a standard we have developed that can be used to control perimeters, the Open Perimetry Interface (OPI), which is part of the Open Perimetry Initiative (OPI, 2012). We describe the interface, the platforms on which it has been implemented, and give a small example of its use. 

Methods

The main goal of the development of the OPI was to remove barriers that were preventing researchers from using commercial perimetric instruments for scientific experiments. These barriers include cost, knowledge, and availability. As such, the OPI is designed according to the following guiding principles. 

Implementations of the OPI should be open source and free for all to use. In an ideal world, implementations of the OPI should be readily and freely available; however, there are possible legal ramifications if the OPI is misused for clinical rather than scientific objectives. As such, the model we have adopted is that manufacturers remain gatekeepers of specific software libraries that are required for the OPI to run on their instrument. OPI code that makes use of these libraries is all open source under the GNU General Public License (GPL, 2012). 

Every attempt will be made to support the OPI in the open source tradition with an active web site that includes FAQs, forums and an active user community (OPI, 2012). 

The OPI should be comprehensible by vision scientists. As vision scientists will most likely be the end users of OPI implementations, we have endeavored to hide many of the engineering and computing decisions that must take place in order to control perimeters. The OPI is a simple, and hopefully intuitive, set of functions that should be accessible to a wide range of users. 

The OPI should allow all programming of current and proposed perimetric techniques, and allow incorporation of new developments. Naturally it is difficult to foresee how perimeters may be used for experimentation in the future. To allow for future developments, the OPI is small and low-level, specifying a minimum set of functions for stimulus production and response gathering. Open source libraries can easily be built on top of the OPI and shared publicly. 

Code that uses the OPI should be easily transferable between different platforms. Current practice in perimetric research is to simulate methods before implementing them in instruments for clinical testing (Bengtsson, Olsson, Heijl, & Rootzen, 1997; Glass, Schaumberger, & Lachenmayr, 1995; King-Smith, Grigsby, Vingrys, Benes, & Supowit, 1994; Turpin, McKendrick, Johnson, & Vingrys, 2002]. Ideally, the simulation code can be written using the OPI, and then the exact code transferred to hardware with minimal change to prevent recoding errors. Furthermore, the code should run on any platform that implements the OPI with minimal changes. 

Results

Currently the OPI is specified in R, an open source language that is rapidly becoming a lingua franca in scientific research (R, 2012), but can be ported to any language supporting functions such as Matlab, C, Java, Python, and so on. The specification consists of the following five functions: 

• opiInitialize(…)  
  Get the perimeter ready to receive further commands.
• opiQueryDevice(…)  
  Get information about the perimeter.
• opiSetBackground(…)  
   Set the background color, luminance, and so on, of the perimeter.
• opiPresent(…)  
  Present a stimulus and return response information.
• opiClose(…)  
  Tell the perimeter it is not needed for OPI anymore.

The main workhorse, opiPresent, can take three different stimulus types: opiStaticStimulus, which allows for stimuli that have only a trivial on/off temporal component (for example, do not flicker); opiTemporalStimulus, which allows for cycling through a lookup table of images at a given temporal frequency; and opiKineticStimulus, which allows specification of paths and speeds for kinetic stimuli. It returns a list of information including seen/not-seen if the response button is pressed and the latency of the response. Other, instrument specific data, such as gaze information, can also be returned. 

Note that the OPI standard relies on the instrument itself for correctness of stimulus attributes such as target location, size, luminance, and so on. It is up to the manufacturers to determine that what the OPI specifies is what is actually displayed. 

Current implementations

At the time of writing, two manufacturers have committed to implementing the OPI on their instruments: Haag-Streit International (Switzerland), for the Octopus 900 perimeter; and Heidelberg Engineering (Germany), for their Heidelberg Edge Perimeter. Both have initial versions implemented that allow use of the R language to produce static stimuli. 

Octopus 900

The Octopus 900 is a projection perimeter controlled by an external PC. The OPI runs as an R package that calls Java routines, which, in turn, interface with the standard EyeSuite software provided by Haag-Streit on the same PC. The ability to present static targets as in conventional automated perimetry is available, allowing targets to be specified to the resolution of one tenth of a degree, and at an intensity at a resolution of one tenth of a dB. The maximum available intensity is 3183 cd/m², which is defined as 0 dB. The stimulus sizes are limited by the aperture wheel in the instrument, which includes Goldmann sizes I through V. These stimuli sizes are historically used in perimetry and have diameters of: I 0.11, II 0.22, III 0.43, IV 0.86, and V 1.72 degrees of visual angle at a viewing distance of 30 cm (Goldmann, 1945). 

Heidelberg Edge Perimeter

The HEP is a compact instrument based on a 9-inch CRT display (Heidelberg Engineering, Heidelberg, Germany) with resolution 1024 × 768 and a maximum luminance of 100 cd/m² run by an onboard PC (Heidelberg Engineering). It also includes a charge-coupled device video camera (Heidelberg Engineering) and infrared illumination that is used for gaze monitoring. As for the Octopus 900, the OPI is implemented as an R package that acts as a client, interfacing with a custom server program that is installed on the instrument itself. At the time of writing, the ability to present gray-scale circular luminance increment stimuli of any diameter (subject to the resolution of the screen and maximum luminance of the monitor) at any location on a grid with a granularity of one degree is possible. The same is also true for the custom Flicker Defined Form (FDF) stimulus that ships with the Heidelberg Edge Perimeter. 

Discussion

The utility of the OPI hinges on its ability to reduce the barriers for exploiting perimeters in research projects. Thus it has been designed to be simple to use, with many of the technical details of stimuli production hidden from the user; to be open source, hence, not requiring money to purchase; and to be well documented, including an online forum and FAQ page to support users. 

Current commercially available perimeters are not readily programmable, hence the need for the OPI. This has generally been the case in the past, with several ad hoc exceptions. The first Humphrey Field Analyzer, manufactured from 1984 to 1995 in the United States, allowed external control over an RS232 port and a custom cable, hence was utilized for nontrivial experiments (Chauhan, Tompkins, LeBlanc, & McCormick, 1993; Johnson, Turpin, & Spry, 2001; Wall, Maw, Stanek, & Chauhan, 1996). Unfortunately this capability is no longer available on newer Humphrey Field Analyzer II instruments. 

It has also been possible for individual researchers to communicate directly with some manufacturers to develop custom programs for specific tasks. Haag-Streit made available custom programs for their Octopus 1-2-3, 300, and 101 machines. These one-off interfaces were used by several research groups (Gonzalez de la Rosa et al., 1996; Matsumoto, et al., 2006; Okuyama, Matsumoto, Uyama, Otsuji, & Otori, 1994; Todorova, Palmowski-Wolfe, Bebie, Flammer, & Monhart, 2011; Vonthein et al., 2007). 

As of June 2012, two commercially available perimeters can be controlled externally using the OPI coded in R to display briefly presented, circular luminance increments, and to collect response time and gaze tracking information. It is envisaged that by the end of 2012, both will offer full control of their instruments using the same mechanism, expanding their role as viable platforms for psychophysical research. As different, commercial instruments develop, we hope that not only will they provide OPI access to their instruments, but also that the OPI can be adapted to incorporate currently unforeseen features of that instrument. 

It is perhaps worth noting that there is no plan for the OPI standard to incorporate access to proprietary data and software on commercial machines. For example, there is no OPI standard specifying how normative databases that exist on all commercially available perimeters could be accessed. If individual manufacturers wish to make these available in addition to the OPI routines, that would be most welcome, but is not mandated by the OPI standard. 

Perimetric equipment has become significantly more sophisticated, including gaze monitoring, improved ergonomics, and a compact footprint. The OPI suggests a wider role for this instrumentation beyond research directly aimed at perimetric questions. 

Conclusion

We encourage anyone interested in conducting perimetry-related experiments in a clinical setting to download and use the OPI for their favorite platform, after obtaining the appropriate libraries from the device's manufacturer. Visit http://perimetry.org/opi for more information. 

Supplementary Materials

PDF S1 

Acknowledgments

The authors thank Matthias Monhart and Alfred Wiederkehr for their assistance in developing the Octopus 900 implementation of the OPI; and Gerhard Zinser, Diana Helling, John Flanagan, and Jim Cassidy for developing the HEP implementation of the OPI. This work was supported by Australian Research Council grant FT0991326 (AT). 

Commercial relationships: none. 

Corresponding author: Andrew Turpin. 

Email: [e-mail] 

Address: Department of Computing and Information Science, University of Melbourne, Australia. 

Appendix: A small, annotated example

Assume we wish to estimate a psychometric function (Frequency of Seeing curve, as it is known in the perimetry literature [Henson, Chaudry, Artes, Faragher, & Ansons, 2000; P. Spry & Johnson, 2002; P. G. D. Spry, Johnson, McKendrick, & Turpin, 2001; Wall, Kutzko, & Chauhan, 2002]) at a single location in the field: say location (−3°, 6°) from central fixation. We suspect that the threshold (50% point on the curve) is about 26 dB, and so test values {23, 24, . . . , 29} 20 times each. The following OPI code accomplishes this. 

err <– opiInitialize("left”)	# Establish connection to # the instrument
if (!is.null(err))	# Check it opened OK
stop("Trouble opening OPI connection”)
stim <– rep(23:29,20)	# Setup all stimuli
stim <– stim[order(runif(length(stim)))]	# and randomly shuffle # their order
for (i in 1:length(stim)) {
s <– list(x = −3, y = 6, level = stim[i])	# Create list of stimulus # attributes
class(s) <– “opiStaticStimulus"	# Tell OPI what sort of # stimulus s is
result <– opiPresent(stim)	# Pass the stimulus to # the instrument
if (!is.null(result$err))	# Check the result is ok
stop(paste("OPI Error:”, result$err, “presenting”, stim))
else
if (result$seen)
...	# Process a seen # response
}
err <– opiClose()	# Close connection to # the instrument
if (!is.null(err))
stop(paste("OPI Error closing instrument:”,err))