Patent Publication Number: US-2023146178-A1

Title: Attention based audio adjustment in virtual environments

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63/263,931, filed Nov. 11, 2021 and titled “ATTENTION BASED AUDIO ADJUSTMENT,” the contents of which are incorporated by reference herein in their entirety. 
     This application is related to U.S. patent application Ser. No. 17/903,629, filed Sep. 6, 2022 and titled “Image Analysis and Gaze Redirection Using Characteristics of the Eye,” the contents of which are incorporated by reference herein in their entirety for all purposes. 
    
    
     FIELD 
     One or more embodiments are related to generating and applying audio adjustments at compute devices associated with a virtual environment, based on detected attention(s) of participants within the virtual environment. 
     BACKGROUND 
     Videoconferencing technologies are ubiquitous in modern business and educational settings. Such technologies include the exchange of video and audio signals to facilitate real-time collaboration of people in different locations. 
     SUMMARY 
     In some embodiments, an attention-based audio adjustment method includes identifying, at a processor and at a first time, a first estimated gaze direction of a first participant from a plurality of participants within a virtual environment. The method also includes receiving, at the processor and from a compute device of the first participant, first audio data including a first set of at least one audio parameter. In some such implementations, the compute device of the first participant is remote from the processor. The method also includes determining, via the processor and at a second time subsequent to the first time, a second estimated gaze direction of the first participant within the virtual environment. The method also includes, in response to detecting that the second estimated gaze direction of the first participant differs from the first estimated gaze direction of the first participant, automatically generating, via the processor, second audio data including a second set of at least one audio parameter different from the first set of at least one audio parameter, based on the first audio data and the second estimated gaze direction. The second audio data can include a modification relative to the first audio data, and can be associated with one of (1) a virtual representation of a second participant from the plurality of participants or (2) a virtual object within the virtual environment. The method also includes sending a signal representing the second audio data from the processor to the compute device of the first participant, at a third time subsequent to the second time, to cause an adjustment to an audio output of the compute device of the first participant. 
     In some embodiments, a non-transitory, processor-readable medium stores instructions that, when executed, cause a processor to identify, at a first time, a first estimated gaze direction of a first participant from a plurality of participants within a virtual environment, and to receive, from a compute device of the first participant, first audio data including a first set of at least one audio parameter, the compute device of the first participant being remote from the processor. The non-transitory, processor-readable medium also stores instructions to cause the processor to determine, at a second time subsequent to the first time, a second estimated gaze direction of the first participant within the virtual environment, the second estimated gaze direction being different from the first estimated gaze direction. The non-transitory, processor-readable medium also stores instructions to cause the processor to generate second audio data including a second set of at least one audio parameter different from the first set of at least one audio parameter, based on the first audio data and the second estimated gaze direction, the second audio data including a modification relative to the first set of at least one audio parameter and associated with one of (1) a virtual representation of a second participant from the plurality of participants or (2) a virtual object within the virtual environment. The non-transitory, processor-readable medium also stores instructions to cause the processor to automatically send a signal representing the second audio data to a compute device of the first participant to cause an adjustment to an audio output of the compute device of the first participant, at a third time subsequent to the second time. 
     In some embodiments, an attention-based audio adjustment method includes receiving, at a processor and from a compute device of the first participant, first audio data including a first set of at least one audio parameter, the compute device of the first participant being remote from the processor. The method also includes receiving, at the processor, eye data associated with an appearance of an eye of a first participant within a virtual environment, and determining, via the processor and based on the eye data, an estimated gaze direction of the first participant within the virtual environment. The estimated gaze direction can be in a direction, within the virtual environment, of (1) a virtual representation of one of a second participant or (2) a virtual object within the virtual environment. The method also includes generating, via the processor, second audio data including a second set of at least one audio parameter different from the first set of at least one audio parameter, based on the first audio data and the estimated gaze direction, the second audio data including a modification relative to the first audio data and associated with one of (1) the virtual representation of the second participant or (2) the virtual object within the virtual environment. The method also includes automatically sending a signal representing the second audio data from the processor to the compute device of the first participant to cause an adjustment to an audio output of the compute device of the first participant. 
    
    
     
       BRIEF DESCRIPTIONS OF THE DRAWINGS 
         FIG.  1    shows a known process in which a gaze duration is compared to a sound threshold. 
         FIG.  2    shows an example interface of a two-dimensional chat software application, according to some embodiments. 
         FIG.  3    is a diagram showing the positioning of eyes of participants in a videoconference before (left) and after (right) gaze redirection, according to an example embodiment. 
         FIG.  4    illustrates an example three-dimensional (3D) chat room, in accordance with some embodiments. 
         FIG.  5    is a two-dimensional (2D) plot of a sound intensity distribution for a virtual environment, according to an example embodiment. 
         FIG.  6    is a 3D plot of the sound intensity distribution of  FIG.  5   . 
         FIG.  7 A  is a diagram of a first example system for performing attention-based audio adjustments, according to some embodiments. 
         FIG.  7 B  is a diagram of a second example system for performing attention-based audio adjustments, according to some embodiments. 
         FIG.  8    is a flow diagram showing a first attention-based audio adjustment method, according to some embodiments. 
         FIG.  9    is a flow diagram showing a second attention-based audio adjustment method, according to some embodiments. 
         FIG.  10    is a flow diagram showing a third attention-based audio adjustment method, according to some embodiments. 
         FIG.  11    illustrates a sequence associated with gaze estimation, according to an embodiment. 
         FIG.  12    illustrates examples of gaze estimation vectors, according to an embodiment. 
         FIG.  13    illustrates examples of gazes before and after gaze redirection, according to an embodiment. 
         FIG.  14    shows example 3D head scan data and a re-parameterization thereof, according to some embodiments. 
         FIG.  15    shows examples of eye region shape and texture variations, according to some embodiments. 
         FIG.  16    shows examples of an eyeball mesh, mean iris texture, and iris texture variations, according to some embodiments. 
         FIG.  17    shows example dense image-similarity measurements over a mask of foreground pixels, according to some embodiments. 
         FIG.  18    shows example observed images with landmarks and model fits based on landmark similarity, according to some embodiments. 
         FIG.  19    shows example model fits on two different gaze datasets, showing estimated gaze and labelled gaze, according to some embodiments. 
         FIG.  20    illustrates an energy summation to be minimized, according to an embodiment. 
         FIG.  21    shows a system block diagram associated with an eye gaze adjustment system, according to an embodiment. 
         FIGS.  22 A- 22 B  show client side and server side computing systems dedicated to user specific calibration, and their associated eye gaze adjustment processing flow, according to an embodiment. 
         FIGS.  23 A- 23 B  show a data flow through an algorithmic framework post-calibration, and how the eye gaze adjustment is dependent on prediction(s) of a given user&#39;s attention/gaze to other users, according to an embodiment. 
         FIG.  24    shows a user interacting with his display screen, including initiating and performing the calibration process, according to an embodiment. 
         FIG.  25    shows rectangular facial areas and their role in the determination of the eye gaze vector present and past data to guide adjustments to the eye gaze vector to represent eye contact with a first participant, followed by a second participant, according to an embodiment. 
         FIG.  26    shows server side computing methods designed to give the user and the other clients different perspectives of the respective user, according to an embodiment. 
         FIGS.  27 A- 27 B  show the client-server side interaction to normalize the eye gaze, taking into account the field of vision of the respective clients and the field of view within the virtual space, according to an embodiment.  FIGS.  17 A- 17 B  go into detail to illustrate how the eyes are adjusted/lifted to make it appear as if their gaze could be as wide as the camera within the virtual space permits greater field of view. 
         FIG.  28    shows a flowchart of a method for generating modified video frames with redirected gaze, according to an embodiment. 
         FIGS.  29 A- 29 B  shows a flowchart of a method for generating modified video frames with redirected gaze, according to an embodiment. 
         FIG.  30    shows a flowchart of a method for generating modified video frames with redirected gaze, according to an embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     In live/real-time collaborative environments such as videoconferences, chat sessions, virtual reality environments, social media platforms and the like, which can be experienced in a non-immersive or immersive capacity, audio can be as vital to the user experience as video and other features such as file sharing and aesthetic enhancements. Indeed, audio may be regarded as the most important element of such environments, since it facilitates communication even in the event of a lapse in/loss of video. Videoconference applications should therefore be equipped to monitor and manage the voice communication activities of participants throughout the live session. The availability of faster graphics processing units (GPUs) and higher broadband speeds have made Machine Learning (ML) based and physics-based audio processing during live streams easier to implement, thereby enhancing the participants&#39; experience by manipulating audio quantitatively and qualitatively. Many audio effects that once were found in robust media players and other audio mixing software can now readily be reproduced on live streams from the server end. 
     Popular multi-user chat applications like Clubhouse™ provide users with spatial audio. Virtual reality (VR) video chats are being built that leverage the substantial computing power of servers and the relative cost-effectiveness of cloud computing in recent times. Clubhouse™ promises its audience a live “party” atmosphere in which a user can hear background noise, as a jumble of audio, as well as a person of their interest talking, while maintaining awareness of other people leaving or arriving. This induces, for the user, a sensation of being present in a real clubhouse environment. From another perspective, this would be akin to the audio-spatial skills that a visually-challenged person builds naturally over time—a faculty somewhere in the region between the visual and the auditory. 
     In the case of videoconferencing, however, the generation of a real-world atmosphere for users is a complicated pursuit. For example, while some VR technologies generate immersive spaces with spatial audio for environmental sounds through VR headsets, the audio from a three-dimensional (3D) source (e.g., a peer user in a video chat) typically does not receive the same consideration/treatment. Some known techniques for spatial audio tuning, such as adjusted communication between the Oculus® headgear firmware with the Agora software development kit (SDK) during real-time VR sessions, have been implemented via a mixing process in the audio stream that is typically heard from the application&#39;s audio output. As part of this process, an application programming interface (API) callback sends the audio stream from a remote user before the mixing. 
     The foregoing procedure can be used to set up an audio source in a spatial audio environment, and users can then play the separate audio stream prior to the mixing, while the audio is also mixed and played in the normal process. 
     When humans process auditory and/or visual information, they naturally tend to focus on what they perceive to be the most pertinent/interesting source of that auditory and/or visual information. Except where anomalously loud extraneous/background noise (such as heavy machinery, explosions, surging traffic, disco music, construction work etc.), the human brain can filter out less relevant information and retain relevant information. VR software and APIs provide a multitude of methods to reproduce 3D spatialization of sound to enhance the immersive experience. Videoconferencing applications set forth herein, according to some embodiments, can achieve similar outputs, but in non-immersive environments and using different methodologies. 
     In some embodiments of the present disclosure, a point or region of focus of attention of a first videoconference user is estimated, and a determination is made as to whether the point or region of focus of attention of the first videoconference user overlaps a field of view that includes another (e.g., a second) videoconference user for/during a given videoconference session. In response to determining that the point or region of focus of attention of the first videoconference user overlaps the field of the second videoconference user, one or more audio settings or parameters of a compute device of the first videoconference user and related to the second videoconference user may be adjusted (e.g., automatically via a processor executing processor-readable instructions), for example such that a volume of audio associated with the second user is increased/made louder relative to other videoconference users. In some such implementations, audio settings or parameters for other audio sources associated with the videoconference session (e.g., background noise) may not be adjusted at all, or may be adjusted (e.g., an associated volume thereof may be reduced), concurrently or overlapping in time with the adjustment to the one or more audio settings or parameters related to the second videoconference user. 
     Alternatively or in addition, a determination can be made as to whether the point or region of focus of attention of the first videoconference user overlaps a field of view that includes a sound emitting virtual object during the given videoconference session. In response to determining that the point or region of focus of attention of the first videoconference user overlaps the field of the sound emitting virtual object, one or more audio settings or parameters of the compute device of the first videoconference user and related to the sound emitting virtual object may be adjusted (e.g., automatically via a processor executing processor-readable instructions), for example such that a volume of audio associated with the sound emitting virtual object is increased/made louder relative to other audio associated with the videoconference session. In some such implementations, audio settings or parameters for other audio sources associated with the videoconference session (e.g., background noise) may not be adjusted at all, or may be adjusted (e.g., an associated volume thereof may be reduced), concurrently or overlapping in time with the adjustment to the one or more audio settings or parameters related to the sound emitting virtual object. 
       FIG.  1    shows a known process in which a gaze duration is compared to a sound threshold. The audio tuning system of  FIG.  1    sought to improve television viewer interaction. The inventor is unaware of any prior work, however, in which a computer responds to a visual focus of eyes of an observing user by coupling and applying the visual focus of the user to audio, to enhance the user experience while communicating. 
     Gaze Estimation and Redirection 
     Although some known multimedia technologies take eye contact of users into account, even state-of-the-art chat applications do not provide for the correction or adjustment of eye contact representations. 
       FIG.  2    shows an example interface of a two-dimensional chat software application, according to some embodiments. Some embodiments of the present disclosure introduce a gaze estimation/re-direction application, as shown in  FIG.  3   , More specifically,  FIG.  3    is a diagram showing the positioning of eyes of participants in a videoconference before (left) and after (right) gaze redirection, according to an example embodiment. Gaze estimation/re-direction applications set forth herein can be coupled, e.g., via laptop/mobile screen parameters, to sound equalization and spatialization features, with reference to the location and perceived depth of a sound source relative to the chat participant involved. 
     Some embodiments of the present disclosure are inspired by the governing equations of fluid mechanics, and can take into account at least two flow fields: an original flow field and a desired flow field. A gaze direction after it has been redirected can be a resultant of the above and/or may be generated via ML capabilities. Depending on the implementation, and in accordance with some embodiments, one or more of the following gaze redirection methods (novel-view synthesis, eye-replacement, and eye-warping) may be used: 
     Novel view synthesis methods re-resolve and render a subject&#39;s (user&#39;s) face in such away that he/she appears to be looking at the camera. Such methods can be implemented using one or more of stereo-vision, monocular red green blue (RGB) cameras, and ML techniques. The image manipulations performed as part of novel view synthesis can, however, result in unwanted face distortion. 
     Eye replacement methods replace representations of eyes of a subject&#39;s (user&#39;s) image with modified representations of the eyes of the subject/user, the modified representations having a different/desired gaze. 
     Warping-based methods of the present disclosure redirect user gaze without the use of user-specific or person-specific training data. Instead, continuous learning (adaptive machine learning (ML)) is performed to generate a flow field from an eye image to another eye image using training pairs of eye images having pre-defined gaze offsets between them. The flow field thus generated is used to warp pixels in the original image, thereby modifying the gaze. Such methods can reduce or eliminate the distortion produced using novel view synthesis. In some implementations, a gaze is defined first, prior to (and in order to) manipulate its parameters, which are components of a generative facial part and an emulated eyeball part, and which can include, for example, shape, texture, position and/or scene illumination. Additional details regarding eye gaze adjustments based on attention can be found below and in U.S. patent application Ser. No. 17/903,629, filed Sep. 6, 2022 and titled “Image Analysis and Gaze Redirection Using Characteristics of the Eye,” the contents of which are incorporated by reference herein in their entirety. 
     Coupling the Gaze Redirection and Attention-Based Audio Equalizer Modules 
     Gaze redirectors of the present disclosure (which may be implemented in software and/or hardware, and configured to modify a representation of a gaze, as shown in  FIG.  3   ) can simulate face-to-face interactions via adjustments to eye positioning (e.g., to establish eye contact between users), in accordance with some embodiments. Alternatively or in addition, gaze estimators of the present disclosure (which likewise may be implemented in software and/or hardware) can generate qualitative as well as quantitative measures of one or more user&#39;s focus. For example, qualitative measures can include blurriness of textured facial features such as skin and eyebrows, and/or distortions of the shapes of facial features such as the edges of eyelids, irises, eyeglasses, etc. Quantitative measures can include, for example, a Learned Perceptual Image Patch Similarity (LPIPS) metric to evaluate the visual quality of generated gaze images. LPIPS is based on deep networks and is engineered to resemble/emulate human perception in image evaluation tasks. A low LPIPS score at every correction angle can indicate that the method used can generate gaze images that are perceptually more similar to ground-truth images. In some implementations, one or more gaze redirectors and/or one or more gaze estimators are located at one or more centralized servers that is/are physically remote from, and in network communication with, one or more compute devices associated with participants of a virtual environment. As used herein, a gaze vector can refer to a two-dimensional vector having a user&#39;s screen/display area as its geometric bounds. In other words, the (X min , Y min ) and the (X max , Y max ) coordinates of the gaze vector can be positioned within a Euclidean XY-plane that corresponds one-to-one with the user screen/display resolution. 
       FIG.  4    illustrates an example three-dimensional (3D) chat room/videoconference, including three participants, in accordance with some embodiments. The gaze estimator vector can continuously or regularly be shifting based on the focus of a given participant on various locations of the screen. An audio equalizer module (which may be implemented in software and/or hardware, optionally at a centralized server that is physically remote from, and in network communication with, one or more compute devices associated with participants of a virtual environment) can receive these locations as inputs, perform a transient lookup, and “tag” its functionality to the participant in that location and the audio produced by a visual element, e.g., a video frame depicting participant “Leonardo” in  FIG.  4   . This tagging can be regarded as a coupling or linking of a user&#39;s attention to one or more audio settings associated with a virtual environment session, and can result in adjustment of audio parameters. The tagging can be accomplished by storing (e.g., in memory, in a table, in a database, etc., for example in a common record thereof) an association among a set of audio equalizer settings, a participant identifier (ID), a location, and a representation of the audio source(s). Optionally, parameters associated with room acoustics, such as reverberation time, speech intelligibility, de-noising threshold, and the A/V ratio (a measurement of room damping, defined as total absorption surface area (A) available in a room to a room volume (V)) may be stored as part of the tagging and/or adjusted. 
     Suppose A is an audio amplitude of a target of a user/participant&#39;s attention, x 0  and y 0 , z 0  are the coordinates of the gaze vector (optionally pointing to the target of the user/participant&#39;s attention), and σ x , σ y  and σ are the centroids of the other sound sources obtained from a broadcast API. An intensity of an audio source may then be given by the following equation: 
         I   audio   =AΓ   n {Ξ( x,y,z,x   0   ,y   0   ,z   0 )},
 
     where depth measures z 0  and z are virtually computed, and a fractal multivariate Gaussian distribution (Γ n ) is convoluted with a thresholding Heavi-side function (Ξ) applied to multiple audio sources spread/distributed across the screen/display of a user/participant of a virtual environment. In some embodiments, the I audio  equation is used to generate a sound intensity distribution for multiple audio sources of a virtual environment (i.e., in a spatialized audio context), with respect to the screen/display coordinate system, and dynamic adjustments can then be made to the sound intensity distribution based on changes to the user/participant&#39;s attention. 
       FIG.  5    is a two-dimensional (2D) plot of a sound intensity distribution for a virtual environment (e.g., generated using the I audio  equation above), illustrating example source data (e.g., from users, speakers, microphones, etc.), according to an example embodiment.  FIG.  6    is a 3D plot of the sound intensity distribution of  FIG.  5   . In  FIGS.  5 - 6   , regions annotated “yellow” are highest intensity, and regions marked “blue” or “purple” are lowest intensity. 
     In some embodiments, a Random Forest regressor (which may be implemented in software and/or hardware, optionally at a centralized server that is physically remote from, and in network communication with, one or more compute devices associated with participants of a virtual environment) is used to perform the above coupling of a user&#39;s attention to one or more audio settings associated with a virtual environment session (i.e., the direct effect that user attention has on the auditory experience) heuristically by continuous machine learning, across audio and video data for multiple different human subjects. This coupling can be referred to as “audio-visual coupling” in the context of 3D audio. For example, when a video image moves further away from a user, the audio volume can be reduced, and when the video image moves across the screen/display, the associated audio rendering can move along the direction of the movement/translation. Thus, video and audio are coupled, in real-time or substantially in real-time (i.e., in real-time when ignoring computation and/or signal transmission time). Such embodiments can reduce or eliminate the amount of computation associated with such coupling during a live broadcast/virtual environment session, thereby conserving computing power/resources and the need to update the physics-based algorithm described by the governing equations discussed herein. 
       FIG.  7 A  is a diagram of a first example system for performing attention-based audio adjustments, according to some embodiments. As shown in  FIG.  7 A , the system  700  includes a centralized (or “remote”) server  702  in communication, via a wireless network “N,” with one or more user compute devices  730 A-N having associated users (also referred to herein as participants in virtual environments). The centralized server  702  includes a memory operably coupled to a processor  706 , which in turn is operably coupled to a transceiver  704  and, optionally, a user interface  708  (e.g., a graphical user interface (GUI)). The memory  710  stores one or more of: user identifiers (IDs)  710 A, virtual environment identifiers  710 B, one or more gaze estimators  710 C, one or more gaze redirectors  710 D, audio setting(s)  710 E, audio equalizer module(s)  710 F, one or more audio models  710 G (e.g., including one or more sound intensity distributions  710 H), user attention/focus data  7101 , user eye data  710 J, gaze vector(s)  710 K, tag(s)  710 L, video frame(s)  710 M, or Random Forest Regressor(s)  710 N. The audio setting(s)  710 E can include one or more audio adjustments, such as (but not limited to) audio volume adjustments, removal of background noise, muting(s), equalization(s), reverberation(s), delay(s), echo(es), panning effect(s), Doppler effect(s), or spatialization(s) (e.g., binauralization(s)), to be applied to a given set of audio parameters. Any of the gaze estimator(s)  710 , gaze redirector(s)  710 D, and audio equalizer module(s)  710 F can include one or more machine learning algorithms. During operation of the system  700  (e.g., while a virtual environment session is in progress), first audio data  720  can be transmitted from one or more of the user compute devices  730 A-N, via the network N, received at the centralized server  702 , and used to generate second audio data  722  including one or more audio adjustments. The second audio data  722 , in turn, is transmitted from the centralized server  702  to the associated user compute device(s)  730 A-N for implementation thereon. Optionally, and also during operation of the system  700 , eye data  724  (and/or other biometric data associated with the user(s) A-N) can be transmitted from one or more of the user compute devices  730 A-N, via the network N, received at the centralized server  702 , and used to generate one or more video frames  726  (e.g., including a modified representation of an eye positioning of the associated user(s) A-N). The video frame(s)  726 , in turn, can be transmitted from the centralized server  702  to the associated user compute device(s)  730 A-N for display thereon. 
       FIG.  7 B  is a diagram of a second example system for performing attention-based audio adjustments, showing an example implementation, according to some embodiments. As shown in  FIG.  7 B , a virtual environment includes four users (users 1 through 4)—see the “client side” panel at the bottom of the figure. User 1 is wearing headphones, and is observing his/her display screen (labelled “Kick back space”). More specifically, user 1 is looking at a representation (e.g., video imagery) of user 2 within the display. Real-time audio streams, including audio data and having an associated time ‘t’, are received at one or more remote servers having graphics processing units (GPUs) from users 2 and 3. Video of user 4 is also received at the remote server(s), optionally overlapping in time with time ‘t’. A spatial audio engine (e.g., similar to the audio equalizer module(s)  710 F in  FIG.  7 A , and/or implemented in software and/or hardware) predicts that the attention of user 1 is directed to user 2 (e.g., based on the received video of user 4). Based on this prediction, the spatial audio engine applies an adjustment to a parameter of the audio data associated with user 2, and optionally transmits the adjusted audio data to a compute device of user 1 for implementation thereon (e.g., such that user 1 hears the audio output of user 2 more prominently than other users and/or sounds). The spatial audio engine tunes the virtual environment experience in real-time in this manner, such that the relative volumes/audio properties of audio sources within the virtual environment (e.g., users, virtual objects, etc.) are dynamically changes to reflect where each user&#39;s attention is focused at any given time. 
       FIG.  8    is a flow diagram showing a first attention-based audio adjustment method  800 , according to some embodiments. The method  800  can be implemented, by way of example, using the system  700  of  FIG.  7 A  and/or the system of  FIG.  7 B . As shown in  FIG.  8   , the attention-based audio adjustment method  800  includes identifying, at  802 , at a processor and at a first time, a first estimated gaze direction of a first participant from a plurality of participants within a virtual environment. The method  800  also includes receiving, at  804 , at the processor and from a compute device of the first participant, first audio data including a first set of at least one audio parameter (e.g., microphone gain level, listen gain/overall volume, etc.). In some such implementations, the compute device of the first participant is remote from the processor. The method  800  also includes determining, at  806 , via the processor and at a second time subsequent to the first time, a second estimated gaze direction of the first participant within the virtual environment. The method  800  also includes, in response to detecting that the second estimated gaze direction of the first participant differs from the first estimated gaze direction of the first participant, automatically generating, at  808  and via the processor, second audio data including a second set of at least one audio parameter different from the first set of at least one audio parameter, based on the first audio data and the second estimated gaze direction. The second audio data can include a modification relative to the first audio data, and can be associated with one of (1) a virtual representation of a second participant from the plurality of participants or (2) a virtual object within the virtual environment. The method  800  also includes sending, at  810 , a signal representing the second audio data from the processor to the compute device of the first participant, at a third time subsequent to the second time, to cause an adjustment to an audio output of the compute device of the first participant. 
     In some implementations, the second set of at least one audio parameter includes a sound equalizer parameter. 
     In some implementations, the generating the second audio data includes generating a representation of at least one of an audio volume (e.g., microphone gain) adjustment, a removal of background noise, a muting, an equalization, a reverberation, a delay, an echo, a panning effect, a Doppler effect, or a spatialization relative to the first set of at least one audio parameter. 
     In some implementations, the second audio data is associated with the virtual representation of the second participant, and the method  800  also includes detecting that the second estimated gaze direction of the first participant overlaps with a field of view of the first participant, the virtual representation of the second participant being within the field of view of the first participant. 
     In some implementations, the second audio data is associated with the virtual representation of the second participant, and the method  800  also includes detecting that the second estimated gaze direction of the first participant overlaps with a field of view of the first participant, the virtual representation of the second participant being within the field of view of the first participant. The sending of the signal from the processor to the compute device of the first participant can be in response to detecting that the second estimated gaze direction of the first participant overlaps with the field of view that includes the second participant. 
     In some implementations, the generating the second audio data includes generating a representation of an adjustment to a sound intensity relative to the first set of at least one audio parameter. 
     In some implementations, the generating the second audio data includes performing at least one of a Random Forest Regressor or continuous machine learning. 
     In some implementations, at least one of the first estimated gaze direction of the first participant or the second estimated gaze direction of the first participant is estimated based on an appearance of an eye of the first participant. The appearance of the eye of the first participant can be defined by one or more of: a color, a texture, an orientation, or an alignment of the eye, as discussed further below in the context of an eye region model. 
     In some implementations, the second audio data is associated with the virtual representation of the second participant, and the virtual representation of the second participant is displayed via a display of the compute device of the first participant when the adjustment to the audio output occurs. 
     In some implementations, the second audio data is associated with the virtual object, and the virtual object is displayed via a display of the compute device of the first participant when the adjustment to the audio output occurs. 
     In some implementations, the second estimated gaze direction is in a direction, within the virtual environment, of the one of the virtual representation of the second participant or the virtual object. 
       FIG.  9    is a flow diagram showing a second attention-based audio adjustment method  900 , according to some embodiments. The method  900  can be implemented, by way of example, using the system  700  of  FIG.  7 A  and/or the system of  FIG.  7 B . As shown in  FIG.  9   , the attention-based audio adjustment method  900  includes identifying, at  902  and at a first time, a first estimated gaze direction of a first participant from a plurality of participants within a virtual environment, and receiving, at  904  and from a compute device of the first participant, first audio data including a first set of at least one audio parameter, the compute device of the first participant being remote from the processor. The method  900  also includes determining, at  906  and at a second time subsequent to the first time, a second estimated gaze direction of the first participant within the virtual environment, the second estimated gaze direction optionally being different from the first estimated gaze direction. The method  900  also includes generating, at  908 , second audio data including a second set of at least one audio parameter different from the first set of at least one audio parameter, based on the first audio data and the second estimated gaze direction, the second audio data including a modification relative to the first set of at least one audio parameter and associated with one of (1) a virtual representation of a second participant from the plurality of participants or (2) a virtual object within the virtual environment. The method  900  also includes automatically sending a signal, at  910 , the signal representing the second audio data to a compute device of the first participant to cause an adjustment to an audio output of the compute device of the first participant, at a third time subsequent to the second time. 
     In some implementations, the second set of at least one audio parameter includes a sound equalizer parameter. 
     In some implementations, the second audio data is associated with the virtual representation of the second participant, and the method  900  also includes detecting that the second estimated gaze direction of the first participant overlaps with a field of view of the first participant. The virtual representation of the second participant can be within the field of view of the first participant. 
     In some implementations, the instructions to automatically send the signal from the processor to the compute device of the first participant include instructions to send the signal from the processor to the compute device of the first participant in response to detecting that the second estimated gaze direction of the first participant overlaps with a field of view that includes the one of the virtual representation of the second participant or the virtual object. 
     In some implementations, the instructions to generate the second audio data include instructions to generate the second audio data based on a fractal multivariate Gaussian distribution. 
     In some implementations, the instructions to generate the second audio data include instructions to generate the second audio data using at least one of a Random Forest Regressor or continuous machine learning. 
       FIG.  10    is a flow diagram showing a third attention-based audio adjustment method  1000 , according to some embodiments. The method  1000  can be implemented, by way of example, using the system  700  of  FIG.  7 A  and/or the system of  FIG.  7 B . As shown in  FIG.  10   , the attention-based audio adjustment method  1000  includes receiving, at  1002 , a processor and from a compute device of the first participant, first audio data including a first set of at least one audio parameter, the compute device of the first participant being remote from the processor. The method  1000  also includes receiving, at  1004  and at the processor, eye data associated with an appearance of an eye of a first participant within a virtual environment, and determining, at  1006 , via the processor and based on the eye data, an estimated gaze direction of the first participant within the virtual environment. The estimated gaze direction can be in a direction, within the virtual environment, of (1) a virtual representation of one of a second participant or (2) a virtual object within the virtual environment. The method  1000  also includes generating, at  1008  and via the processor, second audio data including a second set of at least one audio parameter different from the first set of at least one audio parameter, based on the first audio data and the estimated gaze direction, the second audio data including a modification relative to the first audio data and associated with one of (1) the virtual representation of the second participant or (2) the virtual object within the virtual environment. The method  1000  also includes automatically sending a signal at  1010 , the signal representing the second audio data from the processor to the compute device of the first participant to cause an adjustment to an audio output of the compute device of the first participant. 
     In some implementations, the second set of at least one audio parameter includes a sound equalizer parameter. Sound equalizer parameters can include frequency bands and their associated intensities. For example, the sound equalizer parameters can include mid-range vocal band (600 Hz-3 kHz). Alternatively or in addition, the sound equalizer parameters can include at least 5 frequency bands and their associated intensities. Alternatively, the sound equalizer parameters can be “flat,” such that sound is reproduced without equalization. 
     In some implementations, the automatic sending of the signal is in response to detecting that the estimated gaze direction is in the direction, within the virtual environment, of the one of (1) the first virtual representation of the second participant or (2) the virtual object. 
     In some implementations, the generating the second audio data includes performing at least one of: using at least one of a Random Forest Regressor or continuous machine learning, or based on a fractal multivariate Gaussian distribution. 
     In some implementations, the generating the second audio data includes generating a representation of an adjustment to a sound intensity relative to the first set of at least one audio parameter. 
     In some embodiments, a processor-implemented method for performing attention-based audio adjustments uses a hybrid model that includes an eye-appearance-based gaze estimator (implemented in hardware and/or software) and an attention-based audio equalizer (implemented in hardware and/or software), one or both of which reside on a back-end (e.g., centralized) compute device (e.g., an artificial intelligence (AI)/machine learning (ML) physics kernel), and which are operatively coupled to one or more front-end applications via application programming interfaces (APIs). As used herein, AI/ML physics kernels refer to closed-form mathematical equations or ML inferences, implemented in software/code. A physics kernel is an empirical one-to-one relationship between shifting video frames and their associated audio renderings. The constants and constraints involved in the empirical relationship can be computed after many (e.g., several hundreds of thousands of) chat instances/virtual environment sessions. The determination of acceptable constant ranges can be subject to the variety of displays involved, consistent data acquisition, and maintenance. An ML-physics kernel can refer to a probabilistic mathematical representation of a physics kernel. The hybrid model can be configured to operate in coordination with a gaze redirector, to adjust (quantitatively and/or qualitatively) a source and/or parameter/property of the audio (i.e., an audio adjustment) with respect to the point/object/region of attention of a virtual environment participant, in real-time. In some implementations, the audio adjustment is also based on a perceived depth of a source of the audio within the environment (e.g., a virtual environment and/or a real-time video feed). 
     Virtually immersive chat experiences with minimal or no add-ons to existing hardware are of increasing interest. Embodiments set forth herein facilitate the introduction of features that deliver real-world type audio experiences into 3D visual environments (e.g., virtual environments and/or ML-based real-time video broadcasts), thereby increasing the realism of such environments and improving user experiences. In some implementations, physical and ML models for gaze redirection are coupled with, and enhanced by, one or more mathematical models to optimize parameters of delivered sound associated with various on-screen/displayed “sources” (e.g., virtual representations of users/participants and/or virtual object), taking into account their relative positions, depth perception, etc. 
     Additional implementation details pertaining to the generation of sound distributions can be found, by way of example, in S. Spors, et al.,  IEEE Transactions on Audio, Speech, and Language Processing , “Multimedia Tools and Applications,” 20(9), November 2012, the contents of which are incorporated by reference herein in their entirety. Spors discussed the consequences of the discretization of a continuous distribution of secondary sources used for sound field synthesis for the case of Gaussian sampling. Repetitions of the spatial spectrum of the driving function were shown in the spherical harmonics expansion domain. Some embodiments set forth herein can leverage such methods but using a half-azimuth and a limited angle of elevation. 
     In some embodiments, user/audience “voting” data is used to improve one or more predictive algorithms associated with determining a user&#39;s focus or attention, for example by leveraging user votes for a spatial audiovisual distribution of a given speech audio with changing video frames. Additional details of such voting processes can be found, by way of example only, in M. Paquier, et al., “Audiovisual Spatial Coherence for 2D and Stereoscopic-3D Movies,”  Journal of the Audio Engineering Society,  63(11), November 2015, the contents of which are incorporated by reference herein in their entirety User votes can include, for example, representations of relevance of audio bits coming from certain portions of the screen/display, as indicated by the listening user, e.g., on a predefined scale. 
     In some embodiments, ambisonic formatting is used to reproduce transient video frames with smooth transitions to different audio scenes, for example using a watermarking technique. Alternatively or in addition, portions of a given sound scene may be masked by a slightly rotated version of the given sound scene. In some such implementations, compression quality changes associated with masked sound scenes and/or transitioning video frames may automatically be compensated for by systems described herein. Additional details pertaining to ambisoncs and masking can be found, by of example, in N. Ryouichi, “Audio Watermarking Using Spatial Masking and Ambisonics,”  IEEE Transactions on Audio, Speech, and Language Processing,  20(9), November 2012, the contents of which are incorporated by reference herein in their entirety. Additional details pertaining to the compression of spatial audio (and adjustments thereto) can be found, by way of example, in A. Allen, et al., “AMBIQUAL: Towards a Quality Metric for Headphone Rendered Compressed Ambisonic Spatial Audio,”  Applied Sciences,  10(3188), 2020, the contents of which are incorporated by reference herein in their entirety. 
     In some embodiments, a method for attention determination and associated audio adjustment includes identifying/calculating a half-azimuth in a foreground of a listening user/participant, e.g., to reproduce a person (i.e., another user/participant of a virtual environment) speaking in the foreground. Example implementation details for such calculations can be found, by way of example, in S. Zielinski, et al., “Automatic Spatial Audio Scene Classification in Binaural Recordings of Music,”  Applied Sciences,  1724(9), 2019, the contents of which are incorporated by reference herein in their entirety. 
     In some embodiments, a method for attention determination and associated audio adjustment includes performing cross-talk cancellation, e.g., to prevent lapses and/or overlaps in voice data of various participants within a virtual environment, and/or to synchronize voice data with transformed video frames. Cross-talk cancellation may be implemented, for example, using one or more binaural rendering technologies. Example implementation details for cross-talk cancellation, compatible with systems of the present disclosure, can be found in J. RIsheng, et al., “Binaural rendering technology over loudspeakers and headphones,”  Acoust. Sci. Tech.,  41(1), 2020, the contents of which are incorporated by reference herein in their entirety. 
     In some embodiments, a method for attention determination and associated audio adjustment includes generating one or more transitive parameters for a half-azimuth spatial surround system, and assessing an accuracy thereof. Such parameters may take into account sound source location estimates and/or sound localization perception abilities of users/participants. Additional details pertaining to sound source estimation can be found, by way of example, in D. Thushara, et al., “Binaural Sound Source Localization Using the Frequency Diversity of the Head-Related Transfer Function,”  Acoustical Society of America,  43(66), 2014. 
     In some embodiments, a method for attention determination and associated audio adjustment takes into account complex spatial relationships among differently-distanced audio sources (e.g., software-managed audio sources), acoustic parameters, spatial acoustics, psycho-acoustics, etc. Additional details pertaining to such spatial relationships can be found, by way of example, in L. Brummer, “Composition and Perception in Spatial Audio,”  Computer Music Journal,  41(1), 2017, the contents of which are incorporated by reference herein in their entirety. 
     In some embodiments, a method for attention determination and associated audio adjustment includes generating/identifying one or more representations of sound fields, microphone directivity functions, and/or panning functions associated with one or more audio signals, and converting signals from one directivity set to another, e.g., based on an intermediate estimation of the sound field. Such methods may be compatible with known decoding methods in stereo and ambisonic contexts, and can facilitate the decoding of scene and sub-scene encodings to one or more sound output devices. Additional details pertaining to such transformations can be found, by way of example, in D. Menzies, et al., “Decoding and Compression of Channel and Scene Objects for Spatial Audio,”  IEEE Transactions on Audio, Speech, and Language Processing,  2017, the contents of which are incorporated by reference herein in their entirety. 
     In some embodiments, a method for attention determination and associated audio adjustment includes performing spatial upsampling of head-related transfer functions (HRTF) to enhance sound cone representation of various “chat heads” (users/participants within a virtual environment) and their associated transitions during attention-based audio adjustments. Additional details pertaining to such HRTF spatial upsampling can be found, by way of example, in J. Arend, et al., “Directional Equalization of Sparse Head-Related Transfer Function Sets for Spatial Upsampling,”  IEEE/ACM Transactions on Audio, Speech, and Language Processing,  2019, the contents of which are incorporated by reference herein in their entirety. 
     In some embodiments, a method for attention determination and associated audio adjustment includes mitigation of coloration effects, which may occur (e.g., at high audio frequencies, due to spatial interferences among audio output devices) during panning in the spatial domain (e.g., due to a user/participant&#39;s shifting attention and eye gaze redirection). Such mitigation can include, for example, reproducing high-frequency audio signals and outputting them using a single audio device but with different directionalities (e.g., as contrasted with a panned low-frequency counterpart). Additional details pertaining to addressing coloration effects can be found, by way of example, in P. Gutierrez-Parera, et al., “Effects and Applications of Spatial Acuity in Advanced Spatial Audio Reproduction Systems with Loudspeakers,”  Applied Acoustics,  2020, the contents of which are incorporated by reference herein in their entirety. 
     In some embodiments, a method for attention determination and associated audio adjustment includes modifying at least one of an audio adjustment or a video frame to satisfy a constraint associated with basic audio quality (BAQ) and/or to satisfy a constraint associated with an overall listening experience (OLE). Additional details pertaining to BAQ and OLE considerations can be found, by way of example, in A. Silzle, et al., “Evaluation of Spatial/3D Audio: Basic Audio Quality vs. Quality of Experience,”  IEEE Journal of Selected Topics in Signal Processing,  11(1), February 2017, the contents of which are incorporated by reference herein in their entirety. 
     In some embodiments, a method for attention determination and associated audio adjustment includes at least one of binaural recording, reproduction of binaural signals (e.g., via computer synthesis thereof), or the use of an electronic equalizing filter between a recording head and a headphone (e.g., to ensure a correct total transmission in a binaural system). Optionally, a sound equalizer can be divided/partitioned into a recording side and a playback side as part of this process. Additional details pertaining to binaural sound processing can be found, by way of example, in H. Moller, “Fundamentals of Binaural Technology,”  Applied Acoustics,  36, 1992, the contents of which are incorporated by reference herein in their entirety. 
     In some embodiments, a method for attention determination and associated audio adjustment includes generating a 3D auditory display using a HRTF, which may be modeled using a deep neural network (DNN) based on spatial principal component analysis. For example, the HRTFs may be represented by a limited set of spatial principal components combined with frequency and user/participant dependent weights. Individual HRTFs in arbitrary spatial directions may be predicted by estimating the spatial principal components using DNN and mapping the associated weights to a range of anthropometric parameters. In some such implementations, physics-based methods described herein may be converted to, or replaced with, statistical learning and/or continual reinforcement learning with the data collected in attention based audio instances. Additional details pertaining to HRTF modeling can be found, by way of example, in T. Liu, et al., “Modeling of Individual HRTFs Based on Spatial Principal Component Analysis,”  IEEE/ACM Transactions on Audio, Speech, and Language Processing,  28, 2020, the contents of which are incorporated by reference herein in their entirety. 
     In some embodiments, methods for attention determination and associated audio adjustment use an object-based framework. Object-based audio can make audio content more immersive, interactive, and accessible. To generate object-based audio, one or more parametric approaches may be used to capture, represent, edit, and render reverberation over a 3D spatial audio system. For example, a Reverberant Spatial Audio Object (RSAO), which synthesizes reverberation inside an audio object renderer, may be used. Additional details pertaining to object-based audio can be found, by way of example, in P. Jackson, et al., “Object-Based Reverberation for Spatial Audio,”  Journal of the Audio Engineering Society,  65(1/2), 2017, the contents of which are incorporated by reference herein in their entirety. 
     In some embodiments, a method for attention determination and associated audio adjustment includes determining one or more gradients of transients of audio data with respect to video changes. Details pertaining to human perception of complex soundscapes can be found, by way of example, in B. Katza, et al., “Perceptual Evaluation of Multi-Dimensional Spatial Audio Reproduction,”  J. Acoust. Soc. Am.,  116(2), 2004, the contents of which are incorporated by reference herein in their entirety. 
     In some embodiments, a method for attention determination and associated audio adjustment includes performing one or more of data encoding, HRTF ranging, binaural reproduction, or switching of a spatial array of sources during attention transfer. Additional details pertaining to binaural audio processing hardware and software, as well as signal processing specific to spatial audio, can be found, by way of example, in A. Cvetkovi, et al., “Perceptual Spatial Audio Recording, Simulation, and Rendering,”  IEEE Signal Processing Magazine,  2017, the contents of which are incorporated by reference herein in their entirety. 
     Image Analysis and Gaze Redirection Using Characteristics of the Eye 
     In some embodiments (optionally in combination with attention-based audio adjustment methods set forth herein), a method for performing gaze redirection includes receiving, via a processor of a first compute device and from a second compute device, a signal representing eye data associated with at least one eye of a first user. The method further includes determining, via the processor and in response to receiving the signal representing the eye data, that the eye data is sufficient to perform gaze direction correction for the first user. The method further includes sending, via the processor and to the second compute device, a signal indicating that the eye data is sufficient to perform the gaze direction correction. The method further includes receiving, via the processor and from the second compute device, a signal representing a first video frame of the first user. The method further includes estimating, via the processor and using the eye data, a gaze direction of the first user in the first video frame. The method further includes determining, via the processor, a field of view of a first virtual representation of the first user in a virtual environment, the first virtual representation (1) based on an appearance of the first user and (2) controllable by the first user. The method further includes comparing, via the processor, the gaze direction of the first user in the first video frame and the field of view of the first virtual representation, to predict a target gaze direction for the first user. The method further includes inputting, via the processor, representations of the first video frame, the gaze direction of the first user, the target gaze direction, and a normalizing factor into a processing pipeline to generate a second video frame, a gaze direction of the first virtual representation in the second video frame being different from the gaze direction of the first user in the first video frame. The method further includes generating, via the processor and using the second video frame, a modified video frame that represents the first virtual representation from a perspective of a second virtual representation in the virtual environment. The method further includes causing, via the processor, the modified video frame to be displayed in the virtual environment, at a third compute device, and to a second user associated with the second virtual representation. 
     In some embodiments (optionally in combination with attention-based audio adjustment systems set forth herein), an apparatus includes a memory and a processor operatively coupled to the memory. The processor is configured to receive, at a first compute device and from a second compute device, a signal representing a first video frame of a first user captured at a first time. The processor is further configured to estimate a first gaze direction of the first user in the first video frame. The processor is further configured to determine a first field of view of a first virtual representation of the first user in a virtual environment. The first virtual representation is based on an appearance of the first use. The first field of view includes a second virtual representation (e.g., of a second user or of an object or other feature) included in the virtual environment and does not include a third virtual representation of a third user included in the virtual environment. The processor is optionally further configured to determine that the first gaze direction at least partially overlaps with the first field of view. The processor is further configured to generate (optionally in response to determining that the first gaze direction at least partially overlaps with the first field of view) a second video frame that shows the first virtual representation looking at the second virtual representation and not looking at the third virtual representation. The processor is further configured to send, at a second time subsequent to the first time, the second video frame to a third compute device to cause the third compute device to display the second video frame within the virtual environment. The processor is further configured to receive, at the first compute device and from the second compute device, a signal representing a third video frame of the first user captured at a third time. The processor is further configured to estimate a second gaze direction of the first user in the second video frame. The processor is further configured to determine a second field of view of a first virtual representation in the virtual environment. The second field of view includes the third virtual representation and not the second virtual representation. The processor is optionally further configured to determine that the second gaze direction at least partially overlaps with the second field of view. The processor is further configured to generate (optionally in response to determining that the second gaze direction at least partially overlaps with the second field of view) a fourth video frame that shows the first virtual representation looking at the third virtual representation and not the second virtual representation. The processor is further configured to send, at a fourth time subsequent to the third time, the fourth video frame to the third compute device to cause the third compute device to display the fourth video frame within the virtual environment. The processor can further be configured to implement one or more attention-based audio adjustment methods, as set forth herein. 
     In some embodiments, a non-transitory, processor-readable medium stores code representing instructions executable by a processor, the code comprising code to cause the processor to receive a video stream of a user. Each video frame from the video stream includes a depiction of a gaze of the user. The code further comprises code to cause the processor to, for each video frame from the video stream, determine, substantially in real time as that video frame is received, an estimated gaze direction of the gaze of the user in that video frame. The code further comprises code to cause the processor to determine a field of view for a virtual representation associated with the user in a virtual environment. The code optionally further comprises code to cause the processor to compare the field of view for the virtual representation associated with the user to the estimated gaze direction of the gaze of the user to determine whether the field of view for the virtual representation associated with the user at least partially overlaps with the estimated gaze direction of the gaze of the user. The code further comprises code to cause the processor to generate (optionally based on the comparison of the field of view for the virtual representation associated with the user to the estimated gaze direction of the gaze of the user) an updated video frame including a modified gaze direction of the user different from the estimated gaze direction of the gaze of the user. The modified gaze direction can be in a direction toward another person, object, or other feature within the field of view for the virtual representation associated with the user. The code further comprises code to cause the processor to cause the updated video frame to be displayed. The non-transitory, processor-readable medium can further store code representing instructions executable by a processor to implement one or more attention-based audio adjustment methods, as set forth herein. 
     Some embodiments of the present disclosure facilitate the ability of a given person appearing within a 3D virtual world to accurately perceive an object of attention of any one or more other people appearing within the 3D virtual world (e.g., to accurately perceive who or what the one or more other people is/are looking at) by modifying a representation of an eye gaze of the one or more other people within the 3D virtual world, in real-time, based on their point of attention on a screen. For example, as shown in  FIG.  11   , an image of a user can be input into a software model. The software model can identify facial landmarks of the user from the image, perform normalization, and predict and/or estimate a gaze direction of the user in that input. The gaze direction of the user, as represented within a 3D virtual environment, can then be modified such that the modified gaze direction better conveys, to other users in the 3D virtual environment, the feature(s)/object(s) within a display on a screen (and, by proxy, within the 3D virtual environment) that the user is viewing. 
     In some implementations, an appearance-based gaze estimator is configured to detect a face, resize it, identify facial landmarks thereof, and process the resulting image.  FIG.  12    shows various images of a user&#39;s gaze being predicted/estimated and represented using an estimation vector. These estimation vectors can be used to modify representations of a gaze of a user in a virtual environment. In some implementations, data normalization is performed for noise removal and/or for improving estimation accuracy, in such a way that the Y-axis of the camera coordinate system lies normal to the Y-axis of the head coordinate system. The normalized image data is then scaled to reflect a fixed distance away from the face center. Thus, the input image may have only 2 degrees of freedom in head pose for all kinds of cameras with different intrinsic parameters. 
     Known gaze correction techniques exist. For example, view synthesis methods can re-resolve and render the subject&#39;s face in such a way that the subject appears to be looking at the camera. Various techniques involve the use of stereo-vision and monocular red green blue (RGB) cameras in combination with machine learning (ML) techniques, however unwanted facial distortions can result from such image manipulations. 
     As another example, eye replacement methods replace the eyes of a subject&#39;s image with new eye images having a different desired gaze. Replacement eye images may closely resemble the subject&#39;s natural eyes, since eye appearance is part of the identity of the subject, both to the subject him/herself and to the communicator on the other end. Thus, a need may exist for a large database containing representations of eyes of different shapes, sizes, colors and aspect ratios to choose from. Moreover, person-specific eye images can include defects/undesirable features such as eyelids that remain open, illumination differences, the inability to accommodate different head poses, and matching inaccuracies. As another example, warping-based methods are able to redirect gaze without person-specific training data. Continual learning can be used to generate a flow field from one eye image to another using training pairs of eye images with pre-defined gaze offsets between them. The flow field thus generated can be used to warp pixels in the original image, thereby modifying gaze. Here too, however, certain disadvantages exist, such as the inability to specify a new direction, limitations on the range of the possible redirections due to the invariability of the training dataset, and the inability to redirect an occluded gaze. 
     One or more embodiments of the present disclosure include eye gaze redirection systems that can mitigate the issues discussed above. For example, in some embodiments, a gaze is first defined, and then parameters of the gaze are modified/manipulated by taking into account a generative facial part and an emulated eyeball part, defined by a set of parameters that signify shape, texture, position (or “pose”) and scene illumination, as discussed below. In some implementations, an eye region model is defined. The eye region model can be used to determine characteristics of a user&#39;s eye(s), such as color, texture, orientation, alignment, etc. Some attributes of the eye region model include:
         1. Scene Illumination: In some implementations, an eye region is represented by a Lambertian optical scenario with ambient and directional lights, the former being a light of incidence and the latter being defined by the rotation, pitch and yaw of an eyeball model. This model can be suitable for a relatively small facial zone.   2. Shape: In some implementations, an eye region is dimensionally-reduced to a fixed number of vertices forms a sparse mesh with an assumption that a given face is symmetric. The average face shape, modes of shape variation and standard deviations of these modes are the governing features of an eye region model. The eyeball is modelled as a standard two-sphere based on physiological averages, including the scaling of vertices on the iris boundary about the iris.   3. Texture: Some implementations use a dimensionally-reduced texture model of the facial eye region from a set of similar photographs. The colors of a region of vertices can be used to generate a RGB texture map controlled by average face texture.   4. Pose: In some implementations, pose parameters are defined that describe both global pose(s) and local pose(s). Globally, the eye regions are positioned/defined with rotation and translation. The eyeball positions can be fixed in relation to the eye regions. The local pose parameters can allow rotation of the eyeballs from the face, controlling the apparent gaze. The general gaze direction is given by pitch and yaw angles. When an eyeball looks up or down, the associated eyelid follows it. Procedural animation can be used to pose the eyelids in the facial mesh by a rotational magnitude.       

     Example 3D Eye Region Model 
     In some implementations, a 3D eye region model is used to synthesize an image that matches an input RGB eye image. To render synthetic views, a multi-part model consisting of the facial eye region and the eyeball can be used. The facial eye region and the eyeball can be posed in a scene, illuminated, and then rendered using a model of camera projection. A total set of model and scene parameters Φ can be defined as: 
       Φ={β,τ,θ,ι,κ}  (1),
 
     where β are the shape parameters, τ are the texture parameters, θ are the pose parameters, ι are the illumination parameters, and κ are the camera parameters. Each part of the model, and the parameters that affect it, are discussed below. 
     Morphable Facial Eye Region Model—β, τ 
     In some implementations, a 3D morphable model (3DMM) of an eye region serves as a prior for facial appearance. Although some known approaches have historically used a generative shape model of the eye region, the 3DMM described herein captures both shape and texture variation. Head scans may be acquired as source data. The first stage of constructing a morphable model includes bringing scan data into correspondence, so that a point in one face mesh is semantically equivalent to a point in another. Although some known approaches have historically computed a dense point-to-point correspondence from original scan data, approaches discussed herein compute sparse correspondences that describe 3D shape more efficiently. Each original high-resolution scan can be manually re-parameterized into a low resolution topology that includes the eye region only (see  FIG.  14   ). This topology does not include the eyeball, since the eyeball will be posed separately to simulate its independent movement. Correspondences are maintained for detailed parts, e.g. the interior eyelid margins, which have historically been inadequately defined. The mesh is uv-unwrapped, and color is represented as a texture map, coupling the low-resolution mesh with a high-resolution texture.  FIG.  15    shows the mean shape μ s  and texture μ t  along with the first four modes of variation. The first shape mode U 1  varies between hooded and protruding eyes, and the first texture mode V 1  varies between dark and light skin. 
     Following this registration, the facial eye regions can be represented as a combination of 3D shape s (n vertices) and 2D texture t (m texels), encoded as 3n and 3m dimensional vectors respectively: 
         s =[ x   1   ,y   1   ,z   1   ,x   2   , . . . y   n   ,z   n ] T ∈   3n   (2)
 
         t =[ r   1   ,g   1   ,b   1   ,r   2   , . . . g   m   ,b   m ] T ∈   3m   (3)
 
     where x i ,y i ,z i  is the 3D position of the ith vertex, and r j ,b j ,g j  is the color of the jth texel. Principal Component Analysis (PCA) can then be performed on the set of c ordered scans to extract orthogonal shape and texture basis functions: U∈   3n×c  and V∈   3m×c . For each of the 2m shape and texture basis functions, a Gaussian distribution can be fit to the original data. Using this fit, linear models can be constructed that describe variation in both shape M s  and texture M t : 
           s =(μ s ,σ s   ,U )    t =(μ t ,σ t   ,V ),  (4)
 
     where μ s ∈   3n  and μ t ∈   3m  are the average 3D shape and 2D texture, and σ s =[σ s1  . . . σ sc ] and σ t =[σ t1  . . . σ tc ] describe the Gaussian distributions of each shape and texture basis function.  FIG.  15    shows the mean shape and texture, along with four important modes of variation. Facial eye region shapes s and textures t can then be generated from shape (β face ⊂β) and texture coefficients (τ face ⊂τ) as follows: 
         s (β face )=μ s   +U  diag(σ s )β face   (5)
 
         t (τ face )=μ t   +V  diag(σ t )τ face   (6)
 
     From the set of c=22 scans, 90% of shape and texture variation can be encoded in 8 shape and 7 texture coefficients. This reduction in dimensionality is important for efficient model fitting. Also, since eyelashes can provide a visual cue to gaze direction, eyelashes can be modelled using a semi-transparent mesh controlled, for example, by a hair simulation. 
       FIG.  16    shows an example eyeball mesh, mean iris texture μ iris , and some examples of iris texture variation captured by a linear model M iris . 
     Parametric Eyeball Model—β, τ 
     The second part of the multi-part model pertains to the eyeball. Accurately recovering eyeball shape can be difficult due to its complex structure. A mesh can be created, for example using standard anatomical measurements, for this purpose (see  FIG.  16   ). Eyeballs can vary significantly in shape and texture among different people. Changes in iris size can be modelled geometrically, for example by scaling vertices on the iris boundary about the 3D iris centre as specified by iris diameter β iris . A collection of aligned high-resolution iris photos can be used to build a generative model M iris  of iris texture using PCA: 
           iris =(μ iris ,σ iris   ,W )  (7)
 
     This can be used to generate new iris textures t iris . To account for the fact that the “white” of the eye is not purely white, variations in sclera color can be modelled by multiplying the eyeball texture with a tint color τ tint ∈   3 . The eyeball has a complex layered structure with a transparent cornea covering the iris. To avoid explicitly modelling this, refraction effects can be computed in texture-space. 
     Posing the Multi-Part Model—θ 
     In some implementations, global and local pose information re encoded by θ. The model&#39;s parts can be defined in a local coordinate system with its origin at the eyeball centre, and model-to-world transforms M face  and M eye  can be used to position them in a scene. The facial eye region part has degrees of freedom in translation and rotation, which can be encoded as 4×4 homogenous transformation matrices T and R in a model-to-world transform M face =TR. The eyeball&#39;s position can be anchored to the face model, while able to rotate separately through local pitch and yaw transforms R x (θ p ) and R y (θ y ), giving M eye =TR x R y . 
     When the eye looks up or down, the eyelid follows it. Eyelid motion can be modelled using procedural animation, with each eyelid vertex rotated about the inter-eye-corner axis, with rotational amounts chosen to match known measurements (e.g., from an anatomical study). Since the multi-part model can include disjoint parts, the eyelid skin can be “shrinkwrapped” to the eyeball, projecting eyelid vertices onto the eyeball mesh to avoid gaps and clipping issues. 
     Scene Illumination—ι 
     In some implementations, since a relatively small region of the face is being analyzed/modelled, a simple illumination model can be assumed, where lighting is distant and surface materials are purely Lambertian. The illumination model can define, for example, an ambient light with color l amb ∈   3 , and a directional light with color l dir ∈   3  and 3D direction vector L. Specular effects, global illumination, and self-shadowing may be excluded, such that illumination depends only on surface normal and albedo. Radiant illumination L at a point on the surface with normal N and albedo c can be calculated as: 
         ( n,c )= cl   amb   +cl   dir ( N·L )  (8)
 
     Camera Projection—κ 
     For a complete model of image formation, camera projection can also be considered, for example by fixing an axis-aligned camera at a world origin, and setting the world-to-view transform as the identity I 4 . Assuming knowledge of intrinsic camera calibration parameters κ, these can be used to construct a full projection transform P. A local point in the model can then be transformed into image space using the model-view-projection transform PM {face|eye} . 
       FIG.  17    shows measurements of dense image-similarity as the mean absolute error between I obs  and I syn , over a mask of rendered foreground pixels P (white), with error for background pixels (black) ignored. 
     Analysis-by-Synthesis for Gaze Estimation 
     Given an observed image I obs , consider producing a synthesized image I syn (Φ*) that best matches it. A 3D gaze direction g can then be extracted from the eyeball pose parameters, and a search can be performed for optimal model parameters Φ* using analysis-by-synthesis. To accomplish this, a synthetic image I syn (Φ) can be iteratively rendered and compared to I obs  using the energy function, and Φ can be updated accordingly. The foregoing can be cast as an unconstrained energy minimization problem for unknown Φ, as follows: 
     
       
         
           
             
               
                 
                   
                     Φ 
                     * 
                   
                   = 
                   
                     
                       argmin 
                       Φ 
                     
                     ⁢ 
                         
                     
                       E 
                       ⁡ 
                       ( 
                       Φ 
                       ) 
                     
                   
                 
               
               
                 
                   ( 
                   9 
                   ) 
                 
               
             
           
         
       
     
     Objective Function 
     In some implementations, energy is formulated as a combination of a dense image similarity metric E image  that minimizes difference in image appearance, and a sparse landmark similarity metric E ldmks  that regularizes the model against reliable facial feature points, and weight λ controlling their relative importance: 
         E (Φ)= E   image (Φ)+λ· E   ldmks (Φ, L )  (10)
 
     Image Similarity Metric 
     In some implementations, a primary goal is to minimize the difference between I syn  and I obs . This can be regarded as an ideal energy function: if I syn =I obs , the model must have perfectly fit the data, so virtual and real eyeballs should be aligned. This can be approached by including a dense photo-consistency term E image  in the energy function. However, as the 3DMM in I syn  does not cover the entire of I obs , the image may be split into two regions: a set of rendered foreground pixels P over which error is computed, and a set of background pixels that are ignored (see  FIG.  17   ). Image similarity can then be computed as the mean absolute difference between I syn  and I obs  for foreground pixels p∈P: 
     
       
         
           
             
               
                 
                   
                     
                       E 
                       image 
                     
                     ( 
                     Φ 
                     ) 
                   
                   = 
                   
                     
                       1 
                       
                         
                           ❘ 
                           &#34;\[LeftBracketingBar]&#34; 
                         
                         P 
                         
                           ❘ 
                           &#34;\[RightBracketingBar]&#34; 
                         
                       
                     
                     ⁢ 
                     
                       
                         ∑ 
                         
                           p 
                           ∈ 
                           P 
                         
                       
                         
                       
                         
                           ❘ 
                           &#34;\[LeftBracketingBar]&#34; 
                         
                         
                           
                             
                               I 
                               syn 
                             
                             ( 
                             
                               Φ 
                               , 
                               p 
                             
                             ) 
                           
                           - 
                           
                             
                               I 
                               obs 
                             
                             ( 
                             p 
                             ) 
                           
                         
                         
                           ❘ 
                           &#34;\[RightBracketingBar]&#34; 
                         
                       
                     
                   
                 
               
               
                 
                   ( 
                   11 
                   ) 
                 
               
             
           
         
       
     
       FIG.  18    shows I obs  with landmarks L (white dots), and model fits with the landmark similarity term (top), and without (bottom). Note how erroneous drift is prevented in global pose, eye region shape, and local eyelid pose. 
     Landmark Similarity Metric 
     The face contains important landmark feature points that can be localized reliably. These can be used to efficiently consider the appearance of the whole face, as well as the local appearance of the eye region. A face tracker can be used to localize 14 landmarks L around the eye region in image-space (see  FIG.  18   ). For each landmark l∈L, a corresponding synthesized landmark l′ may be computed using the 3DMM. The sparse landmark-similarity term can be calculated as the distance between both sets of landmarks, normalized by the foreground area to avoid bias from image or eye region size. The foregoing acts as a regularizer to prevent the pose θ from drifting too far from a reliable estimate. 
     
       
         
           
             
               
                 
                   
                     
                       E 
                       ldmks 
                     
                     ( 
                     
                       Φ 
                       , 
                       L 
                     
                     ) 
                   
                   = 
                   
                     
                       1 
                       
                         
                           ❘ 
                           &#34;\[LeftBracketingBar]&#34; 
                         
                         L 
                         
                           ❘ 
                           &#34;\[RightBracketingBar]&#34; 
                         
                       
                     
                     ⁢ 
                     
                       
                         ∑ 
                         
                           i 
                           = 
                           0 
                         
                         
                           
                             ❘ 
                             &#34;\[LeftBracketingBar]&#34; 
                           
                           L 
                           
                             ❘ 
                             &#34;\[RightBracketingBar]&#34; 
                           
                         
                       
                         
                       
                          
                         
                           
                             l 
                             i 
                           
                           - 
                           
                             l 
                             i 
                             ′ 
                           
                         
                          
                       
                     
                   
                 
               
               
                 
                   ( 
                   12 
                   ) 
                 
               
             
           
         
       
     
       FIG.  19    shows example model fits on gaze datasets Eyediap (HD and VGA) and Columbia, showing estimated gaze (annotated “E” in  FIG.  19   ) and labelled gaze (annotated “L” in  FIG.  19   ). 
     Optimization Procedure 
     In some implementations, the model may be fit to a subject&#39;s left eye, for example using gradient descent (GD) with an annealing step size. Calculating analytic derivatives for a scene as complex as the eye region is challenging due to occlusions. Numeric central derivatives VE can be used to guide the optimization procedure: 
     
       
         
           
             
               
                 
                   
                     
                       Φ 
                       
                         i 
                         + 
                         1 
                       
                     
                     = 
                     
                       
                         Φ 
                         i 
                       
                       - 
                       
                         
                           t 
                           · 
                           
                             r 
                             i 
                           
                         
                         ⁢ 
                         
                           ∇ 
                           
                             E 
                             ⁡ 
                             ( 
                             
                               Φ 
                               i 
                             
                             ) 
                           
                         
                       
                     
                   
                   ⁢ 
                   
 
                   where 
                 
               
               
                 
                   ( 
                   13 
                   ) 
                 
               
             
           
         
       
       
         
           
             
               
                 
                   
                     
                       ∇ 
                       
                         E 
                         ⁡ 
                         ( 
                         
                           Φ 
                           i 
                         
                         ) 
                       
                     
                     = 
                     
                       
                         ( 
                         
                           
                             
                               ∂ 
                               E 
                             
                             
                               ϕ 
                               1 
                             
                           
                           ⁢ 
                           … 
                           ⁢ 
                               
                           
                             
                               ∂ 
                               E 
                             
                             
                               ϕ 
                               
                                 
                                   ❘ 
                                   &#34;\[LeftBracketingBar]&#34; 
                                 
                                 Φ 
                                 
                                   ❘ 
                                   &#34;\[RightBracketingBar]&#34; 
                                 
                               
                             
                           
                         
                         ) 
                       
                       ⁢ 
                           
                       and 
                     
                   
                   ⁢ 
                   
 
                   
                     
                       
                         
                           ∂ 
                           E 
                         
                         
                           ϕ 
                           j 
                         
                       
                       = 
                       
                         
                           
                             E 
                             ⁡ 
                             ( 
                             
                               
                                 Φ 
                                 i 
                               
                               + 
                               
                                 h 
                                 j 
                               
                             
                             ) 
                           
                           - 
                           
                             E 
                             ⁡ 
                             ( 
                             
                               
                                 Φ 
                                 i 
                               
                               - 
                               
                                 h 
                                 j 
                               
                             
                             ) 
                           
                         
                         
                           2 
                           ⁢ 
                           
                             h 
                             j 
                           
                         
                       
                     
                     , 
                   
                 
               
               
                 
                   ( 
                   14 
                   ) 
                 
               
             
           
         
       
     
     where t=[t 1  . . . t |Φ| ] are per-parameter step-sizes, h=[h 1  . . . h |Φ| ] are per-parameter numerical values, and r the annealing rate. t and h were calibrated through experimentation. 
     Initialization 
     To perform local optimization, an initial model configuration may be defined. The initial model configuration can include, for example, 3D eye corner landmarks and head rotation from a face tracker to initialize T and R. 2D iris landmarks and a single sphere eyeball model may then be used to initialize gaze. β and τ may be initialized to 0, and illumination l amb  and l dir  may be set to [0.8, 0.8, 0.8]. 
     Runtime 
       FIG.  17    shows convergence for a typical input image, with I obs  size 800×533 px, and I syn  size 125×87 px. Convergence may occur after 60 iterations for 39 parameters, taking 3.69 s on a typical PC (3.3 Ghz CPU, GTX 660 GPU). 
     Extracting Gaze Direction 
     When estimating 3D gaze direction g in camera-space, and once a fitting procedure has converged, g can be extracted, for example by applying the eyeball model transform to a vector pointing along the optical axis in model-space: g=M eye [0,0,−1] T . Additional details related to example implementations of the eye model can be found, by way of example, in Wood, E., et. Al., “A 3D Morphable Eye Region Model for Gaze Estimation,” Proc. European Conference on Computer Vision (ECCV), pp. 297-313 (2016), the entire contents of which are incorporated by reference herein for all purposes. 
     Some implementations use an energy function that is to be reduced (e.g., minimized), such that discrepancies between reality (e.g., a ground truth gaze/gaze direction of a user) and a modeled, predicted, or estimated gaze/gaze direction for the user are minimized. In some machine learning implementations, movement of a machine learning model towards inaccuracy is minimized by adjusting the parameters. One way to achieve this is to use the energy function as a loss function and to minimize the loss function directly. In some contexts described herein, such minimization of the loss function is an attempt to maintain a heuristic balance between the uniqueness of the eye characteristics of a user and a pre-existing machine learning model. In some implementations, the energy function is a weighted sum of several terms signifying the various parameters of the model fit. In some implementations, a Gauss-Newton algorithm can be used for minimizing the energy function, and each term can be expressed as a sum of squares. The data terms guide the model fit using image pixels and facial landmarks, where the prior terms penalize the unreal facial shape, texture and eyeball orientations. 
       FIG.  13    shows an example illustration of gaze redirection, according to an embodiment. Although Stanvin may be looking at Angelina on his screen, and Angelina looking at Stanvin on her screen, video of Stanvin and/or Angelina may show Stanvin, Angelina, and/or both looking elsewhere (as shown in the “Before” image). In some implementations, gaze modification can be performed such as Angelina and Stanvin are looking at each other in a virtual environment (as shown in the “After” image). 
     1.  FIG.  20    illustrates an energy summation, for use in minimizing discrepancies between a true gaze and a modeled gaze, in the context of gaze redirection, according to an embodiment. Considerations for each component of the energy summation are as follows: 
     1. Image Data Similarity: In some implementations, the photometric reconstruction error between a synthesized image (or fitted model) and an observed image can be reduced (e.g., minimized). A data term can measure the relevance of the fitted model with respect to the observed image, by measuring the dense pixel-wise differences across the images. An edge detection algorithm for segmenting the set of rendered foreground pixels, with the background pixels ignored, can also be defined. Segmenting the set of rendered foreground pixels can include collecting similar pixels (e.g., detected in an image according to a selected threshold, region merging, region spreading and/or region growing) and separating them from dissimilar pixels. In some implementations, a boundary-based approach is adapted, as the method for object identification instead of a region-based approach. Unlike region-based detection, where pixels are identified as having similar features, one can identify pixels that are dissimilar to one another in the boundary-based approach.
 
2. Landmark Data Similarity: The face contains several landmark feature points that can be tracked reliably. A dense data term E i mg can be regularized using a sparse set of landmarks “ ” provided by a face tracker.   can consist, for example, of 25 points that describe the eyebrows, nose and/or eyelids. For each 2D tracked landmark ι∈ , a corresponding synthesized 2D landmark ι′ can be computed, for example as a linear combination of projected vertices in a shape model. Facial landmark similarities are incorporated into the energy summation using data measured in image-space. The energy can be normalized by dividing through by the foreground area (“P”), to avoid bias from eye region size in the image. For example, as landmark distances |ι i −ι i ′| are measured in image-space, the energy can be normalized by dividing through by the foreground area to avoid bias from eye region size in the image. The importance of E ldms  (Φ) (energy function component involving landmark similarity) is controlled with weight    tdmks  (weight function influenced by the parameters discussed above), where Φ refers to the eye model.
 
3. Statistical Prior: Unnatural facial shapes and/or textures can be penalized using a “statistical prior.” As used herein, a “statistical prior” refers to a “prior probability distribution” in Bayesian statistical inference, which is the probability distribution that would express one&#39;s beliefs about the quantity before some evidence is taken into account. Assuming a normally distributed population, dimensionally-reduced model parameters should be close to the mean of 0. This energy helps the model fit avoid geometrically disproportionate facial shapes and/or textures, and guides the model&#39;s recovery from poor local minima found in previous frames.
 
4. Pose Prior: Another energy penalizes mismatched parameters for eyeball gaze direction and eyelid position. The eyelids follow eye gaze, so if the eyeball is looking upwards, the eyelids should be rotated upwards, and vice versa. Eyelid pose consistency with the 3D eyeball is enforced so that that any unrealistic relationship between the eyelid pose and the eyeball position is avoided.
 
     Once a set of fitted model parameters (Φ,″ for an image I obs ) have been obtained, gaze is redirected to point at a new 3D target g′. First, Φ″ is modified to obtain Φ′, which represents the redirected gaze. The optical flow between eye region models with Φ″ and Φ′ is then calculated, and used to warp the eyelids in the source image. 
     Gaze is thus redirected in two steps: 
     1. Warp the eyelids in the original image using a flow field derived from the 3D model. This flow field is efficiently calculated by re-posing the eye region model to change the gaze represented, and rendering the image-space flow between tracked and re-posed eye regions.
 
2. Render the redirected eyeballs and composite them back into the image. The boundary between the skin and eyeball may be blurred, to soften the transition so that the eyes “fit in” better.
 
     Some implementations include a hybrid model-appearance-based gaze estimator serving on a backend AI-ML-Physics kernel, in conjunction with front-end application programming interfaces (APIs) and a gaze redirector, accurate enough to compute quantitatively and qualitatively, and predict quantitatively and qualitatively, the point of attention of a subject on a display screen in real-time. 
     Some implementations include a hybrid warping-based gaze redirector serving on a backend AI-ML-Physics kernel, in conjunction with front-end APIs and a gaze estimator, capable of warping and redirecting a hybrid eye model, in accordance with processed data flow from the gaze estimator, to adjust eye gaze in real-time video communication applications. 
     Some implementations include a data-inspired and physics-driven machine learning kernel comprising two components—a gaze estimator and a gaze redirector. As used herein, data-inspired refers to the property of being driven by derived data involving statistical learning based on historical data associated with the user. Physics-driven refers to the property of being driven by data on and about iris localization, eye reflection measurements, pupil centroid tracking, and/or other measurable properties with processes/algorithms within the computer vision domain. The gaze estimator makes it possible for people within a 3D virtual world to accurately perceive any person&#39;s object of attention by modifying 3D representations of participant eye gaze(s) in real-time, based on their point of attention on the screen (i.e., what he/she is looking at on a display screen). The gaze redirector can be configured to undergo continuous learning and generation of flow fields from one eye image to another, e.g., using training pairs of eye images with pre-defined gaze offsets between them. The flow field thus generated by the redirector can be used to warp pixels in an original image, thereby modifying gaze. As such, the 3D experience provided by the eye-contact enhancements presented herein can improve the virtual reality feel and sense of interpersonal conversations. 
     Some implementations are related to eye gaze modifications in video. For example, after capturing eye data of a first user via a calibration process (e.g., via a compute device associated with the first user), a video stream of the first user can be captured. The gaze of the first user in the video stream can be modified to produce a modified gaze, such that a second user views the first user (e.g., at a compute device associated with the second user) with the modified gaze. 
     Some implementations are related to single-angle calibration or multiple angular calibration of eye gaze of multiple users, optionally performed in parallel. For the calibration process, one or more user(s) can login to a front end interface (e.g., via a user compute device) and register for a new-user session or an existing-user session. When the user is a new user, the system prompts them to perform calibration to enable an eye gaze adjustment system (implemented, for example, as shown in  FIG.  21   ). The user(s) can respond to the various interactive prompts using their eyes and/or their keyboard or other input device. The user&#39;s eye(s) may be still/stationary when the user initially looks into the camera, and the system can then prompt the user to move their eye(s) around, for example along one or more different predefined patterns displayed to the user, which the user can follow. At substantially the same time or during an overlapping period of time, there can be several different users who are responding to similar (or modified) prompts laid out by the network of computers on the computer, collectively referred to herein as the “backend” or server cluster, to perform the same exercise. 
     In some implementations, the system&#39;s front end, or “front end interface” (e.g., implemented in software, such as a graphical user interface (GUI)), which communicates with or receives feedback/instructions from the backend, is configured to collect the user eye gaze data (i.e., eye data), store (or cause storage of) the eye data at the backend, and/or gather eye data using software routines for heuristic gauging and gaze re-correction purposes. The heuristic gauging can include optimization of heuristic parameters based on one or more rule evaluation metrics such as an F-measure, the Klösgen measure, and/or the m-estimate. The one or more rule evaluation metrics can be used in a multiple regression. The feedback/instructions from the backend can include, for example, instructions regarding what the GUI should request from the user next (e.g., capture additional X,Y coordinates from one or more specified areas). In some implementations, the front end, in its capacity of functioning in unison with the backend, is configured to collect 2D planar data of the user&#39;s eye as detected/measured by the camera and the software. The backend can be configured to convert these 2D planar data of the user&#39;s eye into a re-engineered version of eye gaze of the user(s) in a 3D world coordinate system. The front end can cause display, for example on a computer monitor or mobile device screen (serving as an interactive display of the user), of an object such as a ball, and ask/instruct the user to move their eye focus to wherever the object moves. The object can be displayed as moving, or intermittently/sporadically moving, to various locations on the screen, and the front end can collect the user eye data while recording where the object was located on the screen when the eye data was captured. The front end and/or a compute device operably coupled to the front end optionally compresses the eye data and transmits or causes transmission of the eye data to the backend. The backend determined whether any additional translations/movements of the object within the display are desired for attaining accurate predictions/estimations of eye gaze by taking into account (e.g., comparing) the eye data already acquired with pre-existing data models of various users, inference models from heuristics, and/or the precision of the measured data. When the backend indicates that the eye data already collected is sufficient, the backend signals to the front end to stop collecting further eye data, and the front end displays a welcome message to the user, welcoming the user to the session as a newcomer. 
     The cluster of computers (which may be deployed remotely) collectively referred to herein as the server or the backend can be configured to generate compressed user eye data received from the front end, and leverage the compressed user eye data when augmenting a user&#39;s eye gaze in real-time. The cluster of computers can include any number of computers, such as 1, 2, 3, etc. 
     In some implementations, the backend is configured to apply one or more different physical and heuristic algorithms to achieve a desired effect (e.g., a cognitive effect). The cognitive effect can refer to an intuitive and integrative effect that influences the end-user to believe that the eye motion of the counterpart user is in accordance with the context of the visual interactions within the 3D environment. Example physical algorithms can include iris center localization in low-resolution images in the visible spectrum. In some implementations, gaze tracking may be performed without any additional hardware. An example two-stage process/algorithm can be used for iris center localization, based on geometrical characteristics of the eye. A coarse location of the urus center can be computed by a convolution algorithm in the first stage, and in the second stage, the iris center location can be refined using boundary tracing and ellipse fitting. The server is configured to calculate a compounding factor which is a resultant of the most recent user data, a predictive component, an existing meta-heuristic model and a correction influenced by a previous episode/interaction of a similar user. The operations of the system are intricately scheduled by automatic balancing between the client-side data received and the computing capacity of the server side. As soon as the user enters the virtual 3D space at the client side, the coordinates of the user along with inputs (e.g., keyboard and/or mouse activities) are collected and transmitted to the server, which determines the position and status of the user in the 3D space. As used herein, “status” can refer to whether the user is present in the 3D environment, their state of action, whether they are speaking or silent, a direction of their gaze, their head position, and/or a probable direction of gaze in the upcoming time steps. The rendering engine, which includes an output data channel of the server side and optionally includes (or uses data from) one or more graphics processing units (GPUs), is configured to adjust this position and status. A compute device of another user who has visual access (e.g., within the virtual 3D space/environment) to the user may receive data that is generated by the server side based on one or more parameter adjustment operations. Mutually between the users, the field of view (FOV), the angle of the perception and the distance are determined, for example by the server and/or by the users themselves by means of one or more peripheral inputs. The back end can contribute to/supplement the foregoing process by sending corrected and new video frames automatically or in response to one or more requests. The corrected and new video frames may contain altered viewpoints and angles, as well as additional changes to the eye movements of the mutual users. The eye movements, fixations and transitions are results of several factors, as explained below. 
     In some implementations, the server can take into account a mapping of a particular user&#39;s eye details and the manner in which the eye movements are perceived and transmitted by the camera of the compute device the user is using. The compute device may be, for example, a laptop, a desktop computer, a tablet, or a smartphone or other mobile compute device. The cameras of these devices may widely vary in their specifications, focal lengths, fields of view etc. Since each user&#39;s eyes are unique to them and since each compute device is unique, the mappings between the former and the latter are sufficiently accurate for the manipulations of the visual artifices and the eye gaze corrections subsequently performed. As such, a process of calibration can be used to achieve the desired adjustments/corrections. As discussed above, the calibration can include requesting that the user focus on a certain object on their screen, and move their eye(s) with the object while concentrating as the object moves. The positions and eye movements of the user are collected by the camera and the front end device, and transmitted to the server, where several computations later the calibration data is stored in the form of a camera calibration matrix. The foregoing process, described as being performed by one user, can be performed for multiple (e.g., several hundred) users concurrently or overlapping in time, and the computing load can be borne by a graphics processing unit (GPU) cluster deployed on the server side of computers. The GPU cluster can be configured to perform machine learning for gaze estimation and/or gaze redirection, for example to generate predictions in an accelerated manner. 
     In some implementations, what the server outputs to the rendering engine is a sequence of new video frames or packets that are curated in accordance with the user&#39;s region of interest (e.g., present or past) and/or one or more heuristics, and that represent evened-out results of the user&#39;s eye movements and transitions, generating the perception of eye contact between users, or perceive someone&#39;s attention is elsewhere, with the present scenario effectively communicated, and with a probability of shifting of gaze being communicated, thus ensuring a smooth transition. The sequence of video frames or packets can be used to interpret the user&#39;s attention (e.g., what/who the user is paying attention to and/or looking at). The back end computing system has the capacity, due to computing routines and algorithms, to predict the next region of interest of a certain user at the client side. The next region of focus of the user can be predicted with an accuracy that depends on the region(s) on which the user was focusing several consecutive time instants earlier. The accuracy can also depend on the size of the video tile, which is proportional to the distance at which the area of focus was in the past. For example, suppose a user&#39;s web camera captures a set of frames at times t 0 , t 1 , . . . t n , encodes them, and sends them to the system&#39;s server(s). As with all real-time systems, there can be latency associated with the transmission. Each frame from the set of frames can include a different gaze scenario for a given “observer” user (e.g., instances of a user switching their gaze), so each frame is analyzed to predict where that observer user&#39;s attention was (i.e., what they were looking at) for each moment in (or snapshot of) time. During these moments in time, there can be participants in front of the observer user who vary with regard to their distance away from the observer user. For those participants who are closer to the observer user, it may be easier for the machine learning model(s) to predict that the observer user is actively looking at them, since those participants occupy more space on the observer user&#39;s screen, and thus have a larger field of view. Participants who are further away from the observer user will occupy less space on the observer user&#39;s screen, however it is possible that the observer user is looking at this distant user. To detect that the observer user&#39;s attention has been routed to, or has switched to, this distant user, the distant user may be assigned a field of view that is proportionally larger than the nearby participants. For example, a distant user could be granted a field of view that is 2× the size of their video tile, whereas a nearby user might only have a field of view that is less than 1× the size of their video tile. 
     In some embodiments, the system uses a convolutional mathematical function that takes into account the visual field algebra of the user, the gaze vector of the user, the camera calibration parameters, the heuristic inference of several users of the past acquired from the server-side database, and/or the recent gaze history of the user. Visual field algebra can include parameters such as the distance between an observer and an observed, the spread angle of the viewer&#39;s eyes, the perspective view parameters with respect to the 3D intuition of the viewer, and the relative distance between the several objects in the user&#39;s visual field. 
     In addition to eye movement adjustments and area of interest adjustments, the eye gaze redirecting system can also take into account differences between the actual eye movements captured by the 2D camera and the way the eye movements are represented in the 3D environment in which the clients engage, for example during chat sessions. For example, the angular span (a specific measure of field of view) of a user as detected by that user&#39;s device camera may not always be well-represented or faithfully represented in the 3D environment. due to under-scaled reproduction thereof. For this reason, in some implementations, the angular span of the client&#39;s eye movement is adjusted (e.g., magnified) by a convenient factor which is also dependent on the distance the client is located from his own camera. 
     The ecosystem thus far described is a robust network of providing, for a multitude of users who are logged in for a chat session at a given time/instant, a seamless, realistic and natural communication feeling due to the corrected eye gaze(s), designed in accordance with the specifications of the 3D visual field of each and every participant of that chat session. 
     System Block Diagram (FIG.  21 ) 
       FIG.  21    shows a system block diagram associated with an eye gaze adjustment system, according to an embodiment.  FIG.  21    includes a first server compute device  1100 , a second server compute device  1102 , user 1 client compute device  1130 , and user 2 client compute device  1140 , each communicably coupled to one another via networks  1120   a ,  1120   b  (which may be the same or different network(s), collectively referred to hereinafter as “network  1120 ”). 
     In some implementations, the network  1120  can be any suitable communications network for transferring data, operating over public and/or private networks. For example, the network  1120  can include a private network, a Virtual Private Network (VPN), a Multiprotocol Label Switching (MPLS) circuit, the Internet, an intranet, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a worldwide interoperability for microwave access network (WiMAX®), an optical fiber (or fiber optic)-based network, a Bluetooth® network, a virtual network, and/or any combination thereof. In some instances, the network  1120  can be a wireless network such as, for example, a Wi-Fi or wireless local area network (“WLAN”), a wireless wide area network (“WWAN”), and/or a cellular network. In other instances, the communication network  1108  can be a wired network such as, for example, an Ethernet network, a digital subscription line (“DSL”) network, a broadband network, and/or a fiber-optic network. In some instances, the network can use Application Programming Interfaces (APIs) and/or data interchange formats, (e.g., Representational State Transfer (REST), JavaScript Object Notation (JSON), Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), and/or Java Message Service (JMS)). The communications sent via the network  1120  can be encrypted or unencrypted. In some instances, the communication network  1120  can include multiple networks or subnetworks operatively coupled to one another by, for example, network bridges, routers, switches, gateways and/or the like (not shown in  FIG.  21   ). 
     The user 1 client compute device  1130  can include a processor, memory, camera(s), peripherals, and display, each communicably coupled to one another (e.g., via a system bus). The user 2 client compute device  1140  can similarly include a processor, memory, camera(s), peripherals, and display, each communicably coupled to one another (e.g., via a system bus). Each of the first server compute device  1100  and the second server compute device  1102  can include a processor operatively coupled to a memory (e.g., via a system bus). The second server compute device  1102  includes a rendering engine  1110 , as described herein. 
     The processors can be, for example, a hardware based integrated circuit (IC) or any other suitable processing device configured to run and/or execute a set of instructions or code. For example, the processors can be a general-purpose processor, a central processing unit (CPU), an accelerated processing unit (APU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic array (PLA), a complex programmable logic device (CPLD), a programmable logic controller (PLC) and/or the like. In some implementations, the processors can be configured to run any of the methods and/or portions of methods discussed herein. 
     The memories can be, for example, a random-access memory (RAM), a memory buffer, a hard drive, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), and/or the like. The memories can be configured to store data used by the processors to perform the techniques discussed herein. In some instances, the memories can store, for example, one or more software programs and/or code that can include instructions to cause the processors to perform one or more processes, functions, and/or the like. In some implementations, the memories can include extendible storage units that can be added and used incrementally. In some implementations, the memories  1104 ,  1134 ,  1144  can be a portable memory (for example, a flash drive, a portable hard disk, and/or the like) that can be operatively coupled to the processors. In some instances, the memories can be remotely operatively coupled with a compute device (not shown in  FIG.  21   ). 
     The peripherals can include various input and/or output devices. In some implementations, the peripherals include cameras. The cameras can be used to capture images and/or video of users 1 and 2 (respectively). The cameras can be, for example, an external web camera or a camera housed within a desktop, laptop, smartphone, tablet, and/or the like. In some implementations, the cameras are configured to capture video that includes the face of users 1 and 2. In some implementations, the cameras are configured to capture video that includes both eyes of users 1 and 2. The peripherals can each also include a device(s) such that users 1 and 2 can control their respective virtual representations in a virtual environment, such as a mouse, keyboard, game controller, and/or the like. 
     The displays can include any type of display, such as a CRT (Cathode Ray tube) display, LCD (Liquid Crystal Display) display, LED (Liquid Emitting Diode) display, OLED (Organic Light Emitting Diode) display, and/or the like. The displays can be used for visually displaying information (e.g., data) to users U1 and U2, respectively. For example, a display of user 1&#39;s client compute device  1130  can display a virtual representation of user U2 in a virtual environment to the user U1, and a display user 2&#39;s client compute device  1140  can display a virtual representation of user U1 in the virtual environment to user U2. The displays can each include one or more displays. For example, the display of user 1&#39;s client compute device  1130  and/or or user 2&#39;s client compute device  1140  may include dual monitors. 
     User 1 may use user 1 client compute device  1130  to enter a virtual environment, where user 1 can be represented via a virtual representation (e.g., video pane of user 1). User 2 may use user 2 client compute device  1140  to enter a virtual environment, where user 2 can be represented via a virtual representation (e.g., video pane of user 2). If, in the virtual environment, user 1&#39;s virtual representation looks in the direction of user 2&#39;s virtual representation, user 1 will see user 2&#39;s virtual representation via the display of user 1&#39;s client compute device  1130 . If, in the virtual environment, user 2&#39;s virtual representation looks in the direction of user 1&#39;s virtual representation, user 2 will see user 1&#39;s virtual representation via the display of user 2&#39;s client compute device  1140 . 
     The memory of the first server compute device  1100  can include a representation of eye data. The eye data can be associated with user 1, and represent eye data of user 1 via a calibration process. The calibration process can include the display of user 1&#39;s client compute device  1130  displaying an object on one or more locations, and a camera included in a peripheral of user 1&#39;s client compute device  1130  capturing images and/or video of user 1 during the displaying of the object. As such, the eye data can include indications of user 1&#39;s gazes when objects are at various locations on the display. The eye data can be received at the first server compute device  1100  from user 1&#39;s client compute device  1130 , for example via one or more webcam streams. 
     The memory of the first server compute device  1100  can also include a representation of video frames without gaze correction. The video frames without gaze correction can refer to video captured of user 1 via the camera included in the peripherals of user 1&#39;s client compute device  1130  while a virtual representation associated user 1 is in a virtual environment. For example, the video frames without gaze correction can refer to video captured of user 1 while user 1 is in a virtual meeting. The video frames without gaze correction can be received at the first server compute device  1100  from user 1&#39;s client compute device  1130 . 
     The memory of the first server compute device  1100  can also include a representation of a processing pipeline. The processing pipeline can be configured to receive input and output engineered video frames with gaze correction  1112 . In some implementations, input to the processing pipeline to generate the video frames with gaze correction  1112  can include the eye data and video frames without gaze correction. For example, video frames without gaze correction can be used to determine a gaze (e.g., eye position) of user 1, and the eye data can be used to determine where on the display of the user 1&#39;s client compute device  1130  user 1 is looking based on their gaze. A new target gaze can then be determined, for each video frame from the video frames without gaze correction, indicating how a gaze of user 1&#39;s virtual representation should be modified for that video frame. In some implementations, at least one generative adversarial network (GAN) included in the processing pipeline can receive each video frame from the video frames without gaze correction and target gaze associated with the video frame to generate a video frame with gaze correction that is included in the video frames with gaze correction  1112 . The video frames with gaze correction  1112  can be similar to the video frames without gaze correction, except that a gaze of user 1 in the video frames with gaze correction  1112  can be different from the gaze of user 1 in the video frames without gaze correction. 
     Depending on the location and field of view of each user in a given virtual environment, different users (e.g., user 2) will see a different angular perspective (i.e., side) of user 1 at the user 1&#39;s virtual representation in the virtual environment. For example, one user may see user 1&#39;s virtual representation showing a left side of user 1&#39;s face, while a different user may see user 1&#39;s virtual representation showing a right side of user 1&#39;s face. As such, modified video frames can be generated based on the video frames with gaze correction  1112 . The modified video frames show the virtual representation associated with user 1 having a corrected/modified gaze, and at an angular perspective(s) of user 1 that considers the location and/or field of view of user 1&#39;s virtual representation and the location and/or field of view of a user&#39;s virtual representation viewing user 1&#39;s virtual representation. For example, where user 1&#39;s virtual representation is located to the left of user 2&#39;s virtual representations, video frames without gaze correction may represent user 1 looking to the left, video frames with gaze correction  1112  may represent user 1 looking to the right, and the modified video frames can represent the right part of user 1 as user 1&#39;s virtual representation is looking to the right. The modified video frames can then be sent from the first server compute device  1100  to the second server compute device  1102  (see “client 1 &amp; 2 augmented video” in  FIG.  21   ), and then forwarded from the rendering engine  1110  of the second server compute device  1102  to user 2&#39;s client compute device  1140 , where the modified video frames are displayed via the display of user 2&#39;s client compute device  1140  so that user 2 can see user 1&#39;s virtual representation with the modified gaze and appropriate angular perspective. 
     Although not explicitly shown in  FIG.  21   , a similar process to that described above about user 2 viewing user 1&#39;s virtual representation with modified video frames can occur at server compute device  1100  such that user 1 can view modified video frames of user 2&#39;s virtual representation having a modified gaze and angular perspective. Additionally, although  FIG.  21    is discussed with respect to two users, two virtual representations, and two compute devices, any other number of users, virtual representations, and/or compute devices can be used. These other users, virtual representations, and/or compute devices can also view the virtual representations of users 1 and/or 2 with the modified gaze and angular perspective. Additionally, although certain representations of data are described herein as being stored in the first service compute device  1100  (e.g., eye data, video frames without gaze correction, video frames with gaze correction, etc.), in some implementations, such data can be stored in a different compute device (e.g., second server compute device  1102 ) as an alternative to, or in addition to, the first service compute device  1100 . 
     Data Flow Through System Architecture (FIGS.  12 A- 12 B) 
     The eye gaze estimation and redirection engine (collectively referred to herein as the gaze adjustment engine) can take inputs/contributions both from the client side (e.g., user 1 compute device  1130  and/or user 2 compute device  1140 ) and the server side (e.g., service compute device  1100 ). Components of  FIGS.  12 A- 12 B  can be implemented in hardware and/or software. Gaze estimation can include computation of the position vector (i.e., gaze vector) centered at the pupil of the subject&#39;s eye, which can be analogous to the normal vector of a three-dimensional curved surface whose radius of curvature is equal to that of the pupil. Redirection is the process of changing the values of the gaze vector at will/as desired. Together, estimation and redirection form the core components of the maintenance of eye contacts of the users of Kickback.space™. A subject looking straight into the camera of his device is expected to hold a zero gaze vector, owing to the fact that his pupilar normal is inline with the camera normal. There are, however, several situations in which this straightforward inference fails due to camera lens distortions, user eye asymmetry, squint, radius parameters and other anomalies intended or unintended. 
     A client side compute device can be a computer or a mobile device operated by an individual  001  who has access to the Kickback.space™ services through his web browser (and/or application). It is possible that there are hundreds of clients/users co-existing at the start of an event. If some of them are first-timers, they can go through the eye gaze adjustment routine to register their uniqueness in the system. The uniqueness of each user can be (but may not be required to be) determined in greater detail than is typically involved in known facial recognition, pupil identification or thumb print biometric systems, in that the users may undergo an additional exercise for documenting their eye topology, geometry and morphology. 
     The server side includes the coordinated and orchestrated computing resources (optionally deployed in the cloud), allotted at a given time to the eye gaze adjustment routines, and works in unison with machine learning (ML) inference engines, a database of multiple eye gaze prediction models, a database of experimental results, a model database, and collections of client side responses and requests. The communication from the server to the client can be in the form of feedback regarding the various eye gaze parameters of interest. The communication from the client to the server predominantly contains compressed media and meta data. 
     Client Side 
     In some embodiments, camera calibration is performed because a camera-to-virtual world correspondence is a one-to-one functional relationship, unique to a camera, dependent on the 3D system rendered remotely to a display, and on the user&#39;s eyes. The camera-to-virtual world correspondence can vary depending on the distance a user is positioned from the camera, the display size, its aspect ratio, the user&#39;s speed of shifting gaze and/or other individual morphological features of the user&#39;s eyes. 
     Turning to  FIGS.  22 A- 22 B , the user, upon access to the client side interface of Kickback.space™ on their computer (e.g., via a webpage, as shown at  001  of  FIG.  22 A ), is instructed to calibrate his eye with respect to the device camera (activated at  002 ), if he is a first-timer as notified by the server via the client. As a first step of camera calibration, the user is prompted (at  003  of  FIG.  22 A ) by the system (e.g., Kickback.space™) after authentication, to respond to visual/textual cues with regard to an object on the screen, created by the gaze adjustment routines. 
     Kickback.space™ makes the webpage full-screen and detects the size of the window at  004 . The front end of Kickback.space™ can also be referred to as the interface. The interface requests that the user draw an object at initial coordinates (x, y) on their screen, and captures, at  006 , the images or videos of the user while the object is at (x, y)  005 . Then the interface moves the object to a new coordinate (x, y), at  010 , which the user is next prompted to focus on. This prompt-response-capture cycle is repeated until there is a sufficient number of observations, which is decided by the server feedback  009 . 
     When this cycle ends at  009 , user data is captured in a compressed format, containing the coordinates (x i , y i )|i=1, 2 . . . N of the object location at N captures and resultant metadata  008 , and transmitted to the remote servers. The user is then prompted to exit the gaze capture cycle, at  011 , to move to the next step. 
     Server Side 
     A functionality of the server side computing in the gaze adjustment engine is to arrive at a heuristically balanced outcome, which compounds the uniqueness of the eye gaze of an individual user with a robustly evolving machine learning model. 
     On the server side, the eye gaze calibration ingress  015  is transmitted to a group of computers, from any number of clients who are actively engaged with calibration at that instant/time. These computers, in turn, send feedback  012  to the respective client computers, the feedback including parameters for use in deciding (e.g., at  016 ) whether further data measurements are desirable, depending on the accuracy of the ingress data and the sufficiency of co-ordinates (x i , y i )|i=1, 2 . . . N, from a particular region in the 3D space. 
     The server side computing resource determines these parameters based on the outcome of experiments conducted, which are resultants of the compound factor involving a prediction using an existing model at  018  and a prediction using a newly-trained model at  020 . The former is obtained by compounding user data  019 ,  023  and data from an experiment conductor, which uses the user eye gaze calibration ingress and data from a database of gaze prediction results. The ingress is used to train one or more prediction models at  021  based on the user data and by coupling with ground truth data  022 , and/or to make predictions using existing models of eye gaze correction/redirection. The foregoing is executed by an experiment conductor  014  module by using data from a database of multiple eye gaze prediction models and experimental results. The data queried from the database to which the composed experimental results  017  are updated can also be used to train models. The predicted models are updated and written to the database  013  after the results of the experiments are composed  017 . The gaze correction can depend on the ML-inferred gaze vector, which may be a resultant of earlier model computations. 
     Operations Layer of System Architecture (FIGS.  23 A- 23 B) 
     In some embodiments, a cluster of one or more servers deployed in the cloud is configured to perform eye gaze correction and redirection by receiving data that includes client-side web cam stream data and/or input data (e.g., keyboard and/or mouse response data), and outputs video frames containing corrected gaze(s) of the user  101 . When a user enters the 3D virtual world, their webcam video stream data  103  and their keyboard and/or mouse inputs  102  are gathered by the services and transmitted to a remote server equipped with GPUs. The initial location  104  of the user and their field of view with respect to the virtual world state data are taken as references. 
     Using the keyboard and/or mouse inputs, the rendering engine  105  is configured to accept and modify the user&#39;s location and perspective. The web video camera stream, in the form of raw data, is decoded into video frames  110  with hardware acceleration. The transmitted data defines the state of the user in the virtual world at time T ( 106 ). The users in the field of view (FOV) of a given user are presented to that user as a function of their area of location A within the virtual world  106  and the user&#39;s location(x, y, z) in their field of vision  107 . The decoded video frame data is used to obtain the user&#39;s eye gaze attention for each video frame by utilizing the user metadata and predicting the (x, y) location of the gaze. The user metadata  112  is also used to determine the camera configuration or the field of view. 
     The source frames from the video are inputs to a GAN pipeline along with the measured  116  eye gaze vector  117  and the target eye gaze vector  119  for each video frame. The output of the GAN pipeline  118  is a set of new frames  123  with the corrected eye gaze vector, which is then encoded with hardware acceleration. The target eye gaze vector for each frame is composed by deciding between two factors. If there is an overlap  115  between the prediction  114  and the participant area, say for example participant B, the eye gaze vector orients to perfectly point to participant B, and then the eye gaze vector is re-computed to make eye contact with the participant. If there is no match  117 , the gaze vector is computed to normalize the user&#39;s gaze to the field of view. The final gaze corrected video frames are then transmitted to the subscribers  121  after proper hardware accelerated video encoding  122 . 
     Camera-to-User Eye Relationship Calibration Example (FIG.  24 ) 
     In this example, the diagram shows the screen state at times t 0    200  and t 1    201 , respectively. The object starts moving from the top left corner of the screen (in other steps it can move in various directions), and is focused on by the user at to, who continues to look at and follow the object, as it moves to the bottom right t 1 . The object can keep hovering throughout the screen until signals from the server cause the cycle to end. In some embodiments, the user can be requested to click or trace the object as it moves or remains static, to collect the cursor coordinates (x cu , y cu ) in conjunction with the coordinates (x obj , y obj ) of the drawn object. The object drawn can be static or dynamic upon certain user inputs, or it can be constantly moving around the screen, e.g., a bouncing ball that reacts to edges or key inputs. The interface also provides a multi-screen ( 202 ,  203 ) calibration option, which can perform the foregoing routine regardless of the number of displays or orientation of displays the user(s) may have. 
     Probabilistic Prediction of Future Area of Interest in 2D Planar Coordinates (FIG.  25 ) 
     Given a scenario (shown in  FIG.  25   ) in which three participants A, B and C are within the field of view of a user (or “client user”), within a time interval, suppose the user is viewing/focusing on participant B&#39;s face and shoulder for the first three video frames, and then switches to viewing/focusing on participant A&#39;s face in the fourth (last) frame. The area of the video stream tile can be represented as A user   tile  and the facial rectangular area be A user   frect . The user subscript can be  A ,  B  or  C , depending on the user concerned. Since the A user   frect  is in proportion to A user   title , and A user   title  varies with the Z-distance in the 3D virtual space, there is a chance that the gaze of the user, when focuses on participant C, may be missed. The Z-distance is inward normal to the screen, and at a design level is assumed to be the focus priority of the client user being given to the participant(s). In  FIG.  25   , amongst participants A, B and C, the client user has given a priority of focus to participants in that same order (e.g., as evaluated on a per frame basis). Thus, the accuracy of eye gaze correction at any given time due to this phenomenon can be given by 
       ϵ user =ζ( A   user   tile   ,A   user   frect   ,Z,t ,Φ(v user     s   ,ϕ user     s   ))
 
     The function ϕ is unique to a client user, and cannot be determined by closure (“closure” referring to a system of consistent equations that can be solved analytically or numerically, and that does not require any more data other than the initial boundary conditions of the system), even by empirical evaluations. Rather, the function ϕ is a heuristic component that can be continuously updated by ML inference from the server feedback. The subscript “s” represents primarily high velocity, conjugate movements of the eyes known as saccades. When the head is free to move, changes in the direction of the line of sight can involve simultaneous saccadic eye movements and movements of the head. When the head moves in conjunction with the eyes to accomplish these shifts in gaze direction, the rules that helped define head-restrained saccadic eye movements are altered. For example, the slope relationship between duration and amplitude for saccadic eye movements is reversed (the slope is negative) during gaze shifts of similar amplitude initiated with the eyes in different orbital positions. 
     The probability that a user could be the next focus (at time state t+1) of the client user, which depends on the ratio of the number of times that the client user shifts focus in the previous time state t, is given by: 
     
       
         
           
             
               
                 P 
                 
                   t 
                   + 
                   1 
                 
               
               ( 
               
                 U 
                 i 
               
               ) 
             
             = 
             
               1 
               - 
               
                 
                   ∑ 
                   
                     i 
                     = 
                     0 
                   
                   N 
                 
                 
                   
                     
                       N 
                       t 
                     
                     ( 
                     
                       U 
                       i 
                     
                     ) 
                   
                   
                     
                       N 
                       t 
                     
                     ( 
                     U 
                     ) 
                   
                 
               
             
           
         
       
     
     Backend Conversion of Probable Areas of Interest and Gaze into Spatial Coordinate Data ( FIG.  26   ) 
     Video frames with users focusing on a certain irrelevant portion of the screen  400  are to be processed by the backend systems  402  to focus on a region of higher probability of natural attention. The latter region is chosen by ML inference and the previously described factors. The augmented video  402  with the gaze direction changed includes several video frames across which the gaze is adjusted to focus in a certain integral equilibrium to the region of probable attention. The augmented video frames are compounded images with the user eye features and the ML model substituting the gaze vector on the eye ball, thus resulting in a realistic eye movement. A rendering engine receives these video frames and then streams the perspective for each user participating in the chat/conference. 
     In the user head figures shown, user 1 is looking at his screen and can observe users 2 and 3. The following two screens belong to users 2 and 3, respectively. The gaze of the user 1 as perceived by the user 2 and 3 is modified enough that they two can tell where user 1 is currently looking.  403  With the palm tree in the figure as a reference object, due to the differing positioning of the users within the 3D world  405 , the palm tree is visible to the respective users at different projection planes, but user 2 observes that user 1 is looking at them, and user 3 observes user 1 is currently not looking at them. 
     Normalizing Eye Gaze Redirection in the Spatial Coordinate System (FIGS.  27 A- 27 B) 
     The eye gaze can be adjusted to reflect the field of view for an “in-space camera.” Virtual environments can be rendered via one or more rendering engines, and each user has their own perspective within the virtual environment. The rendering engine(s) deploy in-space cameras to render perspectives for each individual user. Each user who joins the virtual environment can have their own associated in-space camera, and each in-space camera can have its own associated properties that may differ from others of the in-space cameras. The actual field of view depends on the distance between the user and the monitor, as well as the size of the monitor. In a case of 45 degree field of view for a given user, consider an in-space camera that captures the perspective of this user with the assumption that the field of view within the virtual environment is greater than what we perceive in the real life, for instance ranging from 90 degrees to 260 degrees. When the actual prediction is 45 degrees and the camera configuration is 135 degrees, a normalizing ratio of 3 is obtained. The movement of the eyes of the user is thus exaggerated by a factor of 3 whenever there is a shift in their gaze, and whenever the eyes are off-center, the gaze is normalized and exaggerated by a factor of 3. 
     Methods 
       FIG.  28    shows a flowchart of a method  800  for eye gaze adjustment, according to an embodiment. In some implementations, method  800  can be performed by a processor (e.g., processor  102 ). 
     At  801 , a signal representing eye data (e.g., eye data  106 ) associated with at least one eye of a first user (e.g., user 1) is received at a first compute device (e.g., user 1 compute device  130 ) and from a second compute device (server compute device  100 ). At  802 , a determination is made, in response to receiving the signal representing the eye data, that the eye data is sufficient to perform gaze direction correction for the first user. In some implementations,  802  happens automatically (e.g., without requiring human intervention) in response to completing  801 . At  803 , a signal indicating that the eye data is sufficient to perform the gaze direction correction is sent to the second compute device. In some implementations,  803  happens automatically (e.g., without requiring human intervention) in response to completing  802 . 
     At  804 , a signal representing a first video frame (e.g., included in video frames without gaze correction  108 ) of the first user is received from the second compute device. At  805 , a gaze direction of the first user in the first video frame is estimated using the eye data. In some implementations,  805  happens automatically (e.g., without requiring human intervention) in response to completing  804 . 
     At  806 , a field of view of a first virtual representation of the first user in a virtual environment is determined. The first virtual representation is (1) based on an appearance of the first user and (2) controllable by the first user. For example, the first virtual representation can include a video plane of the first user. At  807 , the gaze direction of the first user in the first video frame and the field of view of the first virtual representation is compared to predict a target gaze direction for the first user. In some implementations,  807  happens automatically (e.g., without requiring human intervention) in response to completing  806 . 
     At  808 , representations of the first video frame, the gaze direction of the first user, the target gaze direction, and a normalizing factor are input into a processing pipeline (e.g., processing pipeline  110 ) to generate a second video frame (e.g., included in video frames with gaze correction  112 ). A gaze direction of the first virtual representation in the second video frame is different from the gaze direction of the first user in the first video frame. In some implementations,  808  happens automatically (e.g., without requiring human intervention) in response to completing  807 . 
     At  809 , a modified video frame that represents the first virtual representation from a perspective of a second virtual representation in the virtual environment is generated using the second video frame. In some implementations,  809  happens automatically (e.g., without requiring human intervention) in response to completing  808 . 
     At  810 , the modified video frame is caused to be displayed in the virtual environment, at a third compute device (e.g., user 2 compute device  140 ), and to a second user (e.g., user 2) associated with the second virtual representation. Causing display can include sending an electronic signal to the third compute device, the third compute device configured to display the modified video fame in the virtual environment (e.g., a video plane in the virtual environment) in response to receiving the electronic signal. In some implementations,  810  happens automatically (e.g., without requiring human intervention) in response to completing  809   
     In some implementations of method  800 , the second compute device is configured to (1) display (e.g., via display  138 ) an object for the first user to view, and (2) capture at least one of an image or a video that includes the at least one eye of the first user, the eye data based on the at least one of the image or the video. For example, the eye data can indicate how the at least one eye looked when the object was at a particular location when displayed. 
     In some implementations of method  800 , the second compute device is configured to determine a size of at least one display of the second compute device, the eye data further based on the size of the at least one display. In some implementations, the size of the display can be used to determine the normalizing factor. 
     In some implementations of method  800 , the comparing the gaze direction and the field of view to predict the target gaze direction for the first user includes determining that the gaze direction and the field of view at least partially overlap. In such a case, a gaze direction of the first virtual representation in the modified video frame is in a direction of the second virtual representation in the modified video frame (e.g., to indicate the making of eye contact). In some implementations, the comparing the gaze direction and the field of view to predict the target gaze direction for the first user includes determining that the gaze direction and the field of view do not at least partially overlap. In such a case, a gaze direction of the first virtual representation in the modified video frame is not in a direction of the second virtual representation in the modified video frame. In other implementations of method  800 , a gaze direction is modified even if there is no overlap with a field of view of a virtual representation of another user. In some such cases, no comparison of the gaze direction and the field of view is performed. For example, a user may be looking at an object (e.g., the palm tree shown in  FIG.  26   ), and a gaze direction of the first virtual representation (of that user) in the modified video frame can be in a direction of the palm tree. 
     In some implementations of method  800 , the normalizing factor is determined based on (1) a field of view range of the first user relative to at least one display (e.g., one, two, three) of the second compute device and (2) a field of view range of the field of view of the first virtual representation. The field of view range of the first user relative to the at least one display is determined based on (i) a distance between the first user and the at least one display and (ii) a size of the at least one display. 
     Some implementations of method  800  further comprise receiving, prior to receiving the signal representing the first video frame of the first user, a plurality of images of the first user, each image from the plurality of images being an image of the first user taken at an associated angle from a plurality of different angles. Method  800  can further comprise determining a location of the first virtual representation during the determining of the field of view of the first virtual representation. Method  800  can further comprise determining a location of the second virtual representation during the determining of the field of view of the first virtual representation. Method  800  can further comprise determining a field of view of the second virtual representation during the determining of the field of view of the first virtual representation, where the modified video frame is generated based on representations of at least one image from the plurality of images, the field of view of the first virtual representation, the location of the second virtual representation, the location of the second virtual representation, and the field of view of the second virtual representation. 
     In some implementations of method  800 , the determining that the eye data is sufficient to perform gaze direction correction for the first user includes: causing (1) the eye data and (2) database data that includes gaze direction perception models and experimental results, to be input into at least one machine learning model to generate an output; and determining that the output indicates that the eye data is sufficient to perform gaze direction correction for the first user. 
     In some implementations of method  800 , the eye data associated with the at least one eye of the first user is a first eye data, the normalizing factor is a first normalizing factor, the modified video frame is a first modified video frame, and the method  800  further comprises receiving, from the third compute device, a signal representing second eye data associated with at least one eye of the second user. The method  800  further comprises determining that the second eye data is sufficient to perform the gaze direction correction for the second user. The method  800  further comprises sending, to the third compute device, a signal indicating that the second eye data is sufficient to perform the gaze direction correction. The method  800  further comprises receiving, from the third compute device, a signal representing a third video frame of the second user. The method  800  further comprises predicting, using the second eye data, a gaze direction of the second user in the third video frame. The method  800  further comprises determining a field of view of the second virtual representation. The method  800  further comprises comparing the gaze direction of the second user and the field of view of the second virtual representation, to predict a target gaze direction for the second user. The method  800  further comprises inputting the third video frame, the gaze direction of the second user, the target gaze direction, and a second normalizing factor into the processing pipeline to generate a fourth video frame, a gaze direction of the second virtual representation in the fourth video frame being different from the gaze direction of the second user in the third video frame. The method  800  further comprises generating, using the fourth video frame, a second modified video frame that represents the second virtual representation from the perspective of the first virtual representation. The method  800  further comprises causing the second modified video frame to be displayed in the virtual environment, at the second device, and to the first user. 
     In some implementations of method  800 , the modified video frame is a first modified video frame, and method  800  further comprises generating, using the second video frame, a second modified video frame that represents the first virtual representation from a perspective of a third virtual representation in the virtual environment different from the second virtual representation. Method  800  can further comprise causing the second modified video frame to be displayed in the virtual environment, at a fourth compute device, and to a third user associated with the third virtual representation. 
     In some implementations of method  800 , the first compute device is remote from the second compute device and the third compute device, and the second compute device is remote from the first compute device and the third compute device. 
       FIGS.  19 A- 19 B  show a flowchart of a method  900  for eye gaze adjustment, according to an embodiment. In some implementations, method  900  can be performed by a processor (e.g., processor  102 ). 
     At  901 , a signal representing a first video frame (e.g., included in video frames without gaze correction  108 ) of a first user (e.g., user 1) captured at a first time is received at a first compute device (e.g., server compute device  100 ) and from a second compute device. (user 2 compute device  140 ). At  902 , a first gaze direction of the first user in the first video frame is estimated. In some implementations,  902  happens automatically (e.g., without requiring human intervention) in response to completing  901 . 
     At  903 , a first field of view of a first virtual representation of the first user in a virtual environment is determined. The first virtual representation is based on an appearance of the first user. The first field of view includes a second virtual representation (e.g., of a second user or of an object or other feature) included in the virtual environment and does not include a third virtual representation of a third user included in the virtual environment. In some implementations, the virtual environment is an emulation of a virtual three-dimensional space (e.g., classroom, meeting room, stadium, etc.). In some implementations,  903  happens automatically (e.g., without requiring human intervention) in response to completing  902 . 
     At  904 , a determination is optionally made that the first gaze direction at least partially overlaps with the first field of view. In some implementations,  904  happens automatically (e.g., without requiring human intervention) in response to completing  903 . At  905 , optionally in response to determining that the first gaze direction at least partially overlaps with the first field of view, a second video frame (e.g., included in video frames with gaze correction  112  or modified video frames  114 ) that shows the first virtual representation looking at the second virtual representation and not looking at the third virtual representation is generated. In some implementations,  905  happens automatically (e.g., without requiring human intervention) in response to completing  904 . 
     At  906 , at a second time subsequent to the first time, the second video frame is sent to a third compute device (e.g., user 2 compute device  140 ) to cause the third compute device to display the second video frame within the virtual environment. In some implementations,  906  happens automatically (e.g., without requiring human intervention) in response to completing  905 . 
     At  907 , a signal representing a third video frame of the first user captured at a third time is received at the first compute device and from the second compute device. At  908 , a second gaze direction of the first user in the second video frame is estimated. In some implementations,  908  happens automatically (e.g., without requiring human intervention) in response to completing  907 . At  909 , a second field of view of a first virtual representation in the virtual environment is determined. The second field of view includes the third virtual representation and not the second virtual representation. In some implementations,  909  happens automatically (e.g., without requiring human intervention) in response to completing  907 . 
     At  910 , a determination is optionally made that the second gaze direction at least partially overlaps with the second field of view. In some implementations,  910  happens automatically (e.g., without requiring human intervention) in response to completing  909 . At  911 , optionally in response to determining that the second gaze direction at least partially overlaps with the second field of view, a fourth video frame that shows the first virtual representation looking at the third virtual representation and not the second virtual representation is generated. In some implementations,  911  happens automatically (e.g., without requiring human intervention) in response to completing  910 . At  912 , at a fourth time subsequent to the third time, the fourth video frame is sent to the third compute device to cause the third compute device to display the fourth video frame within the virtual environment. 
     Some implementations of method  900  also includes receiving, from the second compute device, a signal representing a fifth video frame of the first user at a fifth time. A third gaze direction of the first user in the fifth video frame is predicted. A third field of view of the first virtual representation in the virtual environment is determined, the third field of view including a virtual object that is not a virtual representation of a user. A sixth video frame that shows the first virtual representation looking at the virtual object is generated. At a sixth time after the fifth time, the sixth video frame is sent to the third compute device to cause the third compute device to display the sixth video frame within the virtual environment. 
     Some implementations of method  900  further include generating, optionally in response to determining that the first gaze direction overlaps with the first field of view, a fifth video frame that shows the first virtual representation looking at the second virtual representation. At the first time, the fifth video frame is sent to the second compute device to cause the second compute device to display the fifth video frame. Optionally in response to determining that the second gaze direction at least partially overlaps with the second field of view, a sixth video frame that shows the first virtual representation looking at the third virtual representation is generated. At the second time, the sixth video frame is sent to the second compute device to cause the second compute device to display the sixth video frame. 
     Some implementations of method  900  further include receiving a first set of eye data captured by the second compute device while eyes of the first user viewed an object on a display of the second compute device while the object was at a first location. A determination is made that the first set of eye data is not sufficient to perform gaze direction correction for the first virtual representation. A signal is sent to the second compute device indicating that the first set of eye data is not sufficient to perform gaze direction correction for the first virtual representation. A second set of eye data captured by the second compute device while eyes of the first user viewed the object on the display of the second compute device and while the object was at a second location different from the first location is received. A determination is made that the first set of eye data and the second set of eye data are collectively sufficient to perform gaze direction correction for the first virtual representation. A signal is sent to the second compute device indicating that the first set of eye data and the set of eye data are sufficient to perform gaze direction correction for the first virtual representation. 
       FIG.  30    shows a flowchart of a method  1000  for eye gaze adjustment, according to an embodiment. In some implementations, method  1000  can be performed by a processor (e.g., processor  102 ). 
     At  1001 , a video stream (e.g., video frames without gaze correction  108 ) of a user (e.g., user 1) is received, each video frame from the video stream including a depiction of a gaze of the user. At  1002 , for each video frame from the video stream, an estimated gaze direction of the gaze of the user in that video frame is determined substantially in real time as that video frame is received (e.g., in substantially real time). At  1003 , for each video frame from the video stream, a field of view for a virtual representation associated with the user in a virtual environment is determined. In some implementations,  1003  happens automatically (e.g., without requiring human intervention) in response to completing  1002 . 
     At  1004 , for each video frame from the video stream, the field of view for the virtual representation associated with the user is optionally compared to the estimated gaze direction of the user to determine whether the field of view for the virtual representation associated with the user at least partially overlaps with the estimated gaze direction of the user. In some implementations,  1004  happens automatically (e.g., without requiring human intervention) in response to completing  1003 . 
     At  1005 , for each video frame from the video stream, an updated video frame (e.g., included in video frames with gaze correction  112  and/or modified video frames  114 ) including a modified gaze direction of the user different from the gaze direction of the user is generated, optionally based on the comparison of the field of view for the virtual representation associated with the user to the estimated gaze direction of the user. The modified gaze direction can be in a direction toward another person, object, or other feature within the field of view for the virtual representation associated with the user. In some implementations, the updated video frame is generated using a generative adversarial network (GAN). In some implementations,  1005  happens automatically (e.g., without requiring human intervention) in response to completing  1004 . 
     At  1006 , for each video frame from the video stream, the updated video frame is caused to be displayed. In some implementations, causing display can include sending an electronic signal representing the updated video frame to a compute device (e.g., user 2 compute device  140 ) configured to display the updated video frame in response to receiving the electronic signal. In some implementations,  1006  happens automatically (e.g., without requiring human intervention) in response to completing  1005 . 
     Some implementations of method  1000  further include receiving a representation of eye data of the user, the representation generated using at least one of (1) a plurality of images of the user or (2) a video of the user, the determining of the estimated gaze direction of the user based on the eye data. 
     In some implementations of method  1000 , the video stream is a first video stream, the user is a first user, the virtual representation is a first virtual representation associated with the first user, and method  1000  further includes receiving a second video stream of a second user, each video frame from the second video stream including a depiction of a gaze of the second user. Method  1000  further includes determining, for each video frame from the second video stream and substantially in real time as that video frame is received, an estimated gaze direction of the gaze of the second user in that video frame. Method  1000  further includes determining, for each video frame from the second video stream, a field of view for a second virtual representation associated with the second user. Method  1000  further includes generating, for each video frame from the second video stream and based on the field of view for the second virtual representation and the estimated gaze direction of the second user, an updated video frame including a modified gaze direction of the second user different from the gaze direction of the second user. Method  100  further includes, for each video frame from the second video stream, causing the updated video frame to be displayed. 
     All combinations of the foregoing concepts and additional concepts discussed herewithin (provided such concepts are not mutually inconsistent) are contemplated as being part of the subject matter disclosed herein. The terminology explicitly employed herein that also may appear in any disclosure incorporated by reference should be accorded a meaning most consistent with the particular concepts disclosed herein. 
     The drawings are primarily for illustrative purposes, and are not intended to limit the scope of the subject matter described herein. The drawings are not necessarily to scale; in some instances, various aspects of the subject matter disclosed herein may be shown exaggerated or enlarged in the drawings to facilitate an understanding of different features. In the drawings, like reference characters generally refer to like features (e.g., functionally similar and/or structurally similar elements). 
     The entirety of this application (including the Cover Page, Title, Headings, Background, Summary, Brief Description of the Drawings, Detailed Description, Embodiments, Abstract, Figures, Appendices, and otherwise) shows, by way of illustration, various embodiments in which the embodiments may be practiced. The advantages and features of the application are of a representative sample of embodiments only, and are not exhaustive and/or exclusive. Rather, they are presented to assist in understanding and teach the embodiments, and are not representative of all embodiments. As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have been presented for a specific portion of the innovations or that further undescribed alternate embodiments may be available for a portion is not to be considered to exclude such alternate embodiments from the scope of the disclosure. It will be appreciated that many of those undescribed embodiments incorporate the same principles of the innovations and others are equivalent. Thus, it is to be understood that other embodiments may be utilized and functional, logical, operational, organizational, structural and/or topological modifications may be made without departing from the scope and/or spirit of the disclosure. As such, all examples and/or embodiments are deemed to be non-limiting throughout this disclosure. 
     Also, no inference should be drawn regarding those embodiments discussed herein relative to those not discussed herein other than it is as such for purposes of reducing space and repetition. For instance, it is to be understood that the logical and/or topological structure of any combination of any program components (a component collection), other components and/or any present feature sets as described in the figures and/or throughout are not limited to a fixed operating order and/or arrangement, but rather, any disclosed order is exemplary and all equivalents, regardless of order, are contemplated by the disclosure. 
     The term “automatically” is used herein to modify actions that occur without direct input or prompting by an external source such as a user. Automatically occurring actions can occur periodically, sporadically, in response to a detected event (e.g., a user logging in), or according to a predetermined schedule. 
     The term “determining” encompasses a wide variety of actions and, therefore, “determining” can include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, “determining” can include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, “determining” can include resolving, selecting, choosing, establishing and the like. 
     The phrase “based on” does not mean “based only on,” unless expressly specified otherwise. In other words, the phrase “based on” describes both “based only on” and “based at least on.” 
     The term “processor” should be interpreted broadly to encompass a general purpose processor, a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a graphics processing unit (GPU), a controller, a microcontroller, a state machine and/or the like so forth. Under some circumstances, a “processor” may refer to an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable gate array (FPGA), etc. The term “processor” may refer to a combination of processing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core or any other such configuration. 
     The term “memory” should be interpreted broadly to encompass any electronic component capable of storing electronic information. The term memory may refer to various types of processor-readable media such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), programmable read-only memory (PROM), erasable programmable read only memory (EPROM), electrically erasable PROM (EEPROM), flash memory, magnetic or optical data storage, registers, etc. Memory is said to be in electronic communication with a processor if the processor can read information from and/or write information to the memory. Memory that is integral to a processor is in electronic communication with the processor. 
     The terms “instructions” and “code” should be interpreted broadly to include any type of computer-readable statement(s). For example, the terms “instructions” and “code” may refer to one or more programs, routines, sub-routines, functions, procedures, etc. “Instructions” and “code” may comprise a single computer-readable statement or many computer-readable statements. 
     Some embodiments described herein relate to a computer storage product with a non-transitory computer-readable medium (also can be referred to as a non-transitory processor-readable medium) having instructions or computer code thereon for performing various computer-implemented operations. The computer-readable medium (or processor-readable medium) is non-transitory in the sense that it does not include transitory propagating signals per se (e.g., a propagating electromagnetic wave carrying information on a transmission medium such as space or a cable). The media and computer code (also can be referred to as code) may be those designed and constructed for the specific purpose or purposes. Examples of non-transitory computer-readable media include, but are not limited to, magnetic storage media such as hard disks, floppy disks, and magnetic tape; optical storage media such as Compact Disc/Digital Video Discs (CD/DVDs), Compact Disc-Read Only Memories (CD-ROMs), and holographic devices; magneto-optical storage media such as optical disks; carrier wave signal processing modules; and hardware devices that are specially configured to store and execute program code, such as Application-Specific Integrated Circuits (ASICs), Programmable Logic Devices (PLDs), Read-Only Memory (ROM) and Random-Access Memory (RAM) devices. Other embodiments described herein relate to a computer program product, which can include, for example, the instructions and/or computer code discussed herein. 
     Some embodiments and/or methods described herein can be performed by software (executed on hardware), hardware, or a combination thereof. Hardware modules may include, for example, a general-purpose processor, a field programmable gate array (FPGA), and/or an application specific integrated circuit (ASIC). Software modules (executed on hardware) can be expressed in a variety of software languages (e.g., computer code), including C, C++, Java™ Ruby, Visual Basic™, and/or other object-oriented, procedural, or other programming language and development tools. Examples of computer code include, but are not limited to, micro-code or micro-instructions, machine instructions, such as produced by a compiler, code used to produce a web service, and files containing higher-level instructions that are executed by a computer using an interpreter. For example, embodiments may be implemented using imperative programming languages (e.g., C, Fortran, etc.), functional programming languages (Haskell, Erlang, etc.), logical programming languages (e.g., Prolog), object-oriented programming languages (e.g., Java, C++, etc.) or other suitable programming languages and/or development tools. Additional examples of computer code include, but are not limited to, control signals, encrypted code, and compressed code. 
     Various concepts may be embodied as one or more methods, of which at least one example has been provided. The acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments. Put differently, it is to be understood that such features may not necessarily be limited to a particular order of execution, but rather, any number of threads, processes, services, servers, and/or the like that may execute serially, asynchronously, concurrently, in parallel, simultaneously, synchronously, and/or the like in a manner consistent with the disclosure. As such, some of these features may be mutually contradictory, in that they cannot be simultaneously present in a single embodiment. Similarly, some features are applicable to one aspect of the innovations, and inapplicable to others. 
     In addition, the disclosure may include other innovations not presently described. Applicant reserves all rights in such innovations, including the right to embodiment such innovations, file additional applications, continuations, continuations-in-part, divisionals, and/or the like thereof. As such, it should be understood that advantages, embodiments, examples, functional, features, logical, operational, organizational, structural, topological, and/or other aspects of the disclosure are not to be considered limitations on the disclosure as defined by the embodiments or limitations on equivalents to the embodiments. Depending on the particular desires and/or characteristics of an individual and/or enterprise user, database configuration and/or relational model, data type, data transmission and/or network framework, syntax structure, and/or the like, various embodiments of the technology disclosed herein may be implemented in a manner that enables a great deal of flexibility and customization as described herein. 
     All definitions, as defined and used herein, should be understood to control over dictionary definitions, definitions in documents incorporated by reference, and/or ordinary meanings of the defined terms. 
     As used herein, in particular embodiments, the terms “about” or “approximately” when preceding a numerical value indicates the value plus or minus a range of 10%. Where a range of values is provided, it is understood that each intervening value, to the tenth of the unit of the lower limit unless the context clearly dictates otherwise, between the upper and lower limit of that range and any other stated or intervening value in that stated range is encompassed within the disclosure. That the upper and lower limits of these smaller ranges can independently be included in the smaller ranges is also encompassed within the disclosure, subject to any specifically excluded limit in the stated range. Where the stated range includes one or both of the limits, ranges excluding either or both of those included limits are also included in the disclosure. 
     The indefinite articles “a” and “an,” as used herein in the specification and in the embodiments, unless clearly indicated to the contrary, should be understood to mean “at least one.” 
     The phrase “and/or,” as used herein in the specification and in the embodiments, should be understood to mean “either or both” of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with “and/or” should be construed in the same fashion, i.e., “one or more” of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the “and/or” clause, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, a reference to “A and/or B”, when used in conjunction with open-ended language such as “comprising” can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc. 
     As used herein in the specification and in the embodiments, “or” should be understood to have the same meaning as “and/or” as defined above. For example, when separating items in a list, “or” or “and/or” shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as “only one of” or “exactly one of,” or, when used in the embodiments, “consisting of,” will refer to the inclusion of exactly one element of a number or list of elements. In general, the term “or” as used herein shall only be interpreted as indicating exclusive alternatives (i.e. “one or the other but not both”) when preceded by terms of exclusivity, such as “either,” “one of,” “only one of,” or “exactly one of.” “Consisting essentially of,” when used in the embodiments, shall have its ordinary meaning as used in the field of patent law. 
     As used herein in the specification and in the embodiments, the phrase “at least one,” in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase “at least one” refers, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, “at least one of A and B” (or, equivalently, “at least one of A or B,” or, equivalently “at least one of A and/or B”) can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc. 
     In the embodiments, as well as in the specification above, all transitional phrases such as “comprising,” “including,” “carrying,” “having,” “containing,” “involving,” “holding,” “composed of,” and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases “consisting of” and “consisting essentially of” shall be closed or semi-closed transitional phrases, respectively, as set forth in the United States Patent Office Manual of Patent Examining Procedures, Section 2111.03.