This application is a Continuation-in-part of U.S. patent application Ser. No.: 09/589,645, filed Jun. 7, 2000, entitled Method and Apparatus for Electronically Distributing Motion Panoramic Images that is a continuation in part of U.S. patent application Ser. No.: 09/131,186 filed Aug. 7, 1998, also entitled Method and Apparatus for Electronically Distributing Motion Panoramic Images. Both of these applications are included by reference in their entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the field of warped video image processing. Specifically, embodiments of this invention include methods, apparatus, and computer program products for specifying objects in a warped video image and tracking the specified objects as they move through the video over time.

2. Background

A warped video image includes a set of video frames each frame containing non-rectilinear data. Such a warped video image can be created by capturing an image through a wide-angle lens, a catadioptric lens or some other distorting lens. The warped video image can be sent to a user/viewer who can then select portions of the data for transformation into a rectilinear form for presentation (such as by display).

Most video cameras only record a view within a small viewing angle. Thus, a typical video camera only captures an image in the direction that the camera is aimed. Such conventional cameras force viewers to look only at what the camera operator chooses to focus upon.

A video camera equipped with a wide-angle lens captures warped video images. For example, a panoramic camera constructed with a catadioptric lens captures a warped annular image that represents a substantially 360-degree scene that extends through a horizon line. Other wide-angle lenses (for example, a fish-eye lens) can generate warped circular images and may capture substantially a hemisphere (180-degree) view.

A portion of the warped video image can be transformed to provide a rectilinear representation of that portion of the warped video image. Thus, a viewer/user of the warped video image can individually select what portion of the warped video image is to be presented. As the user/viewer focuses on a moving object, the user/viewer must constantly adjust the presented view to track the moving object as it moves through the warped video image.

In some circumstances (for example, in a television broadcast control room), a user selects a view for presentation to other viewers. In this case, the viewer is unable to independently select the view because the user has done so.

There are many known techniques for tracking moving objects in a video. Some of these are described by U.S. Pat. No. 5,548,659, by Okamoto and entitled Method and Apparatus for Detecting Changes in Dynamic Images; by U.S. Pat. No. 5,877,804, by Otsuki et al. and entitled Method and Apparatus for Moving Object Detection; by U.S. Pat. No. 5,537,155, by O'Connell et al. and entitled Method for estimating Motion in a Video Sequence; U.S. Pat. No. 6,072,494, by Nguyen and entitled Method and Apparatus for Real-Time Gesture Recognition; by U.S. Pat. No. 5,434,617, and by Bianchi and entitled Automatic Tracking Camera Control System. In addition, other teachings are from Statistical Background Modeling for Tracking With a Virtual Camera, by Rowe and Blake; from Divide and Conquer: Using Approximate World Models to Control View-Based Algorithms, by Bobick and Pinhanez, and from Approximate World Models: Incorporating Qualitative and Linguistic Information into Vision Systems, by Pinhanez and Bobick. However, these techniques are not known to have been used to track movement or objects through a warped video image, nor to other aspects of the inventions disclosed within.

Conventional images are often delivered by electronic means. For example, television and the Internet deliver conventional images across wired and wireless electronic media. However, there are no standard means of delivering real-time panoramic images or wide-angle images electronically. Since panoramic images are so large and include so much data, it is difficult to deliver these images using conventional image transmission techniques. To further compound the problem, real-time motion panoramic images require a very high bandwidth channel for electronic distribution.

It would be advantageous to provide methods, apparatus, systems and program product solutions that allow a user/viewer to select an object-of-interest and to track it in real-time as the object-of-interest moves through a warped video image. In addition it would be advantageous to allocate bandwidth to the portions of the warped video image that include the tracked object-of-interest. Furthermore, it would be advantageous to monitor when the object-of-interest moves into an area-of-interest and to respond to such an occurrence.

SUMMARY OF THE INVENTION

Apparatus, methods and computer program products are disclosed that track movement or a moving object through a warped video image. The warped video image can result from a video camera attached to a warping lens such as a wide-angle lens or panoramic lens. Some embodiments allow a user to select the portion of the image that interests the user for tracking. Other embodiments automatically select and track movement through the warped video image without input from a user. Still other embodiments track when movement comes into proximity with an area-of-interest and will raise an alarm (a signal) that can be used to start recording of the warped video image or to trigger other alarm or signal responses (the alarm can be used to trigger typical surveillance systems, monitor traffic or interest generated by a display or attraction, or perform other operations responsive to the alarm response). Yet other embodiments change the bandwidth allocated to portions of the warped video image sent over a network responsive to the tracked movement so that the movement stays in a quality view.

