Patent Description:
Traditional electronic displays encode data as a two-dimensional (2D) matrix of pixels (x, y). This pixel data can be stored in various formats such as RGB, RGBA, BGR, and HSV. In contrast to the flat, 2D data representation of traditional electronic displays, light field displays provide a four-dimensional (4D) display of data. 4D light fields are generated using 4D plenoptic vectors that are composed of position (x, y) and angle (theta, phi), with a color value (e.g., RGB) for each permutation.

<CIT> describes that light-field data can be generated from image data that does not include light-field data, or from image data that includes sparse light-field data. The source light-field data may include one or more sub-aperture images that may be used to reconstruct the light-field in denser form.

<NPL> describes a computational approach to generate realistic depth of field effects for mobile devices such as tablets, comprising generating a low-res disparity map using graph cuts stereo matching and subsequently upsampleing the map via joint bilateral upsampling.

<CIT> describes a method for generating a light-field 3D display unit image, including: acquiring a two-dimensional left eye and right eye images of an original image, offering a depth information and a depth image of which and selecting either of which as a basic image, slicing a depth image corresponding to the basic image in a depth direction to obtain in different depth directions, establishing a virtual scene, generating a virtual recording device and a virtual micro-lens array, recording slice images by the device after the micro-lens array to obtain a corresponding number of recording images, superimposing recording images, and obtaining a unit image.

Traditional media content (e.g. images and video) typically does not contain the necessary angular information (theta, phi) for 4D light field displays. Computing the missing angular information is complex and computationally intensive. In practice, this means that 4D light field data must either be pre-rendered explicitly as 4D light field data (in a non- real-time fashion), or considerable GPU horsepower (e.g. arrays of high-end graphics cards) must be committed to calculate the four-dimensional data. 4D light field generation is so computationally expensive that it generally cannot be done in real-time without extremely powerful hardware (e.g., numerous GPUs running in parallel).

To address these and other problems with providing 4D light fields, embodiment of the disclosure provide novel systems and methods for producing a light field from a depth map, as define in the appended claims.

The disclosed embodiments provide several practical applications and technical advantages, which include at least: <NUM>) circumventing the need for multiple render passes to produce a 4D light field by instead programmatically computing the necessary data for the 4D light field from a single two-dimensional (2D) or two-and-a-half-dimensional (<NUM>. 5D) source image; and <NUM>) the real-time generation of a 4D light field from a 2D or <NUM>. 5D source, even on low-end computing hardware (e.g., a smartphone CPU / GPU).

Certain embodiments may include none, some, or all of the above technical advantages and practical applications. One or more other technical advantages and practical applications may be readily apparent to one skilled in the art from the figures, descriptions, and claims included herein.

Embodiments of the present disclosure and its advantages are best understood by referring to <FIG> of the drawings, like numerals being used for like and corresponding parts of the various drawings.

In general, embodiments disclosed herein provide systems and methods which render a 4D light field using 2D or <NUM>. 5D source image data. In typical systems, computing the 4D light field generally requires many render passes (i.e., one render pass for each plenoptic cell). This means, for example, a relatively low-spatial-resolution light field of ten plenoptic cells takes 10x more graphics processing power than the amount of processing power to render the same content on a traditional 2D screen. Most typical light field generation systems are predicated on brute-force computing the 4D plenoptic function (RGB for each x, y, theta, and phi). This is equivalent to rendering a scene from many different camera positions for each frame. This is computationally expensive and generally impractical (or impossible) for real-time content. Embodiments of the disclosure, however, circumvent the need for multiple render passes and instead programmatically compute the necessary data for a 4D light field from a single 2D or <NUM>. 5D source image. As will be appreciated, embodiments of the disclosure may provide a 10x to 100x decrease in the amount of time to produce a 4D light field over the approach of traditional systems.

