<html>
<head>
<title>
Light Fields
</title>
</head>
<body>

<h2>
Light Fields
</h2>

<blockquote>
CS 348B - Computer Graphics: Image Synthesis Techniques
<br>
Spring Quarter, 1997
<br>
(TA)  Lucas Pereira
<br>
Lecture notes for Tuesday, May 13, 1997
<br>
Handout #26
<br>
</blockquote>

<hr>
<h2>
Light Fields
</h2>

<h3> Contents: </h3>
<ul>
<li> Introduction:  Image-based rendering
<li> Background
<li> The light field
<li> Light field parameterization
<li> Is this really rendering at all?
<li> Sampling issues
<li> The line space dual
<li> Light field generation
<li> Light field compression
</ul>


<h3> Introduction:  Image-based rendering </h3>
<ul>
<li> <b> Image-based rendering</b> - Creating new views of a 3D
	environment based on existing images
<li> Why would we want image-based rendering?
	<ul>
	<li> Speed, Realism
		<ul>
		<li> Raytracers can't do 30 frames a second
		<li> Infinite Not-Quite-Reality
		</ul>
	</ul>
<li> Advantages:
	<ul>
	<li> Speed, independent of scene complexity
	<li> Source of images: real or synthetic
	</ul>
<li> Disadvantages:
	<ul>
	<li> Memory usage
	<li> Finite Resolution
	<li> Possibly high precomputation costs 
		(such as raytracing a billion pixels)
	</ul>
<li> Where have we seen image-based approaches before?
	<ul>
	<li> Texture-mapping
		<ul> 
		<li> Faster than a million polygons
		<li> More realistic than a Gouraud-interpolated plane
		</ul>
	<li> Environment-mapping
		<ul>
		<li> Direction-dependent
		<li> "Environment" picture mapped onto planes that
			don't really exist, but provide a nice
			parameterization
		</ul>
	</ul>
</ul>


