Patent Description:
As used herein, VR and AR systems are described and referenced interchangeably. Unless stated otherwise, the descriptions herein apply equally to all types of MR systems, which (as detailed above) include AR systems, VR reality systems, and/or any other similar system capable of displaying virtual content.

A MR system may also employ different types of cameras in order to display content to users, such as in the form of a passthrough image. A passthrough image or view can aid users in avoiding disorientation and/or safety hazards when transitioning into and/or navigating within a MR environment. A MR system can present views captured by cameras in a variety of ways. The process of using images captured by world-facing cameras to provide views of a real-world environment creates many challenges, however.

Some of these challenges occur when attempting to align image content from multiple cameras. Often, this alignment process requires detailed timestamp information and pose information in order to perform the alignment processes. Sometimes, however, timestamp data or perhaps even pose data is not available because different cameras may be operating in different time domains such that they have a temporal offset. Furthermore, sometimes the timestamp data is simply not available because the cameras may be operating remotely from one another, and the timestamp data is not transmitted. Another problem occurs as a result of having both a left and a right HMD camera (i.e. a dual camera system) but only a single detached camera. Aligning image content between the detached camera's image and the left camera's image in addition to aligning image content between the detached camera's image and the right camera's image causes many problems in compute efficiency and image alignment. That said, aligning image content provides substantial benefits, especially in terms of hologram placement and generation, so these problems present serious obstacles to the technical field. Accordingly, there is a substantial need in the field to improve how images are aligned with one another.

<CIT> describes a real-time surgery method and apparatus for displaying a stereoscopic augmented view of a patient from a static or dynamic viewpoint of the surgeon, which employs real-time three-dimensional surface reconstruction for preoperative and intraoperative image registration. Stereoscopic cameras provide real-time images of the scene including the patient. A stereoscopic video display is used by the surgeon, who sees a graphical representation of the preoperative or intraoperative images blended with the video images in a stereoscopic manner through a see through display.

<NPL> describes how although head-mounted displays (HMDs) are ideal devices for personal viewing of immersive stereoscopic content, exposure to VR applications on them results in significant discomfort for the majority of people, with symptoms including eye fatigue, headaches, nausea, and sweating. A conflict between accommodation and vergence depth cues on stereoscopic displays is a significant cause of visual discomfort. This article describes the results of an evaluation used to judge the effectiveness of dynamic depth-of-field (DoF) blur in an effort to reduce discomfort caused by exposure to stereoscopic content on HMDs. Using a commercial game engine implementation, study participants report a reduction of visual discomfort on a simulator sickness questionnaire when DoF blurring is enabled. The study participants reported a decrease in symptom severity caused by HMD exposure, indicating that dynamic DoF can effectively reduce visual discomfort.

Embodiments disclosed herein relate to systems, devices (e.g., hardware storage devices, wearable devices, etc.), and methods that align and stabilize images generated by an integrated stereo camera pair comprising a first camera and a second camera that are physically mounted to a computer system with images generated by a detached camera that is physically unmounted from the computer system.

In some embodiments, a first image is generated using the first camera; a second image is generated using the second camera; and a third image is generated using the detached camera. A first rotation base matrix of the third image is computed relative to the first image, and a second rotation base matrix of the third image is computed relative to the second image. The third image is then aligned to the first image using the first rotation base matrix, and the third image is also aligned to the second image using the second rotation base matrix. A first overlaid image is generated by overlaying the third image onto the first image based on the alignment process while a second overlaid image is generated by overlaying the third image onto the second image based on the corresponding alignment process. Some embodiments optionally perform a first parallax correction on the first overlaid image by modifying the first overlaid image from a first perspective to a first new perspective and optionally also perform a second parallax correction on the second overlaid image by modifying the second overlaid image from a second perspective to a second new perspective. The embodiments then optionally display the first overlaid image and the second overlaid image.

Embodiments disclosed herein relate to systems, devices (e.g., hardware storage devices, wearable devices, etc.), and methods that align and stabilize images generated by an integrated stereo camera pair with images generated by a detached camera.

In some embodiments, a first image is generated using a first stereo camera; a second image is generated using a second stereo camera; and a third image is generated using the detached camera. A first rotation base matrix is computed between the third and first images, and a second rotation base matrix is computed between the third and second images. The third image is aligned to the first image using the first rotation base matrix, and the third image is also aligned to the second image using the second rotation base matrix. A first overlaid image is generated by overlaying the third image onto the first image, and a second overlaid image is generated by overlaying the third image onto the second image. Optionally, some embodiments perform parallax correction on the two overlaid images. Some embodiments also optionally display the first overlaid image and the second overlaid image.

The following section outlines some example improvements and practical applications provided by the disclosed embodiments. It will be appreciated, however, that these are just examples only and that the embodiments are not limited to only these improvements.

The disclosed embodiments provide substantial improvements, benefits, and practical applications to the technical field. By way of example, the disclosed embodiments improve how images are generated and displayed and improve how image content is aligned.

That is, the embodiments solve the problem of aligning image content from a remote or detached camera image with image content from an integrated camera image to create a single composite or overlaid image. Notably, the overlaid image is generated without requiring the use of timestamp data, but rather is generated based on an assumption of co-location between the integrated cameras and the detached camera and further based on a feature matching process. There may be a variety of reasons as to why the information regarding the timestamp might not be known. For instance, asynchronous wireless communications might be occurring between multiple devices operating over different time domains, resulting in the occurrence of not knowing the timestamp. Furthermore, the disclosed embodiments solve problems related to image alignment when both a left and a right passthrough image are generated despite only a single detached camera image being generated. By performing the disclosed operations, the embodiments are able to significantly improve image quality and image display.

Attention will now be directed to <FIG> and <FIG>, which illustrate flowcharts of an example method <NUM> for aligning and stabilizing images generated by an integrated stereo camera pair comprising a first camera and a second camera that are physically mounted to a computer system (e.g., a HMD) with images generated by a detached camera that is physically unmounted from the computer system. In this regard, the embodiments are able to generate so-called "passthrough" images that have aligned content generated by different cameras.

By way of example, method <NUM> may be performed by the head-mounted device HMD <NUM> of <FIG>. HMD <NUM> can be any type of MR system 200A, including a VR system 200B or an AR system 200C. It should be noted that while a substantial portion of this disclosure is focused on the use of an HMD, the embodiments are not limited to being practiced using only an HMD. That is, any type of scanning system can be used, even systems entirely removed or separate from an HMD. As such, the disclosed principles should be interpreted broadly to encompass any type of scanning scenario or device. Some embodiments may even refrain from actively using a scanning device themselves and may simply use the data generated by the scanning device. For instance, some embodiments may at least be partially practiced in a cloud computing environment.