One preferred embodiment is a computer-controlled method that includes a step of selecting a first view into a warped video image. The warped video image includes a plurality of frames. The method also includes the step of identifying an object-of-interest in a first set of frames of the plurality of frames and the step of tracking the object-of-interest through a subsequent set of frames of the plurality of frames.

Another preferred embodiment is a computing device that performs the steps of the computer-controlled method above.

Yet another preferred embodiment is a computer program product that provides computer readable data that can be executed by the computer to perform the steps of the computer-controlled method above.

Versions of these embodiments respond to where the object-of-interest is in the view and can respond by triggering an alarm or signal condition or by changing the bandwidth allocated to portions of the warped video image.

The foregoing and many other aspects of the present invention will no doubt become obvious to those of ordinary skill in the art after having read the following detailed description of a preferred embodiment that is illustrated in the various drawing figures.

DESCRIPTION OF THE DRAWINGS

FIG. 1

illustrates a computer system capable of using the invention in accordance with a preferred embodiment;

FIG. 2

illustrates a process that tracks an object-of-interest through a warped video image in accordance with one preferred embodiment;

FIG. 3A

illustrates one preferred embodiment of the â€˜select view; enable trackingâ€™ procedure 217 of

FIG. 2

;

FIG. 3B

illustrates one preferred embodiment of the â€˜capture view modelâ€™ procedure 305 of

FIG. 3A

;

FIG. 4A

illustrates one preferred embodiment of the â€˜generate tracker transformationsâ€™ procedure 219 of

FIG. 2

;

FIG. 4B

illustrates a motion model tracking process invoked by the â€˜apply modelâ€™ procedure 405 of

FIG. 4A

in accordance with a preferred embodiment;

FIG. 4C

illustrates a color model tracking process invoked by the â€˜apply modelâ€™ procedure 405 of

FIG. 4A

in accordance with one preferred embodiment; and

FIG. 5

illustrates an ancillary adjustment process that can be invoked by the â€˜ancillary operationsâ€™ procedure 218 of

FIG. 2

in accordance with one preferred embodiment.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Notations and Nomenclature

The following â€˜notations and nomenclatureâ€™ are provided to assist in the understanding of the present invention and the preferred embodiments thereof.

Procedureâ€”A procedure is a self-consistent sequence of computerized steps that lead to a desired result. These steps are defined by one or more computer instructions. These steps can be performed by a computer executing the instructions that define the steps. Thus, the term â€œprocedureâ€ can refer (for example, but without limitation) to a sequence of instructions, a sequence of instructions organized within a programmed-procedure or programmed-function, or a sequence of instructions organized within programmed-processes executing in one or more computers. Such a procedure can also be implemented directly in circuitry that performs the steps.

Overview

U.S. Pat. No. 6,043,837 is included by reference in its entirety. This patent discloses, among other things, at least one embodiment of a panoramic lens, the annular image captured by the panoramic lens, and at least one embodiment for sending a warped video image from a data source (such as a server computer) to a client such as (a client computer).

Detailed Description

FIG. 1

illustrates a computer system, indicated by general reference character 100, that incorporates the invention. The computer system 100 includes a processor 101 that includes a central processor unit (CPU) 103, a memory section 105 and an input/output (I/O) section 107. The I/O section 107 can be connected to a user interface 111, a disk storage unit 113 and/or a DVD/CD-ROM drive unit 115. The DVD/CD-ROM drive unit 115 can read a CD-ROM medium 117 that typically contains a program and data 119. The DVD/CD-ROM drive unit 115 (along with the CD-ROM medium 117 and/or a DVD medium 127 ) and the disk storage unit 113 comprise a file storage mechanism. Some embodiments of the invention include a network interface 121 that connects the computer system 100 to a network 123. Portions of the program and data 119 can be resident in a program memory 125 for execution by the CPU 103. The DVD medium 127 can contain motion image data 129 that can be read by the DVD/CD-ROM drive unit 115 for presentation by the user interface 111, other presentation device, or a display device. A client computer 131 can also access the warped video image through the network 123 from a server computer that includes the processor 101. In addition, motion images can be collected by a video camera 133 in real time.

One skilled in the art will understand that not all of the displayed features of the computer system 100 are required in some of the embodiments. Such a one will also understand that computers are used in many devices to cause the device to operate. These extend from toasters to navigational devices to televisions and beyond. The inventors' use of the term â€œcomputer systemâ€ includes any system that has circuitry that performs the steps of the invention as well as any general-purpose programmed computer. In addition, aspects of the network 123 can include a broadcast network, a wireless network, the Internet, a LAN, a WAN, a telephone network or other network.

