Patent Description:
Some computers configured to render computer graphic objects can render the objects at a specified view given multiple, existing views. For example, given several depth images and color images captured from cameras about a scene that includes such computer graphic objects, a goal may be to synthesize a new view of the scene from a different viewpoint. The scene can be either real, in which case the views are captured using physical color and depth sensors, or synthetic, in which case the views are captured using rendering algorithms such as rasterization or ray tracing. For a real scene, there exist many depth-sensing technologies, such as time-of-flight sensors, structured-light-based sensors, and stereo or multi-view stereo algorithms. Such technologies may involve visible or infrared sensors with passive or active illumination patterns, where the patterns may be temporally varying. Additional technological background is disclosed in <CIT>, <CIT> and in <NPL>.

The proposed solution is defined by independent claims <NUM>, <NUM>, and <NUM>. Possible embodiments are in particular defined by the dependent claims.

The context described herein is computer graphics rendering from existing views. Given several depth images and color images captured from cameras about a scene, it is desired to synthesize a new view of the scene from a different viewpoint. The scene can be either physical (in which case the views are captured using physical color and depth sensors) or synthetic (in which case the views are captured using rendering algorithms such as rasterization or ray tracing).

For a physical scene, there exist many depth-sensing technologies, such as time-of-flight sensors, structured-light-based sensors, and stereo (or multi-view stereo) algorithms. These technologies may involve visible or infrared sensors, optionally with passive or active illumination patterns, where the patterns may be temporally varying.

The general problem is to merge the information from the plurality of views into a consistent representation of the scene, so that the reconstructed scene can be rendered with correct inter-surface occlusion and parallax from the specified viewpoint. In a physical scene, both the depth and color sensors create noisy data. Additionally, the acquired depth images can have large errors, particularly near depth discontinuities such as silhouettes. Therefore, it is desirable to adaptively vary the importance given to the different views when merging them, e.g. giving less preference to views that see a scene surface obliquely if it is visible in a more head-on direction from another view. The process of merging the views into a consistent geometric representation is referred to as "geometric fusion.

Conventional approaches to solving this general problem include defining a truncated signed-distance field (TSDF) from each given depth image in each voxel of a volume (three-dimensional) grid, accumulating the TSDFs for each voxel of the volume grid, and approximating the representation of the scene using the zeroes of the TSDF over all voxels.

A technical problem involved in the above-described conventional approaches to solving the technical problem use an enormous amount of memory due to the volume grid. Further, the conventional approaches encounter problems with noisy depth data and near depth discontinuities such as silhouettes.

In contrast to the conventional approaches to solving the above-described technical problem, a technical solution to the above-described technical problem includes generating signed distance values (SDVs) along a ray from a specified viewpoint in terms of projected distances along that ray from given depth images. For each pixel in an image from the perspective of the specified viewpoint, a ray is traced into a three-dimensional scene represented by the image. An iterative step is performed along the ray, obtaining in each iteration a three-dimensional world-space point p. For each depth view Dj associated with a given depth image, the point p is projected into the depth image, a depth value is sampled from the depth image, and the sampled depth value is subtracted from the z coordinate (depth) of p with respect to the depth view camera. The result is the signed distance sj as measured from depth view Dj. If the absolute value of the signed distance sj is greater than some truncation threshold parameter, the signed distance sj is replaced by a special undefined value. The defined signed-distance values are aggregated to obtain an overall signed distance s. Finally, the roots or zero set (isosurface) of the signed distance field is determined.

A technical advantage of the above-described technical solution is that the technical solution does not require accumulating or aggregating information from the multiple views into a volumetric representation stored in memory. Therefore, a computer operating according to the technical solution is able to operate with less memory space and bandwidth. Further, the above-described technical solution is robust in the presence of noisy depth data and in the vicinity of depth discontinuities.

<FIG> is a diagram that illustrates an example electronic environment <NUM> in which the above-described improved techniques may be implemented. As shown, in <FIG>, the example electronic environment <NUM> includes a computer <NUM>.

The computer <NUM> is configured to render images of objects. The computer <NUM> includes a network interface <NUM>, one or more processing units <NUM>, and memory <NUM>. The network interface <NUM> includes, for example, Ethernet adaptors, and the like, for converting electronic and/or optical signals received from a network to electronic form for use by the computer <NUM>. The set of processing units <NUM> include one or more processing chips and/or assemblies. The memory <NUM> includes both volatile memory (e.g., RAM) and non-volatile memory, such as one or more ROMs, disk drives, solid state drives, and the like. The set of processing units <NUM> and the memory <NUM> together form control circuitry, which is configured and arranged to carry out various methods and functions as described herein.

