GB2523554A - Head-mountable apparatus and systems - Google Patents

Abstract

A head mountable display (HMD) comprises: a detection arrangement 450, 460 to detect the position of the HMD and supply position data to a game engine 500; a display 510 to display images generated by the game engine at an image orientation responsive to position data supplied by the HMD; and a latency detection arrangement to detect a time period between a change in position of the HMD and a corresponding change in the image orientation of images generated by the game engine, comprising: a position data generator 700, 710, 720 to provide position data to the game engine, in place of that generated by the detection arrangement, which is independent of actual motion of the HMD, and providing first position data 700 followed by second position data 710, 720 indicative of a different position; and an image correlation detector 730, 740, 750 to detect a time period between the second position data being supplied to the game engine and a test image area in the images generated by the game engine moving from an original image position to a new image position displaced by an amount dependent upon a difference between the first and second positions.

Description

HEAD-MOUNTABLE APPARATUS AND SYSTEMS

This invention relates to head-mountable apparatus and systems.

A head-mountable display (HMD) is one example of a head-mountable apparatus. In an HMD, an image or video display device is provided which may be worn on the head or as part of a helmet. Either one eye or both eyes are provided with small electronic display devices.

Some HMD5 allow a displayed image to be superimposed on a real-world view. This type of HMD can be referred to as an optical see-through HMD and generally requires the display devices to be positioned somewhere other than directly in front of the user's eyes.

Some way of deflecting the displayed image so that the user may see it is then required. This might be through the use of a partially reflective mirror placed in front of the user's eyes so as to allow the user to see through the mirror but also to see a reflection of the output of the display devices. In another arrangement, disclosed in EP-A-1 731 943 and US-A-2010/0157433, a waveguide arrangement employing total internal reflection is used to convey a displayed image from a display device disposed to the side of the user's head so that the user may see the displayed image but still see a view of the real world through the waveguide. Once again, in either of these types of arrangement, a virtual image of the display is created (using known techniques) so that the user sees the virtual image at an appropriate size and distance to allow relaxed viewing. For example, even though the physical display device may be tiny (for example, 10 mm x 10 mm) and may be just a few millimetres from the user's eye, the virtual image may be arranged so as to be perceived by the user at a distance of (for example) 20 m from the user, having a perceived size of 5 m x 5m.

Other HMD5, however, allow the user only to see the displayed images, which is to say that they obscure the real world environment surrounding the user. This type of HMD can position the actual display devices in front of the user's eyes, in association with appropriate lenses or other optical components which place a virtual displayed image at a suitable distance for the user to focus in a relaxed manner -for example, at a similar virtual distance and perceived size as the optical see-through HMD described above. This type of device might be used for viewing movies or similar recorded content, or for viewing so-called virtual reality content representing a virtual space surrounding the user. It is of course however possible to display a real-world view on this type of HMD, for example by using a forward-facing camera to generate images for display on the display devices.

Although the original development of HMD5 was perhaps driven by the military and professional applications of these devices, HMD5 are becoming more popular for use by casual users in, for example, computer game or domestic computing applications.

In many HMD5, when the user turns his or her head, the displayed image is also moved (in terms of changing its display position with respect to the HMD) so that the displayed image appears locked to a fixed location in real space. So, for example, if the user's head rotates to the left, the rotation is detected by a suitable detector and the displayed images are moved to the right so as to appear still to be placed at the same position in real space. Another way of considering this process is that the displayed image represents a currently visible window onto a larger notional image which is stationary with respect to real space.

Various aspects and features of the present invention are defined in the appended claims and within the text of the accompanying description and include at least a head mountable apparatus such as a display and a method of operating a head-mountable apparatus as well as a computer program.

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 schematically illustrates an HMD worn by a user; Figure 2 is a schematic plan view of an HMD; Figure 3 schematically illustrates the formation of a virtual image by an HMD; Figure 4 schematically illustrates another type of display for use in an HMD; Figure 5 schematically illustrates a pair of stereoscopic images; Figures 6 and 7 schematically illustrate a user wearing an HMD connected to a Sony® PlayStation 3® games console; Figure 8 schematically illustrates a change of view of user of an HMD; Figures 9a and 9b schematically illustrate HMDs with motion sensing; Figure 10 schematically illustrates a position sensor based on optical flow detection; Figure 11 schematically illustrates the generation of images in response to HMD position or motion detection; Figures 12 and 13 schematically illustrate HMD position detection in cooperation with a video game; Figure 14 schematically illustrates a latency problem; Figure 15 schematically illustrates a latency detector; Figure 16 is a schematic flowchart illustrating aspects of the operation of the detector of Figure 15; and Figures 17 to 22 are schematic representations of example display images at different stages in the operations of Figure 16.

Referring now to Figure 1, a user lOis wearing an HMD 20 (as an example of a generic head-mountable apparatus -other examples including audio headphones or a head-mountable light source) on the usei's head 30. The HMD comprises a frame 40, in this example formed of a rear strap and a top strap, and a display pofton 50.

Note that the HMD of Figure 1 may comprise further features, to be described below in connection with other drawings, but which are not shown in Figure 1 for clarity of this initial explanation.

The HMD of Figure 1 completely (or at least substantially completely) obscures the user's view of the surrounding environment. All that the user can see is the pair of images displayed within the HMD.

The HMD has associated headphone audio transducers or earpieces 60 which fit into the user's left and right ears 70. The earpieces 60 replay an audio signal provided from an external source, which may be the same as the video signal source which provides the video signal for display to the user's eyes.