One skilled in the art will understand that the program and data 119 can also reside on the DVD medium 127.

One preferred embodiment is used to track images through a panoramic video image. One skilled in the art will understand that the techniques described within can also be applied to other warped video images.

FIG. 2

illustrates a tracking process 200 that can be used to select and track an object-of-interest as it moves through a warped video image in real-time. The warped video image can include a sequence of frames each containing data that represents a portion of the warped image and/or the entire image with portions that can have differing quality. In addition, the tracking process 200 can be used with a tiled or tiered warped video image as described in the previously referenced parent application. For a panoramic image, a substantially 360-degree scene extends through a horizon line.

The tracking process 200 can be used by a viewer of the warped video image and/or it can be used by a human or machine user. A user may or may not also be a viewer. However, a user can select an object for subsequent tracking for viewing by viewers who do not have access to the tracking process 200.

The tracking process 200 initiates at a â€˜startâ€™ terminal 201 and continues to an â€˜initializationâ€™ procedure 203 that initializes the tracking process 200. After initialization, the tracking process 200 continues to a â€˜receive panoramic video frameâ€™ procedure 205. The â€˜receive panoramic video frameâ€™ procedure 205 receives a video frame that contains panoramic data. The panoramic data can be in a warped annular form, in an un-warped form, or some other form that contains information from a portion of and/or the entirety of the panorama. Portions of the panoramic data can be of differing quality as discussed in the parent application. The video frame can be received over the network 123, from reading a CD or DVD on the DVD/CD-ROM drive unit 115, from the video camera 133, or from any other device that can provide panoramic video frames. After receiving the video frame, the tracking process 200 continues to a â€˜tracking decisionâ€™ procedure 207.

The â€˜tracking decisionâ€™ procedure 207 determines whether automatic tracking is enabled. Automatic tracking is enabled by operations performed by a user/viewer as is subsequently described with respect to FIG. 3A. If automatic tracking is not enabled, the tracking process 200 continues to an â€˜apply user/viewer transformationsâ€™ procedure 209 that applies one or more user/viewer specified transformations to the warped video frame. Examples of such transformations include coordinate transformations, pan, rotation, zoom or other transformations that generate a view into the warped video frame.

Once the transformations are applied, a â€˜store view in video frameâ€™ procedure 211 stores the transformed data into a video frame suitable for presentation. Once stored in a video frame, the view can be (for example, but without limitation) presented to the viewer, transmitted to the client computer for presentation or storage, or stored on some computer-readable or video-readable media.

An â€˜accept user/viewer commandsâ€™ procedure 213 accepts any commands that the user/viewer may have input. These commands can be input to the server computer or the client computer by manipulation of devices that communicate to the computer or by programs executed by a computer. These commands can include presentation commands that create or modify transformations that are applied to the warped video frame to generate a view. Examples (but without limitation) of such commands include pan, rotation and zoom commands. Once the user command is accepted, it is processed by either a â€˜process presentation commandâ€™ procedure 215 or a â€˜select view; enable trackingâ€™ procedure 217. One skilled in the art will understand that the â€˜process presentation commandâ€™ procedure 215 and the â€˜select view; enable trackingâ€™ procedure 217 are both procedures for processing commands and that they are illustrated separately to simplify the following discussion.

The â€˜process presentation commandâ€™ procedure 215 parses the user's command and creates and/or modifies transformations that are applied to the warped video frame to generate a view.

The â€˜select view; enable trackingâ€™ procedure 217 allows the user/viewer to select a view containing an object-of-interest and to enable tracking as is subsequently described with respect to FIG. 3A and FIG. 3B.

An â€˜ancillary operationsâ€™ procedure 218 can be used to perform operations responsive to the current view. As is subsequently described with respect to

FIG. 5

, one such operation can be an adjustment of the amount of the available bandwidth of the network interface 121 and the network 123 that is allocated to portions of the warped video frame so as to improve the presentation quality of the portions of the warped video frame that include the tracked object-of-interest (using techniques similar to those described in the parent application). Another operation is the triggering of an alarm or signal condition if the tracked object has entered area-of-interest. Other operations responsive to the tracked object can also be performed. One skilled in the art will understand that the alarm condition is a term that means something of interest has happened and can be a software signal among others. In surveillance situations, the alarm condition may invoke a physical alarm. However, in other situations, the alarm condition can invoke other operations that are normal responses to the condition.

