The present invention generally relates to the transmission and display of three-dimensional content, and more particularly, to adjustment of disparity between views forming the three dimensional content.
A three-dimensional image is formed by displaying images recorded or generated from different view points or perspectives of a scene or an object to each eye of a user: a right view is displayed to the right eye of a user while a left view is displayed to the left eye of a user. “Disparity” is the horizontal displacement between these two view points or perspectives. In particular, the disparity between two view points is what permits a viewer to perceive video content in three-dimensions; the higher the disparity, the higher the intensity of the three-dimensional effect in that the depth of the perceived image is greater.
Some of the existing methods for delivering three-dimensional (3D) stereo content use fixed disparity, such as, for example, anaglyph-based approaches used in package media and television broadcasts employing ColorCode 3D technology. These approaches have a minimal increase in complexity compared to traditional two-dimensional (2D) video delivery. However, they do not permit adjusting the disparity of the stereo content. As a result, they may provide a poor viewing experience. For example, if the disparity is too low, the 3D effect will be lost; conversely, if the disparity is too high, it may cause visual discomfort.
Other approaches, such as 2d+depth video format, deliver 3D video content by transmitting 2D video with depth information and generate the stereo pair (left & right views) on the receiver side. While this approach permits adjusting the disparity on-the-fly using views generated at the receiver, it greatly increases the complexity and cost of the receiver. Additionally, because the second view has to be interpolated from the 2D video, the resulting 3D image may have visual artifacts, especially around large, foreground objects.
Other known methods are based on 3D models, such as, for example, Nvidia 3D Vision. Similar to the previous approaches based on 2D +depth, these 3D model-based methods generate the 3D stereo pair on the receiver side, but do not introduce video artifacts, as the complete 3D model of the scene is available. Requiring a complete 3D model of the scene is the main limitation of these methods because it greatly increases complexity and limits their application to video games, which are already based on 3D models.
As noted above, the intensity of the 3D effect depends on the disparity of views displayed. The intensity also depends on the viewing conditions, such as screen size and viewing distance, and the response of the visual system of each viewer. Thus, the disparity of the 3D stereo content should be adjusted to fit the viewer and the viewing conditions.
Accordingly, there is a need for efficient and low-complexity methods and systems for delivering 3D stereo content that permits adjusting the disparity of the content and, at the same time, maintains high visual quality. Methods and systems in accordance with various exemplary embodiments are presented that address current deficiencies by enabling dynamic selection and adjustment of the disparity of views for three-dimensional content. This provides low complexity and does not require the use of 3D models. In addition, Multi-view Video Coding (MVC) schemes can be utilized, which permit the transmission of views of three-dimensional content in a quick and efficient manner. The MVC schemes facilitate dynamic selection and adjustment of disparity by configuring dependencies of enhancement views to reference only base views.
In one exemplary embodiment, a method for delivering three-dimensional media content over a network includes: storing a plurality of different views for the content, wherein different combinations of the views yield different disparities; receiving a request to transmit at least one pair of the views with a corresponding disparity selected at a receiver; selecting at least one pair of views having the selected disparity; and transmitting the at least one pair of views having the selected disparity to the receiver over the network in response to receiving the request.
In an alternate exemplary embodiment, a method for receiving three-dimensional media content over a network includes: selecting a disparity for the three-dimensional content; transmitting to a server a request for at least one pair of views having the selected disparity; and receiving the at least one pair of views having the selected disparity over the network.
In another exemplary embodiment, a system for delivering three-dimensional media content over a broadcast network includes: a server configured to store and broadcast a plurality of different views for the content, wherein different combinations of the views yield different disparities; and a receiver configured to receive the plurality of different views, select a disparity for the content and output a pair of the views having the selected disparity for display.
In a different exemplary embodiment, a method for delivering three-dimensional media content over a network by employing Multi-view Video Coding includes: receiving a base view and a plurality of enhancement views for the content, wherein different combinations of the base view and the enhancement views yield different disparities; MVC encoding the base view and the enhancement views such that the enhancement views reference the base view without referencing any other enhancement view; and transmitting at least one pair of the MVC encoded views to a receiver, wherein the base view is included in the at least one pair.
The teachings of the present invention can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:
It should be understood that the drawings are for purposes of illustrating the concepts of the invention and are not necessarily the only possible configuration for illustrating the invention. To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.
Exemplary embodiments provide methods and systems for delivering three-dimensional stereo content that permit disparity adjustment by enabling users or receivers to select among several pairs of left & right views. The proposed embodiments can customize the 3D experience to fit the preferences of the viewer and the viewing conditions, such as screen size and viewing distance, without reducing the image video quality or significantly increasing the complexity of the receiver and display.
It should be understood that the functions of the various elements shown in the figures can be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions can be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which can be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and can implicitly include, without limitation, digital signal processor (“DSP”) hardware, read-only memory (“ROM”) for storing software, random access memory (“RAM”), and non-volatile storage. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).
Thus, for example, it will be appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of illustrative system components and/or circuitry embodying the principles of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which can be substantially represented in computer readable storage media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.
Referring now in specific detail to the drawings in which like reference numerals identify similar or identical elements throughout the several views, and initially to
Returning to method 100, method 100 can begin at step 102 in which the server 302 stores a plurality of different views for the same three-dimensional media content. For example, the server 302 can store M independent views 310 in storage device 311 so that, in response to a user-request, they can subsequently be combined and/or interpolated to generate a pair with a desired disparity in accordance with user-preferences. Alternatively or additionally, server 302 can combine and/or interpolate different, multiple left and right views for video content to generate pairs having different disparities and the generated pairs can be stored in storage device 311. For example, the generated pairs can correspond to different (N) stereo pairs 308 stored at the server 302. In this scenario, the receiver 304 can select any one or more stored pairs 310 for transmission from the server 302 on delivery channel 306.
Optionally, at step 103, the server 302 can receive a streaming request for a default stereo pair from the receiver 304. The request can simply reference a “default” or can specify a desired disparity for the default stereo pair. Further, the request can be transmitted over back channel 307.
Optionally, at step 104, the server can transmit a default stereo pair of views to a receiver. This step is useful in an exemplary embodiment in which the user can request a pair having a different disparity based on the default pair. For example, the user can indicate to the receiver 304 that a pair having a higher or a lower disparity in relation to the default pair should be transmitted by the server. It should be noted that the default stereo pair can be broadcast to several receivers through delivery channel 306. In this scenario, the user-request (or receiver-request) for alternative views, described in more detail below, can be transmitted to the server via back channel 307. For example, if the default stereo pair is broadcast via satellite, the back channel 307 can be a hardwire or optical channel connected to a wide area network such as the Internet or some other service provider network.
At step 106, the server 302 can receive a request to transmit at least one pair of the views with a corresponding disparity selected at a receiver. For example, selection of a particular pair of views can be made upon system startup at a receiver. Additionally, selection of a particular pair of views can be made by a user at the receiver. Further, selection of the pair of views can be based on a default pair of views. For example, the request can include an indication that the server should transmit a view pair having more or less disparity than the default pair. Moreover, in a streaming scenario, switching between different stereo pairs could happen on-the-fly, simply by sending a new request to the server. The new requests for on-the-fly switching can indicate that the server should transmit one or more pairs of views that have a disparity that is greater than or less than any previous pair transmitted by the server, such as the last pair transmitted by the receiver. In addition, in a scenario in which the receiver downloads three-dimensional video content as opposed to receiving streaming content, the appropriate stereo pair can be requested at the beginning of the download; alternatively, several stereo pairs could be requested for download to provide several viewing options. It should also be noted that a “selected disparity,” as employed herein, can correspond to a selected disparity range. For example, in the download scenario, a user can request a range of disparities and the server can provide several pairs of views have disparities within the specified range. In any scenario described here, as noted above, the request can be received along a back channel 307.
At step 108, the server 302 can select the pair of views having the selected disparity. For example, as mentioned above, the server 302 can generate different pairs of views 308 having different disparities prior to receiving a request from the receiver 304. Here, in response to receiving a request, the pair selector 314 in server 302 can select the requested pairs of views for transmission to the receiver 304. Alternatively or additionally, the pairs can be generated on-the-fly in response to user requests. For example, receiver 304 can transmit a request for one or more pairs of views that has more or less disparity than the default pair of views. Further, receiver 304 can transmit a request for one or more pairs of views having specified disparities in accordance with user-preferences. In response to receiving the request, the pair selector 314 can generate the requested pair or pairs for transmission to the receiver 304 by “selecting,” at step 108, the pair or pairs of views having the selected disparity from the independent views 310 stored in storage device 311.
At step 110, in response to receiving the request from the receiver 304, the server 302 can transmit to the receiver 304 one or more pairs of views having the selected disparity over the network.
Optionally, at step 112, the server 302 can determine whether a new request for pair transmission has been received from the receiver 304. If a new request has been received, then the method can proceed to step 110 in which a new one or more pairs of views corresponding to the disparity indicated in the request are transmitted to the receiver 304. Alternatively, if the corresponding pair is not stored, then the method can proceed to step 108, in which the pair having the indicated disparity can be generated. The new request, can, for example, be part of an on-the-fly switching scheme discussed above. Otherwise, the method can proceed to step 114 in which the server 302 determines whether a termination condition is satisfied. For example, a termination condition can correspond to completion of transmission of all content in a download scenario. In a streaming scenario, a termination condition can correspond to a transmission of all content, such as video-on-demand content, or it can correspond to the receiver being in a shut-down state. If the termination condition is satisfied, then the method can end. Otherwise, the server can continue to transmit the one or more pairs of views having corresponding disparities in accordance with step 110.
Method 100 permits a viewer to customize the three-dimensional viewing experience in accordance with his or her preferences when streaming or downloading video content. Further, the method is economical in that pair generation is conducted at a server, thereby permitting the use of simple, low-complex receivers by a large number of customers serviced over a network.
It should be understood that method 100 can be implemented in a variety of ways as understood by those of ordinary skill in the art. For example, implementations can vary with respect to stereo pair creation and storage, stereo pair/disparity selection and coding of the three-dimensional content. Exemplary variations are described herein below.
Stereo Pair Creation
In accordance with various exemplary implementations of the present invention, generation of pairs of views, as discussed above with respect to steps 102 and 108, can be performed in several different ways. For example, according to one exemplary embodiment, a Multi-view 3D content approach can be employed to generate the pairs of stereo views. This approach generates the 3D video content using a multi-view system utilizing either multiple cameras for live action content or multiple renderings for computer generated content. Therefore, generating the different stereo pairs can simply comprise pairing different generated views such that each pair has a different disparity. This approach offers the best video quality, but also has the highest content creation burden.
Another approach that can be employed to perform step 102 or step 108 includes 2D content creation and view interpolation. Here, only 2D video content is employed and interpolated to generate multiple views, optionally with some additional information such as depth data. While this approach greatly simplifies the content creation process, it entails complex, time consuming manual video processing for view interpolation. It might also provide lower quality than true multi-view content given that only one 2D view is available for the interpolation.
According to other exemplary aspects of the present invention, step 102 or step 108 can be performed using 3D stereo content creation and view interpolation. In this approach, 3D stereo content is interpolated to artificially generate multiple, different views. By using a single 3D stereo pair, content creation is greatly simplified compared to the true Multi-view 3D content approach. This approach does not reach the same quality level as multi-view 3D content creation, but it improves on that of the 2D content creation quality level. And for the stereo pair, this approach provides the same quality as the multi-view case.
Multi-view 3D content creation and view interpolation is another approach that can be employed to generate different views at step 102 or step 108. Here, Multi-view 3D content, described above, is interpolated to generate additional, different views. By adding view interpolation to multi-view 3D content creation, it is possible to reduce the complexity of the content creation process at the expense of slightly reduced image quality and additional cost for the view interpolation.
Storage
In accordance with exemplary implementations, storage of views, as discussed above with respect to step 102, can be performed by the server in a variety of ways. The manner in which the views are stored can be selected based on complexity and capacity constraints.
As discussed above, at step 102, server 302 can employ stereo pair-based storage. In this mode, full pairs of left and right views, such as pairs 308, are stored. Thus, switching to a new disparity simply comprises switching to a new stored pair. While this mode requires the lowest complexity, it also requires the most storage, as different stereo pairs could actually share one of the two views.
Alternatively or additionally, views can be stored at step 102 in server 302 independently in accordance with a view-based storage approach. In this mode, several different views, such as views 310, are stored independently and full stereo pairs are generated on-the-fly based on the requested disparity. This approach increases complexity but minimizes space requirements and permits sending 2D video. In a particular embodiment, a single left view L (base view) and multiple right views (additional views) {R1, . . . RN} can be stored at step 102; stereo pairs can be formed at step 108 by combining the left view with each right view (L,Rn).
Video Coding
Transmission of one or more pairs of views at step 110 can be implemented by the server using many different encoding strategies. Simulcasting provides one viable option for transmitting views at step 110. In accordance with simulcasting, each view is encoded in an independent video stream and transmitted to the receiver. This approach uses a greater amount of bandwidth, as the bandwidth used compared to 2D video is approximately doubled. However, it has low complexity because it does not require using new coding or post-processing algorithms. Additionally, because each view is encoded in an independent video stream, any combination of views is possible, potentially resulting in more disparity options for the same number of views. This approach supports either stereo pair- and view-based storage, and it is backward compatible with 2D content.
Another technique that can be employed at step 110 includes spatial interleaving. Here, two views are spatially interleaved together and then encoded as a single 2D stream. Thus, it uses the same amount of bandwidth as for regular 2D video. However, the approach also results in lower image quality because each view is down-sampled by a factor of two. For example, the view can be down-sampled in the horizontal dimension for a side-by-side spatial interleaving. Spatial interleaving has a lower encoding and decoding complexity than simulcast, but it can require additional post-processing on the receiver side to reconstruct the full resolution stereo pair. This approach only supports stereo pair-based storage and breaks compatibility with 2D only systems.
Multi-view Video Coding (MVC) can also be employed at step 110 to transmit views to receiver 304. In particular, the MVC standard can be utilized to encode different views available on the server 302. Depending on the encoding configuration, such as cross-view dependencies, this approach can achieve different tradeoffs between encoding efficiency (i.e. bandwidth use) and complexity. In accordance with exemplary aspects, when a base view and additional views are employed in accordance with the view-based storage approach discussed above, coding dependencies would only occur between the base view and the additional views, and not between additional views—this would permit sending only the base view and any single additional view. This approach supports both stereo pair- and view-based storage, albeit with fewer view combinations than simulcast, and it is backward compatible with 2D only systems. A particular MVC approach in accordance with an exemplary embodiment of the present invention is discussed more fully below.
It should be understood that other coding approaches can be employed at step 110. For example, the scalable video coding (SVC) standard can be employed to encode the views for transmission or, for systems with view interpolation at the receiver, a combination of 2D views and depth information can be employed to encode the views for transmission.
Other Exemplary Disparity Selection Embodiments
With reference now to
Optionally, method 200 can begin at step 202, in which the receiver 304 receives a default stereo pair of views. The default stereo pair can correspond to the default pair described above with respect to step 104. As noted above, in exemplary embodiments, the default stereo pair can be broadcast to a plurality of receivers.
At step 204, the receiver 304 or a user can select a disparity for the three dimensional content in accordance with the descriptions provided above. For example, selection of a particular pair of views can be made upon system startup at a receiver. Additionally, a user can select a particular pair of views at the receiver. The receiver can also select the disparity based on viewing conditions. For example, the receiver can detect the screen size of the display device and can select a disparity appropriate to the screen size and viewing distance. The viewing distance parameter can be preset by a user or can simply be a default viewing distance parameter stored in software of the receiver device. Moreover, the selection process can be direct or indirect. In the direct mode, the receiver knows exactly which disparities are available on the server. Thus, the receiver can present the available, specified disparities to a user and the user can select a desired disparity. In the indirect mode, the receiver receives the default stereo pair and provides a user with the option of selecting a disparity that is greater than or less than the default stereo pair. Further, in the indirect mode, selection can be made iteratively by referencing the most recent stereo pair or stereo pairs received by the receiver. It should also be noted that a “selected disparity” can correspond to a selected disparity range, as discussed above.
At step 206, the receiver 304 can transmit to the server a request for at least one pair of views having the selected disparity. For example, in the direct mode, to request a stereo pair or a new stereo pair, the request can include an identifier (ID) of the left and right views to be sent. In the indirect mode, the request can include an indication of a higher or lower disparity with respect to any other pair or pairs of views previously transmitted by the server. As noted above, the pair selector 314 on the server side can select the appropriate pair of views to satisfy the request. Further, the request for a default pair can be made at step 206. As noted above, the request for the default pair can reference a “default” or can specify a desired disparity for the default stereo pair. It should also be noted that the direct mode puts much of the intelligence on the receiver side, simplifying the pair selector 314. The indirect mode entails using a more complex pair selector 314, but it permits adding or removing views from the storage without requiring any change on the receiver side. Further, it should be understood that the request can be the request described above with respect to step 106. As discussed above, the request, in certain exemplary embodiments, can be transmitted along a back channel 307.
At step 208, the receiver can receive at least one pair of views having the selected disparity from the server over the network and can display the three dimensional content using a pair of views having the selected disparity. The selected pairs can correspond to the selected pairs discussed above with respect to steps 108 and 110.
As stated above, the switching of views can be performed iteratively or on-the-fly by submitting new requests. Optionally, at step 210, the receiver can determine whether the user has selected a new disparity. If the user has not selected a new disparity, then the receiver can continue receiving the one or more pairs of transmitted by the server and maintain the current display of the content. Otherwise, the method can proceed to step 212.
Optionally, at step 212, the receiver can transmit a new request indicating the new selected disparity. The request can be comprised of any of the features discussed above with respect to step 206. For example, the request can specify that the new selected disparity is greater than or less than the disparity of at least one of the pair of views received. In addition, the request can specify one or more identifiers of specific pairs of views. Furthermore, the new request can include features of requests discussed above to steps 112 and 106.
At step 214, the receiver can receive at least one pair of views having the new selected disparity from the server over the network and can display the three-dimensional content using a pair of views having the new selected disparity. Thereafter, method 200 can proceed to step 210.
It should be understood that switching of views on-the-fly can occur at any time. For example, in a streaming scenario in which a user wishes to play three-dimensional content in accordance with a video-on-demand scheme, a video can be transmitted to the receiver as the default pair of views or as some receiver/user-specified pair of views. While the video is presented to the user, the user can iteratively adjust the disparity of the content displayed by using the on-the-fly switching feature discussed above until a desired disparity for the video is achieved while the video is playing. The adjustment can be implemented by permitting a user to select particular disparities and by transmitting a request for the pair of views having the selected disparity by using identifiers, as discussed above. Alternatively, the adjustment can be based on user-selection of a disparity that is greater or less than a disparity of a pair of views previously received at the receiver.
With reference now to
At step 404, the server 302 can broadcast a plurality of views to a plurality of receivers. For example, a plurality of stereo pairs and/or a plurality of independent views can be transmitted to a plurality of receivers over delivery channel 306, which is implemented in a broadcast network, as discussed above. Any broadcasted stereo pairs have different corresponding disparities. Similarly, any broadcasted independent views, for example at least three independent views, have different corresponding disparities when combined. In addition, the plurality of views can each be transmitted with a disparity indicator. For example, the disparity indicator can indicate a distance from a base view to permit a receiver to choose a pair of views have a desired disparity. The base view can be any view and an indicator can be a negative or positive value indicating that the distance is to the left or right of a base view. Alternatively, for example if stereo pairs are broadcast 308, the indicators can simply reference a particular disparity. Further disparity distances and particular values of disparities can be implemented using codes and a lookup table that is either transmitted with the three-dimensional content or is pre-stored at a receiver 304.
Referring now to
At step 504, the optional disparity selector 315 of receiver 304 can select a disparity for the three-dimensional content. For example, a pair of independent views or stereo pairs received can be appended with an indicator indicating that the pair of views or stereo pair is a default pair of views or stereo pair. Thus, the disparity selector 315 can be configured to use a lookup table either received with the content or pre-stored in the memory of receiver 304 to determine the default pair of views and output the default pair of views for display. In addition, the user can indicate to the receiver 304 that a pair of views having a higher or a lower disparity in relation to the default pair of views should be displayed. This selection/display process can be performed iteratively until a desired disparity is reached, for example, as discussed above with respect to steps 208-210 of
Furthermore, it should be noted that, as discussed above, selection of a particular pair of views can be made upon system startup at a receiver. The receiver can also select the disparity based on viewing conditions. For example, the receiver can detect the screen size of the display device and can select a disparity appropriate to the screen size and viewing distance. The viewing distance parameter can be preset by a user or can simply be a default viewing distance parameter stored in software of the receiver device.
At step 506, the receiver 304 can decode and output the pair of views having the selected disparity for display.
It should be understood that although methods 400 and 500 were described separately from methods 100 and 200 for ease of understanding, any one or more steps of methods 400/500 can be included with methods 100/200 and vice versa. For example, system 300 can perform methods 400/500 simultaneously with methods 100/200 in that methods 400/500 can be performed for a subset of receivers while methods 100/200 are performed for a different subset of receivers. Alternatively or additionally, methods 400/500 can be performed for certain three-dimensional content while methods 100/200 are performed for other three-dimensional content.
Embodiments Utilizing MVC
With reference now to
For example, according to one exemplary implementation of the present invention, a single left view L and N right views {R1, . . . , RN} can be stored on the storage device 311 at server 302. The views can be encoded using the MVC standard, where the left view L would be the base view and the right views Rn would be the enhancement views, with no coding dependencies between right views. To send a particular stereo pair (L, Rn), the base view L and the enhancement view Rn would be combined into a single MVC stream and then streamed or downloaded. However, it should be noted that other approaches can be employed. For example, one could assume that two views, such as a default or base left view and a default or base right view will always be sent, and therefore both can be used as a reference to encode the remaining views.
As noted above,
Method 700 can begin at optional step 702 in which an optional view interpolator 602 can interpolate the base view and/or captured enhancement views to generate a plurality of enhancement views. For example, a left captured left base view L 604, a captured right view R2 606 and a captured right view R5 608 can be input to the view interpolator 602 to generate views R1 610, R3 612 and R4 614 via interpolation of the base view 604, enhancement view 606, and/or enhancement view 608 for the captured three-dimensional scene 616, as shown, for example in
Once all the plurality of different views 609 are available, such as, for example, L and {R1, . . . , R5}, which can also include one or more other base views, they can be passed to the MVC encoder 620. However, it should be understood that the interpolator 602 is optional and the plurality of different views can be captured views that are passed on to the MVC encoder 620. As such, how the plurality of views is generated need not affect the MVC encoding process.
At step 704, the MVC encoder 620 can receive a base view and a plurality of enhancement views for the content. Further, as noted above, the MVC encoder 620 can also receive at least one other base view. Here, different combinations of one or more of the base views and the enhancement views yield different disparities
At step 706, the MVC encoder 620 can encode the base view(s) and the enhancement views such that the enhancement views reference the base view(s) without referencing any other enhancement view. For example, in the particular embodiment illustrated in
For example, with reference to
It should also be noted that the MVC encoded views can be stored in storage device 311 as pairs and/or as independent views, as discussed above with respect to step 102 of method 100.
At step 708, the server 601 can receive a request to transmit over the network at least one pair of the views with a corresponding disparity selected at receiver 304. Step 708 can be performed in accordance with step 106 discussed at length above. For example, the request can include any and all features discussed above with respect to method 100. Alternatively, it should be noted that in certain embodiments that use MVC encoding, the request can simply be a request for the content, as discussed in more detail below.
At step 710, the server 601 can transmit at least one pair of the MVC encoded views to the receiver 304. For example, the step 710 can be implemented in accordance with step 110 discussed above with respect to method 100. For example, the transmitted pair or pairs of MVC encoded views can have the selected disparity indicated in the request. Alternatively, if the request is simply a request for content, the server 601 can select some or all of the MVC encoded views in response to receiving the request such that the receiver can have several options of utilizing different pairs having different disparities to display the three dimensional content.
It should be noted that in method 700, all one or more base views are transmitted to the receiver regardless of any disparities selected at the receiver 304. Thus, to transmit a pair of views having a specified disparity to the receiver 304, the pair selector 314 can select or generate pairs of views by choosing the appropriate enhanced view or views for combination with the one or more base views. For example, with reference to
Having described preferred embodiments for a methods and systems for delivering three-dimensional media content, (which are intended to be illustrative and not limiting), it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. It is therefore to be understood that changes can be made in the particular embodiments of the invention disclosed which are within the scope of the invention as outlined by the appended claims. While the forgoing is directed to various embodiments of the present invention, other and further embodiments of the invention can be devised without departing from the basic scope thereof.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/US09/06167 | 11/18/2009 | WO | 00 | 5/10/2012 |