The combination of the fact that the user can see only what is displayed by the HMD and, subject to the limitations of the noise blocking or active cancellation properties of the earpieces and associated electronics, can hear only what is provided via the earpieces, mean that this HMD may be considered as a so-called "full immersion" HMD. Note however that in some embodiments the HMD is not a full immersion HMD, and may provide at least some facility for the user to see and/or hear the user's surroundings. This could be by providing some degree of transparency or partial transparency in the display arrangements, and/or by projecting a view of the outside (captured using a camera, for example a camera mounted on the HMD) via the HMD's displays, and/or by allowing the transmission of ambient sound past the earpieces and/or by providing a microphone to generate an input sound signal (for transmission to the earpieces) dependent upon the ambient sound.

A front-facing camera 122 may capture images to the front of the HMD, in use. A Bluetooth® antenna 124 may provide communication facilities or may simply be arranged as a directional antenna to allow a detection of the direction of a nearby Bluetooth transmitter.

In operation, a video signal is provided for display by the HMD. This could be provided by an external video signal source 80 such as a video games machine or data processing apparatus (such as a personal computer), in which case the signals could be transmitted to the HMD by a wired or a wireless connection 82. Examples of suitable wireless connections include Bluetooth® connections. Audio signals for the earpieces 60 can be carried by the same connection. Similarly, any control signals passed from the HMD to the video (audio) signal source may be carried by the same connection. Furthermore, a power supply 83 (including one or more batteries and/or being connectable to a mains power outlet) may be linked by a cable 84 to the HMD. Note that the power supply 83 and the video signal source 80 may be separate units or may be embodied as the same physical unit. There may be separate cables for power and video (and indeed for audio) signal supply, or these may be combined for carriage on a single cable (for example, using separate conductors, as in a USB cable, or in a similar way to a "power over Ethernet" arrangement in which data is carried as a balanced signal and power as direct current, over the same collection of physical wires). The video and/or audio signal may be carried by, for example, an optical fibre cable. In other embodiments, at least part of the functionality associated with generating image and/or audio signals for presentation to the user may be carried out by circuitry and/or processing forming part of the HMD itself. A power supply may be provided as part of the HMD itself.

Some embodiments of the invention are applicable to an HMD having at least one electrical and/or optical cable linking the HMD to another device, such as a power supply and/or a video (and/or audio) signal source. So, embodiments of the invention can include, for

example:

(a) an HMD having its own power supply (as part of the HMD arrangement) but a cabled connection to a video and/or audio signal source; (b) an HMD having a cabled connection to a power supply and to a video and/or audio signal source, embodied as a single physical cable or more than one physical cable; (c) an HMD having its own video and/or audio signal source (as part of the HMD arrangement) and a cabled connection to a power supply; or (d) an HMD having a wireless connection to a video and/or audio signal source and a cabled connection to a power supply.

If one or more cables are used, the physical position at which the cable 82 and/or 84 enters or joins the HMD is not particularly important from a technical point of view. Aesthetically, and to avoid the cable(s) brushing the user's face in operation, it would normally be the case that the cable(s) would enter or join the HMD at the side or back of the HMD (relative to the orientation of the user's head when worn in normal operation). Accordingly, the position of the cables 82, 84 relative to the HMD in Figure 1 should be treated merely as a schematic representation.

Accordingly, the arrangement of Figure 1 provides an example of a head-mountable display system comprising a frame to be mounted onto an observer's head, the frame defining one or two eye display positions which, in use, are positioned in front of a respective eye of the observer and a display element mounted with respect to each of the eye display positions, the display element providing a virtual image of a video display of a video signal from a video signal source to that eye of the observer.

Figure 1 shows just one example of an HMD. Other formats are possible: for example an HMD could use a frame more similar to that associated with conventional eyeglasses, namely a substantially horizontal leg extending back from the display portion to the top rear of the user's ear, possibly curling down behind the ear. In other (not full immersion) examples, the user's view of the external environment may not in fact be entirely obscured; the displayed images could be arranged so as to be superposed (from the users point of view) over the external environment. An example of such an arrangement will be described below with reference to Figure 4.

In the example of Figure 1, a separate respective display is provided for each of the user's eyes. A schematic plan view of how this is achieved is provided as Figure 2, which illustrates the positions 100 of the users eyes and the relative position 110 of the user's nose.

The display portion 50, in schematic form, comprises an exterior shield 120 to mask ambient light from the user's eyes and an internal shield 130 which prevents one eye from seeing the display intended for the other eye. The combination of the users face, the exterior shield 120 and the interior shield 130 form two compartments 140, one for each eye. In each of the compartments there is provided a display element 150 and one or more optical elements 160.

The way in which the display element and the optical element(s) cooperate to provide a display to the user will be described with reference to Figure 3.

Referring to Figure 3, the display element 150 generates a displayed image which is (in this example) refracted by the optical elements 160 (shown schematically as a convex lens but which could include compound lenses or other elements) so as to generate a virtual image 170 which appears to the user to be larger than and significantly further away than the real image generated by the display element 150. As an example, the virtual image may have an apparent image size (image diagonal) of more than 1 m and may be disposed at a distance of more than 1 m from the users eye (or from the frame of the HMD). In general terms, depending on the purpose of the HMD, it is desirable to have the virtual image disposed a significant distance from the user. For example, if the HMD is for viewing movies or the like, it is desirable that the user's eyes are relaxed during such viewing, which requires a distance (to the virtual image) of at least several metres. In Figure 3, solid lines (such as the line 180) are used to denote real optical rays, whereas broken lines (such as the line 190) are used to denote virtual rays.

An alternative arrangement is shown in Figure 4. This arrangement may be used where it is desired that the user's view of the external environment is not entirely obscured. However, it is also applicable to HMD5 in which the users external view is wholly obscured. In the arrangement of Figure 4, the display element 150 and optical elements 200 cooperate to provide an image which is projected onto a mirror 210, which deflects the image towards the user's eye position 220. The user perceives a virtual image to be located at a position 230 which is in front of the user and at a suitable distance from the user.