For a near-eye light field system composed of plenoptic cells, each plenoptic cell's location represents a spatial position and each pixel location within that cell represents a ray direction. As such, embodiments of the disclosure transform data from a 2D or <NUM>. 5D source image into a 4D light field via one of two approaches. In a first approach, some embodiments perform simple replication of source imagery in an identical manner across each plenoptic cell. In these embodiments, 2D data is projected into infinity with no additional depth data. In a second approach, some embodiments utilize the depth buffer (intrinsically present for computer-generated 3D imagery) to programmatically compute ray direction (theta, phi) for each pixel in the 2D matrix. In essence, the second approach is identical to the first approach except each pixel within a plenoptic cell is shifted in x/y space as a function of its associated depth value.

The two approaches described above allow for rapid computation of the 4D light field data (x, y, theta, phi) from a 2D or <NUM>. 5D source image. Embodiments described herein allow for the generation of a 4D light field from a 2D or <NUM>. 5D source image in real time, even on low-end computing hardware (e.g., smartphone CPU / GPU). The embodiments described herein circumvent the need for multiple render passes, instead programmatically computing the necessary data from a single 2D or <NUM>. 5D source image. Thus, the disclosed embodiments are 10x to 100x faster than the traditional approach (depending on the spatial resolution of the target light field display). The disclosed embodiments may be a key enabler for extended reality (XR) visors, XR wall portals, XR construction helmets, XR pilot helmets, XR far eye displays, and the like. As used herein, XR includes Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR), and any combination thereof.

<FIG> illustrates an example system <NUM> for producing a light field from a depth map. As seen in <FIG>, system <NUM> includes a processor <NUM>, memory <NUM>, and an electronic display <NUM>. One or more source images <NUM> and a depth map to light field module <NUM> may be stored in memory <NUM>. Electronic display <NUM> includes multiple plenoptic cells <NUM> (e.g., 132A, 132B, etc.), and each plenoptic cell <NUM> includes multiple display pixels <NUM> (e.g., 134A-134P). For illustrative purposes only, electronic display <NUM> of <FIG> includes nine plenoptic cells <NUM>, and each plenoptic cell <NUM> includes sixteen display pixels <NUM>. This provides a 4D resultant light field that has a 4x4 angular resolution and a 3x3 spatial resolution. However, electronic display <NUM> may have any number of plenoptic cells <NUM> in any physical arrangement, and each plenoptic cell <NUM> may have any number of display pixels <NUM>.

Processor <NUM> is any electronic circuitry, including, but not limited to microprocessors, application specific integrated circuits (ASIC), application specific instruction set processor (ASIP), and/or state machines, that communicatively couples to memory <NUM> and controls the operation of automatic alerting communications system <NUM>. Processor <NUM> may be <NUM>-bit, <NUM>-bit, <NUM>-bit, <NUM>-bit or of any other suitable architecture. Processor <NUM> may include an arithmetic logic unit (ALU) for performing arithmetic and logic operations, processor registers that supply operands to the ALU and store the results of ALU operations, and a control unit that fetches instructions from memory and executes them by directing the coordinated operations of the ALU, registers and other components. Processor <NUM> may include other hardware that operates software to control and process information. Processor <NUM> executes software stored on memory to perform any of the functions described herein. Processor <NUM> controls the operation and administration of depth map to light field module <NUM>. Processor <NUM> may be a programmable logic device, a microcontroller, a microprocessor, any suitable processing device, or any suitable combination of the preceding. Processor <NUM> is not limited to a single processing device and may encompass multiple processing devices.

Memory <NUM> may store, either permanently or temporarily, source images <NUM>, operational software such as depth map to light field module <NUM>, or other information for processor <NUM>. Memory <NUM> may include any one or a combination of volatile or non-volatile local or remote devices suitable for storing information. For example, memory <NUM> may include random access memory (RAM), read only memory (ROM), magnetic storage devices, optical storage devices, or any other suitable information storage device or a combination of these devices. Depth map to light field module <NUM> represents any suitable set of instructions, logic, or code embodied in a computer-readable storage medium. For example, depth map to light field module <NUM> may be embodied in memory <NUM>, a disk, a CD, or a flash drive. In particular embodiments, depth map to light field module <NUM> may include an application executable by processor <NUM> to perform one or more of the functions described herein.