HMD <NUM> is shown as including scanning sensor(s) <NUM> (i.e. a type of scanning or camera system), and HMD <NUM> can use the scanning sensor(s) <NUM> to scan environments, map environments, capture environmental data, and/or generate any kind of images of the environment (e.g., by generating a 3D representation of the environment or by generating a "passthrough" visualization). Scanning sensor(s) <NUM> may comprise any number or any type of scanning devices, without limit.

In accordance with the disclosed embodiments, the HMD <NUM> may be used to generate a parallax-corrected passthrough visualization of the user's environment. In some cases, a "passthrough" visualization refers to a visualization that reflects what the user would see if the user were not wearing the HMD <NUM>, regardless of whether the HMD <NUM> is included as a part of an AR system or a VR system. In other cases, the passthrough visualization reflects a different or novel perspective.

To generate this passthrough visualization, the HMD <NUM> may use its scanning sensor(s) <NUM> to scan, map, or otherwise record its surrounding environment, including any objects in the environment, and to pass that data on to the user to view. In many cases, the passed-through data is modified to reflect or to correspond to a perspective of the user's pupils, though other perspectives may be reflected by the image as well. The perspective may be determined by any type of eye tracking technique or other data.

To convert a raw image into a passthrough image, the scanning sensor(s) <NUM> typically rely on its cameras (e.g., head tracking cameras, hand tracking cameras, depth cameras, or any other type of camera) to obtain one or more raw images (aka texture images) of the environment. In addition to generating passthrough images, these raw images may also be used to determine depth data detailing the distance from the sensor to any objects captured by the raw images (e.g., a z-axis range or measurement). Once these raw images are obtained, then a depth map can be computed from the depth data embedded or included within the raw images (e.g., based on pixel disparities), and passthrough images can be generated (e.g., one for each pupil) using the depth map for any reprojections.

As used herein, a "depth map" details the positional relationship and depths relative to objects in the environment. Consequently, the positional arrangement, location, geometries, contours, and depths of objects relative to one another can be determined. From the depth maps, a 3D representation of the environment can be generated.

Relatedly, from the passthrough visualizations, a user will be able to perceive what is currently in his/her environment without having to remove or reposition the HMD <NUM>. Furthermore, as will be described in more detail later, the disclosed passthrough visualizations will also enhance the user's ability to view objects within his/her environment (e.g., by displaying additional environmental conditions or image data that may not have been detectable by a human eye).

It should be noted that while the majority of this disclosure focuses on generating "a" passthrough image, the embodiments may generate a separate passthrough image for each one of the user's eyes. That is, two passthrough images are typically generated concurrently with one another. Therefore, while frequent reference is made to generating what seems to be a single passthrough image, the embodiments are actually able to simultaneously generate multiple passthrough images.

In some embodiments, scanning sensor(s) <NUM> include visible light camera(s) <NUM>, low light camera(s) <NUM>, thermal imaging camera(s) <NUM>, potentially (though not necessarily, as represented by the dotted box in <FIG>) ultraviolet (UV) camera(s) <NUM>, and potentially (though not necessarily) a dot illuminator (not shown). The ellipsis <NUM> demonstrates how any other type of camera or camera system (e.g., depth cameras, time of flight cameras, virtual cameras, depth lasers, etc.) may be included among the scanning sensor(s) <NUM>.

As an example, a camera structured to detect mid-infrared wavelengths may be included within the scanning sensor(s) <NUM>. As another example, any number of virtual cameras that are reprojected from an actual camera may be included among the scanning sensor(s) <NUM> and may be used to generate a stereo pair of images. In this manner and as will be discussed in more detail later, the scanning sensor(s) <NUM> may be used to generate the stereo pair of images. In some cases, the stereo pair of images may be obtained or generated as a result of performing any one or more of the following operations: active stereo image generation via use of two cameras and one dot illuminator; passive stereo image generation via use of two cameras; image generation using structured light via use of one actual camera, one virtual camera, and one dot illuminator; or image generation using a time of flight (TOF) sensor in which a baseline is present between a depth laser and a corresponding camera and in which a field of view (FOV) of the corresponding camera is offset relative to a field of illumination of the depth laser.

Generally, a human eye is able to perceive light within the so-called "visible spectrum," which includes light (or rather, electromagnetic radiation) having wavelengths ranging from about <NUM> nanometers (nm) up to about <NUM>. As used herein, the visible light camera(s) <NUM> include two or more red, green, blue (RGB) cameras structured to capture light photons within the visible spectrum. Often, these RGB cameras are complementary metal-oxide-semiconductor (CMOS) type cameras, though other camera types may be used as well (e.g., charge coupled devices, CCD).

The RGB cameras are typically stereoscopic cameras, meaning that the fields of view of the two or more RGB cameras at least partially overlap with one another. With this overlapping region, images generated by the visible light camera(s) <NUM> can be used to identify disparities between certain pixels that commonly represent an object captured by both images. Based on these pixel disparities, the embodiments are able to determine depths for objects located within the overlapping region (i.e. "stereoscopic depth matching" or "stereo depth matching"). As such, the visible light camera(s) <NUM> can be used to not only generate passthrough visualizations, but they can also be used to determine object depth. In some embodiments, the visible light camera(s) <NUM> can capture both visible light and IR light.

The low light camera(s) <NUM> are structured to capture visible light and IR light. IR light is often segmented into three different classifications, including near-IR, mid-IR, and far-IR (e.g., thermal-IR). The classifications are determined based on the energy of the IR light. By way of example, near-IR has relatively higher energy as a result of having relatively shorter wavelengths (e.g., between about <NUM> and about <NUM>,<NUM>). In contrast, far-IR has relatively less energy as a result of having relatively longer wavelengths (e.g., up to about <NUM>,<NUM>). Mid-IR has energy values in between or in the middle of the near-IR and far-IR ranges. The low light camera(s) <NUM> are structured to detect or be sensitive to IR light in at least the near-IR range.

In some embodiments, the visible light camera(s) <NUM> and the low light camera(s) <NUM> (aka low light night vision cameras) operate in approximately the same overlapping wavelength range. In some cases, this overlapping wavelength range is between about <NUM> nanometers and about <NUM>,<NUM> nanometers. Additionally, in some embodiments these two types of cameras are both silicon detectors.

One distinguishing feature between these two types of cameras is related to the illuminance conditions or illuminance range(s) in which they actively operate. In some cases, the visible light camera(s) <NUM> are low power cameras and operate in environments where the illuminance is between about a dusk illuminance (e.g., about <NUM> lux) and a bright noonday sun illuminance (e.g., about <NUM>,<NUM> lux), or rather, the illuminance range begins at about <NUM> lux and increases beyond <NUM> lux. In contrast, the low light camera(s) <NUM> consume more power and operate in environments where the illuminance range is between about a starlight illumination (e.g., about <NUM> milli lux) and a dusk illumination (e.g., about <NUM> lux).