The tracking process 200 continues to the â€˜receive panoramic video frameâ€™ procedure 205 for processing of the next warped video frame. The tracking process 200 continues until all the warped video frames are processed, the user/viewer disables or terminates the tracking process 200, or some other termination condition occurs.

Looking again at the â€˜tracking decisionâ€™ procedure 207, if tracking is enabled, the tracking process 200 continues to a â€˜generate tracker transformationsâ€™ procedure 219. As is subsequently described with respect to

FIG. 4A

, the â€˜generate tracker transformationsâ€™ procedure 219 determines how the view should be changed to keep the object-of-interest contained within the view. The user/viewer can specify whether the transformation includes a magnification component to keep the object-of-interest substantially the same size as it moves through the warped video image. An â€˜apply tracker transformationsâ€™ procedure 221 applies these transformations to the warped video frame to generate the view. The view containing the object-of-interest can be presented to a viewer in a number of ways (for example, presenting the view on a computer terminal, on video display, storing the view on a video disk, printing the view on a printer, etc.). In some embodiments, the view need not be presented at all times (for example, but without limitation, in an embodiment that determines when a tracked object comes into proximity with an area-of-interest and records the image while the condition exists).

One skilled in the art will understand that the tracking process 200 can be implemented using (for example, but without limitation) object-oriented programming practices, procedural programming practices, single or multiple threads of execution; and can be implemented using a general purpose computer, specialized circuitry or some combination of each.

FIG. 3A

illustrates a â€˜select view and enable trackingâ€™ process 300 invoked by the â€˜select view; enable trackingâ€™ procedure 217 of FIG. 2. The â€˜select view and enable trackingâ€™ process 300 initiates at a â€˜startâ€™ terminal 301 and continues to a â€˜select viewâ€™ procedure 303 that allows a user/viewer to identify the object-of-interest that the user/viewer desires to track. The user/viewer can specify the object-of-interest by using computer controls (for example the user interface 111) to include the object-of-interest in a bounding box and so specify an object box that contains the object-of-interest, by selecting a view and indicating that the object-of-interest is the portion of the view that moves in subsequent frames, or by using a combination of these approaches. One skilled in the art will understand that in some embodiments, multiple objects-of-interest can be specified and tracked. Where the presentation of the tracked objects-of-interest is via a display mechanism, the multiple objects-of-interest view can be displayed in separate views, can be displayed in a single view that includes the multiple objects-of-interest, can display the view containing the most prominent of the multiple objects-of-interest, can display the view containing the fastest moving object-of-interest, or can display the view having an object-of-interest in or near an area-of-interest.

In another preferred embodiment, the â€˜select view and enable trackingâ€™ process 300 can be configured to select moving pixels without user/viewer selection. In this embodiment, each frame is scanned to determine which pixels moved over time and one or more groups of pixels are automatically selected for tracking.

Once the view is selected (with or without the object box) the â€˜select view and enable trackingâ€™ process 300 continues to a â€˜capture view modelâ€™ procedure 305 that processes the view and initializes one or more models that are used to track the object-of-interest as it moves through the panorama. The â€˜capture view modelâ€™ procedure 305 is subsequently described with respect to FIG. 3B.

An â€˜enable trackingâ€™ procedure 307 enables tracking in the tracking process 200. The â€˜select view and enable trackingâ€™ process 300 completes through an â€˜endâ€™ terminal 309.

FIG. 3B

illustrates a â€˜capture modelâ€™ process 320 that is invoked by the â€˜capture view modelâ€™ procedure 305 and initiates at a â€˜startâ€™ terminal 321. A â€˜receive view and/or object boxâ€™ procedure 323 receives the view and possibly an object box as specified by the user/viewer at the â€˜select viewâ€™ procedure 303 of FIG. 3B. An â€˜object box existsâ€™ decision procedure 325 determines whether the user/viewer has selected an object box. If no object box was specified, an â€˜estimate object boxâ€™ procedure 327 automatically defines one. The â€˜estimate object boxâ€™ procedure 327 operates by, for example, assuming the object-of-interest is in the middle of the presented view, selecting a seed area in the middle of the view, and determining the boundary around the seed area defined by a transition from the characteristics of the seed to some other characteristic (such as motion, color, texture, luminance or other characteristic of the seed that is well known in the art). Other techniques known to one skilled in the art can be utilized to estimate the object box if the user/viewer does not supply the object box at the â€˜receive view and/or object boxâ€™ procedure 323.

Once an object box is defined the â€˜capture modelâ€™ process 320 continues to an â€˜iterate modelsâ€™ procedure 329 that passes the view and object box to at least one of the available models for initialization. Once the models are initialized the â€˜select view and enable trackingâ€™ process 300 continues to an â€˜endâ€™ terminal 331.