Source image <NUM> is any image or electronic data file associated with an image. In some embodiments, source image <NUM> is captured by a camera. In some embodiments, source image <NUM> is a 2D image that contains color data but does not contain depth data. In some embodiments, source image <NUM> is a <NUM>. 5D image that contains color data plus depth data (e.g., RGB-D). In some embodiments, source image <NUM> is a stereographic image from a stereo pair. Source image <NUM> may contain any appropriate pixel data (e.g., RGB-D, RGBA, BGR, HSV, and the like).

In operation, system <NUM> provides (via, e.g., depth map to light field module <NUM>) a 4D light field for display on electronic display <NUM> from a 2D or <NUM>. 5D source image <NUM>. To do so, depth map to light field module <NUM> accesses a source image <NUM> stored in memory <NUM> and determines depth data for each pixel <NUM> of a plurality of pixels <NUM> of the source image <NUM>. If the source image <NUM> is a 2D image that does not contain depth data, depth map to light field module <NUM> may assume a constant depth for the image (e.g., infinity) and then map each pixel <NUM> of the source image <NUM> to a corresponding pixel <NUM> of each electronic display <NUM>. For example, <FIG> is a diagrammatic view of a 2D source image <NUM> to a 4D light field mapping. As illustrated in <FIG>, pixel 152A is mapped to display pixel 134A of each plenoptic cell <NUM> (i.e., all nine plenoptic cells <NUM>), pixel 152B is mapped to display pixel 134B of each plenoptic cell <NUM>, and so forth. The pixel data (i.e., color data plus constant depth) is sent from depth map to light field module <NUM> to electronic display <NUM> as light field pixel data <NUM> in order to produce the corresponding 4D light field. For example, as the pixel data (e.g., RGB+XYD) arrives at the parser, the RGB-D is copied to the corresponding (x,y) for each cell within the target buffer. On the other hand, if the source image <NUM> is a <NUM>. 5D image that does contain depth data, depth map to light field module <NUM> uses the depth data when mapping each pixel <NUM> of the source image <NUM> to a corresponding pixel <NUM> of each electronic display <NUM>. For example, <FIG> is a diagrammatic view of a <NUM>. 5D source image <NUM> to a 4D light field mapping. As illustrated in <FIG>, pixel 152A is mapped to display pixel 134A of each plenoptic cell <NUM> (i.e., all nine plenoptic cells <NUM>), pixel 152B is mapped to display pixel 134B of each plenoptic cell <NUM>, and so forth. The pixel data (e.g., RGB-D) is sent from depth map to light field module <NUM> to electronic display <NUM> as light field pixel data <NUM> in order to produce the corresponding 4D light field. For example, as the pixel data (e.g., RGB+XYD) arrives at the parser, the RGB-D is copied to the corresponding (x,y) for each cell within the target buffer, but is shifted as a function of the depth data. This is illustrated in <FIG> by the shifting of the <NUM> inner pixels of source image <NUM> (labeled "A" and shaded grey) in certain plenoptic cells <NUM>.

<FIG> illustrates a method <NUM> for producing a light field from a depth map. In general, method <NUM> may be utilized by depth map to light field module <NUM> to generate light field pixel data <NUM> from source image <NUM> and send light field pixel data <NUM> to electronic display <NUM> in order to display a 4D light field corresponding to the source image <NUM>. To do so, method <NUM> may accesses a source image (e.g., source image <NUM>) stored in one or more memory units (e.g., memory <NUM>). Method <NUM> may then determine depth data for each pixel of a plurality of pixels of the source image (e.g., steps <NUM>-<NUM>) and then map, using the plurality of pixels and the determined depth data for each of the plurality of pixels, the source image to a four-dimensional light field (e.g., steps <NUM>-<NUM>). Each of these steps is described in more detail below.