The thermal imaging camera(s) <NUM>, on the other hand, are structured to detect electromagnetic radiation or IR light in the far-IR (i.e. thermal-IR) range, though some embodiments also enable the thermal imaging camera(s) <NUM> to detect radiation in the mid-IR range. To clarify, the thermal imaging camera(s) <NUM> may be a long wave infrared imaging camera structured to detect electromagnetic radiation by measuring long wave infrared wavelengths. Often, the thermal imaging camera(s) <NUM> detect IR radiation having wavelengths between about <NUM> microns and <NUM> microns to detect blackbody radiation from the environment and people in the camera field of view. Because the thermal imaging camera(s) <NUM> detect far-IR radiation, the thermal imaging camera(s) <NUM> can operate in any illuminance condition, without restriction.

In some cases (though not all), the thermal imaging camera(s) <NUM> include an uncooled thermal imaging sensor. An uncooled thermal imaging sensor uses a specific type of detector design that is based on an array of microbolometers, which is a device that measures the magnitude or power of an incident electromagnetic wave / radiation. To measure the radiation, the microbolometer uses a thin layer of absorptive material (e.g., metal) connected to a thermal reservoir through a thermal link. The incident wave strikes and heats the material. In response to the material being heated, the microbolometer detects a temperature-dependent electrical resistance. Changes to environmental temperature cause changes to the bolometer's temperature, and these changes can be converted into an electrical signal to thereby produce a thermal image of the environment. In accordance with at least some of the disclosed embodiments, the uncooled thermal imaging sensor is used to generate any number of thermal images. The bolometer of the uncooled thermal imaging sensor can detect electromagnetic radiation across a wide spectrum, spanning the mid-IR spectrum, the far-IR spectrum, and even up to millimeter-sized waves.

The UV camera(s) <NUM> are structured to capture light in the UV range. The UV range includes electromagnetic radiation having wavelengths between about <NUM> and about <NUM>. The disclosed UV camera(s) <NUM> should be interpreted broadly and may be operated in a manner that includes both reflected UV photography and UV induced fluorescence photography.

Accordingly, as used herein, reference to "visible light cameras" (including "head tracking cameras"), are cameras that are primarily used for computer vision to perform head tracking. These cameras can detect visible light, or even a combination of visible and IR light (e.g., a range of IR light, including IR light having a wavelength of about <NUM>). In some cases, these cameras are global shutter devices with pixels being about <NUM> in size. Low light cameras, on the other hand, are cameras that are sensitive to visible light and near-IR. These cameras are larger and may have pixels that are about <NUM> in size or larger. These cameras are also sensitive to wavelengths that silicon sensors are sensitive to, which wavelengths are between about <NUM> to <NUM>. These sensors can also be fabricated with III-V materials to be optically sensitive to NIR wavelengths. Thermal / long wavelength IR devices (i.e. thermal imaging cameras) have pixel sizes that are about <NUM> or larger and detect heat radiated from the environment. These cameras are sensitive to wavelengths in the <NUM> to <NUM> range. Some embodiments also include mid-IR cameras configured to detect at least mid-IR light. These cameras often comprise non-silicon materials (e.g., InP or InGaAs) that detect light in the <NUM> to <NUM> wavelength range.

Accordingly, the disclosed embodiments may be structured to utilize numerous different camera types. The different camera types include, but are not limited to, visible light cameras, low light cameras, thermal imaging cameras, and UV cameras. Stereo depth matching may be performed using images generated from any one type or combination of types of the above listed camera types.

Generally, the low light camera(s) <NUM>, the thermal imaging camera(s) <NUM>, and the UV camera(s) <NUM> (if present) consume relatively more power than the visible light camera(s) <NUM>. Therefore, when not in use, the low light camera(s) <NUM>, the thermal imaging camera(s) <NUM>, and the UV camera(s) <NUM> are typically in the powered-down state in which those cameras are either turned off (and thus consuming no power) or in a reduced operability mode (and thus consuming substantially less power than if those cameras were fully operational). In contrast, the visible light camera(s) <NUM> are typically in the powered-up state in which those cameras are by default fully operational.

It should be noted that any number of cameras may be provided on the HMD <NUM> for each of the different camera types. That is, the visible light camera(s) <NUM> may include <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or more than <NUM> cameras. Often, however, the number of cameras is at least <NUM> so the HMD <NUM> can perform stereoscopic depth matching, as described earlier. Similarly, the low light camera(s) <NUM>, the thermal imaging camera(s) <NUM>, and the UV camera(s) <NUM> may each respectively include <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or more than <NUM> corresponding cameras.

<FIG> illustrates an example HMD <NUM>, which is representative of the HMD <NUM> from <FIG>. HMD <NUM> is shown as including multiple different cameras, including cameras <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. Cameras <NUM>-<NUM> are representative of any number or combination of the visible light camera(s) <NUM>, the low light camera(s) <NUM>, the thermal imaging camera(s) <NUM>, and the UV camera(s) <NUM> from <FIG>. While only <NUM> cameras are illustrated in <FIG>, HMD <NUM> may include more or less than <NUM> cameras.

In some cases, the cameras can be located at specific positions on the HMD <NUM>. For instance, in some cases a first camera (e.g., perhaps camera <NUM>) is disposed on the HMD <NUM> at a position above a designated left eye position of any users who wear the HMD <NUM> relative to a height direction of the HMD. For instance, the camera <NUM> is positioned above the pupil <NUM>. As another example, the first camera (e.g., camera <NUM>) is additionally positioned above the designated left eye position relative to a width direction of the HMD. That is, the camera <NUM> is positioned not only above the pupil <NUM> but also in-line relative to the pupil <NUM>. When a VR system is used, a camera may be placed directly in front of the designated left eye position. For example, with reference to <FIG>, a camera may be physically disposed on the HMD <NUM> at a position in front of the pupil <NUM> in the z-axis direction.

When a second camera is provided (e.g., perhaps camera <NUM>), the second camera may be disposed on the HMD at a position above a designated right eye position of any users who wear the HMD relative to the height direction of the HMD. For instance, the camera <NUM> is above the pupil <NUM>. In some cases, the second camera is additionally positioned above the designated right eye position relative to the width direction of the HMD. When a VR system is used, a camera may be placed directly in front of the designated right eye position. For example, with reference to <FIG>, a camera may be physically disposed on the HMD <NUM> at a position in front of the pupil <NUM> in the z-axis direction.

When a user wears HMD <NUM>, HMD <NUM> fits over the user's head and the HMD <NUM>'s display is positioned in front of the user's pupils, such as pupil <NUM> and pupil <NUM>. Often, the cameras <NUM>-<NUM> will be physically offset some distance from the user's pupils <NUM> and <NUM>. For instance, there may be a vertical offset in the HMD height direction (i.e. the "Y" axis), as shown by offset <NUM>. Similarly, there may be a horizontal offset in the HMD width direction (i.e. the "X" axis), as shown by offset <NUM>.