Looking again at the â€˜iterate modelsâ€™ procedure 329; as each model is iterated, a â€˜determine model parameters and weightâ€™ procedure 333 initializes the model with respect to the object box and the view. The â€˜determine model parameters and weightâ€™ procedure 333 can operate by evaluating the pixels in the current and a subset of the previous frames to determine which models are better suited for tracking the object-of-interest represented by a group of pixels (a blob). Thus, a set of models is enabled based on the characteristics of a blob in the object box and in some cases how these characteristics have changed over a subset of the past frames. Each of the enabled models has an associated â€œweight valueâ€ that represents how well the model expects be able to track the particular characteristics of the blob in the object box. For example, a pixel motion model (such as shown in

FIG. 4B

) can evaluate the past history of how the blob currently in the object box have moved in the pastâ€”so as to predict how it will move in the future. For another example, a blob having a particular arrangement of color and relationships between the colors of the pixels within the blob can be identified. Other mechanisms known in the art can also be applied such as generating eigenvectors and eigenvalues identifying the blob, providing templates to match grayscale values, or applying edge map mechanisms among others.

A blob is a data representation of a portion of the light reflected off the object-of-interest and captured by a panoramic video camera. In one preferred embodiment the blob can be defined by specifying some combination of its center (with respect to the warped video image), its size and/or shape, a pixel motion map, a color map, a texture map and/or an edge map, a set of eigenaxes with corresponding eigenweights that represent the pixel arrangement that make up the blob or other image identification mechanisms.

As the object-of-interest is captured, the â€˜determine model parameters and weightâ€™ procedure 333 also computes the quality of the model as applied to the blob. For example, if the color map of the object-of-interest is similar to the color map of the surroundings, if the blob is too small, or if the blob is motionless for a sufficient period of time the corresponding color model, motion model, or texture model will be assigned a lower weight. If the blob specified by the user's object box yields models with insufficient weight, model can be disabled or the model's result rejected. In addition, if all the models generate a low weight (meaning that the specified object cannot be tracked) the object is rejected and tracking is not enabled.

Another preferred embodiment automatically selects an interesting area of the warped video image as the object-of-interest. It does so by detecting changes between adjacent video frames. These changes can include motion, changes in velocity, changes in texture, changes in color or some combination of these. In this embodiment, the user/viewer need not select a view containing the object-of-interest. Instead, the system automatically selects some interesting change. User/viewer preferences can be provided to prioritize the relative importance of the types of detected changes.

FIG. 4A

illustrates a â€˜generate tracker transformationâ€™ process 400 that can be invoked by the â€˜generate tracker transformationsâ€™ procedure 219 of FIG. 2 and that initiates at a â€˜startâ€™ terminal 401. The â€˜generate tracker transformationâ€™ process 400 continues to a â€˜model weight checkâ€™ decision procedure 402 that determines whether selected disabled models should be weight checked and possibly enabled as is subsequently described.

Regardless of the results of the â€˜model weight checkâ€™ decision procedure 402 the â€˜generate tracker transformationâ€™ process 400 eventually continues to an â€˜iterate enabled modelsâ€™ procedure 403 that iterates each enabled tracking model. For each iterated model, an â€˜apply modelâ€™ procedure 405 is applied to the pixels in a region surrounding where the object-of-interest was in the previous frame. Examples (but without limitation) of the available models are subsequently described with respect to FIG. 4B and FIG. 4C.

After all the enabled tracking models have been applied to the current frame, a â€˜select modelâ€™ procedure 407 can select a model result by comparing the results, weight and confidence of each of the enabled models and selecting a model dependent on the model's weight, confidence, and agreement to the other models. In addition, the â€˜select modelâ€™ procedure 407 can combine the results from the enabled models (responsive to the model's weight and confidence, and agreement between models) to generate a model result that is different from any of the results returned by the enabled models.

An â€˜update model historyâ€™ procedure 411 updates the history for all the enabled modules. The model result from the â€˜select modelâ€™ procedure 407 is used to update each enabled model. Thus, each enabled model has access to the current position of the object as represented by the model result as well as its own result. The history can include the last location of the blob in the warped video image, the last size of the blob, the velocity vector of the blob over the last â€˜nâ€™ seconds (such as captured by a Kalman filter), and the change in the size of the blob in the last â€˜nâ€™ seconds (again such as captured by a Kalman filter). One skilled in the art will understand that filters other than a Kalman filter can be used. In addition, the â€˜update model historyâ€™ procedure 411 can cause the models to reevaluate their weight based on the model result from the â€˜select modelâ€™ procedure 407.