In the case of an HMD in which the user's view of the external surroundings is entirely obscured, the mirror 210 can be a substantially 100% reflective mirror. The arrangement of Figure 4 then has the advantage that the display element and optical elements can be located closer to the centre of gravity of the user's head and to the side of the users eyes, which can produce a less bulky HMD for the user to wear. Alternatively, if the HMD is designed not to completely obscure the useis view of the external environment, the mirror 210 can be made partially reflective so that the user sees the external environment, through the mirror 210, with the virtual image superposed over the real external environment.

In the case where separate respective displays are provided for each of the users eyes, it is possible to display stereoscopic images. An example of a pair of stereoscopic images for display to the left and right eyes is shown in Figure 5. The images exhibit a lateral displacement relative to one another, with the displacement of image features depending upon the (real or simulated) lateral separation of the cameras by which the images were captured, the angular convergence of the cameras and the (real or simulated) distance of each image feature from the camera position.

Note that the lateral displacements in Figure 5 could in fact be the other way round, which is to say that the left eye image as drawn could in fact be the right eye image, and the right eye image as drawn could in fact be the left eye image. This is because some stereoscopic displays tend to shift objects to the right in the right eye image and to the left in the left eye image, so as to simulate the idea that the user is looking through a stereoscopic window onto the scene beyond. However, some HMD5 use the arrangement shown in Figure 5 because this gives the impression to the user that the user is viewing the scene through a pair of binoculars. The choice between these two arrangements is at the discretion of the system designer.

In some situations, an HMD may be used simply to view movies and the like. In this case, there is no change required to the apparent viewpoint of the displayed images as the user turns the user's head, for example from side to side. In other uses, however, such as those associated with virtual reality (VR) or augmented reality (AR) systems, the user's viewpoint needs to track movements with respect to a real or virtual space in which the user is located.

Figure 6 schematically illustrates a user wearing an HMD connected to a Sony® Playstation 3® games console 300 as an example of a base device. (Another equally applicable example of a base device is a Sony® PlayStation 4® games console). The games console 300 is connected to a mains power supply 310 and (optionally) to a main display screen (not shown). A cable, acting as the cables 82, 84 discussed above (and so acting as both power supply and signal cables), links the HMD 20 to the games console 300 and is, for example, plugged into a IJSB socket 320 on the console 300. Note that in the present embodiments, a single physical cable is provided which fulfils the functions of the cables 82, 84. In Figure 6, the user is also shown holding a hand-held controller 330 which may be, for example, a Sony® Move® controller which communicates wirelessly with the games console 300 to control (or to contribute to the control of) game operations relating to a currently executed game program.

The video displays in the HMD 20 are arranged to display images generated by the games console 300, and the earpieces 60 in the HMD 20 are arranged to reproduce audio signals generated by the games console 300. Note that if a USB type cable is used, these signals will be in digital form when they reach the HMD 20, such that the HMD 20 comprises a digital to analogue converter (DAC) to convert at least the audio signals back into an analogue form for reproduction.

Images from the camera 122 mounted on the HMD 20 are passed back to the games console 300 via the cable 82, 84. Similarly, if motion or other sensors are provided at the HMD 20, signals from those sensors may be at least partially processed at the HMD 20 and/or may be at least partially processed at the games console 300. The use and processing of such signals will be described further below.

The USB connection from the games console 300 also provides power to the HMD 20, according to the USB standard.

Figure 7 schematically illustrates a similar arrangement in which the games console is connected (by a wired or wireless link) to a so-called "break out box" acting as a base or intermediate device 350, to which the HMD 20 is connected by a cabled link 82, 84. The breakout box has various functions in this regard. One function is to provide a location, near to the user, for some user controls relating to the operation of the HMD, such as (for example) one or more of a power control, a brightness control, an input source selector, a volume control and the like. Another function is to provide a local power supply for the HMD (if one is needed according to the embodiment being discussed). Another function is to provide a local cable anchoring point. In this last function, it is not envisaged that the break-out box 350 is fixed to the ground or to a piece of furniture, but rather than having a very long trailing cable from the games console 300, the break-out box provides a locally weighted point so that the cable 82, 84 linking the HMD 20 to the break-out box will tend to move around the position of the break-out box. This can improve user safety and comfort by avoiding the use of very long trailing cables.

It will be appreciated that the localisation of processing in the various techniques described in this application can be varied without changing the overall effect, given that an HMD may form part of a set or cohort of interconnected devices (that is to say, interconnected for the purposes of data or signal transfer, but not necessarily connected by a physical cable).

So, processing which is described as taking place "at' one device, such as at the HMD, could be devolved to another device such as the games console (base device) or the break-out box.

Processing tasks can be shared amongst devices. Source signals, on which the processing is to take place, could be distributed to another device, or the processing results from the processing of those source signals could be sent to another device, as required. So any references to processing taking place at a particular device should be understood in this context.

Similarly, where an interaction between two devices is basically symmetrical, for example where a camera or sensor on one device detects a signal or feature of the other device, it will be understood that unless the context prohibits this, the two devices could be interchanged without any loss of functionality.

As mentioned above, in some uses of the HMD, such as those associated with virtual reality (VR) or augmented reality (AR) systems, the user's viewpoint needs to track movements with respect to a real or virtual space in which the user is located.

This tracking is carried out by detecting motion of the HMD and varying the apparent viewpoint of the displayed images so that the apparent viewpoint tracks the motion.

Figure 8 schematically illustrates the effect of a user head movement in a VR or AR system.

Referring to Figure 8, a virtual environment is represented by a (virtual) spherical shell 250 around a user. Because of the need to represent this arrangement on a two-dimensional paper drawing, the shell is represented by a part of a circle, at a distance from the user equivalent to the separation of the displayed virtual image from the user. A user is initially at a first position 260 and is directed towards a portion 270 of the virtual environment. It is this portion 270 which is represented in the images displayed on the display elements 150 of the user's HMD.