At step <NUM>, method <NUM> determines whether the source image contains depth data (e.g. from a render buffer). In some embodiments, the source image is source image <NUM>. If the source image includes depth data, method <NUM> proceeds to step <NUM>. If the source image does not include depth data, method <NUM> proceeds to step <NUM>.

At step <NUM>, method <NUM> determines if the depth data of the source image is RGB-D data. If the depth data of the source image is RGB-D data, method <NUM> proceeds to step <NUM>. If the depth data of the source image is not RGB-D data, method <NUM> proceeds to step <NUM>. At step <NUM>, method <NUM> converts the depth data to RGB-D and then proceeds to step <NUM>.

At step <NUM>, method <NUM> determines if the source image is stereoscopic. If method <NUM> determines that the source image is stereoscopic, method <NUM> proceeds to step <NUM>. If method <NUM> determines that the source image is not stereoscopic, method <NUM> proceeds to step <NUM>.

At step <NUM>, method <NUM> computes the depth data from the stereoscopic source image. In some embodiments, the depth data is computed via parallax differences. After step <NUM>, method <NUM> proceeds to step <NUM>.

At step <NUM>, method <NUM> assigns a constant depth and a fixed location to the source image that is devoid of depth data. For example, method <NUM> may assign a constant depth of infinity. After step <NUM>, method <NUM> proceeds to step <NUM>.

At step <NUM>, method <NUM> determines if the runtime environment supports reverse-lookup (e.g., a hardware implementation for providing a light field). If method <NUM> determines that the runtime environment supports reverse-lookup in step <NUM>, method <NUM> proceeds to step <NUM>. If method <NUM> determines that the runtime environment does not support reverse-lookup in step <NUM>, method <NUM> proceeds to step <NUM>.

At step <NUM>, method <NUM> maps and sends light field pixel data (e.g., light field pixel data <NUM>) using reverse lookup (e.g., hardware implementation). In general, step <NUM> may include copying RGB+D to corresponding X & Y for each plenoptic cell within the target buffer as pixel data (RGB + XYD) arrives at the parser, shifting as a function of depth (D). In some embodiments, Ax * Ay total reads and Ax * Ay * Sx * Sy total writes may be performed. More details about certain embodiments of step <NUM> are described in more detail below with respect to <FIG>. After step <NUM>, method <NUM> may end.