Once the â€˜select modelâ€™ procedure 407 has determined the model result, a â€˜generate transformationsâ€™ procedure 413 generates the transforms that, when applied to the panorama, will position the object-of-interest substantially in the center (or other user/viewer specified location) of the view while optionally maintaining the object-of-interest at substantially the same size. The â€˜select modelâ€™ procedure 407 also generates a confidence value that indicates a certainty that the object-of-interest (represented by the blob) was successfully tracked. This confidence value is passed to a â€˜view confidence sufficientâ€™ decision procedure 415 that determines whether the confidence value is sufficient to continue tracking. If so, the â€˜generate tracker transformationâ€™ process 400 completes through an â€˜endâ€™ terminal 417 and the transformations are applied at the â€˜apply tracker transformationsâ€™ procedure 221 of FIG. 2. However, if the confidence level is insufficient the â€˜generate tracker transformationâ€™ process 400 continues to a â€˜recoveryâ€™ procedure 419.

The â€˜recoveryâ€™ procedure 419 can disable tracking (presenting an indication to the user/viewer where the object-of-interest was expected to be and where the object-of-interest was last known to be), and/or it can attempt to recover the object-of-interest in subsequent frames to handle the case where, for example, the object-of-interest has been occluded for a short time, and/or it can accept user/viewer input to help recapture the object-of-interest. After attempting recovery, the â€˜generate tracker transformationâ€™ process 400 completes through the â€˜endâ€™ terminal 417.

The user/viewer can specify threshold confidence value below which the user/viewer is notified that the tracking of the object-of-interest may have failed, that the tracker is attempting recovery, or if two similar blobs have been found.

Looking again at the â€˜model weight checkâ€™ decision procedure 402, if the â€˜model weight checkâ€™ decision procedure 402 determines that it should reevaluate and re-weight a selection of the available disabled models (the weights of the enabled models can be updated when they execute and/or at the â€˜update model historyâ€™ procedure 411), the â€˜generate tracker transformationâ€™ process 400 continues to a â€˜enable weight checkâ€™ procedure 421 that enables selected models. The â€˜model weight checkâ€™ decision procedure 402 periodically (after some number of frames, after a period of time or in response to an event) invokes the â€˜enable weight checkâ€™ procedure 421. If a model is enabled for weight check, it will be applied to the current frame with other enabled models. The weight-check-enabled model will re-evaluate its weight with respect to the current information in the object box, and if the re-evaluated weight is sufficient, the model will enable itself. In a preferred embodiment, there can be a limit on the number of models that can be enabled at any given time. In addition, there can be a limit on the number of models that are weight-check-enabled.

FIG. 4B

illustrates a â€˜pixel motion trackerâ€™ process 430 that can be one of the models invoked by the â€˜apply modelâ€™ procedure 405 of FIG. 4A. The â€˜pixel motion trackerâ€™ process 430 initiates at a â€˜startâ€™ terminal 431 and continues to a â€˜generate motion mapâ€™ procedure 432 that compares the pixels in a region where the object-of-interest is expected to be from at least the previous frame and the current frame. This generates a motion map that indicates pixel motion in the region.

The region includes the position of the object-of-interest in the previous frame (for example, the region can be centered on this position). The size of the region is determined by the past history of the motion and size of the object-of-interest such that the region includes (but is not limited to) both the position of the object-of-interest in the previous frame and the expected position of the object-of-interest in the current frame.

Next, a â€˜median filterâ€™ procedure 433 filters out isolated pixel differences within the region without substantially altering the motion characteristics of the pixels within the region that may represent the object-of-interest.

Using the motion map, a â€˜motionâ€™ decision procedure 435 determines whether the object-of-interest is in motion. If no motion is detected, the â€˜pixel motion trackerâ€™ process 430 continues to a â€˜determine view confidenceâ€™ procedure 437 that evaluates the confidence value for the view. The â€˜determine view confidenceâ€™ procedure 437 can (for example, but without limitation) reduce the confidence value when the object box is too small or remains motionless for too long, reduce the confidence value when the boundary of pixels representing the object-of-interest changes shape, color, texture, and/or when the expected position of pixels representing the object-of-interest is sufficiently different from the actual position of pixels representing the object-of-interest.

An â€˜update motion historyâ€™ procedure 439 maintains any model-specific history required by the operation of the model. This history can include (among others) previous motion maps, motion vectors, the search region, size and position of the object box, the previous image, and environmental information such as three-dimensional information about motionless objects in the warped video image. The â€˜update motion historyâ€™ procedure 439 can also adjust the weight of the motion tracker model using the same or similar techniques as used in the â€˜determine model parameters and weightâ€™ procedure 333.