Consider the situation in which the user then moves his head to a new position and/or orientation 280. In order to maintain the correct sense of the virtual reality or augmented reality display, the displayed portion of the virtual environment also moves so that, at the end of the movement, a new portion 290 is displayed by the HMD.

So, in this arrangement, the apparent viewpoint within the virtual environment moves with the head movement. If the head rotates to the right side, for example, as shown in Figure 8, the apparent viewpoint also moves to the right from the user's point of view. If the situation is considered from the aspect of a displayed object, such as a displayed object 300, this will effectively move in the opposite direction to the head movement. So, if the head movement is to the right, the apparent viewpoint moves to the right but an object such as the displayed object 300 which is stationary in the virtual environment will move towards the left of the displayed image and eventually will disappear off the left-hand side of the displayed image, for the simple reason that the displayed portion of the virtual environment has moved to the right whereas the displayed object 300 has not moved in the virtual environment.

Figures 9a and 9b schematically illustrated HMD5 with motion sensing. The two drawings are in a similar format to that shown in Figure 2. That is to say, the drawings are schematic plan views of an HMD, in which the display element 150 and optical elements 160 are represented by a simple box shape. Many features of Figure 2 are not shown, for clarity of the diagrams. Both drawings show examples of HMD5 with a motion detector for detecting motion of the observer's head.

In Figure Ga, a forward-facing camera 322 is provided on the front of the HMD. This may be the same camera as the camera 122 discussed above, or may be an additional camera.

This does not necessarily provide images for display to the user (although it could do so in an augmented reality arrangement). Instead, its primary purpose in the present embodiments is to allow motion sensing. A technique for using images captured by the camera 322 for motion sensing will be described below in connection with Figure 10. In these arrangements, the motion detector comprises a camera mounted so as to move with the frame; and an image comparator operable to compare successive images captured by the camera so as to detect inter-image motion.

Figure 9b makes use of a hardware motion detector 332. This can be mounted anywhere within or on the HMD. Examples of suitable hardware motion detectors are piezoelectric accelerometers or optical fibre gyroscopes. It will of course be appreciated that both hardware motion detection and camera-based motion detection can be used in the same device, in which case one sensing arrangement could be used as a backup when the other one is unavailable, or one sensing arrangement (such as the camera) could provide data for changing the apparent viewpoint of the displayed images, whereas the other (such as an accelerometer) could provide data for image stabilisation.

Figure 10 schematically illustrates one example of motion detection using the camera 322 of Figure Ga.

The camera 322 is a video camera, capturing images at an image capture rate of, for example, 25 images per second. As each image is captured, it is passed to an image store 400 for storage and is also compared, by an image comparator 410, with a preceding image retrieved from the image store. The comparison uses known block matching techniques (so-called "optical flow" detection) to establish whether substantially the whole image has moved since the time at which the preceding image was captured. Localised motion might indicate moving objects within the field of view of the camera 322, but global motion of substantially the whole image would tend to indicate motion of the camera rather than of individual features in the captured scene, and in the present case because the camera is mounted on the HMD, motion of the camera corresponds to motion of the HMD and in turn to motion of the user's head.

The displacement between one image and the next, as detected by the image comparator 410, is converted to a signal indicative of motion by a motion detector 420. If required, the motion signal is converted to a position signal by an integrator 430.

As mentioned above, as an alternative to, or in addition to, the detection of motion by detecting inter-image motion between images captured by a video camera associated with the HMD, the HMD can detect head motion using a mechanical or solid state detector 332 such as an accelerometer. This can in fact give a faster response in respect of the indication of motion, given that the response time of the video-based system is at best the reciprocal of the image capture rate. In some instances, therefore, the detector 332 can be better suited for use with higher frequency motion detection. However, in other instances, for example if a high image rate camera is used (such as a 200 Hz capture rate camera), a camera-based system may be more appropriate. In terms of Figure 10, the detector 332 could take the place of the camera 322, the image store 400 and the comparator 410, so as to provide an input directly to the motion detector 420. Or the detector 332 could take the place of the motion detector 420 as well, directly providing an output signal indicative of physical motion.

Other position or motion detecting techniques are of course possible. For example, a mechanical arrangement by which the HMD is linked by a moveable pantograph arm to a fixed point (for example, on a data processing device or on a piece of furniture) may be used, with position and orientation sensors detecting changes in the deflection of the pantograph arm. In other embodiments, a system of one or more transmitters and receivers, mounted on the HMD and on a fixed point, can be used to allow detection of the position and orientation of the HMD by triangulation techniques. For example, the HMD could carry one or more directional transmitters, and an array of receivers associated with known or fixed points could detect the relative signals from the one or more transmitters. Or the transmifters could be fixed and the receivers could be on the HMD. Examples of transmitters and receivers include infra-red transducers, ultrasonic transducers and radio frequency transducers. The radio frequency transducers could have a dual purpose, in that they could also form part of a radio frequency data link to and/or from the HMD, such as a Bluetooth® link.

Figure 11 schematically illustrates image processing carried out in response to a detected position or change in position of the HMD. Figures 11, 12, 13 and 15 provide an example of a head mountable display (HMD) comprising: a detection arrangement operable to detect the rotational position of the HMD and to supply position data to a game engine indicative of the detected rotational position; and a display operable to receive and display images generated by the game engine at an image orientation responsive to position data supplied by the HMD.

As mentioned above in connection with Figure 10, in some applications such as virtual reality and augmented reality arrangements, the apparent viewpoint of the video being displayed to the user of the HMD is changed in response to a change in actual position or orientation of the user's head.