As described earlier, HMD <NUM> is configured to provide passthrough image(s) for the user of HMD <NUM> to view. In doing so, HMD <NUM> is able to provide a visualization of the real world without requiring the user to remove or reposition HMD <NUM>. These passthrough image(s) effectively represent the same view the user would see if the user were not wearing HMD <NUM>. Cameras <NUM>-<NUM> are used to provide these passthrough image(s).

None of the cameras <NUM>-<NUM>, however, are telecentrically aligned with the pupils <NUM> and <NUM>. The offsets <NUM> and <NUM> actually introduce differences in perspective as between the cameras <NUM>-<NUM> and the pupils <NUM> and <NUM>. These perspective differences are referred to as "parallax.

Because of the parallax occurring as a result of the offsets <NUM> and <NUM>, raw images (aka texture images) produced by the cameras <NUM>-<NUM> may not be available for immediate use as passthrough images. Instead, it is beneficial to perform a parallax correction (aka an image synthesis) on the raw images to transform the perspectives embodied within those raw images to correspond to perspectives of the user's pupils <NUM> and <NUM>. The parallax correction includes any number of corrections, which will be discussed in more detail later.

Returning to <FIG>, initially method <NUM> includes an act (act <NUM>) of generating a first image using the first camera, generating a second image using the second camera, and generating a third image using the detached camera. For instance, the first camera may be any one of the cameras <NUM>-<NUM> illustrated in <FIG>, and the second camera may be any other one of the cameras <NUM>-<NUM>. Furthermore, the first and second cameras may be any of the camera modalities mentioned earlier (e.g., thermal imaging, etc.). The detached camera, on the other hand, will not be any of the cameras <NUM>-<NUM>. Instead, the detached camera is physically separated or unmounted from the HMD. <FIG> is illustrative of such a scenario. Accordingly, the first camera, the second camera, or even the detached camera mentioned in method act <NUM> may all be visible light cameras, thermal imaging cameras, low light cameras, UV cameras, or, alternatively, any combination of visible light cameras, low light cameras, thermal imaging cameras, or UV cameras.

<FIG> shows an example environment <NUM> in which an HMD <NUM> is operating. HMD <NUM> is representative of HMD <NUM> of <FIG> and HMD <NUM> of <FIG>. HMD <NUM> is shown as including an integrated stereo camera pair <NUM> comprising a first camera <NUM> and a second camera <NUM>, which cameras are representative of the cameras mentioned in method act <NUM> of <FIG> and which are representative of the cameras discussed thus far.

<FIG> also shows a detached camera <NUM>, which is representative of the detached camera mentioned in method act <NUM>. Notice, the detached camera <NUM> is physically unmounted from the HMD <NUM> such that it is able to move independently of any motion of the HMD <NUM>. Furthermore, the detached camera <NUM> is separated from the HMD <NUM> by a distance <NUM>. This distance <NUM> may be any distance, but typically it is less than <NUM> meters (i.e. the distance <NUM> is at most <NUM> meters).

In this example, the various different cameras are being used in a scenario where objects in the environment <NUM> are relatively far away from the HMD <NUM>, as shown by the distance <NUM>. The relationship between the distance <NUM> and the distance <NUM> will be discussed in more detail later.

In any event, the first camera <NUM> is capturing images of the environment <NUM> from a first perspective <NUM>, the second camera <NUM> is capturing images of the environment <NUM> from a second perspective <NUM>, and the detached camera <NUM> is capturing images of the environment <NUM> from a third perspective <NUM>. In accordance with the disclosed principles, despite there being a distance <NUM> between the stereo camera pair <NUM> and the detached camera <NUM>, the embodiments initially rely on an assumption that the detached camera <NUM> is co-located <NUM> with the stereo camera pair <NUM>. By co-located <NUM>, it is meant that the detached camera <NUM> is assumed to be positioned at the same location as the first camera <NUM> (for one set of operations) and is assumed to be positioned at the same location as the second camera <NUM> (for a different set of operations) on the HMD <NUM>. Being co-located <NUM> does not mean that the detached camera <NUM> has the same <NUM> degree of freedom (<NUM> DOF) pose or perspective as the first or second cameras <NUM> and <NUM>; rather, it means that the physical placement of the detached camera <NUM> is assumed to be at the same location as the first and second camera <NUM> (i.e. same distance <NUM>).

<FIG> shows a scenario in which the different cameras mentioned in <FIG> are now being used to generate respective images. Specifically, the first camera <NUM> of <FIG> has a FOV <NUM> and is generating an image based on the FOV <NUM>. Similarly, the second camera <NUM> of <FIG> has a FOV <NUM> and is generating an image based on the FOV <NUM>. Finally, the detached camera <NUM> has a FOV <NUM> and is generating an image based on the FOV <NUM>.

In some embodiments, the size of the FOV <NUM> is the same as the size of the FOV <NUM>. In some embodiments, the size of FOV <NUM> may be different from the size of FOV <NUM>. In some embodiments, the size of FOV <NUM> is smaller than either one of the sizes of FOVs <NUM> or <NUM>. In some embodiments, the size of FOV <NUM> may be the same as either one or both of the sizes of FOVs <NUM> and <NUM>.

In some cases, the size of FOV <NUM> is less than about a <NUM>-degree horizontal spread, such as perhaps a <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or less than <NUM>-degree horizontal spread. In some cases, either one or both of the sizes of FOVs <NUM> and <NUM> is less than about a <NUM>-degree horizontal spread, such as perhaps a <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or less than <NUM>-degree horizontal spread. <FIG> shows the resulting images, which are representative of the images discussed in method act <NUM> of <FIG>.

<FIG> shows a first image <NUM>, which was generated by the first camera <NUM> of <FIG>. The second image <NUM> was generated by the second camera <NUM>, and the third image <NUM> was generated by the detached camera <NUM>. <FIG> shows how the first image <NUM> has a resolution <NUM>, the second image <NUM> has a resolution <NUM>, and the third image <NUM> has a resolution <NUM>.

In some embodiments, the resolution <NUM> is the same as the resolution <NUM>, and the resolution <NUM> is the same as the resolutions <NUM> and <NUM>. In some embodiments, the resolutions may all be different or two of them may be the same while the remaining resolution is different. Because the sizes of the FOVs of the different cameras may be different, the size of the resulting images may also be different. Despite the sizes being different, the resolutions may still be the same. For instance, <FIG> shows how the third image <NUM> is smaller than either one of the first image <NUM> or the second image <NUM>. Notwithstanding this difference in size, the resolutions may all still be the same. Consequently, each pixel included in the third image <NUM> is smaller and provides a heightened level of detail as compared to each pixel in either the first image <NUM> or the second image <NUM>.

Accordingly, in some embodiments, the resolution <NUM> of the third image <NUM> may be the same as the resolution <NUM> of the first image <NUM> (or the resolution <NUM> of the second image <NUM>) such that, as a result of the FOV of the third image <NUM> (e.g., FOV <NUM> in <FIG>) being smaller than the FOV of the first image (e.g., FOV <NUM>), each pixel in the third image <NUM> is smaller than each pixel in the first image <NUM> (and also the second image <NUM>).