In some embodiments, one or more of the components of the computer <NUM> can be, or can include processors (e.g., processing units <NUM>) configured to process instructions stored in the memory <NUM>. Examples of such instructions as depicted in <FIG> include a depth image manager <NUM>, a viewpoint manager <NUM>, a ray casting manager <NUM>, a SDV manager <NUM>, an aggregation manager <NUM>, a root-finding manager <NUM>, and a depth image generation manager <NUM>. Further, as illustrated in <FIG>, the memory <NUM> is configured to store various data, which is described with respect to the respective managers that use such data.

The depth image manager <NUM> is configured to receive depth image data <NUM>. The depth image manager <NUM> receives the depth image data <NUM>, in some implementations, over a network via the network interface <NUM>. In some implementations, the depth image manager <NUM> receives the depth image data <NUM> from a local storage device, e.g., a hard drive, a flash drive, a storage disk, and so on.

The depth image data <NUM> represents a plurality of depth images <NUM>(<NUM>). <NUM>(N) of an object. An example of a depth image may be seen in <FIG>, e.g., depth image <NUM>. Each depth image, e.g., depth image <NUM>, represents a map of distances - or depths - along a line from a camera to pixels on the surface of the object. The camera is oriented with respect to the object at an angle indicated by a viewpoint from which the depth image is captured. In the examples described herein, there are two given depth images of an object to be fused into a new depth image captured from a specified viewpoint. Nevertheless, in some implementations, there may be more than two depth images to be fused.

The viewpoint manager <NUM> is configured to receive viewpoint data <NUM>. In some implementations, the viewpoint manager <NUM> receives the viewpoint data <NUM> in response to user input or during runtime of an application. In some implementations, the viewpoint manager <NUM> receives the viewpoint data <NUM> over a network via network interface <NUM>. In some implementations, the viewpoint manager <NUM> receives the viewpoint data <NUM> from a local storage device, e.g., a hard drive, a flash drive, a storage disk, and so on.

The viewpoint data <NUM> represents an orientation of a target viewpoint from which new depth image data is generated. In some implementations, the viewpoint data <NUM> includes a camera matrix. In some implementations, the camera matrix is a <NUM> X <NUM> matrix representing a mapping from three-dimensional camera coordinates to two-dimensional image coordinates.

The ray casting manager <NUM> is configured to generate ray data <NUM> based on a three-dimensional scene represented by an image as seen from the perspective of the target viewpoint. For example, the ray casting manager <NUM> is configured to cast a respective ray for each pixel of the image. In some implementations, the ray casting manager <NUM> casts rays using a parallel process, i.e., using multiple threads and/or processors simultaneously. In such implementations, operations on each ray that has been cast are performed in parallel similarly. In some implementations, the ray casting manager <NUM> casts the rays in parallel across the pixels of the image using CUDA warps. In some implementations, the ray casting manager <NUM> casts the rays in parallel across the pixels of the image using an OpenGL fragment shader.

The ray data <NUM> represents rays used to form an image of a three-dimensional scene including the object. Each ray represented by the ray data <NUM> is associated with a pixel of the image. The rays represented by the ray data <NUM> emanate from a viewpoint origin (e.g., a camera) to a pixel of the image.

The SDV manager <NUM> is configured to generate SDV data <NUM> by computing SDVs along each ray at various positions along that ray for each of the depth images. To accomplish this, in some implementations, the SDV manager <NUM> is configured to step along the ray iteratively until a stopping condition is satisfied. In some implementations, the stopping condition is that the location of the next step crosses a surface of the object associated with a depth image. In some implementations, the step size along the ray is proportional to an absolute value of a distance between a current location along the ray of a step and a surface of the object. In this way, the steps become finer as the locations approach the object surface associated with the viewpoint a depth image. In some implementations, if the absolute value of a SDV is greater than some truncation threshold value, then that SDV is replaced by a specified value. In some implementations, the specified value is undefined.

The SDV data <NUM> represents SDVs (signed distance values) along each ray for each depth image. As a convention, the sign of the SDVs herein is positive for positions along a ray between the viewpoint origin and the surface associated with a viewpoint and negative for positions along a ray beyond the surface.