With reference to Figure 11, this is achieved by a motion sensor 450 (such as the arrangement of Figure 10 and/or the motion detector 332 of Figure 9b) supplying data indicative of motion and/or current position to a required image position detector 460, which translates the actual position of the HMD into data defining the required image for display. An image generator 480 accesses image data stored in an image store 470 if required, and generates the required images from the appropriate viewpoint for display by the HMD. The external video signal source can provide the functionality of the image generator 480 and act as a controller to compensate for the lower frequency component of motion of the observer's head by changing the viewpoint of the displayed image so as to move the displayed image in the opposite direction to that of the detected motion so as to change the apparent viewpoint of the observer in the direction of the detected motion.

Referring to Figure 12, in some examples of the functionality of the "image generator" 480 can be provided by a videogame system referred to in this context as a "game engine" 500.

The game engine 500 may be implemented in a physical sense as part of the HMD itself, or, as shown in examples such as that of Figures 6 and 7, by a separate games console. In the case that the game engine 500 is implemented as a separate unit, an example division of functionality between the HMD and the games console is shown by a schematic vertical dashed line 520. It is to the left of the line are implemented as pad of the HMD and items to the right as part of the games console. For the sake of this illustration, a display 510 forming part of the HMD is also shown schematically.

Figure 13 shows a similar arrangement, but in this case the required image position detector 460' is implemented as part of the games console, being drawn to the right of a further schematic dashed line 520'.

Figure 14 schematically illustrates the issue of latency in this type of arrangement.

Figure 14 is similar in some respects to Figure 8 in that it represents changes in viewing direction (indicated by the broken lines) with respect to a part-cylindrical or part-spherical image 550. The diagram is a schematic plan view. Assume (just for the sake of this example) that the user's head stays at the same point in space (a location 560) but rotates about an axis perpendicular to the drawing, so that in effect the user looks towards the side. Starting at an initial viewing direction 570, the user's head rotates in a clockwise direction 580 as drawn.

The latency of the system represents a delay period of time, taken by the system to respond to changes in head orientation and realign the displayed image to a newly detected head orientation.

The latency relates generally to processing and pipeline delays in the image generation system and so, at least in some examples, is independent of the rate at which the head is changing its orientation. However, its effect upon the displayed image does of course depend on the rate of rotation of the head. If the head is stationary, then the latency has no effect upon the correct alignment of the displayed images, because there is no realignment process taking place. If the head is rotating rapidly, at a high angular velocity, then a non-zero latency will mean that the realignment of the images will lag behind the actual orientation of the head while the head is in motion. For example, in Figure 14 the latency period might be such that at a particular angular velocity, the head has already rotated to a new orientation 590 before the system is able to respond to realign the image from that corresponding to the initial head orientation 570. At that angular velocity, this will lead to an alignment error 600 in the image alignment.

The mechanical and/or electronic processes involved in detecting head rotation and generating new images so as to be realigned with the newly detected head orientation mean that there will always be a non-zero latency. However, whether that latency is subjectively noticeable or disturbing to the user depends on the magnitude of the latency. A very small latency of (for example) less than an image period of perhaps 2Oms or 4Oms is unlikely to be subjectively disturbing for the user. A latency of O.25s or O.5s could be subjectively disturbing.

The actual threshold at which the latency becomes disturbing will vary from user to user, but even to assess its effect on an average basis across a cohort of users requires knowledge of what the latency actually is.

Accordingly, a potential problem which relates to HMD5 using motion-dependent image variation of the type described above relates to the difficulty using previously proposed arrangements, for program developers and quality assurance (QA) teams to measure the latency between a head movement (of a user wearing the HMD) and the image actually being displayed at the newly-correct image position by the HMD. Detecting the latency can be useful in order to assess how acceptable the latency is for the general population and also as a tool to improve the games processing pipeline. In some arrangements, a detection of the actual latency could even allow an accurate tracker prediction value to be established, or in other words, to allow a future head position to be estimated based on current motion and the images for the estimated head position to be prepared in advance of the head reaching that position.

However, if is not considered appropriate that detecting latency should require a significant reformulation of game or other image generation software. Indeed, it is desirable that latency detection could be implemented so that the game or other software does not have to make any special provision for it as this could lead to false results if it is not implemented correctly, or may prove not to accurately represent normal usage.

Embodiments of the present techniques include a feature, for example into the operation of the HMD, that uses its existing technology to drive the game in a controlled manner in order to measure the latency. The HMD can drive the tracker data (motion detection data) to the game, and then detect when the game is able to deliver an image to the HMD that has clearly been created by the given tracker data. The time between these two events represents the latency to measure and report.

Detailed techniques will be described below, but in a brief summary of some embodiments, an extra feature can be enabled in the HMD operation, for example being accessible only to development teams and QA teams but removed from a consumer version.

This feature provides (as example embodiments) the following functionality: (a) freeze or latch the current tracking data (head position detection) to its current values to provide a static controllable reference in the game's view point.

(b) display a source and target box (or other marker, graticule or the like) at distinct (separate) positions on the HMD display, for example positions separated by a separation amount equivalent to predetermined head rotation. In some embodiments, the user can then steer these boxes to a location that is sufficiently static (few changes in the image over successive frames) but with a significant measurable difference in the image patch content between the source and target box. That is to say, the image segments in the boxes are compared with one another and a difference factor is reported to the user (or handled automatically by the system) so as to judge whether the image segments initially selected as source and target areas as sufficiently different. The image segments are also compared with themselves overtime, so as to detect whether the image segments exhibit less then a threshold degree of change over time.

The two thresholds just described may be different. The inter-region difference may be detected, for example, at one or more common time points as a sum of squared pixel value (such as luminance or more than one component) differences and compared with a threshold value. This test could be conducted once or could be conducted at spaced-apart time points.