Returning to <FIG>, method <NUM> further includes an act (act <NUM>) of computing a first rotation base matrix of the third image relative to the first image. Either in parallel or in serial with act <NUM>, there is an act <NUM> of computing a second rotation base matrix of the third image relative to the second image. To compute the rotation base matrices, the embodiments first perform a feature matching process <NUM>, as shown in <FIG>.

<FIG> shows a first image <NUM>, a second image <NUM>, and a third image <NUM>, which correspond to the first image <NUM>, the second image <NUM>, and the third image <NUM> of <FIG>, respectively. In accordance with the disclosed principles, the embodiments identify so-called "feature points" within the different images. Generally, a "feature point" refers to discrete and identifiable points included within an object or image. Examples of feature points include corners, edges, or other geometric contours having a stark contrast with other areas of the environment. The dark circles in each of the images shown in <FIG> correspond to the corners where two walls meet and are considered to be feature points. While only a few feature points are illustrated in <FIG>, one will appreciate how the embodiments are able to identify any number of feature points in an image.

Identifying feature points may be performed using any type of image analysis, image segmentation, or perhaps even machine learning (ML). Any type of ML algorithm, model, or machine learning may be used to identify feature points. As used herein, reference to "machine learning" or to a ML model may include any type of machine learning algorithm or device, neural network (e.g., convolutional neural network(s), multilayer neural network(s), recursive neural network(s), deep neural network(s), dynamic neural network(s), etc.), decision tree model(s) (e.g., decision trees, random forests, and gradient boosted trees), linear regression model(s) or logistic regression model(s), support vector machine(s) ("SVM"), artificial intelligence device(s), or any other type of intelligent computing system. Any amount of training data may be used (and perhaps later refined) to train the machine learning algorithm to dynamically perform the disclosed operations.

<FIG> specifically identifies feature point 720A in the first image <NUM>. The feature point 720B in the second image <NUM> corresponds to the feature point 720A. Similarly, the feature point 720C identified in the third image <NUM> corresponds to both the feature points 720A and 720B. In this context, "correspond" means that the three identified feature points represent the same area or object in the environment (i.e. the specific portion of the corner wall).

The embodiments are able to analyze the three different images, identify different feature points, and then perform feature point matching <NUM> to link or associate corresponding feature points with one another. For instance, the dotted lined labeled as feature point matching <NUM> symbolically represents the association between the feature points 720A, 720B, and 720C.

Detecting corresponding feature points requires that the FOVs of the different cameras at least partially overlap with one another, as was shown in <FIG>. If there is no overlap or not a sufficient amount of overlap between the different FOVs, then the feature matching process <NUM> may not be able to detect a sufficient number of feature points. If there is a sufficient level of overlap, on the other hand, then the embodiments can detect corresponding feature points.

Once the corresponding feature points are identified (e.g., corresponding features points 720A, 720B, and 720C), the embodiments rely on an assumption that the three different cameras are co-located with one another, as was introduced in <FIG>. For instance, the embodiments assume the third camera is co-located with the first camera and separately assume the third camera is co-located with the second camera. In this regard, the embodiments assume the first and third cameras are located at the same position but that the two cameras currently have different poses or rotational alignments. Similarly, the embodiments assume the second and third cameras are located at the same position but that the two cameras currently have different poses or rotational alignments.

This co-location assumption is valid when the distance <NUM> shown in <FIG> between the cameras and objects in the environment is sufficiently large. The assumption may break down when the distance <NUM> is smaller than a minimum threshold distance. The minimum threshold distance may be set to any distance, but the assumption will typically be operational for distances over about <NUM> meters.

Based on the results of the feature matching and based on the co-location assumption, the embodiments then compute the rotation base matrices described in method acts <NUM> and <NUM>. <FIG> is illustrative of this process.

<FIG> shows a third image <NUM>, which is representative of the third images discussed thus far (i.e. the one generated by the detached camera), and a first image <NUM>, which is representative of the first images discussed thus far (i.e. the one generated by the first camera). In accordance with the disclosed principles, the embodiments assume that the detached camera and the first camera are co-located <NUM> with one another such that there is only a rotational alignment difference, or a <NUM> DOF <NUM> difference, between the third image <NUM> and the first image <NUM>.

Using the detected feature points as reference points, the embodiments then compute a first rotation base matrix <NUM> between the third image <NUM> and the first image <NUM>. The first rotation base matrix <NUM> details the angular difference between the position of the third image <NUM> and the first image <NUM>. Stated differently, the first rotation base matrix <NUM> provides a mapping on the translational or angular movement that would be required to go from the perspective of the third image <NUM> to the perspective of the first image <NUM>.

That is, computing the first rotation base matrix <NUM> of the third image <NUM> relative to the first image <NUM> is performed based on an incorrect, but acceptable, assumption that the third camera and the first camera are co-located <NUM> with one another (thus there is no translational mapping required, only a rotational mapping). Furthermore, computing the first rotation base matrix <NUM> of the third image <NUM> relative to the first image <NUM> may be performed based on a result of a feature matching process (e.g., feature matching process <NUM> of <FIG>) being performed between the first image <NUM> and the third image <NUM>.

The first rotation base matrix <NUM> can be considered a type of motion model. Generally, a motion model is a type of transformation matrix that enables a model, a known scene, or an object to be projected onto a different model, scene, or object.

In some cases, the motion model may simply be a rotational motion model. With a rotational model, the embodiments are able to shift one image by any number of pixels (e.g., perhaps <NUM> pixels to the left and <NUM> pixels up) in order to overlay one image onto another image. For instance, once the feature points are identified, the embodiments can identify the pixel coordinates of those feature points or correspondences. Once the coordinates are identified, then the embodiments can generate the first rotation base matrix <NUM> by determining the amount or level of shifting required in order to align the feature points from the third image to the feature points of the first image.

In some cases, the motion model may be more complex, such as in the form of a similarity transform model. The similarity transform model may be configured to allow for (i) rotation of either one of the integrated camera image (i.e. the first image) or the detached camera image (i.e. the third image), (ii) scaling of the first image or the third image, or (iii) homographic transformations of the first image or the third image. In this regard, the similarity transform model approach may be used to determine the first rotation base matrix <NUM>.

Similar operations may be performed as between the third image <NUM> and the second image <NUM>, as shown in <FIG>. For instance, the embodiments initially assume the third image <NUM> is co-located <NUM> with the second image <NUM>. Based on this co-located <NUM> assumption, the embodiments determine there is only a <NUM> DOF <NUM> difference between the third image <NUM> and the second image <NUM>. With that assumption, the embodiments are able to generate a second rotation base matrix <NUM> to rotationally translate the perspective of the third image <NUM> until it aligns with the perspective of the second image <NUM> based on the pixel locations or coordinates of the detected and corresponding feature points present in those two images.