A point along the ray is expressed as p = o + αv, where o denotes the target viewpoint, v is the unit view direction of the ray, and the scalar α encodes parametric location along the ray. Given a ray point p, for each depth image j, we transform p into the camera space of the depth image, compute the perspective projection to determine the pixel coordinates of point p in the camera image, and sample the stored depth value. In some implementations, a weight value is also stored. The depth value is subtracted from the z coordinate of the camera-space point to obtain a signed-distance value sj. Note, as mentioned above, that sj is positive if the point p lies in front of the frontmost surface visible from the depth camera, or negative otherwise.

The aggregation manager <NUM> is configured to perform an aggregation operation on the SDVs over the depth images at each location along the ray to produce aggregated SDV data <NUM>. In some implementations, the aggregation operation is a summing of the SDVs across the depth images. In some implementations, the summing is a weighted sum with a respective weight being associated with each depth image.

The aggregated SDV data <NUM> represents the aggregated SDV along the ray. The weight data <NUM> represents the weights used to produce the aggregated SDV data <NUM>.

The root-finding manager <NUM> is configured to perform a root-finding operation to produce a root of the aggregated SDV along each of the rays. In some implementations, the root-finding operation includes determining a location at which the aggregated SDV changes sign, e.g., from positive to negative, and performing a binary search operation to locate the root (e.g., where the aggregated SDV along the ray is zero or some other constant).

The root location data <NUM> represents the roots of the aggregated SDV along each ray as determined via the root-finding operation described above.

The depth image generation manager <NUM> is configured to generate a depth image of the object captured from the target viewpoint represented by the viewpoint data <NUM>. The depth image generation manager <NUM>, along these lines, generates an object surface based on the roots represented by the root location data <NUM>. In some implementation, the depth image generation manager <NUM> performs an interpolation operation to produce a continuous surface from the discrete roots.

The perspective depth image data <NUM> represents the output surface of the object from the target viewpoint.

<FIG> is a flow chart depicting an example method <NUM> of rendering images of objects. The method <NUM> may be performed by software constructs described in connection with <FIG>, which reside in memory <NUM> of the user device computer <NUM> and are run by the set of processing units <NUM>.

At <NUM>, the depth image manager <NUM> receives depth image data <NUM> representing a plurality of depth images <NUM>(<NUM>. N) of an object, each of the plurality of depth images being a depth image of the object captured from a respective viewpoint, the depth image representing a distance between a specified camera and an image of the object.

At <NUM>, the viewpoint manager <NUM> receives viewpoint data <NUM> representing a target viewpoint of an image of the object, the target viewpoint being different from the viewpoint from which each of the plurality of depth images are captured, the image including a plurality of pixels.

At <NUM>, the ray casting manager <NUM> generates ray data <NUM> representing a plurality of rays toward the image, each of the plurality of rays corresponding to a respective pixel of the plurality of pixels of the image.

At <NUM>, for each of the plurality of rays, the SDV manager <NUM> generates SDV data <NUM> representing a plurality of SDVs at each of a plurality of locations along that ray, each of the plurality of SDVs at each of the plurality of locations along that ray corresponding to a respective depth image of the plurality of depth images.

At <NUM>, for each of the plurality of rays, the aggregation manager <NUM> performs an aggregation operation on the SDV data at each of the plurality of locations along that ray to produce aggregated SDV data <NUM> along that ray representing an aggregated SDV at each of the plurality of locations along the ray. In some implementations, the aggregation operation includes generating a weighted sum of the plurality of SDVs at each of the plurality of locations along that ray using the weight data <NUM>.

At <NUM>, for each of the plurality of rays, the root-finding manager <NUM> performs a root-finding operation to produce a location (i.e., from location data <NUM>) along that ray where the aggregated SDV is equal to a specified value.

At <NUM>, the depth image generation manager <NUM> generates a depth image of the object captured from the perspective of the target viewpoint based on the locations along the plurality of rays for which the respective aggregated SDV for that ray is equal to the specified value.

<FIG> is a diagram that illustrates an example geometry <NUM> for determining a point along a ray at which a target depth map is generated at the target viewpoint. As shown in <FIG>, two depth images <NUM> and <NUM> are captured from viewpoints defined by direction vectors <NUM> and <NUM> and cameras <NUM> and <NUM>, respectively. The depth images <NUM> and <NUM> are surfaces of an object as seen from the respective viewpoints defined by vectors <NUM> and <NUM>.

As shown in <FIG>, the geometry <NUM> further includes a target viewpoint <NUM> for which a geometric fused image, or surface of the object, is determined. Along these lines, a ray <NUM> is cast along a direction. The ray <NUM> corresponds to a pixel of an image of the object within a three-dimensional scene. For example, the object may take the form of a person having various features (e.g., a face, arms, a torso, legs) within a scene (e.g., with other objects at various depths and a background).