The intra-region stability may be detected by detecting (for example) a sum of squared pixel differences between one or more pairs of instances of the same region spaced apart in time, such that the test is failed if any one of those pairs exhibits greater than a threshold difference.

When the source and target boxes are acceptable (that is to say, their image content differs by at least a threshold difference and they are changing over time by less than a threshold amount of change), the latency test is activated. For example, this activation may be automatic, for example in response to the detection that the source and target boxes contain different image content, or may be in response to a user pressing a menu button. The HMD then sends updated (though artificially generated) tracker data that would cause the source box image to move to the target box's previous location (for example representing a predefined angle of rotation around the current position reference). The HMD then monitors the target box, looking for a significant change in the image difference from the previous or earlier image's target box. This could be detected just as a change of at least a threshold change amount, or could be detected as a reduction in the image difference to below a lower threshold amount. In either instance, an aim of the detection is to detect a situation in which the image movement prompted by the updated tracker data has led to the source box image being moved to the previous target box location.

When this change is detected, the time between initially sending the tracker data and detecting the significant target image change is reported as the total system latency. The total system latency can be made up of an HMD latency and a console and transmission latency.

Example arrangements by which this can be achieved will now be described.

Figure 15 schematically illustrates a latency detection arrangement. It is important to note that (a) some features, such as the motion sensor 450, the required image position detector 460, the game engine 500 and the display 510 are common to the arrangements already described and so will not be described further here; and (b) as discussed earlier, the division between which features are implemented as part of the HMD and which is part of a games console is a choice of the system designer, but purely by way of example all of the features of Figure 15 except the game engine 500 are implemented as part of the HMD.

Furthermore, Figure 15 schematically illustrates apparatus features of the present arrangement (although of course many of these can be implemented by suitably programmed data processing apparatus running under the control of appropriate computer software); Figure 16 and the example images of Figures 17-22 will be used to describe the mode of operation of the apparatus.

A latch 700 is operable to latch (for example, sample and hold at a current value) the output of the required image position detector 460 so that, when the latch 700 is in a latching mode, further movement of the HMD detected by the motion sensor 450 has no further effect on the output of the latch 700. So, when the latch 700 is in a latching mode, the indication of the required image position which is passed to the game engine is fundamentally static. However, one way in which the indication of the required image position, as passed to the game engine 500, can be changed is by means of a schematic adder 710 which adds to the output of the latch 700 an offset value generated by an offset generator 720. Clearly, the format or nature of the offset depends upon the format or nature of the value passed from the latch 700. For example, if the value held by the latch 700 represents an angular position, the offset generator 720 may also generate an angular offset relative to that latched angular position. So, at those stages in the operation of the apparatus (to be discussed below with reference to Figure 16) at which the offset generator 720 is enabled, a rotational or positional offset is added by means of the adder 710 to the output of the latch 700 before the required image position data is passed to the game engine.

In the context of the apparatus of Figure 15 operating at least in part as a latency detection arrangement operable to detect a time period between a change in rotational position of the HMD and a corresponding change in the image orientation of images generated by the game engine, the latch 700, the offset generator 720 and the adder 710 provide an example of a position data generator operable to provide position data to the game engine, in place of that generated by the detection arrangement, which is independent of actual motion of the HMD, the position data generator being operable to provide first position data indicative of a first rotational position followed by second position data indicative of a second rotational position.

It is not necessary, however, that the position data and the detected positions relate (or relate entirely) to rotational positions. They could relate to lateral positions, or to lateral and rotational positions. In some embodiments, however, the detection arrangement is operable to detect at least a rotational position of the HMD; and the position data generator is operable to provide position data indicative of at least a rotational position.

In particular, the latch 700 therefore provides an example of a position data generator comprising a latch operable to latch a current value of the position data provided by the detection arrangement so as to generate first position data.

The offset generator 720 and the adder 710 provide an example of the position data generator comprising a combiner operable to combine the first position data with a position offset so as to generate second position data. So, although an adder could be used, other combinations (such as subtractions, multiplications and the like) are envisaged. It will also be appreciated that although combining the first position data with an offset is a convenient way to generate the second position data, the second position data could simply be generated or provided as a separate, predetermined, data value.

However, it will be appreciated that the generation of "dummy" position data as discussed here does not necessarily require the latching of a current actual position data value.

Entirely artificially provided position data could be used. The use of a latched value does have the advantage, however, that the transition from a normal mode of operation of the HMD to a latency-detecting mode of operation can be less jarring for the user.

Because freezing the tracking data is not idea when the HMD is in use, the test could be performed when the user is not wearing the HMD, for example. A parallel output of at least some of the content viewed on the HMD may be provided to a television monitor, for example by an HDMI link, to improve the social nature of an HMD-based game (as otherwise it is just the HMD wearer who enjoys the game). The test discussed here could be coordinated using that or another display. If the test is carried out when the HMD is being worn, it may be appropriate to use a small angular step (of maybe 5 degrees or less) and to freeze the tracking data just before the angular jump is made so as to reduce the time period over which the tracking data is frozen. In any event, the user of a small angular step can be appropriate because some games systems may ignore large and sudden angular changes in tracking data as potential anomalies.

As well as supplying images to the display 500, the game engine 500 also passes those same images as an output to a buffer 730 which is associated with a comparator 740 and a timer 750.

A final technical feature of Figure 15 is a box or graticule generator 760 which operates under the control of a user control 770.

Referring now to Figure 16, a latency detection process is initiated at a step 800.

As discussed above, the process relies upon selecting source and target image areas, with the HMD then supplying false or "dummy" rotation data to the game engine 500 to initiate realignment of the position of the source image area to that of the original target image area.

The time taken to achieve this is detected as the system latency.