<h3> Background </h3>
<ul>
<li> Chen & Williams (Siggraph '93)
	<ul>
	<li> When doing real-time fly-throughs, images are coherent
		(similar)
	<li> Morphing in-between images faster than rendering every
		image
	<li> Computing the warp: depends on object depth
	<li> Inverse velocity gives depth
	<li> Differences in depth cause missing pixels
	</ul>
<li> <a href="http://quicktimevr.apple.com">QuickTime VR </a>
	<ul>
	<li> panorama: 360-degree field of view, discrete locations
		<ul>
		<li> Viewer "jumps" from one discrete location to another
		</ul>
	<li> object: discrete locations around the object<br>
		<img src="2quicktimevr.gif">
	</ul>
</ul>

<h3> The light field </h3>
<ul>
<li> Samples the 4D flow of light in free space.
<li> Can reconstruct any view inside the convex hull (for
	outward-looking) or outside the convex hull (for inward-looking)<br>
	<img src="raycombine.gif">

<li> Webster Definitions:
	<ul>	
	<li> <b>Light</b> - electromagnetic energy in the visible 
		spectrum<br>
	<li> <b>Field</b> - a region or space in which a given effect 
		(such as magnetism) exists
	<li> <b>Render</b> - to reproduce or represent
	</ul>
<li> <b>Light field Rendering</b> -  To reproduce or represent an object 
	using the distribution of visible electromagnetic energy
	over a region of space
<li> <b>Plenoptic Field</b> - from latin "plenum", which was 
	once thought to be the ether through which 
	light flowed
</ul>

<h3> Light Field Parameterization </h3>
<ul>
<li> Fully general parameterization: from every point in space x,y,z (3D), x
	the light travelling in every direction s,t (2D), = 5D<br>
	<img src="lf5d.gif">
	<ul>
	<li> Equivalent to having an environment map for every
		point in space
	<li> Expensive - in free space, rays don't change along their 
		length
	</ul>


<li> 2-Plane parameterization: light in free space<br>
	<img src="lfparam.gif">
	<ul>
	<li> Each u,v,s,t specifies a unique line in freespace
	<li> Planes can be arbitrarily placed, even at infinity
	<li> Singularities: intersections, both planes at infinity
	<li> Everything is linear - an image from anywhere in space
		is a planar 2D "slice" in the 4D volume
		<ul>
		<li> This makes it easy for computers to compute quickly
		</ul>
	</ul>
</ul>

<h3> Is this really rendering at all? </h3>
<ul>
<li> <b>Rendering</b>: Generation of a 2D image from a 3D scene
		<i>(from lecture #1)</i>
	<ul>
	<li> Light fields satisfy that definition
	</ul>
<li> Ways to think about light fields
	<ol>
	<li> A rendering method
	<li> An object representation format
	<li> A caching method
	<li> A hidden-surface algorithm, with reflectance maps
	<li> An object simplification algorithm
	</ol>
</ul>

<h3> Sampling issues </h3>
<ul>
<li> Prefilter:<br>
	<img src = "prefilter.gif">
	<ul>
	<li> Each u,v,s,t pixel represents all the rays that
		pass through these two filter regions
	</ul>
<li> Postfilter:<br>
	<ul>
	<li> Quadralinear interpolation: convolve triangle filter
		in all 4 dimensions
		<ul>
		<li> This can be implemented as a bilinear interpolation
			between 4 bilinearly interpolated samples
		<li> 16 samples contribute to each screen pixel	
		</ul>
	<li> Faster: bilinear interpolation
		<ul>
		<li> Choose only two dimensions to filter, such as u-v
		<li> If we do this, we might want more resolution in
			the un-filtered two dimensions
			<ul>
			<li> Example: typical light field
				64x64 in uv, 256x256 in st
			</ul>
		</ul>
	<li> Fastest: point sampling
		<ul>
		<li> Grab the closest sample
		<li> See "jaggies" both in uv, and st<br>
			<img src="fulldragon.gif">
			<img src="dragon8.gif">

		</ul>
	<li> Minification:
		<ul>
		<li> Can build multiresolution pyramid, which would
			be 5D (An linear array of 4D structures)
		<li> Each level up is 1/16 the size -- So cost of
			the pyramid is trivial
		</ul>
	</ul>
</ul>


<h3> The line space dual </h3>

<ul>
<li> Nonuniform spatial resolution
	<ul>
	<li> A light field does not have uniform resolution throughout
		space
	<li> Uniform resolution impossible:
		<ul>
		<li> Memory is finite
		<li> 4D space is infinite
		<li> Uniform resolution everywhere means average 
			resolution is (memorysize / infinity), which
			is 0
		</ul>
	<li> Nonuniform resolution hard to visualize
	</ul>
<li> What do we care about, to generate an image of light field?
	<ul>
	<li> From a given viewpoint, what is the sample spacing
	<li> From a given viewpoint, what is the angular
		distribution
	</ul>
<li> The line space dual (in 2D) <br>
	<img src = "linespace.gif">
	<ul>
	<li> Lines in Cartesian space map to points in line space
	<li> Parallel lines map to a horizontal line in line space
	<li> Lines that pass through a single point map to a
		vertical line in line space
	<li> Density of points in line space show light field resolution
		in Cartesian space
	</ul>

</ul>




<h3> Light field generation </h3>

<ul>
<li> Object placement
	<ul>
	<li> Typically, a surface has higher spatial variation than 
		angular variation
	<li> Remember bilinear filtering is cheaper, so we often
		have nonuniform spatial resolution
	<li> Place object so that its spatial variation corresponds
		to highest region of spatial resolution
	<li> If st plane is higher resolution, place object near st plane
	<li> Often refer to st plane as "focal plane", and uv as
		"camera plane"
	<li> Effects of low linespace resolution: blurring<br>
		<img src="crystal.gif">
	</ul>
<li> Sheared projection
	<ul>
	<li> Each view from a uv "camera location" is a sheared
		projection<br>
	<img src="sheared.gif">
	<li> For acquired light fields, camera was rotated instead of
		sheared, so we have to warp the images
	<li> For synthetic light fields, shear is not a problem	
	</ul>
</ul>

<h3> Light Field Compression </h3>
<ul>
<li> Two big disadvantages: memory usage, finite resolution
	<ul>
	<li> Closely related: without memory restrictions, we could
		do far higher resolution
	<li> Solution: compression
		<ul>
		<li> Light fields have huge coherence
		<li> Each closely-spaced image is very similar
		<li> Surface reflection map generally low frequency
		</ul>
	</ul>
<li> Current solution: vector quantization
	<ul>
	<li> Codebook represents block of pixels
	<li> Codebook learned on "training set"
	<li> Indices choose best codebook for each tile of light field
	<li> Typical: 
		<ul>
		<li> 2-byte index (64K Codebook entries)
		<li> 2x2x2x2 pixels, x3 colors = 48 bytes
		<li> compression: 48:2, or 24:1
		</ul>
	<li> Example: Buddha light field
		<ul>
		<li> 32 x 32 x 256 x 256 x 3 = 192 MB
		<li> 24:1 compression =  8 MB of indices
		<li> 32K codebook entries x 48 bytes = 1.5 MB
		<li> Total size: 8 + 1.5 = 9.5 MB
		</ul>
	</ul>
<li> Future solution: "motion" estimation?
	<ul>
	<li> In epipolar space (e.g. u-s), points in space form
		lines in a light field<br>
		<img src="sliceus.gif">
	<li> Slope of the line depends on depth of the point
	<li> We are trying to represent this set of lines as
	     a textured polygon and motion vectors
	<li> Similar to mpeg, in theory
	<li> In practice, needs to be random-access for rendering
	<li> Calculating "velocity" of the planes equal to
		Chen & Williams calculating depth
	<li> Then, just render the textured polygon in the right
		place, to get 4D sample
		<ul>
		<li> Once again, we only filtering in 2D
		<li> This is reminiscent of hidden surface algorithm,
			where for each local area, there is only
			one valid plane
		</ul>
	<li> This is the topic of my current research (along with
		Ben Zhu)
	</ul>
</ul>











<hr>	

<address>
lucasp@graphics.stanford.edu
</address>
<b>Copyright &copy; 1997 Lucas Pereira</b>
<br>
Last update:
Tuesday, 13-May-97 

</body>
</html>


	