Along the ray <NUM> (one of several rays, each corresponding to a pixel of the image in the scene), there is an initial sampling position on the ray <NUM>(<NUM>). At this position and for each of the depth images <NUM> and <NUM>, the SDV associated with that depth image is computed. The SDVs associated with the depth images are aggregated. If the aggregated SDV is positive, then the computer <NUM> takes another step to a new location <NUM>(<NUM>) along the ray <NUM>.

As described above, a point p (e.g., <NUM>(<NUM>. N)) along the ray is expressed as p = o + αv, where o denotes the viewpoint, v is the unit view direction of the ray, and the scalar α encodes parametric location along the ray. Given a ray point p, for each depth image j (<NUM> or <NUM> in <FIG>), we transform p into the camera space of the depth image <NUM>/<NUM>, compute the perspective projection to determine the pixel coordinates of point p in the camera image, and sample the stored depth value. In some implementations, a weight value is also stored. The depth value is subtracted from the z coordinate of the camera-space point to obtain a SDV sj. Note, as mentioned above, that sj is positive if the point p lies in front of the frontmost surface visible from the depth camera, or negative otherwise.

In some implementations, the weight value used to aggregate the SDVs is based on an inner product of the direction of the ray <NUM> and the directions <NUM> and <NUM>. In some implementations, the weight value increases with the inner product so that surfaces seen fully in the target viewpoint <NUM> are given greater weight than those at oblique directions and not seen as fully. In some implementations, the weights may be decreased in the presence of occlusions in the scene. In some implementations, the weights are precomputed based on at least one of (i) the distance between the specified camera <NUM>, <NUM> for the viewpoint from which that depth image was captured and an image of the object (i.e., surfaces <NUM>, <NUM>), and (ii) a gradient of the distance along the direction of that viewpoint. The intent is that surfaces that are perpendicular to the view direction should be assigned greater weight than surfaces that are oblique, because the perpendicular surfaces are likely to be more geometrically accurate.

Accordingly, the process of determining the depth image from the target viewpoint <NUM> includes updating the value of the scalar α based on the aggregated SDV s at the current location along the ray <NUM>. As described above, in some implementations, the change in the value of the scalar α decreases with the distance between the location and a surface of a depth image. In some implementations, if the SDV s is large, the step size is accordingly large (and related to the truncation threshold value).

As shown in <FIG>, the aggregated SDVs along the ray <NUM> at the locations <NUM>(<NUM>). <NUM>(N-<NUM>) are positive because the points are in front of both surfaces <NUM> and <NUM>. In contrast, the point along the ray at the location <NUM>(N) is in between the surfaces <NUM> and <NUM>. At this location, the SDV may be positive or negative. If the SDV is positive, there is another step forward in between the surfaces. If the SDV is negative, however, as shown in <FIG>, then there is a sign change and there is a root between locations <NUM>(N-<NUM>) and <NUM>(N).

The computation of the SDVs at location <NUM>(N) along ray <NUM> is shown in some detail in <FIG>. The direction vectors <NUM> and <NUM> are normal to the respective surfaces <NUM> and <NUM>. Along these normals, the distances <NUM> and <NUM> between the location <NUM>(N) and the respective surfaces <NUM> and <NUM> are measured (e.g., computed, generated). The distances <NUM> and <NUM> then are the above-described perspective projection of the point at the location <NUM>(N) in the respective camera images <NUM> and <NUM>.

Once the interval between the locations <NUM>(N-<NUM>) and <NUM>(N) is determined to have a sign change, a finer root-finding operation is used to determine the location along the ray where the aggregated SDV is zero. As mentioned above, in some implementations the root-finding operation includes a binary search algorithm. In some implementations, the binary search includes a linear estimator.

In some implementations, there is a lower bound and upper bound precomputed for the value of the scalar α along the ray <NUM>. In such an implementation, these lower bounds are obtained by computing a forward map (rasterization) of the depth pixels from each depth image into a coarse-resolution framebuffer over the new view. In this rasterization pass, the lower bound is updated using an atomic-min update, and the upper bound is updated using an atomic-max update.

The rasterization step can be combined with the depth pre-processing stage that precomputes the weights for each depth view, and thus avoiding having to read the depth images twice during pre-processing.