The â€˜pixel motion trackerâ€™ process 430 completes through an â€˜endâ€™ terminal 441.

Looking again at the â€˜motionâ€™ decision procedure 435, if motion is detected, the â€˜pixel motion trackerâ€™ process 430 continues to a â€˜find bounding box around motionâ€™ procedure 445 that updates the position and size of the object box around the object-of-interest. In the circumstance where the motion is insubstantially transverse to the warped video image the object box changes size but does not change position. Where there is a transverse component, the object box will change position and possibly size. The â€˜pixel motion trackerâ€™ process 430 continues through the â€˜determine view confidenceâ€™ procedure 437 and eventually completes through the â€˜endâ€™ terminal 441.

FIG. 4C

illustrates a â€˜color trackerâ€™ process 450 that can be another one of the models invoked by the â€˜apply modelâ€™ procedure 405 of FIG. 4A. This type of model tracks a group of pixels in the warped video image that maintain a similar relationship (although possibly a varying relationship) between them (for example, the same shape, color, texture etc.) As previously discussed, such a group of pixels is a blob.

The â€˜color trackerâ€™ process 450 initiates at a â€˜startâ€™ terminal 451 and continues to a â€˜blob predictionâ€™ procedure 453. The â€˜blob predictionâ€™ procedure 453 uses the blob's history to predict the current position, and size of the blob in the panorama. The blob's history can also be used to predict changing color relationships within the blob by monitoring the color map history. Next, a â€˜blob searchâ€™ procedure 455 attempts to match the blob with the data in the current frame. The search starts at the blob's predicted position (using the blob's predicted size and color map) and if the blob is not immediately found at the predicted position the â€˜blob searchâ€™ procedure 455 will search around the predicted position or trace back to the previously known position to attempt to locate the blob. A â€˜generate confidenceâ€™ procedure 457 then generates a value that represents how confident the model is that it was able to find the blob. An â€˜update historyâ€™ procedure 459 can then adjust the model's weight depending on how well the model was able to track the blob. Finally, the â€˜color trackerâ€™ process 450 completes through an â€˜endâ€™ terminal 461.

The â€˜update historyâ€™ procedure 459 maintains any model-specific history required by the operation of the model. This history can include (among others), color maps, motion vectors, the search region, size and position of the object box, and environmental information such as three-dimensional information about motionless objects in the warped video image. The â€˜update historyâ€™ procedure 459 can also adjust the weight of the color tracker model using the same or similar techniques as used in the â€˜determine model parameters and weightâ€™ procedure 333 (for example, by how well the blob is distinguishable from its surroundings).

Similar models can be created following the same or similar structure as shown in FIG. 4B. These models can include a texture model, a shape model, an edge model, an eigen model, etc.

FIG. 5

illustrates an â€˜ancillary operationâ€™ process 500 that can be invoked by the â€˜ancillary operationsâ€™ procedure 218 of FIG. 2 and that initiates at a â€˜startâ€™ terminal 501. The â€˜ancillary operationâ€™ process 500 continues to a â€˜view changeâ€™ decision procedure 503 that determines whether the view has changed (either as a result of a user/viewer command, or of the operation of the tracking process). If the view has not changed, the â€˜ancillary operationâ€™ process 500 continues to an â€˜extended stationary viewâ€™ decision procedure 504 that determines whether the view has not changed for a sufficient period. If the view has remained stationary for the required period, the â€˜ancillary operationâ€™ process 500 continues to an â€˜increase bandwidth for current viewâ€™ procedure 505. The â€˜increase bandwidth for current viewâ€™ procedure 505 increases the bandwidth allocated to the currently presented view and reduces the bandwidth allocated to unseen portions of the warped video image using techniques such as those described in the parent applicationâ€”thus, increasing the quality of the presented view. The â€˜increase bandwidth for current viewâ€™ procedure 505 can also trigger a re-weighting of the models to adjust for the improved pixel resolution available from the increased bandwidth available to the view.

However, if the view has changed, the â€˜ancillary operationâ€™ process 500 continues to a â€˜change bandwidth allocation for new viewâ€™ procedure 507 that determines whether the changed view has been using lower quality data to generate the view and if so allocates more bandwidth to the portion of the data currently used to generate the view.

Regardless of which branch of the â€˜view changeâ€™ decision procedure 503 and the â€˜extended stationary viewâ€™ decision procedure 504 is taken, the â€˜ancillary operationâ€™ process 500 eventually continues to an â€˜area monitoringâ€™ decision procedure 508. The â€˜area monitoringâ€™ decision procedure 508 determines whether an area monitoring capability is enabled as is subsequently described.