At step <NUM>, method <NUM> maps and sends light field pixel data (e.g., light field pixel data <NUM>) using forward-lookup (e.g., software such as a graphics pipeline shader). In general, step <NUM> may include performing a ray-march for each pixel in output buffer along its corresponding theta / phi direction to determine target pixel data from the reference RGB-D map. In some embodiments, this may require Ax * Ay * Sx * Sy (parallelizable) ray-marches (where Ax & Ay are angular resolution width & height (e.g. pixels per cell) and Sx & Sy are spatial resolution width & height (e.g. cells per display). More details about certain embodiments of step <NUM> are described in more detail below with respect to <FIG>. After step <NUM>, method <NUM> may end.

<FIG> is a flowchart of a method <NUM> for producing a light field from a depth map using reverse-lookup (e.g., hardware implementation), according to certain embodiments. <FIG> is a diagrammatic view of a reverse lookup-mapping for a hardware implementation such as method <NUM>. In general, if parallelizable hardware is available, method <NUM> uses the color and depth (e.g., RGB-D) of the pixel in question to determine in which location in the output image to write that data. In step <NUM>, method <NUM> determines if the incoming pixel <NUM> of source image <NUM> has been written to all plenoptic cells <NUM>. If, so, method <NUM> ends. Otherwise, method <NUM> proceeds to step <NUM>. In step <NUM>, method <NUM> uses the pixel's location in the display matrix (its cell) to determine the real world offset from the center of the light field display to its encompassing plenoptic cell's corners. In some embodiments, step <NUM> includes computing the pixel offset (dX/dY) as a ratio-of-slopes-function of the plenoptic cell position (cX/cY) and pixel depth (D). After step <NUM>, method <NUM> proceeds to step <NUM>.

In step <NUM>, method <NUM> determines if the pixel has already been written at the location (X + dX, Y + dY) of this cell for this frame. If so, method <NUM> proceeds to step <NUM>. If not, method <NUM> proceeds to step <NUM>.

At step <NUM>, method <NUM> determines if the depth of the already-written pixel is smaller (i.e., closer to the camera) than the depth of the not-yet-written pixel. If the depth of the already-written pixel is smaller than the depth of the not-yet-written pixel, method <NUM> does not write any pixel data for the incoming pixel and proceeds back to step <NUM>. If the depth of the already-written pixel is not smaller than the depth of the not-yet-written pixel, method <NUM> proceeds to step <NUM>.

In step <NUM>, method <NUM> writes the pixel data (RGB+D) to location (X+dX, Y+dY) of the plenoptic cell. Because each pixel in a plenoptic cell represents a different ray direction (the angles theta and phi), method <NUM> may use the difference between the pixel's location and the plenoptic cells center, multiplied by the pitch of a cell, to calculate one side of a right triangle in step <NUM>. Method <NUM> may use the given depth to calculate the other side of that same triangle. The ratio of those two sides generates an angle related to the pixel offset that should be applied when writing the output buffer data for the display. This relationship may be defined by taking that angle, converting it to degrees, multiplying by the pixels-per-degree of the display and the sign of the difference between the pixel's location and its cell center. This offset is then added to the original pixel x/y and its cell's center to create a new world position. The pixel's color value and depth are written to this position in the output buffer if it is closer than what was there before to create a part of the light field.

Method <NUM> may be implemented in low level code, firmware, or transistor-logic and run on hardware close to the light field display <NUM>. In this application, identical synthetic content me be fed to each one and it may use its known position to calculate its portion of the light field.

<FIG> is a flowchart of a method <NUM> for producing a light field from a depth map using forward-lookup (e.g., software such as a graphics pipeline shader), according to certain embodiments. <FIG> is a diagrammatic view of a forward-lookup mapping for a software implementation such as method <NUM>. In general, in the case where there is not a hardware implementation, it is possible to map the 4D light field from source image <NUM> using a loop. Method <NUM> uses the pixel in question's buffer location and the depth (if available) and cell location to determine which color should be placed in that same spot in the output buffer. At a high level, method <NUM> represents the location and direction in space of that cell within that particular pixel within the plenoptic cell into the virtual camera space so that the appropriate color to put in that cell can be looked up. As illustrated in <FIG>, the operation of method <NUM> is opposite from that of method <NUM> (i.e., method <NUM> reads through the display pixels <NUM> of plenoptic cells <NUM> while method <NUM> reads through the source pixel data <NUM> of source image <NUM> as illustrated in <FIG>). The first step of method <NUM> is to calculate the camera ray for the given pixel location. This is the ray direction that light is traveling along as it would intersect this pixel's cell location. This ray uses the world position of the pixel's cell as its origin and the angles theta and phi as its direction. These angles can be calculated from the pixel's offset from the center of its cell. The details of this calculation depend on if foveation or other mapping needs to take place and should not be assumed to be linear. The ray's origin is converted from pixel space to world space using known properties of the collection system such as near plane and field of view. Next, method <NUM> converts this ray into one in the depth (backspace). This transformation converts the 3D world space vector into a 2D depth space vector and uses inverse depth for comparisons. Next the derivatives for both the camera ray and the depth vector are calculated with respect to the spatial dimensions (x,y). These derivatives are then used in a loop to traverse through depth space to determine the closest object in the rendered buffer that the ray would hit. In the case of having a separate depth buffer, the depth space vector would also be traversed through its buffer. At the end, the closest object between the depth space and color space would determine the actual depth of the pixel's ray. In these steps it may be preferable to use the tangent of the inverse depth during the recursion for stability reasons. With the depth of the object that was hit, the origin of the ray and its direction, trigonometric relations (using known properties of the collector such as field of view) can be used to convert from world back to screen space to determine which source color image pixel's color data should be used for the output image at this pixel location. The specific steps of some embodiments of method <NUM> are described in more detail below.

Method <NUM> may begin in step <NUM> where method <NUM> determines if every pixel in the render target has been checked. If so, method <NUM> may end. Otherwise, method <NUM> proceeds to step <NUM>.

At step <NUM>, method <NUM> retrieves the next pixel X,Y in the render target. After step <NUM>, method <NUM> proceeds to step <NUM> where method <NUM> determines the ray direction of pixel X,Y in the scene space (d<NUM>). After step <NUM>, method <NUM> proceeds to step <NUM> where method <NUM> determines the ray direction of pixel X,Y in the background space (d<NUM>). After step <NUM>, method <NUM> proceeds to step <NUM> where method <NUM> calculates the derivative of d<NUM> and d<NUM> with respect to X/Y. After step <NUM>, method <NUM> proceeds to step <NUM> where method <NUM> calls the function of <FIG> using di and its derivatives to approximate the ray intersection point ii in the scene space. After step <NUM>, method <NUM> proceeds to step <NUM> where method <NUM> calls the function of <FIG> using d<NUM> and its derivatives to approximate the ray intersection point i<NUM> in the background space. After step <NUM>, method <NUM> proceeds to step <NUM> where method <NUM> converts i<NUM>and i<NUM> into more accurate inverse depths id<NUM> and id<NUM>. After step <NUM>, method <NUM> proceeds to step <NUM> where method <NUM> calculates an ending inverse depth (ide) from id<NUM>. After step <NUM>, method <NUM> proceeds to step <NUM>.

At step <NUM>, method <NUM> determines if id<NUM> is less than id<NUM>. If id<NUM> is less than id<NUM>, method <NUM> proceeds to step <NUM> where method <NUM> writes Ø (blocked) and then proceeds back to step <NUM>. Otherwise, if id<NUM> is not less than id<NUM>, method <NUM> proceeds to step <NUM> where method <NUM> writes the color sample form the scene or multisample (e.g., derivative) at i<NUM>. After step <NUM>, method <NUM> proceeds back to step <NUM>.

In the forward-lookup application (i.e., <FIG>), method <NUM> may be implemented as a post process shader in a game engine or render engine. This shader would take as input data from cameras placed in the synthetic scene and optionally depth buffers from those virtual cameras. Method <NUM> would then output a single image that contained the cells that make up the light field in an array of images.

<FIG> is a flowchart of a sub-method <NUM> of <FIG>, according to certain embodiments. Method <NUM> is a parallax occlusion ray to inverse depth method that functions by raymarching with uniform steps in the pixel space. In general, method <NUM> first sets up a conversion between 3D space and the 2D space of the input render input. This allows method <NUM> to its iteration in a pixel-perfect manner while still doing the computation in 3D space. Not only does this provide better quality results, but it also provides drastic performance gains when the light field display is small with respect to the scene it is displaying.

Method <NUM> may begin in step <NUM> where method <NUM> calculates the starting tangent for the inverse depth for the direction passed in from method <NUM> (d<NUM> or d<NUM>). After step <NUM>, method <NUM> proceeds to step <NUM> where method <NUM> calculates the ending tangent for the inverse depth for the direction passed in from method <NUM> (d<NUM> or d<NUM>). In general, in steps <NUM> and <NUM>, method <NUM> obtains the tangents (original render space) corresponding to the start and end inverse depths along the input ray. Method <NUM> may in addition compute the constant step (corresponding to half of the diagonal length of one pixel) to be used in the raymarching.

In steps <NUM> and <NUM>, method <NUM> begins a loop that takes a parameter 't' from <NUM> to <NUM>. Method <NUM> considers t=<NUM> to be the start of the input ray and t=<NUM> to be the endpoint, and method <NUM> increments 't' by the previously described precomputed constant at each iteration of the loop (step <NUM>). Because 't' is linearly related to the original render's pixel space, it has an inverse relation to depth of the input ray (i.e., t*depth is constant). Method <NUM> uses this fact to compute the depth of the input ray at each step in the raymarch (step <NUM> where method <NUM> calculates the parametric inverse depth idt using 't'), and method <NUM> uses the linear relation between t and the input pixel space to sample the input depth map, which is called the scene depth (step <NUM>). On the first iteration in which the ray depth exceeds the scene depth (step <NUM>), method <NUM> concludes that the ray has 'hit' something and takes an early exit to return an appropriately interpolated value (step <NUM>). Otherwise, in the case that this never occurs before the end of the loop, method <NUM> returns an indication that we hit nothing (step <NUM>). Method <NUM> thus is a parallax occlusion algorithm that results in an inverse depth, allowing it to return an intersection point (as an inverse depth along the ray) as well as returning a 'nothing hit' signal (as the input ending inverse depth).

The methods described herein mostly use tangent space as opposed to either pixel space or angle space, and mostly use inverse depth as opposed to depth. Both of these choices in space have both conceptual and computational advantages. For directions in 3D space and for locations on a 2D pinhole-style image, the space of choice is tangent space. This is defined with respect to the plane perpendicular to the view direction of the camera/light field so that for tangent coordinate {w_x, w_y}, the direction it points corresponds to the vector <x = w_x, y = w_y, z = <NUM>>. In plenoptic cellular light field contexts, tangent space may be the best choice because it is the most consistent, computationally cheapest option and is readily compatible with the other spaces (pixel space is tangent space with a scalar multiplier).

The use of inverse depth space offers many advantages. As noted above, in a standard camera projection, pixel position is inversely related to scene depth (coordinate parallel to the view direction, not distance to the camera) and therefore linearly related to inverse depth. This allows the disclosed embodiments to execute large sections of computation (such as pixel-perfect raymarching) without ever directly computing depth and without ever using a division. Another advantage of using inverse depth is a clean representation of infinity. An inverse depth of <NUM> may be used to refer to the 'back' of the scene as it is effectively a depth of infinity. This proves to be much more useful than the counterpart depth of zero that the inverse depth space renders unwieldy.

Modifications, additions, or omissions may be made to the systems and apparatuses described herein without departing from the scope of the claims.

The components of the systems and apparatuses may be integrated or separated. Moreover, the operations of the systems and apparatuses may be performed by more, fewer, or other components. Additionally, operations of the systems and apparatuses may be performed using any suitable logic comprising software, hardware, and/or other logic.

Modifications, additions, or omissions may be made to the methods described herein without departing from the scope of the claims.

Claim 1:
A system (<NUM>) comprising:
an electronic display (<NUM>), the electronic display (<NUM>) comprising a plurality of plenoptic cells (<NUM>), each plenoptic cell (<NUM>) comprising a plurality of display pixels (<NUM>);
a computer processor (<NUM>);
one or more memory units (<NUM>); and
a module (<NUM>) stored in the one or more memory units (<NUM>), the module (<NUM>) configured, when executed by the processor (<NUM>), to:
access a source image (<NUM>) stored in the one or more memory units (<NUM>);
determine depth data for each pixel of a plurality of pixels (<NUM>) of the source image (<NUM>);
map, using the plurality of pixels (<NUM>) and the determined depth data for each of the plurality of pixels (<NUM>), the source image (<NUM>) to four-dimensional light field data, said mapping comprising copying pixel data for each of the plurality of pixels (<NUM>) of the source image (<NUM>) to a corresponding display pixel (<NUM>) of each of the plenoptic cells (<NUM>); and
send instructions to the electronic display (<NUM>) to display the mapped four-dimensional light field data.