<FIG> is a diagram that illustrates an example geometric fusion <NUM> of depth maps <NUM> and <NUM> to produce depth map <NUM>. Depth map <NUM> is a depth image of a seated person from a first oblique viewpoint; this could correspond to viewpoint <NUM> in <FIG>. Depth map <NUM> is a depth image of the seated person from a second oblique viewpoint; this could correspond to viewpoint <NUM> in <FIG>. The specified viewpoint for the fused depth image <NUM> is facing directly in front of the person and could correspond to viewpoint <NUM> in <FIG>.

In depth maps <NUM> and <NUM>, the depth values are shown in grayscale ranging from dark (indicating small depth values) to light (indicating large depth values). White color indicates background (essentially infinite depth). Black color indicates unknown or undefined depth.

The ray casting approach used to generate the depth image <NUM> uses far fewer resources than previous volumetric-based techniques and may be performed in real time. This is useful in applications such as teleconferencing.

In some implementations, the computer <NUM> also includes a color image manager that is configured to receive color image data representing a plurality of color images. Each of the plurality of color images is a color image of the object captured from a respective viewpoint. Accordingly, for each pixel of a target color image oriented at the target viewpoint, the color image manager then is configured to generate a depth value of the target depth image corresponding to that pixel, identify a point in world space corresponding to the depth value, perform a projection operation by projecting that point into a surface of that color image to produce a color of a plurality of colors of that pixel corresponding to that color image, and perform a blending operation on the plurality of colors of that pixel to produce a blended color of that pixel. In some implementations, the colors of that pixel are blended according to a respective weight corresponding to each of the plurality of color images. In some implementations, the weight corresponding to a color image is based on an inner product of a normal to the image at the pixel and an orientation of the color image. One possible application of the color image manager as described above is to synthesize a new color from a target viewpoint without saving the depth view from the target viewpoint.

In some implementations, the identified point may not be visible in a color view because it is not a frontmost surface in that view. In such implementations, as a preprocess, for each color view a depth image is computed by treating the color view as a target view for which to generate a target depth image from the input depth images. Then, given the point p and each color view, the depth of p is compared in the color view's camera frame (as given by the color view's camera parameters) with the depth of p in the precomputed depth image associated with the color camera. If the depth stored in the precomputed depth image is smaller than the depth in the color view's camera frame, it may be deduced that in the color view p p is occluded by another surface. In this case, the color value is stored in that particular color image. That is, a color blend weight of that color sample may be set to zero.

<FIG> illustrates an example of a generic computer device <NUM> and a generic mobile computer device <NUM>, which may be used with the techniques described here.

As shown in <FIG>, computing device <NUM> is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Computing device <NUM> is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smart phones, and other similar computing devices.

Thus, for example, expansion memory <NUM> may be provided as a security module for device <NUM>, and may be programmed with instructions that permit secure use of device <NUM>.

Returning to <FIG>, in some implementations, the memory <NUM> can be any type of memory such as a random-access memory, a disk drive memory, flash memory, and/or so forth. In some implementations, the memory <NUM> can be implemented as more than one memory component (e.g., more than one RAM component or disk drive memory) associated with the components of the compression computer <NUM>. In some implementations, the memory <NUM> can be a database memory. In some implementations, the memory <NUM> can be, or can include, a non-local memory. For example, the memory <NUM> can be, or can include, a memory shared by multiple devices (not shown). In some implementations, the memory <NUM> can be associated with a server device (not shown) within a network and configured to serve the components of the compression computer <NUM>.

The components (e.g., modules, processing units <NUM>) of the compression computer <NUM> can be configured to operate based on one or more platforms (e.g., one or more similar or different platforms) that can include one or more types of hardware, software, firmware, operating systems, runtime libraries, and/or so forth. In some implementations, the components of the compression computer <NUM> can be configured to operate within a cluster of devices (e.g., a server farm). In such an implementation, the functionality and processing of the components of the compression computer <NUM> can be distributed to several devices of the cluster of devices.

The components of the computer <NUM> can be, or can include, any type of hardware and/or software configured to process attributes. In some implementations, one or more portions of the components shown in the components of the computer <NUM> in <FIG> can be, or can include, a hardware-based module (e.g., a digital signal processor (DSP), a field programmable gate array (FPGA), a memory), a firmware module, and/or a software-based module (e.g., a module of computer code, a set of computer-readable instructions that can be executed at a computer). For example, in some implementations, one or more portions of the components of the computer <NUM> can be, or can include, a software module configured for execution by at least one processor (not shown). In some implementations, the functionality of the components can be included in different modules and/or different components than those shown in <FIG>.