Similar to what was discussed earlier, computing the second rotation base matrix <NUM> of the third image <NUM> relative to the second image <NUM> may be performed based on an incorrect, but acceptable, assumption that the third camera and the second camera are co-located <NUM> with one another. Furthermore, computing the second rotation base matrix <NUM> of the third image <NUM> relative to the second image <NUM> may be performed based on a result of a feature matching process (e.g., feature matching process <NUM> of <FIG>) being performed between the second image <NUM> and the third image <NUM>.

After computing the two different rotation base matrices, method <NUM> of <FIG> continues with an act <NUM> of aligning the third image to the first image using the first rotation base matrix and aligning the third image to the second image using the second rotation base matrix. Whereas method acts <NUM> and <NUM> involved generating the base matrices, which itself might also be considered an alignment process, act <NUM> involves manipulating the different images so that they are actually overlaid or positioned on one another, perhaps in a layered manner. As a consequence of performing this alignment operation, method <NUM> continues in <FIG> with an act (act <NUM>) of actually generating a first overlaid image by overlaying the third image onto the first image (based on the alignment process) and an act (act <NUM>) of generating a second overlaid image by overlaying the third image onto the second image (based on that alignment process). <FIG> is representative of these two acts.

<FIG> shows an alignment <NUM> process representative of the alignment processes described in method acts <NUM> through <NUM> of <FIG> and <FIG>. Specifically, the alignment <NUM> process involves using the previously computed first rotation base matrix to align third image content <NUM> with the first image content <NUM> so as to generate a single, integrated (i.e. perhaps not layered) first overlaid image <NUM>. In some cases, a boundary <NUM> is visually displayed in the first overlaid image <NUM> to emphasize or identify pixels that originated from the first image (i.e. the first image content <NUM>) and pixels that originated from the third image (i.e. the third image content <NUM>).

Recall, in some embodiments the resolution of the smaller FOV third image was the same as the resolution of the larger FOV first image. Consequently, the pixels of the third image will give content a sharper, clearer, or more crisp visualization as compared to pixels of the first image. Therefore, by overlaying the third image content <NUM> onto the first image content <NUM>, the section of the first overlaid image <NUM> corresponding to the third image content <NUM> may appear to be clearer or of higher detail than other portions of the first overlaid image <NUM> (e.g., those pixels corresponding to the first image content <NUM>). Similar operations may be performed as between the third image and the second image.

The alignment <NUM> process may additionally involve using the previously computed second rotation base matrix to align third image content <NUM> with the second image content <NUM> so as to generate a single, integrated (i.e. perhaps not layered) second overlaid image <NUM>. In some cases, a boundary <NUM> is visually displayed in the second overlaid image <NUM> to emphasize or identify pixels that originated from the second image (i.e. the second image content <NUM>) and pixels that originated from the third image (i.e. the third image content <NUM>).

In some embodiments, the alignment <NUM> process may be dependent on inertial measurement unit (IMU) data obtained from any of the first, second, or detached cameras. For instance, IMU data 945A is IMU data obtained from an IMU of the first camera and describes movement of the first camera. IMU data 945B is IMU data obtained from an IMU of the detached camera and describes movement of the detached camera. IMU data 945C is IMU data obtained from an IMU of the second camera and describes movement of the second camera.

If the first or second rotational base matrices were calculated prior to a subsequent movement of any of the first, second, or detached cameras, the embodiments are able to utilize the IMU data 945A, 945B, and 945C to update the respective first or second rotational base matrices to account for the new movement. For instance, by multiplying the first rotational base matrix against matrix data generated based on the IMU data 945A and 945B, the embodiments are able to undo the effects of movement of either one of the first camera or the detached camera. Similarly, by multiplying the second rotational base matrix against matrix data generated based on the IMU data 945C and 945B, the embodiments are able to undo the effects of movement of either one of the second camera or the detached camera. In this regard, aligning the third image to the first image using the first rotation base matrix may be performed using inertial measurement unit (IMU) data from the first camera and IMU data from the third camera, with similar operations for the second and detached cameras. Accordingly, the alignment <NUM> process may be based on the results of the feature matching operations as well as utilizing the rotational base matrices and possibly even IMU data.

Returning to <FIG>, method <NUM> also includes an act (act <NUM>) of performing a first parallax correction on the first overlaid image by modifying the first overlaid image from a first perspective to a first new perspective. In parallel or in serial with act <NUM>, method <NUM> includes an act (act <NUM>) of performing a second parallax correction on the second overlaid image by modifying the second overlaid image from a second perspective to a second new perspective. Both acts <NUM> and <NUM> are illustrated in <FIG> using a dotted line to show that these acts are optional.

The computer system implementing the disclosed operations (including method <NUM>) may be a head-mounted device (HMD) worn by a user. The first new perspective may correspond to one of a left eye pupil or a right eye pupil, and the second new perspective may correspond to the other one of the left eye pupil or the right eye pupil.

Another optional act involves the act <NUM> of displaying the first overlaid image and the second overlaid image. <FIG>, <FIG>, and <FIG> are illustrative of some of these operations.

<FIG> shows an overlaid image <NUM>, which may be either one of the first overlaid image <NUM> or the second overlaid image <NUM> from <FIG> and which may be the overlaid images discussed in method <NUM>. Here, the overlaid image <NUM> is shown as having an original perspective <NUM>. In accordance with the disclosed principles, the embodiments are able to perform a parallax correction <NUM> to transform the original perspective <NUM> of the overlaid image <NUM> into a new or novel perspective.

