Capturing and rendering light-field video: Approaches and challenges
CC Attribution - NoDerivatives 2.0 UK: England & Wales:
You are free to use, copy, distribute and transmit the work or content in unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Milliron, Tim
Lytro is building a revolutionary system to record and render the light-field of live-action video, enabling viewers to immerse themselves in 3D cinematic VR experiences. In this presentation, we will describe our system design for capturing, processing, and rendering light-field video and discuss the significant data and computing challenges to be solved on our journey. 
 10, capturing and rendering light field video from Tim Millerin, Milliron, who is perhaps the VP of Engineering at Lytro. Do I have that part right? Awesome. So he's certainly the VP of Engineering at Lytro. And prior to that, you were at Pixar doing more jobs I can remember from your LinkedIn profile. The tricky one with the computers. So hi, everybody. I'm Tim Millerin. I'm the Vice President of Engineering at Lytro. As I was introduced, I spent about 12 years at Pixar and the last five years at a little company called Twilio, which is a telecom startup. You can ask me about how that transition happened later. But today I'm going to talk about capturing and rendering light field video. And in particular, at Lytro, we're building a system that I'm going to talk quite a bit about called the Lytro Emerge. Lytro Emerge is a 360-degree light field capture device and end-to-end solution for playback. And I'm going to talk a little bit about the approaches that we're undertaking to build that as well as the challenges that we're seeing there. So first of all, a little bit about Lytro. So Lytro was founded in 2006. And I think Lytro's big claim to fame is that the company was the first to bring a planoptic camera to market. Some of you may actually remember this. It was an odd little thing. It looked kind of like a stick of butter. We call it the butter stick at Lytro. It had a fixed lens. And most importantly, it had a micro lens array that sat in front of the sensor that captured the light field that was coming into the lens of the camera. So you got some really interesting effects. And it allowed photographers to do things that they'd never really done before, like, for instance, changing focus of a picture after the fact, because we have all of this light field information. In 2014, we launched our second camera called the Lytro Illume. The Lytro Illume was obviously a much bigger camera. It had a much better lens. And it could produce sort of professional level quality pictures. But both of these two cameras, even though they allowed photographers to do things that they'd never done before that were never possible, they have big trade-offs in terms of resolution and in terms of cost. Because by capturing the entire light field, we have to throw away some image density, some resolution in the final 2D camera. So these were really the only, these consumer cameras, really the only things we could build at the time that they were launched. But of course, with Moore's law, we now have, and continue to have, exponentially increasing storage density and computing power. We also have the cloud that gives us an exponentially lot more computing power on demand. And so now more applications are finally within the reach of light field technology, although, as you'll see, just barely within the reach of light field technology. And so last October, we announced LytroEmerge. So this is a conceptual rendering of what the emerge will look like. This is a 360-degree light field camera device. It's about three-quarters of a meter across. So you can think of this as capturing the light field volume within that three-quarters of a meter. That allows you to do interesting things like move your head around within that volume, and get true parallax effects and real-time light, and, oh, sorry, few dependent lighting effects and so on. So the viewer can move their head around inside this volume and really give you a lot more from VR. Why do we care about this? We care about this in a word because of presence. So I'm curious, how many of you have put on a headset and watched a 360-degree video? Okay, a lot of you. Stereoscopic 360-degree video and some actual computer-generated content. Probably everybody. So there's a real big difference between those different levels in terms of what the VR experience is, and it really has a lot to do with presence. You obviously are throwing away a ton of information in a 360 video. You can move your head around. You can rotate your head, but you can't get any parallax effects. You can't feel as if you're there quite the same way. And in some of these CG demos that we see in VR, you have a much more immersive experience. You feel like you're in that environment because that environment responds to everything you're doing on a headset like the Oculus. So 6 degrees of freedom really puts you there, and I think that's what we're all excited about with VR, but we don't have the capability yet to capture that in live action. So Emerge was an announcement that we made to build, and based on things that we believe that we can build and things that we are building today, there's a ton of engineering work going on with a team of about 30 at Lightro today to bring it to market and to actually productize it and make it useful. And in this talk, what I'm going to do is I'm going to dive into and give you a sneak peek into the system architecture of Emerge and discuss some of the big computing and algorithmic challenges that we have in order to finally bring it to market. So first thing I want to point out is that Emerge is different than our previous cameras. Our previous cameras used microlenses, and they were true phenoptic cameras. Emerge is different than that, Emerge is a multi-camera system, but it uses all the same principles of light field. So let's dive into the architecture here. So there's really four key pieces to the architecture. One is capture. Now, of course, that includes the camera, and we'll talk a little bit about how many cameras we have in this array, how configurable it is, that kind of thing. But because of the enormous data rates, which again we'll talk more about as well, there's also an on-set server that will sit 50 meters, 100 meters away from the production that actually captures the data. And we need to do this on-site because of enormous IO throughput that you'll see in a bit. The second phase is construction. Taking that raw information, the raw capture from these 60, 100, couple hundred cameras, and then turning that into a light field representation that we can use further down in the pipeline. Editing is a really important part that's often left out of this. Content creators are really used to editing their footage after the fact. Because they're doing that in VR, especially for repair, to smooth out seam lines in a 360 stitched video, for instance, but also frequently they're doing that for creative reasons as well. And so editing is a really important part, and light field editing in particular is very challenging because of the enormous data that you have, the redundancy of information, and figuring out a way for those content creators to use the tools that they're used to in order to do editing is key. And then finally, of course, there's playback on the headset. So it's really these four key areas, these four pieces of the system that provide an end-to-end experience for content creators to shoot their footage, produce it, and then actually play it back on the device. So I'm going to walk through what the system goals are for these in brief, just to give you a sense. And then we'll start talking about some of the big computing challenges and how we're thinking about solving them. So first of all, light field capture. We want to match the native frame rates on the latest generation displays, or the displays that will be out later this year. So we're talking about 90 frames per second for creative content. This needs to be a 10-bit of HDR. And in terms of the practical considerations of how you use this thing on set, it needs to be able to store hours of footage at a time on our servers. So you go to set, strike times on sets, usually 7 AM, and then you work until about 5. You're not going to capture all 10 hours of that footage, but you need to be able to capture probably three or four hours of footage all in one go. In terms of light field construction, for those of you not familiar with how the film and video production process works, the usual expectation is you show up today on Monday morning, you shoot your stuff all day long, and then you go home, everybody takes a rest, and then tomorrow morning you come back in and you expect to see what are called dailies. You expect to see whatever you shot yesterday projected on screen. Now in the case of VR, what we're expecting is that you need to be able to put on the headset and see what you got so that you know what decisions you need to make in terms of shooting for that day. And so targeting a nightly turnaround time to be able to take the hours of footage that we have captured on day one and then be able to play that back on the morning of day two is a really important part of the process. In terms of light field editing, again, content creators are very used to editing their content after the fact, but in this case we now have tens or hundreds of camera views or we have a light field. And so we need to come up with tools for content creators either to propagate their edits between cameras possibly or to efficiently edit the light field directly, which is of course a new territory that we haven't done before. And then finally, in terms of light field playback, we need to be able to play back again 360 degrees of this one meter sized volleyball or sort of beach ball size that's around your shoulders at 90 FPS and on what I'm calling commodity hardware. Make no mistake about it. In the early days, I doubt very much that my machine here, little MacBook Pro, is going to be able to play back this content, but we do need to be able to play this back on sort of a big, beefy gaming box rather than a supercomputer. So there are obviously a bunch of challenges here and what I'm going to talk through first is each of those challenges across each of these areas and also the solutions that we're attempting to roll out for these. There are some really big, interesting challenges both on the hardware side and on the software side. So let's dive into capture, first of all. So on the capture side, just to give you a sense of the scale of the system, our system will operate. We're still figuring out densities and there is configurability so that you can shoot 90 degrees, 180 degrees, 360 degrees. But we're talking about 60 to 200 cameras, give or take, so dozens to hundreds of cameras. Each of those is capturing a 2K by 2K stream at 10 bits at 90 FPS. And so just doing the math, for those of you who are doing math at home, that is almost 100 gigabytes per second of data rate from the camera to the servers, which is obviously a lot. And again, doing the math, that means about 6 terabytes per minute of storage. This is obviously an enormous system, very high-cost system to be able to do all of this. But most importantly is the IO throughput that's required in order to get to that system. And so our system engineers have done a lot of work in terms of how many computers or how many cameras can wire into each computer, what are the drives, what are the cards that you need in order to do camera intake in order to be able to support these massive data rates. And then of course, as I said, we need to do hours of stored footage on set, which means those computers need to be pretty big as well. On the construction side, there are a couple of things that are really important. So obviously we're synthesizing views from the fundamental footage, the raw footage, from tens or hundreds of cameras. That means that we need really accurate color and positional information and calibration information from the cameras. So that's kind of table stakes. The good news at LITRO is that because we're a consumer manufacturing company for a while and we're used to dealing with MLA's and sensors that were all different, but we had to produce good images with all of them, we're really good at this kind of thing. But we also need accurate depth information. And the reason for that is that even though we are very much an image-based approach, in order to get away with dozens or hundreds of cameras instead of say thousands or tens of thousands of cameras where you could do pure image interpolation, our light field algorithms rely on reasonably accurate depth information for view interpolation. So you require that reconstruction as well. So the good news here, of course, is that we have tons of data to work from to get accurate depth. We have dozens or hundreds of camera viewpoints and we have a pretty good notion about where those cameras are, but it's still a very difficult problem to solve. So there's no way around this. This takes a lot of time. Right now we run at about 30 seconds per, sorry, 30 minutes per frame. That can certainly be optimized, but it's certainly not going to become milliseconds per frame for free. And then just as you think, well, that's okay. You just throw it up all to the cloud. Remember the data transfer rates. So transferring to the cloud over my very fast internet connection at home at 100 megabits per second, assuming that I could get that from Comcast, would take dozens of hours per minute of footage. So you have to think a little bit outside the box here. So on the depth reconstruction side, there's really no other way around this. You just need to hire the best people on the planet in order to solve these problems. There are some breakthroughs that will be needed before we get to truly great depth information there as well. And then on the cloud side, it is true that actually the cloud is the way to get to nighttime processing. You can't build a portable 1000 node render farm that rolls around with your camera. And so we do need to solve this with cloud, but you consider some unconventional cloud transfer techniques. And what I mean by unconventional is, for instance, you might take your servers and you might take them off of set at 5 p.m. and drive them to a co-location facility somewhere nearby the set, perhaps in LA, if you're shooting in LA, and plug it into a terabit ethernet connection to S3 or to Azure or to Google Cloud. And so there are some very interesting ways that we might sort of transfer this data to the cloud and get it there quickly, but do it in sort of unconventional ways. Another trick very frequently used in the film and video production area is to actually ship hard drives. So hard drives get FedExed back and forth from San Francisco to LA all the time. And so getting to that overnight time that we need is really going to be dependent in large part on the data transfer and some unconventional ways of doing that. On the editing side, again, we run into the big problem of light field size data processing, which is very different than image size data processing. So the key thing here is that artists are not going to change their workflows. And so we are building a set of plugins in standard VFX tools. One of the big requirements is that whatever artists are currently using, they need to be able to continue to use. Nuke by the Foundry is one of the dominant packages here. And so we are using that and building for that first and then other things later. But the workflow that we actually imagine is that Nuke is actually running in the cloud. And you are running on a cloud data set, running in the cloud, or some other packages running in the cloud. And there's a lot of work that's happening in this regard, but very much of it is not all the way there yet. And then finally, on the playback side, again, data rates. We're talking about 40 gigabytes per second in order to store on the local disk. We don't actually need all of that in order to play back through the headset. We have ways of pruning that. But we are talking about a gigabyte a second or so of data rate from the disk in order to get into the display and play through the GPU and the CPU. And so no magic here. The secret is really codex, codex, codex. The great news is that light field provides us with a plethora of ways that we can compress. Of course, you have your image space compression and your temporal compression. But we also have a lot of redundancy in the light field volume itself. Most of the views within the volume are very similar to other views. And so there are great opportunities to do a lot of compression there that's really quite novel and that can get us down to file sizes that probably won't be able to stream any time soon, but that at least can play back and fit on a normal hard drive. So I think that gives you a pretty good sense of what we're building and what some of the big computational challenges are there. We're really and incredibly excited to bring light field technology into this new industry and we can't wait to see how it evolves and how people start using it. Thank you. That's all I had. I'm happy to take any questions. To start with, a number of people from different standard levels are actually living dorms.
 10, capturing and rendering light field video from Tim Millerin, Milliron, who is perhaps  the VP of Engineering at Lytro.  Do I have that part right?  Awesome.  So he's certainly the VP of Engineering at Lytro.  And prior to that, you were at Pixar doing more jobs I can remember from your LinkedIn  profile.  The tricky one with the computers.  So hi, everybody.  I'm Tim Millerin.  I'm the Vice President of Engineering at Lytro.  As I was introduced, I spent about 12 years at Pixar and the last five years at a little  company called Twilio, which is a telecom startup.  You can ask me about how that transition happened later.  But today I'm going to talk about capturing and rendering light field video.  And in particular, at Lytro, we're building a system that I'm going to talk quite a bit  about called the Lytro Emerge.  Lytro Emerge is a 360-degree light field capture device and end-to-end solution for playback.  And I'm going to talk a little bit about the approaches that we're undertaking to build  that as well as the challenges that we're seeing there.  So first of all, a little bit about Lytro.  So Lytro was founded in 2006.  And I think Lytro's big claim to fame is that the company was the first to bring a planoptic  camera to market.  Some of you may actually remember this.  It was an odd little thing.  It looked kind of like a stick of butter.  We call it the butter stick at Lytro.  It had a fixed lens.  And most importantly, it had a micro lens array that sat in front of the sensor that  captured the light field that was coming into the lens of the camera.  So you got some really interesting effects.  And it allowed photographers to do things that they'd never really done before, like,  for instance, changing focus of a picture after the fact, because we have all of this  light field information.  In 2014, we launched our second camera called the Lytro Illume.  The Lytro Illume was obviously a much bigger camera.  It had a much better lens.  And it could produce sort of professional level quality pictures.  But both of these two cameras, even though they allowed photographers to do things that  they'd never done before that were never possible, they have big trade-offs in terms of resolution  and in terms of cost.  Because by capturing the entire light field, we have to throw away some image density,  some resolution in the final 2D camera.  So these were really the only, these consumer cameras, really the only things we could build  at the time that they were launched.  But of course, with Moore's law, we now have, and continue to have, exponentially increasing  storage density and computing power.  We also have the cloud that gives us an exponentially lot more computing power on demand.  And so now more applications are finally within the reach of light field technology, although,  as you'll see, just barely within the reach of light field technology.  And so last October, we announced LytroEmerge.  So this is a conceptual rendering of what the emerge will look like.  This is a 360-degree light field camera device.  It's about three-quarters of a meter across.  So you can think of this as capturing the light field volume within that three-quarters  of a meter.  That allows you to do interesting things like move your head around within that volume,  and get true parallax effects and real-time light, and, oh, sorry, few dependent lighting  effects and so on.  So the viewer can move their head around inside this volume and really give you a lot more  from VR.  Why do we care about this?  We care about this in a word because of presence.  So I'm curious, how many of you have put on a headset and watched a 360-degree video?  Okay, a lot of you.  Stereoscopic 360-degree video and some actual computer-generated content.  Probably everybody.  So there's a real big difference between those different levels in terms of what the VR experience  is, and it really has a lot to do with presence.  You obviously are throwing away a ton of information in a 360 video.  You can move your head around.  You can rotate your head, but you can't get any parallax effects.  You can't feel as if you're there quite the same way.  And in some of these CG demos that we see in VR, you have a much more immersive experience.  You feel like you're in that environment because that environment responds to everything you're  doing on a headset like the Oculus.  So 6 degrees of freedom really puts you there, and I think that's what we're all excited  about with VR, but we don't have the capability yet to capture that in live action.  So Emerge was an announcement that we made to build, and based on things that we believe  that we can build and things that we are building today, there's a ton of engineering work going  on with a team of about 30 at Lightro today to bring it to market and to actually productize  it and make it useful.  And in this talk, what I'm going to do is I'm going to dive into and give you a sneak  peek into the system architecture of Emerge and discuss some of the big computing and  algorithmic challenges that we have in order to finally bring it to market.  So first thing I want to point out is that Emerge is different than our previous cameras.  Our previous cameras used microlenses, and they were true phenoptic cameras.  Emerge is different than that, Emerge is a multi-camera system, but it uses all the  same principles of light field.  So let's dive into the architecture here.  So there's really four key pieces to the architecture.  One is capture.  Now, of course, that includes the camera, and we'll talk a little bit about how many  cameras we have in this array, how configurable it is, that kind of thing.  But because of the enormous data rates, which again we'll talk more about as well, there's  also an on-set server that will sit 50 meters, 100 meters away from the production that actually  captures the data.  And we need to do this on-site because of enormous IO throughput that you'll see in  a bit.  The second phase is construction.  Taking that raw information, the raw capture from these 60, 100, couple hundred cameras,  and then turning that into a light field representation that we can use further down in the pipeline.  Editing is a really important part that's often left out of this.  Content creators are really used to editing their footage after the fact.  Because they're doing that in VR, especially for repair, to smooth out seam lines in a 360  stitched video, for instance, but also frequently they're doing that for creative reasons as  well.  And so editing is a really important part, and light field editing in particular is very  challenging because of the enormous data that you have, the redundancy of information,  and figuring out a way for those content creators to use the tools that they're used to in order  to do editing is key.  And then finally, of course, there's playback on the headset.  So it's really these four key areas, these four pieces of the system that provide an  end-to-end experience for content creators to shoot their footage, produce it, and then  actually play it back on the device.  So I'm going to walk through what the system goals are for these in brief, just to give  you a sense.  And then we'll start talking about some of the big computing challenges and how we're  thinking about solving them.  So first of all, light field capture.  We want to match the native frame rates on the latest generation displays, or the displays  that will be out later this year.  So we're talking about 90 frames per second for creative content.  This needs to be a 10-bit of HDR.  And in terms of the practical considerations of how you use this thing on set, it needs  to be able to store hours of footage at a time on our servers.  So you go to set, strike times on sets, usually 7 AM, and then you work until about 5.  You're not going to capture all 10 hours of that footage, but you need to be able to capture  probably three or four hours of footage all in one go.  In terms of light field construction, for those of you not familiar with how the film  and video production process works, the usual expectation is you show up today on Monday  morning, you shoot your stuff all day long, and then you go home, everybody takes a rest,  and then tomorrow morning you come back in and you expect to see what are called dailies.  You expect to see whatever you shot yesterday projected on screen.  Now in the case of VR, what we're expecting is that you need to be able to put on the  headset and see what you got so that you know what decisions you need to make in terms of  shooting for that day.  And so targeting a nightly turnaround time to be able to take the hours of footage that  we have captured on day one and then be able to play that back on the morning of day two  is a really important part of the process.  In terms of light field editing, again, content creators are very used to editing their content  after the fact, but in this case we now have tens or hundreds of camera views or we have  a light field.  And so we need to come up with tools for content creators either to propagate their edits between  cameras possibly or to efficiently edit the light field directly, which is of course a  new territory that we haven't done before.  And then finally, in terms of light field playback, we need to be able to play back  again 360 degrees of this one meter sized volleyball or sort of beach ball size that's  around your shoulders at 90 FPS and on what I'm calling commodity hardware.  Make no mistake about it.  In the early days, I doubt very much that my machine here, little MacBook Pro, is going  to be able to play back this content, but we do need to be able to play this back on  sort of a big, beefy gaming box rather than a supercomputer.  So there are obviously a bunch of challenges here and what I'm going to talk through first  is each of those challenges across each of these areas and also the solutions that we're  attempting to roll out for these.  There are some really big, interesting challenges both on the hardware side and on the software  side.  So let's dive into capture, first of all.  So on the capture side, just to give you a sense of the scale of the system, our system  will operate.  We're still figuring out densities and there is configurability so that you can shoot 90  degrees, 180 degrees, 360 degrees.  But we're talking about 60 to 200 cameras, give or take, so dozens to hundreds of cameras.  Each of those is capturing a 2K by 2K stream at 10 bits at 90 FPS.  And so just doing the math, for those of you who are doing math at home, that is almost  100 gigabytes per second of data rate from the camera to the servers, which is obviously  a lot.  And again, doing the math, that means about 6 terabytes per minute of storage.  This is obviously an enormous system, very high-cost system to be able to do all of this.  But most importantly is the IO throughput that's required in order to get to that system.  And so our system engineers have done a lot of work in terms of how many computers or  how many cameras can wire into each computer, what are the drives, what are the cards that  you need in order to do camera intake in order to be able to support these massive data rates.  And then of course, as I said, we need to do hours of stored footage on set, which means  those computers need to be pretty big as well.  On the construction side, there are a couple of things that are really important.  So obviously we're synthesizing views from the fundamental footage, the raw footage,  from tens or hundreds of cameras.  That means that we need really accurate color and positional information and calibration  information from the cameras.  So that's kind of table stakes.  The good news at LITRO is that because we're a consumer manufacturing company for a while  and we're used to dealing with MLA's and sensors that were all different, but we had  to produce good images with all of them, we're really good at this kind of thing.  But we also need accurate depth information.  And the reason for that is that even though we are very much an image-based approach,  in order to get away with dozens or hundreds of cameras instead of say thousands or tens  of thousands of cameras where you could do pure image interpolation, our light field  algorithms rely on reasonably accurate depth information for view interpolation.  So you require that reconstruction as well.  So the good news here, of course, is that we have tons of data to work from to get accurate  depth.  We have dozens or hundreds of camera viewpoints and we have a pretty good notion about where  those cameras are, but it's still a very difficult problem to solve.  So there's no way around this.  This takes a lot of time.  Right now we run at about 30 seconds per, sorry, 30 minutes per frame.  That can certainly be optimized, but it's certainly not going to become milliseconds  per frame for free.  And then just as you think, well, that's okay.  You just throw it up all to the cloud.  Remember the data transfer rates.  So transferring to the cloud over my very fast internet connection at home at 100 megabits  per second, assuming that I could get that from Comcast, would take dozens of hours per  minute of footage.  So you have to think a little bit outside the box here.  So on the depth reconstruction side, there's really no other way around this.  You just need to hire the best people on the planet in order to solve these problems.  There are some breakthroughs that will be needed before we get to truly great depth  information there as well.  And then on the cloud side, it is true that actually the cloud is the way to get to nighttime  processing.  You can't build a portable 1000 node render farm that rolls around with your camera.  And so we do need to solve this with cloud, but you consider some unconventional cloud  transfer techniques.  And what I mean by unconventional is, for instance, you might take your servers and  you might take them off of set at 5 p.m. and drive them to a co-location facility somewhere  nearby the set, perhaps in LA, if you're shooting in LA, and plug it into a terabit ethernet  connection to S3 or to Azure or to Google Cloud.  And so there are some very interesting ways that we might sort of transfer this data to  the cloud and get it there quickly, but do it in sort of unconventional ways.  Another trick very frequently used in the film and video production area is to actually  ship hard drives.  So hard drives get FedExed back and forth from San Francisco to LA all the time.  And so getting to that overnight time that we need is really going to be dependent in  large part on the data transfer and some unconventional ways of doing that.  On the editing side, again, we run into the big problem of light field size data processing,  which is very different than image size data processing.  So the key thing here is that artists are not going to change their workflows.  And so we are building a set of plugins in standard VFX tools.  One of the big requirements is that whatever artists are currently using, they need to  be able to continue to use.  Nuke by the Foundry is one of the dominant packages here.  And so we are using that and building for that first and then other things later.  But the workflow that we actually imagine is that Nuke is actually running in the cloud.  And you are running on a cloud data set, running in the cloud, or some other packages running  in the cloud.  And there's a lot of work that's happening in this regard, but very much of it is not  all the way there yet.  And then finally, on the playback side, again, data rates.  We're talking about 40 gigabytes per second in order to store on the local disk.  We don't actually need all of that in order to play back through the headset.  We have ways of pruning that.  But we are talking about a gigabyte a second or so of data rate from the disk in order  to get into the display and play through the GPU and the CPU.  And so no magic here.  The secret is really codex, codex, codex.  The great news is that light field provides us with a plethora of ways that we can compress.  Of course, you have your image space compression and your temporal compression.  But we also have a lot of redundancy in the light field volume itself.  Most of the views within the volume are very similar to other views.  And so there are great opportunities to do a lot of compression there that's really  quite novel and that can get us down to file sizes that probably won't be able to stream  any time soon, but that at least can play back and fit on a normal hard drive.  So I think that gives you a pretty good sense of what we're building and what some of the  big computational challenges are there.  We're really and incredibly excited to bring light field technology into this new industry  and we can't wait to see how it evolves and how people start using it.  Thank you.  That's all I had.  I'm happy to take any questions.  To start with, a number of people from different standard levels are actually living dorms.
SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_0_1715.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_1716_1847.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_1848_4751.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_4752_5543.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_5544_7991.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_7992_8279.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_8280_9131.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_9132_13199.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_13200_13271.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_13272_13775.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_13776_14879.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_14880_14975.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_14976_15071.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_15072_16583.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_16584_20315.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_20316_21131.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_21132_21623.png SD_A_2016__Capturing_and_rendering_light-field_video__Approaches_and_challenges_rF3Vv78QRtk_21624_22480.png