If area monitoring is not enabled, the â€˜ancillary operationâ€™ process 500 continues to an â€˜other ancillary adjustmentsâ€™ procedure 509 that implements other enhancements that can be responsive to the state of change of the object-of-interest in the panorama. Finally, the â€˜ancillary operationâ€™ process 500 completes through an â€˜endâ€™ terminal 511.

Looking again at the â€˜area monitoringâ€™ decision procedure 508. If area monitoring is enabled, the â€˜ancillary operationâ€™ process 500 continues to an â€˜alarm conditionâ€™ decision procedure 513 that determines whether the object-of-interest has come into proximity an area-of-interest for which intrusions are monitored. If an alarm condition is detected, the â€˜ancillary operationâ€™ process 500 continues to an â€˜alarm responseâ€™ procedure 515 that responds to the alarm. The â€˜alarm responseâ€™ procedure 515 can respond to the alarm in a variety of ways. Some of these responses include starting a recording mechanism of the warped video image or view, presenting a display on a computer monitor, television or other presentation or display device of the view containing the area-of-interest (or areas) and the triggering object, causing audible and/or visual alarms, and invoking a surveillance response from a security company or the police. The recorded views can be saved for later retrieval and playback.

One skilled in the art will understand from reading this description an area-of-interest and an object-of-interest can be specified in very similar ways. The user/viewer can also specify the alarm type for intrusions or proximity to each specific area-of-interest by any of the object-of-interests. Furthermore, the area-of-interest can also be tracked (but generally not presented) and need not be stationary. Thus, for example, a moving area-of-interest (for example, a car) can be specified as well as an object-of-interest (for example, a dog). One embodiment would present the object-of-interest (for example, by display on a computer screen) but track both the object-of-interest and the area-of-interest. In this case, the embodiment would raise an alarm if the object-of-interest and the area-of-interest eventually came into proximity with each other.

One preferred embodiment of previously described models allows the user/viewer to specify that the tracker can wander to follow changes in the warped video image. Thus, the tracker would detect and follow interesting motion in the warped video image instead of following only one particular object-of-interest specified by the user/viewer. In this instance, there would be no â€œlost trackâ€ condition. Instead, when the object-of-interest was lost (or after a suitable time), the â€˜recoveryâ€™ procedure 419 would find other motion and automatically track that motion. This can also be applied to the other models to wander from color change to color change, or texture change to texture change or some combination thereof. These models track a particular condition (motion, color, texture etc.) for a limited time (for example for as long as it remains interesting or until a more interesting condition occurs).

One preferred embodiment includes the capability to select a second view into the warped video image and to identify and track a second object-of-interest while still tracking the first. Thus, multiple objects of interest can be tracked through the warped video image.

Another preferred embodiment allows the object to be selected on a client computer and to have the tracking done by the server computer.

When using a stationary single video camera with a panoramic lens, one skilled in the art will understand that detecting and tracking movement or moving objects is much simplified over the prior art. In particular, because the background does not move in the image (because the camera does not move) movement is simpler to detect. This advantage also extends over multiple stationary cameras covering an area because there is no need to identify and calibrate the overlapping portions of the images from the multiple cameras nor any need to track movement that exits the view of one camera and enters the view of another.

From the foregoing, it will be appreciated that the invention has (without limitation) the following advantages:

- 1) The ability to track movement or an object through a warped video image.
- 2) The ability to adjust the bandwidth allocated to different portions of the warped video image that is sent across a network responsive to the tracked object or movement.
- 3) The ability to monitor an area and to determine when a track movement or object approaches and/or enters an area-of-interest.
- 4) The ability to automatically select movement or a moving object in a warped video image and to initiate tracking of that object and/or automatically select another movement or moving object.
- 5) The ability to track movement without the complexity of detecting background movement resulting from a movement of the camera.
- 6) The ability to track movement with a single camera to avoid the complexities of tracking a movement that exits one camera's field of view and enters another camera's field of view.

Although the present invention has been described in terms of the presently preferred embodiments, one skilled in the art will understand that various modifications and alterations may be made without departing from the scope of the invention. In particular, the order of the programming steps as described are not intended to be limiting. For example, but without limitation, the inventors contemplate practicing the invention using multiple threads of execution, multiple processors, and object-oriented programming practices. In addition, the scope of the invention includes the addition of or replacement of the previously described models. Accordingly, the scope of the invention is not to be limited to the particular invention embodiments discussed herein.