Although not shown, in some implementations, the components of the computer <NUM> (or portions thereof) can be configured to operate within, for example, a data center (e.g., a cloud computing environment), a computer system, one or more server/host devices, and/or so forth. In some implementations, the components of the computer <NUM> (or portions thereof) can be configured to operate within a network. Thus, the components of the computer <NUM> (or portions thereof) can be configured to function within various types of network environments that can include one or more devices and/or one or more server devices. For example, a network can be, or can include, a local area network (LAN), a wide area network (WAN), and/or so forth. The network can be, or can include, a wireless network and/or wireless network implemented using, for example, gateway devices, bridges, switches, and/or so forth. The network can include one or more segments and/or can have portions based on various protocols such as Internet Protocol (IP) and/or a proprietary protocol. The network can include at least a portion of the Internet.

In some embodiments, one or more of the components of the computer <NUM> can be, or can include, processors configured to process instructions stored in a memory. For example, the depth image manager <NUM> (and/or a portion thereof), the viewpoint manager <NUM> (and/or a portion thereof), the ray casting manager <NUM> (and/or a portion thereof), the SDV manager <NUM> (and/or a portion thereof), the aggregation manager <NUM> (and/or a portion thereof), the root-finding manager <NUM> (and/or a portion thereof), and the depth image generation manager <NUM> (and/or a portion thereof) can be a combination of a processor and a memory configured to execute instructions related to a process to implement one or more functions.

It will be understood that when an element is referred to as being on, connected to, electrically connected to, coupled to, or electrically coupled to another element, it may be directly on, connected or coupled to the other element, or one or more intervening elements may be present. In contrast, when an element is referred to as being directly on, directly connected to or directly coupled to another element, there are no intervening elements present. Although the terms directly on, directly connected to, or directly coupled to may not be used throughout the detailed description, elements that are shown as being directly on, directly connected or directly coupled can be referred to as such. The claims of the application may be amended to recite exemplary relationships described in the specification or shown in the figures.

While certain features of the described implementations have been illustrated as described herein, many modifications, substitutions, changes and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the scope of the implementations. It should be understood that they have been presented by way of example only, not limitation, and various changes in form and details may be made. Any portion of the apparatus and/or methods described herein may be combined in any combination, except mutually exclusive combinations. The implementations described herein can include various combinations and/or sub-combinations of the functions, components and/or features of the different implementations described.

Claim 1:
A method, comprising:
receiving, by processing circuitry of a computer configured to render images of objects, depth image data (<NUM>) representing a plurality of depth images (<NUM>(<NUM>)... <NUM>(N); <NUM>, <NUM>) of an object, each of the plurality of depth images (<NUM>(<NUM>)... <NUM>(N); <NUM>, <NUM>) being a depth image of the object captured from a respective viewpoint, the depth image representing a map of distances between an image capture device and the object;
receiving viewpoint data (<NUM>) representing a target viewpoint (<NUM>) of an image of the object, the target viewpoint (<NUM>) being different from the respective viewpoint from which each of the plurality of depth images (<NUM>(<NUM>)... <NUM>(N)) are captured, the image including a plurality of pixels;
generating ray data (<NUM>) representing a plurality of rays toward the image, each of the plurality of rays corresponding to a respective pixel of the plurality of pixels of the image and the plurality of rays emanating from the target viewpoint (<NUM>) to the plurality of pixels of the image;
for each of the plurality of rays:
generating signed distance value, SDV, data (<NUM>) representing a plurality of SDVs at each of a plurality of locations along that ray (<NUM>), each of the plurality of SDVs at each of the plurality of locations along that ray (<NUM>) corresponding to a respective depth image (<NUM>, <NUM>) of the plurality of depth images (<NUM>(<NUM>)... <NUM>(N); <NUM>, <NUM>);
performing an aggregation operation on the SDV data at each of the plurality of locations along that ray (<NUM>) to produce aggregated SDV data (<NUM>) along that ray (<NUM>) representing an aggregated SDV at each of the plurality of locations along the ray (<NUM>); and
determining a location along that ray (<NUM>) where the aggregated SDV satisfies a specified condition by performing a root-finding operation on the aggregated SDV along the ray to produce a root location; and generating a target depth image of the object captured from the perspective of the target viewpoint (<NUM>) based on the locations along the plurality of rays (<NUM>) for which the respective aggregated SDV for that ray (<NUM>) satisfies the specified condition.