Accordingly, at a step 810, the latch 700 operates so as to latch or "freeze" the motion detection data and accordingly the required image position as detected by the HMD. Further physical motion of the HMD by the user is no longer passed to the game engine 500 and therefore has no effect upon the operation of the game engine 500. Also at the step 810, the source and target areas of the currently displayed image are selected.

Note that the images being supplied by the game engine 500 to the display 510 may be changing in time, given the fact that the game engine 500 continues its normal operation, unaware that its latency is being detected. The only unusual feature, which again the game engine 500 is unaware of, is that the motion detection feature of the HMD is inhibited by virtue of the latch 700.

The aim of selecting appropriate source and target areas, given this variation in time of the displayed images, is to select areas which are themselves not varying significantly over time.

In some embodiments, the user can select these, for example by steering displayed boxes generated by the box generator 760 using the user control 770, based on a visual check by the user. In other words, the user can watch the displayed images for a short time and assess visually that the source and target areas are not themselves varying significantly over time. In other embodiments, however, the selection of source and target areas can be carried out automatically or semi-automatically. This arrangement can make use of the buffer 730 and the comparator 740, to detect for candidate source and target areas the amount of image variation over a sample time period such as 5s. The amount of image variation can be detected using known techniques such as detecting whether a sum of squared differences between successive or different instances of the source area (or the target area) exceeds a first threshold difference value. If a candidate source or target area fails this test, or in other words exhibits more than the threshold difference between the different instances, then a new source and/or target area is tested as a candidate. The process is repeated until a source and a target area which do not fail the test are found.

Figure 21 schematically illustrates the fluctuation over time of the content of the source 900 and target 910 areas shown as candidates in that image. The fluctuations are represented by schematic plots 920 along a horizontal time axis, and in this example instance the fluctuations are within the allowable threshold difference value and so the candidate source and target areas are accepted from the point of view of their temporal stability.

A further test applied to candidate source and target areas is that they need to be different to one another. So, the source area needs to be significantly different to the target area.

Again, a sum of squared differences can be detected, for example by the comparator 740, and candidate source and target areas accepted if their differences exceed a second (potentially different) threshold difference amount.

Accordingly, in this context, the buffer 730 and the comparator 740 provide an example of a test image area analyser operable to detect one or both of: (a) whether image content at the original position and image data at the new position, in images generated by the game engine in response to the first position data, are different by at least a first threshold difference; and (b) whether image content at the original position and image data at the new position, in images generated by the game engine in response to the first position data, vary over time by less than a second threshold difference. In some embodiments, the test image area analyser is operable to reject a candidate test image area which fails either of the tests (a) or (b).