Performing the parallax correction <NUM> involves the use of a depth map in order to reproject the image content to a new perspective. Additionally, the parallax correction <NUM> is shown as including any one or more of a number of different operations. For instance, the parallax correction <NUM> may involve distortion corrections <NUM> (e.g., to correct for concave or convex wide or narrow angled camera lenses), epipolar transforms <NUM> (e.g., to parallelize the optical axes of the cameras), and/or reprojection transforms <NUM> (e.g., to reposition the optical axes so as to be essentially in front of or in-line with the user's pupils). The parallax correction <NUM> includes performing depth computations to determine the depth of the environment and then reprojecting images to a determined location or as having a determined perspective. As used herein, the phrases "parallax correction" and "image synthesis" may be interchanged with one another and may include performing stereo passthrough parallax correction and/or image reprojection parallax correction.

The reprojections are based on the original perspective <NUM> of the overlaid image <NUM> relative to the surrounding environment. Based on the original perspective <NUM> and the depth maps that are generated, the embodiments are able to correct parallax by reprojecting a perspective embodied by the overlaid images to coincide with a new perspective, as shown by the parallax-corrected image <NUM> and the new perspective <NUM>. In some embodiments, the new perspective <NUM> is that of one of the user's pupils <NUM> and <NUM> from <FIG>.

Some embodiments perform three-dimensional (3D) geometric transforms on the overlaid images to transform the perspectives of the overlaid images in a manner so as to correlate with the perspectives of the user's pupils <NUM> and <NUM>. Additionally, the 3D geometric transforms rely on depth computations in which the objects in the HMD's environment are mapped out to determine their depths as well as the perspective. Based on these depth computations and perspective, the embodiments are able to three-dimensionally reproject or three-dimensionally warp the overlaid images in such a way so as to preserve the appearance of object depth in the parallax-corrected image <NUM> (i.e. a type of passthrough image), where the preserved object depth substantially matches, corresponds, or visualizes the actual depths of objects in the real world. Accordingly, the degree or amount of the parallax correction <NUM> is at least partially dependent on the degree or amount of the offsets <NUM> and <NUM> from <FIG>.

By performing the parallax correction <NUM>, the embodiments effectively create "virtual" cameras having positions that are in front of the user's pupils <NUM> and <NUM>. By way of additional clarification, consider the position of camera <NUM> from <FIG>, which is currently above and to the left of the pupil <NUM>. By performing the parallax correction, the embodiments programmatically transform images generated by camera <NUM>, or rather the perspectives of those images, so the perspectives appear as though camera <NUM> were actually positioned immediately in front of pupil <NUM>. That is, even though camera <NUM> does not actually move, the embodiments are able to transform images generated by camera <NUM> so those images have the appearance as if camera <NUM> were positioned in front of pupil <NUM>.

In some cases, the parallax correction <NUM> relies on a full depth map to perform the reprojections while in other cases the parallax correction <NUM> relies on a planar depth map to perform the reprojections. <FIG> illustrates an example usage of a full depth map while <FIG> illustrates an example usage of a planar depth map.

Turning first to <FIG>, this figure illustrates a scenario involving a full depth map reprojection <NUM>. Initially, there is shown a third image <NUM>, which is representative of the third images discussed thus far. Similar to the other third images, third image <NUM> is bounded by a circle <NUM> (of course, any other shape may be used) comprising any number of pixels <NUM>. One pixel in particular is emphasized and is shown by the center pixel <NUM> (i.e. the pixel located at the center of the circle <NUM>).

When performing a reprojection using a full depth map on the overlaid image, it is beneficial to attribute a single depth to all of the pixels bounded by the circle <NUM>. Not doing so may result in skewing or warping of the parallax corrected region corresponding to the third image content. For instance, instead of resulting in a circle of pixels, as shown by the circle emphasized in the parallax-corrected image <NUM> of <FIG>, not using a single common depth for the pixels in the third image <NUM> may result in an oval or other skewing effects. Accordingly, the embodiments determine a depth <NUM> corresponding to the depth of the center pixel <NUM> and then attribute <NUM> that single depth <NUM> to all of the pixels bounded by the circle <NUM>, as shown by the uniform depth <NUM> illustration.

To clarify, all of the pixels bounded by the circle <NUM> are given the same depth value (i.e. the depth of the center pixel <NUM>). The resulting depth map will appear as the full depth map <NUM>, where the color gradients reflect different depth values and where the pixels corresponding to those bounded by the circle <NUM> are all given the same shading such that they all have the same depth value.

The full depth map <NUM> is then used to perform the reprojections involved in the parallax correction operations discussed earlier. By attributing the same depth to all of the pixels for the third image content included in the overlaid image, the embodiments prevent skewing from occurring on that image content as a result of performing parallax correction.

While most embodiments select the depth corresponding to the center pixel <NUM>, some embodiments may be configured to select a depth of a different pixel bounded by the circle <NUM>. As such, using the depth of the center pixel <NUM> is simply one example implementation, but it is not the only implementation. Some embodiments select a number of pixels that are centrally located and then use the average depth of those pixels. Some embodiments select an off-center pixel or group of pixel's depth.

Instead of using the full depth map <NUM> to perform reprojections, some embodiments use a fixed depth map to perform a fixed depth map reprojection <NUM> as shown in <FIG>. Specifically, a third image <NUM> is again shown, which image is representative of the other third images discussed thus far. Here again, the embodiments select the depth of a particular pixel from the third image <NUM>. In this case, the center pixel <NUM> is selected, and a depth <NUM> of that center pixel <NUM> is identified (or perhaps some other pixel or group of pixel's depth).

Based on the depth <NUM>, the embodiments then attribute that single depth to all of the pixels of a depth map to generate the fixed depth map <NUM>. To clarify, all of the depth pixels in the fixed depth map <NUM> are assigned or attributed the same depth, which is the depth <NUM> of the center pixel <NUM> (or some other selected pixel). The common shading across the entire fixed depth map <NUM> symbolizes the uniform depth values or planar depth values in the depth map.

Once the fixed depth map <NUM> is generated, this depth map may then be used to perform a reprojection (e.g., a planar reprojection) on the overlaid image using the fixed depth map <NUM>. In this regard, reprojecting the overlaid image (e.g., overlaid image <NUM> from <FIG>) to generate parallax-corrected image <NUM> may be performed using a full depth map <NUM> or a fixed depth map <NUM>. Stated differently, the first parallax correction and/or the second parallax correction mentioned in method acts <NUM> and <NUM> of <FIG> may include reprojecting content based on a fixed depth plane or, alternatively, based on a full depth map.

Accordingly, the embodiments are able to perform the first (or second) parallax correction mentioned in acts <NUM> and <NUM> of <FIG> on the first (or second) overlaid image. Such parallax correction may involve a number of different operations. For example, one operation includes identifying pixels included within at least a portion (or potentially the entirety) of the third image (e.g., the embodiments may identify all of the pixels bounded by the circle <NUM> of <FIG>). To clarify, in some cases, the portion of the third image may be a circle such that the identified pixels form the circle. In other cases, the portion may form a different shape, such as any polygon.

Another operation includes selecting a depth corresponding to at least one of the identified pixels (e.g., the center pixel <NUM> of <FIG>). That is, the selected depth may be the depth of the center pixel of the circle mentioned earlier. Another operation includes attributing the depth (e.g., attribute <NUM> of <FIG>) to all of the identified pixels, as shown by the uniform depth <NUM>. When performing the first or second parallax correction, another operation involves reprojecting the identified pixels using the attributed depth.

Accordingly, the disclosed embodiments are able to align images from different cameras and then perform parallax correction on the aligned images in order to generate passthrough images having new perspectives. Such operations significantly enhance the quality of images by enabling new and dynamic image content to be displayed.

Attention will now be directed to <FIG> which illustrates an example computer system <NUM> that may include and/or be used to perform any of the operations described herein. Computer system <NUM> may take various different forms. For example, computer system <NUM> may be embodied as a tablet 1300A, a desktop or laptop 1300B, a wearable device 1300C (e.g., such as any of the disclosed HMDs), a mobile device, a standalone device, or any other embodiment as shown by the ellipsis 1300D. Computer system <NUM> may also be a distributed system that includes one or more connected computing components/devices that are in communication with computer system <NUM>.

In its most basic configuration, computer system <NUM> includes various different components. <FIG> shows that computer system <NUM> includes one or more processor(s) <NUM> (aka a "hardware processing unit"), scanning sensor(s) <NUM> (e.g., such as the scanning sensor(s) <NUM> of <FIG>), an image processing engine <NUM>, and storage <NUM>.

Regarding the processor(s) <NUM>, it will be appreciated that the functionality described herein can be performed, at least in part, by one or more hardware logic components (e.g., the processor(s) <NUM>). For example, and without limitation, illustrative types of hardware logic components/processors that can be used include Field-Programmable Gate Arrays ("FPGA"), Program-Specific or Application-Specific Integrated Circuits ("ASIC"), Program-Specific Standard Products ("ASSP"), System-On-A-Chip Systems ("SOC"), Complex Programmable Logic Devices ("CPLD"), Central Processing Units ("CPU"), Graphical Processing Units ("GPU"), or any other type of programmable hardware.

Any type of depth detection may be utilized by the computer system <NUM> and by the scanning sensor(s) <NUM>. Examples include, but are not limited to, stereoscopic depth detection (both active illumination (e.g., using a dot illuminator), structured light illumination (e.g., <NUM> actual camera, <NUM> virtual camera, and <NUM> dot illuminator), and passive (i.e. no illumination)), time of flight depth detection (with a baseline between the laser and the camera, where the field of view of the camera does not perfectly overlap the field of illumination of the laser), range finder depth detection, or any other type of range or depth detection.

The image processing engine <NUM> may be configured to perform any of the method acts discussed in connection with method <NUM> of <FIG>. In some instances, the image processing engine <NUM> includes a ML algorithm. That is, ML may also be utilized by the disclosed embodiments, as discussed earlier. ML may be implemented as a specific processing unit (e.g., a dedicated processing unit as described earlier) configured to perform one or more specialized operations for the computer system <NUM>. As used herein, the terms "executable module," "executable component," <NUM> "component," "module," "model," or "engine" can refer to hardware processing units or to software objects, routines, or methods that may be executed on computer system <NUM>. The different components, modules, engines, models, and services described herein may be implemented as objects or processors that execute on computer system <NUM> (e.g. as separate threads). ML models and/or the processor(s) <NUM> can be configured to perform one or more of the disclosed method acts or other functionalities.

Storage <NUM> may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term "memory" may also be used herein to refer to non-volatile mass storage such as physical storage media. If computer system <NUM> is distributed, the processing, memory, and/or storage capability may be distributed as well.

Storage <NUM> is shown as including executable instructions (i.e. code <NUM>). The executable instructions represent instructions that are executable by the processor(s) <NUM> (or perhaps even the image processing engine <NUM>) of computer system <NUM> to perform the disclosed operations, such as those described in the various methods.

The disclosed embodiments may comprise or utilize a special-purpose or general-purpose computer including computer hardware, such as, for example, one or more processors (such as processor(s) <NUM>) and system memory (such as storage <NUM>), as discussed in greater detail below. Embodiments also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions in the form of data are "physical computer storage media" or a "hardware storage device. " Computer-readable media that carry computer-executable instructions are "transmission media. " Thus, by way of example and not limitation, the current embodiments can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.

Computer storage media (aka "hardware storage device") are computer-readable hardware storage devices, such as RAM, ROM, EEPROM, CD-ROM, solid state drives ("SSD") that are based on RAM, Flash memory, phase-change memory ("PCM"), or other types of memory, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code means in the form of computer-executable instructions, data, or data structures and that can be accessed by a general-purpose or special-purpose computer.

Computer system <NUM> may also be connected (via a wired or wireless connection) to external sensors (e.g., one or more remote cameras) or devices via a network <NUM>. For example, computer system <NUM> can communicate with any number devices or cloud services to obtain or process data. In some cases, network <NUM> may itself be a cloud network. Furthermore, computer system <NUM> may also be connected through one or more wired or wireless networks <NUM> to remote/separate computer systems(s) that are configured to perform any of the processing described with regard to computer system <NUM>.

A "network," like network <NUM>, is defined as one or more data links and/or data switches that enable the transport of electronic data between computer systems, modules, and/or other electronic devices. When information is transferred, or provided, over a network (either hardwired, wireless, or a combination of hardwired and wireless) to a computer, the computer properly views the connection as a transmission medium. Computer system <NUM> will include one or more communication channels that are used to communicate with the network <NUM>. Transmissions media include a network that can be used to carry data or desired program code means in the form of computer-executable instructions or in the form of data structures. Further, these computer-executable instructions can be accessed by a general-purpose or special-purpose computer.

Computer-executable (or computer-interpretable) instructions comprise, for example, instructions that cause a general-purpose computer, special-purpose computer, or special-purpose processing device to perform a certain function or group of functions. The described features and acts are disclosed as example forms of implementing the claims.

Claim 1:
A method (<NUM>) for aligning and stabilizing images generated by an integrated stereo camera pair (<NUM>) comprising a first camera (<NUM>) and a second camera (<NUM>) that are physically mounted to a computer system for mixed reality (<NUM>) with images generated by a detached camera (<NUM>) that is physically unmounted from the computer system (<NUM>), said method (<NUM>) comprising:
generating (<NUM>) a first image (<NUM>) using the first camera (<NUM>), generating a second image (<NUM>) using the second camera (<NUM>), and generating a third image (<NUM>) using the detached camera (<NUM>);
computing (<NUM>) a first rotation base matrix (<NUM>) of the third image (<NUM>) relative to the first image (<NUM>), wherein computing the first rotation base matrix of the third image relative to the first image is performed based on an incorrect, but acceptable, assumption that the detached camera and the first camera are co-located with one another;
computing (<NUM>) a second rotation base matrix (<NUM>) of the third image (<NUM>) relative to the second image (<NUM>);
aligning (<NUM>) the third image (<NUM>) to the first image (<NUM>) using the first rotation base matrix (<NUM>) and aligning the third image (<NUM>) to the second image (<NUM>) using the second rotation base matrix (<NUM>);
generating (<NUM>) a first overlaid image (<NUM>) by overlaying the third image (<NUM>) onto the first image (<NUM>) based on said aligning;
generating (<NUM>) a second overlaid image (<NUM>) by overlaying the third image (<NUM>) onto the second image (<NUM>) based on said aligning;
performing (<NUM>) a first parallax correction on the first overlaid image (<NUM>) by modifying the first overlaid image (<NUM>) from a first perspective to a first new perspective;
performing (<NUM>) a second parallax correction on the second overlaid image (<NUM>) by modifying the second overlaid image (<NUM>) from a second perspective to a second new perspective; and
displaying (<NUM>) the first overlaid image (<NUM>) and the second overlaid image (<NUM>).