A significant feature of the source and target areas is their separation 930 in the horizontal direction of the image. The source and target areas should be separated such that a simple rotation (mimicking the lateral rotation of the user's head wearing the HMD) would align the source area to the original position of the target area. The lateral separation 930 should either be equal to a predetermined known value or should be detected at this stage.

Figure 17 schematically illustrates a first stage at which the step 810 has been carried out and source and target areas have been selected.

At a step 820, an ongoing difference detecting process is initiated. The intention here is to allow the detection of the image content of the original source area becoming aligned with the original image position of the target area. Various difference detecting techniques can be used to allow this detection.

In some examples, the difference between successive instances of the target image area is detected; such a difference will get larger as the source area approaches the target area (because, as described above, it is known in advance that the image content of the original source area is different to the image content of the original target area) and will then decrease once the original source area has become aligned with the target area, because there will be no further significant changes at that stage. So, the time at which the two areas become aligned in this fashion can be detected as the time at which the target area stops changing.

In other examples, the difference detecting step 820 detects a difference between the original target area and the current target area. When this detected difference matches the difference (as detected during the step 810) between the original source area and the original target area, it is assumed that the original source area has been realigned to the position of the target area.

In further examples, the difference detecting step detects a difference between the current target area and the original source area. Wien this difference drops below a threshold it is assumed that the original source area has been realigned to the position of the target area.

Accordingly, it will be appreciated that there are various different ways of the step 820 detecting the fact that the original source area has been realigned to the position of the original target area. But as mentioned, the step 820 is an ongoing difference detection process; the actual detection of the successful realignment will be described below as a further step.

Miichever of these techniques is used, the buffer 730, the comparator 740 and the timer 750 cooperate to provide an example of an image correlation detector operable to detect a time period between the position data generator supplying the second position data to the game engine and a test image area in the images generated by the game engine moving from an original image position to a new image position in the images generated by the game engine, the new position being displaced from the original image position by a displacement amount dependent upon a difference between the first and second rotational positions. For example, the image correlation detector may detect one or more of a difference between successive instances of image material at the new image position; a difference between image content at the new image position and image content at the original image position in images generated in response to the first position data; and a difference between image content at the new image position and image content at the new image position in images generated in response to the first position data.

Note that the operation of the step 820 is carried out in the example of Figure 15 by the buffer 730 and the comparator 740 comparing corresponding areas of images which are spaced apart over time.

At a step 830, the offset generator 720 is enabled so that an offset amount is added, using the add 710, to the latched image position held by the latched 700. The addition of the offset amount mimics a sudden but fixed rotation of the user's head to a new rotational position.

The amount of the offset corresponds to the lateral separation 930 discussed above between the source and target areas. In other words, when the system has fully and successfully responded to the addition of the offset amount, the source area should be realigned to the position of the original target area.

At a step 840, this realignment is detected using any one or more of the techniques discussed above.

Finally, at a step 850, the time taken between the addition of the offset and the realignment as detected at the step 840 is detected by the time of 750. This time period corresponds to the latency of the system including the HMD and the game engine 500 to response to the rotation established at the step 830.

Of course, after the test has been completed, the latched 700 and the offset generator 720 can be disabled so that normal motion-dependent operation of the HMD can continue.

Accordingly, the steps of Figure 16 provide an example of a method of operation of a head mountable display (HMD), the method comprising: detecting the rotational position of the HMD and supplying position data to a game engine indicative of the detected rotational position; receiving and displaying images generated by the game engine at an image orientation responsive to position data supplied by the HMD; and detecting a time period between a change in rotational position of the HMD and a corresponding change in the image orientation of images generated by the game engine, by: providing position data to the game engine, in place of that generated by the detecting step, which is independent of actual motion of the HMD, the providing step comprising providing first position data indicative of a first rotational position followed by providing second position data indicative of a second rotational position; and detecting a time period between the position data generator supplying the second position data to the game engine and a test image area in the images generated by the game engine moving from an original image position to a new image position in the images generated by the game engine, the new position being displaced from the original image position by a displacement amount dependent upon a difference between the first and second rotational positions.

Referring to Figure 18, using one of the detection techniques discussed above, false rotation has been initiated at the step 830 and the target area is being monitored for changes, but (because of the latency of the system) no change has yet occurred. In a further successive image shown in Figure 19, similarly no change has yet occurred to the target area. Finally, in a next image shown in Figure 20, a significant change corresponding to the difference between the original source area and the original target area has been detected, as illustrated schematically by a peak in a difference chart drawn (purely for the sake of this explanation) over Figure 20. The time period (36ms in this example) between the time at which the significant changes detected and the time (represented in Figure 20 by a vertical downward arrow) at which the step 830 was carried out represents the system latency. These features are illustrated in slightly more detail in Figure 22.

In summary, a technique has been described which allows the detection of system latency corresponding to the operation of a game engine without the need to reconfigure or adjust the operation of the game engine itself this therefore allows a more objective detection of game engine latency to be obtained and can potentially reduce the cost and time taken to carry out this test.

It will be appreciated that features other than the game engine may be implemented as part of an HMD, but also that the HMD may include one or more external devices such as the break-out box 350 of Figure 7, or even that some HMD functionality may be provided by portions of a game console. The important feature is to distinguish the HMD functionality (including the operations discussed above) from the functionality of the game engine itself, noting that the present techniques advantageously allow the latency of the game engine to be detected without having to change the operation of the game engine itself. It will also be appreciated that the invention may be embodied as a system comprising such an HMD and a game engine, or as an HMD and a test box performing the functionality described above.

It will also be appreciated that the various techniques described above may be carried out using software, hardware, software programmable hardware or combinations of these. It will be appreciated that such software, and a providing medium by which such software is provided (such as a machine-readable non-transitory storage medium, for example a magnetic or optical disc or a non-volatile memory) are considered as embodiments of the present invention.

Claims (11)

1. CLAIMS1. A head mountable display (HMD) comprising: a detection arrangement operable to detect the position of the HMD and to supply position data to a game engine indicative of the detected position; and a display operable to receive and display images generated by the game engine at an image orientation responsive to position data supplied by the HMD; and a latency detection arrangement operable to detect a time period between a change in position of the HMD and a corresponding change in the image orientation of images generated by the game engine, the latency detection arrangement comprising: a position data generator operable to provide position data to the game engine, in place of that generated by the detection arrangement, which is independent of actual motion of the HMD, the position data generator being operable to provide first position data indicative of a first position followed by second position data indicative of a second, different, position; and an image correlation detector operable to detect a time period between the position data generator supplying the second position data to the game engine and a test image area in the images generated by the game engine moving from an original image position to a new image position in the images generated by the game engine, the new position being displaced from the original image position by a displacement amount dependent upon a difference between the first and second positions.
2. 2. An HMD according to claim 1, in which the position data generator comprises a latch operable to latch a current value of the position data provided by the detection arrangement so as to generate the first position data.
3. 3. An HMD according to claim 1 or claim 2, in which the position data generator comprises a combiner operable to combine the first position data with a position offset so as to generate the second position data.
4. 4. An HMD according to any one of claims 1 to 3, comprising a test image area analyser operable to detect one or both of: (a) whether image content at the original position and image data at the new position, in images generated by the game engine in response to the first position data, are different by at least a first threshold difference; and (b) whether image content at the original position and image data at the new position, in images generated by the game engine in response to the first position data, vary over time by less than a second threshold difference.
5. 5. An HMD according to claim 4, in which the test image area analyser is operable to reject a candidate test image area which fails either of the tests (a) or (b).
6. 6. An HMD according to any one of the preceding claims, in which the image correlation detector is operable to detect one or more of: a difference between successive instances of image material at the new image position; a difference between image content at the new image position and image content at the original image position in images generated in response to the first position data; and a difference between image content at the new image position and image content at the new image position in images generated in response to the first position data.
7. 7. An HMD according to any one of the preceding claims, in which: the detection arrangement is operable to detect at least a rotational position of the HMD; and the position data generator is operable to provide position data indicative of at least a rotational position.
8. 8. A system comprising an HMD according to any one of the preceding claims and a game engine.
9. 9. A method of operation of a head mountable display (HMD), the method comprising: detecting the position of the HMD and supplying position data to a game engine indicative of the detected position; receiving and displaying images generated by the game engine at an image orientation responsive to position data supplied by the HMD; and detecting a time period between a change in position of the HMD and a corresponding change in the image orientation of images generated by the game engine, by: providing position data to the game engine, in place of that generated by the detecting step, which is independent of actual motion of the HMD, the providing step comprising providing first position data indicative of a first position followed by providing second position data indicative of a second, different, position; and detecting a time period between the position data generator supplying the second position data to the game engine and a test image area in the images generated by the game engine moving from an original image position to a new image position in the images generated by the game engine, the new position being displaced from the original image position by a displacement amount dependent upon a difference between the first and second positions.
10. 10. Computer software which, when executed by a computer, causes the computer to carry out the method of claim 9.
11. 11. A non-transitory machine-readable storage medium which stores computer software according to claim 10.