Focal Length

Focal length seems to be the most troublesome optical system parameter. It is the number most often converted to 35mm equivalents. Most compact consumer-grade cameras will omit actual focal length from advertising material, since the actual numbers give very little useful information. The main parameter implied from the 35mm equivalent focal length is field-of-view. It makes more sense to skip converting to a 35mm equivalent and simply advertising a lens' field of view directly. Not only would it preclude calculating equivalent focal lengths for comparison, but it would actually give you more information than focal length does, since you could immediately start to visualize how wide or narrow your view would be.

f-stop

Second, f-stop numbers are inherently confusing and unintuitive. Even though f-stop is independent of sensor size and gives a very good estimate of the light gathering power of a lens, it is a poor metric for two reasons: A higher f-stop number indicates less light gathering power, and different f-stop numbers cannot be compared to each other directly with a simple linear relationship. That is, f-stop is inversely proportional to aperture diameter, but the light gathering power is proportional to the square of aperture diameter. This means that f-stop numbers must be squared to be compared with a linear relationship. I recommend writing f-stop numbers as a squared square-root. That is, f/1.4 becomes f/√2, f/2.0 becomes f/√4, f/2.8 becomes f/√8, etc.

This change allows for linear comparison between numbers under the radical sign. However it does not solve the problem of having an inverse relationship when we probably want an arguably more-intuitive direct relationship. The only solution I can think of for this problem is reformulating f-stop from a divisor of focal length to a multiple of focal length. For example: f/1.4 becomes (1/2)f√2, f/2.0 becomes (1/4)f√4, f/2.8 becomes (1/8)f√8. While this nomenclature may seem more cumbersome, a photographer would only need concern themselves with the multiplier in front of the f, omitting the radical expression. This allows for direct comparison of f-stop numbers with a linear relationship and gives a direct relationship between light-gathering power and this number. It's immediately apparent that f/1.4 gives you half the light of f/1.0 when you write these numbers instead as (1/2)f and (1)f, respectively (with the omitted √2 and √1 being implicit).

If this implicit multiplier is too confusing, and "backwards-compatibility" with current f-stop numbers is desired, another possibility is simply re-factoring in a way that keeps 'old' numbers, with these 'new' squared factors as divisors. Examples: f/1.4 becomes f1.4/2, f/2 becomes f2/4, f/2.8 becomes f2.8/8, f/4 becomes f4/16, etc. The divisor tells you light gathering power relative to f/1, while the numerator tells you an equivalence to 'old' values, i.e. the same fraction written as 1/f-number. It would be nice to replace the old system completely, but this might be a nice compromise.

Defocus Blur

Another problem that has arisen with many different sized camera sensors is that there aren't good numbers to indicate how much control a given optical system gives a photographer over defocus blur (limiting depth of field). Usually, the focal length of a non-35mm sensor system is converted into an equivalent field of view for a 35mm system, using the crop factor. The f-stop number is then scaled by this same crop factor. A photographer can then compare these numbers to lenses within the 35mm system, which they are presumably more familiar with. This is fine for an experienced photographer, but those less experienced will probably find this procedure confusing and labor-intensive. Here the relationship with f-stop is linear and simple, but the relationship with focal length is complex. Doubling focal length gives you about one-fourth the depth of field. Even given focal length and f-stop in 35mm equivalents, it's still difficult to understand how changing these numbers changes the depth of field. For example, it's not immediately obvious whether a 50mm f/1.8 lens can give you a shallower depth of field than a 75mm f/4 lens.

As a solution, I suggest adding a new sensor-independent number to camera system and lens parameters. This number would simply be the aperture diameter multiplied by the focal length (which is focal length squared divided by f-number). This number is proportional to hyperfocal distance, and is easily calculated with commonly used lens parameters. By listing this number with lens parameters, photographers can more easily understand the depth-of-field capabilities of different lenses in different sensor-format systems. Compared to using 35mm equivalents, this number would allow for a much more straight-forward comparisons. A higher lens number means a higher control over limiting depth of field. Also, differences in these depth-of-field units translate directly into proportional differences of depth of field.

The one drawback of this approach is that I have not factored in sensor size. If you view images from different sensor formats at the same size, then this needs to be factored in. The image from a smaller sensor needs to be enlarged more to be viewed at the same size as an image from a larger sensor. What is acceptably sharp on the enlargement from a larger sensor may not be acceptably sharp at that same size when using a smaller sensor. Basically, we need to factor in the "circle of confusion" (CoC) of a given sensor, which is a function of various parameters. However, if we only seek to compare sensor and lens combinations to one another, we only need to know the relative size of circles of confusion to one another, controlling for the required viewing size and resolution of the image. These ratios come back to the crop factor, the ratio of sensor diagonals. Factoring in the CoC, we would simply quote Hyperfocal distance for a a lens/sensor combination at its widest aperture, using some standard CoC number for each sensor size. I'm really not sure why things like the wikipedia topic on this issue seem to be so obfuscating. Comparing hyperfocal distances at maximum aperture seems to simplify things considerably.

Sensor Size and Resolution

Full-frame, or medium-format cameras have much more light-gathering ability than smaller camera sensors because they are larger in area. Consequently individual photo-sensing pixels are usually larger as well, although usually not by the same ratio. For examples, the 4/3rds sensor format is about 1/4th the area of a full-frame sensor. This gives the sensor about 1/4th the light gathering power, as a whole. Most current 4/3rds sensors are either 12 or 16 megapixels. If these sensors were scaled up to full-frame with the same pixel density, they would be 48 and 64 megapixels, respectively. The full-frame Nikon D800 has a 36 megapixel sensor. This means that a 12 megapixel 4/3rds sensor has pixels with surface area almost as large as those of this particular Nikon. If a 4/3rds sensor had around 8 megapixels, then we might expect the light gathering performance per-pixel of this sensor to be on-par with the full-frame camera's performance.

Pixel size is important for the same reason sensor size is important, light gathering power, but also because it determines how finely detail can be resolved. Larger pixels mean more light gathering, but also, less spatial resolution. This can be thought of as a trade-off between temporal and spatial resolution. Bigger pixels allow for faster shutter speeds, but give you less detail. You can increase both temporal and spatial resolution if you make the sensors bigger, but if you constrain sensor size then you have to make a choice between the two. As I write this, camera makers still seem to be (slowly) increasing megapixel counts. This is a predictable consequence of primarily emphasizing the number of pixels on a sensor: pixel counts are optimized and unmeasured parameters are largely ignored. (This seems a universal principle: what you measure is where your effort goes, so choose your metrics wisely.)

As a solution, I suggest adding pixel area to the stats for camera sensors. This serves two purposes. First, it allows simple comparisons to be made between cameras with different sensor sizes. It gives a good indication of the per-pixel temporal resolution performance of a sensor. Second, measuring this number provides slight push-back on the race for more and more megapixels. Given another metric to measure performance, camera companies would presumably seek to optimize both pixel counts and pixel areas, balancing temporal and spatial performance. Most photographers do not require the level of spatial resolution offered by current camera sensors. However, temporal resolution, low-light performance, etc. could still be improved almost without exception. Having a specific metric which correlates strongly with this performance will push camera companies to improve in this direction, and help keep them from pushing for more impressive megapixel numbers. If we have more megapixels than most people can use, but many are still asking for better low-light performance, then clearly the current pixel size that most manufacturers choose is not ideal, and there is still room for optimization. Personally, I would gladly trade better low-light performance for lower resolution images.

Examples

Power

Most radiometric quantities are measured in terms of power. In radiometry, power is calculated over all wavelengths of electromagnetic radiation. In computer graphics, we are only interested in visible light: electromagnetic radiation with wavelengths between 400 and 800 nanometers. In general, power in computer graphics is further simplified to calculations done at only three discrete wavelengths. We calculate power at only three discrete wavelengths because our color displays only require this data to display a color image. \footnote{Power over a narrow band of electromagnetic radiation is known specifically as Spectral power. Computing radiometric quantities in terms of Spectral power is known as Spectroradiometry. However, being this precise can be cumbersome and it is rarely done in computer graphics literature. Likewise, we will trade precision for simplicity and not distinguish between Radiometry and Spectroradiometry.}

As with the discretization of radiometry into three color channels, the main goal of most computer graphics is rendering of images to color displays. Our rendering is calculated with the output in mind. For this reason, it is unusual to formalize rendering results to absolute units. Instead, power is measured as a relative quantity, relative either to other values within a rendering, or to the output capabilities of the color display being used.

Power is energy per unit time. In addition to being discretized into measurement over narrow wavelength bands of the electromagnetic spectrum and rarely being measured in absolute terms, the time component of power calculations is also usually only measured implicitly, in relative terms.

Radiance

Radiance represents the power per unit solid angle per unit projected area. In a color rendering, we can think of each final pixel color as representing a radiance measurement. The surfaces in the image are projected from the 3D scene world into a 2D image. We see the power reflected off of these surfaces through the solid angle of each pixel area, relative to some virtual eye location. We can see how this represents a measurement of power per unit solid angle per unit projected area since we average over the pixel to arrive at a final pixel color.

With ray tracing, we shoot virtual rays from the eye through the pixels to calculate the reflected power that passes through each. Each ray is a radiance query where we calculate the radiance $L$ reflected in the ray direction $\hat{v}$ from the surface intersection point $\vec{p}$, specifically $L(\vec{p},\hat{v})$. In order to calculate the reflected radiance, we need to know how much power is incident on the surface (irradiance) and also model in some way how incident light is reflected.

Irradiance and Radiosity

Irradiance is how much power is incident on a surface per unit area. As a first step to calculating how much power a surface reflects in any given direction, we need to know how much power is incident on that surface. Given an incoming radiance value for some small solid angle $ d\omega$, we can convert to irradiance by projecting that radiance value to the surface: multiplying by the cosine of the angle between $\omega_i$ and the surface normal $\hat{n}$: $\theta_i$ (Equation \ref{irradiance&radiance}). This allows us to know the contribution from some small part of the hemisphere on the power per unit area of a surface.

The simplest way surfaces can reflect light is equally in all directions. These surfaces are known as perfectly diffuse or Lambertian. Radiosity is a useful concept in such instances.

Radiosity is the total power reflected and emitted from a surface per unit area (also known as Radiant exitance). Both irradiance and radiosity have the same units, since they are describing similar phenomena just in opposite directions. If we know the total amount of light incident on a Lambertian surface, we also know how much light is reflected. In this case, radiosity $B$ is equal to $\rho E$, where $E$ is the irradiance, and $\rho$ is the albedo (percent of radiation reflected) of the surface. Once we've calculated the radiosity of a surface, we know the reflected radiance in any direction. We just divide the radiosity value by the total projected solid angle of the hemisphere, $\pi$, giving us the radiosity per unit projected solid angle which is also the reflected radiance.

The Bidirectional Reflectance Distribution Function

The bidirectional reflectance distribution function (BRDF) is a convention for describing power transfer at an opaque surface~\cite{Nicodemus65}. The function describes the ratio of outgoing radiance to incoming irradiance as a function of outgoing and incoming angles (Equation \ref{brdf}, see figure~\ref{renderingeqdomain}). A BRDF can also be dependent on spatial location, time, and wavelength. Since we usually only calculate reflectance for three color channels, it's common for the wavelength-variance of a BRDF to be implicit. That is, we write it as a function without parameterizing by wavelength but the calculation is done three times, once for each color channel.

A BRDF allows us to simplify complicated surface reflectance phenomenon into a single function. To compute the differential contribution of reflected radiance in the direction $\omega_o$ reflected from direction $\omega_i$, we calculate incoming radiance from $\omega_i$, project it to the surface by multiplying by the cosine of $\theta_i$, and multiply by the BRDF (Equation \ref{outgoingradiance}).

Conceptually, the BRDF specifies the proportion of light that is reflected in the outgoing direction, for some small solid angle of the hemisphere. In practice, this function can be completely arbitrary. If geometric optics are to be modeled accurately, a BRDF must be reciprocal, $f_r(\omega_i,\omega_o)=f_r(\omega_o,\omega_i)$, and not reflect more light than is incident, $\forall \omega_i \int_{\Omega}f_r(\omega_i,\omega_o)cos(\theta_o)d\omega_o \le 1$ (see appendix~\ref{appendix:albedo}).

For example, the BRDF of a Lambertian surface is simply $\sfrac{\rho}{\pi}$. Again, $\rho$ represents the albedo of the surface. The integral of this function over the hemisphere with respect to projected solid angle, $\int_{\Omega}\frac{\rho}{\pi}cos(\theta_o)\omega_o$, is just $\rho$. Consequently, for a Lambertian surface to reflect less light than is incident, $\rho$ must be less than one.

The Rendering Equation

We can now detail mathematically the equation we attempt to solve when rendering an image using the physically based concepts of Radiometry. Equation \ref{mainrenderingequation} details physically-based rendering and is known as the rendering equation.

We have taken the equation for differential reflected radiance (Equation \ref{outgoingradiance}) and simply integrated over the entire hemisphere of directions. We then add a dependence on position $\vec{p}$, since we are performing this calculation at many different positions in a scene and the BRDF can vary spatially over these positions. We also model light emission $L_e(\vec{p},\omega_o)$ at any point in a scene, allowing the specification of light sources. As stated earlier, this calculation can also be dependent on time and wavelength. Put simply, the total radiance reflected from point $\vec{p}$ in direction $\omega_o$ is the sum of emitted radiance and reflected radiance.

When rendering an image, for every surface point $\vec{p_i}$ that is visible along the direction $\omega_o$ we perform the rendering equation calculation. This simple equation is central to every computer graphics rendering algorithm. Although it is a simple formulation, the difficulty comes with the fact that the incoming radiance over the hemisphere of directions is not known. Each unknown incoming radiance value requires another rendering equation calculation. Doing this calculation recursively until a solution converges is incredibly computational intensive. For this reason, most graphics algorithms detail ways to simplify this calculation.

Direct and indirect lighting are both reflected radiance from camera-visible surfaces. Therefore, differentiating the two is not entirely necessary. However, doing so usually leads to increased efficiency, since direct lighting is probably more important visually than indirect lighting. Separating the two allows us to more explicitly decide how much computation time we want to dedicate to each part of a scene's lighting. Also, the general character of these two lighting components is very different. Direct lighting often has sharp discontinuities and indirect lighting is usually smooth, with little spatial variance. We can refer to this separation of lighting contributions as reflected radiance decomposition.

The term 'caching' in rendering usually refers to the reuse of data from one part of a render or a previous time step to render other parts faster. Caching exchanges memory storage for computation time. We save the results of past work, and check whether or not we can use these results for subsequent calculations. The overall effect on the workflow of algorithms employing caching is minor. We are not necessarily adding to an algorithm's complexity, but just trying to find instances where work does not need to be repeated. 

These two ideas--reflected radiance decomposition and caching--form the foundation for irradiance caching. Decomposing reflected radiance into direct and indirect lighting led to the observation that indirect lighting and spatial location are highly correlated. A simple way to exploit this correlation and amortize work over many nearby pixels was by utilizing caching.

Irradiance caching works by separating out the lighting caused by inter-reflection among diffuse surfaces from direct lighting in the rendering equation. Due to its low frequency nature, indirect lighting can be sparsely evaluated over the scene at a set of carefully chosen sample points. Interpolation can be performed to reconstruct the signal over the entire scene. At each sample point, Monte Carlo integration is used over the hemisphere of directions to calculate an accurate estimate of irradiance. In addition to this estimate, information from hemisphere sampling is used to estimate how likelihood of spatial changes in lighting. In the original formulation, the harmonic mean of the distances to intersection points in hemisphere sampling is used. This number is linearly scaled by a user-provided parameter to designate how close new irradiance calculations must be to stored records in order to have a cache hit.

Originally, hemisphere integration was only used to calculate a single irradiance value and average distance to intersection points. However, the hundreds or even thousands of ray traces required for this integral contains a lot more information about the lighting at a given point. Ward introduced irradiance gradients for irradiance caching to better utilize this information. Irradiance gradients are computed during hemisphere sampling and are used to improve interpolation, extrapolation, and cache spacing of the irradiance cache. Irradiance gradients are an estimate of the magnitude of irradiance change for each spatial direction and rotation angle. Using irradiance gradients results in a marked improvement in interpolation quality with little additional computation and no additional ray tracing. 

Because irradiance caching is a world-space caching approach, distant surfaces which cover few pixels in a rendered image, but a large area in world-space can result in too many cache misses. Tabellion and Lamorlette introduced an error metric and weighting function to space cache points evenly in screen space, replacing the harmonic mean calculation with a minimum, clamped to ensure adjacent image pixels on the same surface do not create new cache records. This optimization serves to place irradiance cache points in a way more sensitive to the final output image. To our knowledge, this technique marks the first published documentation of irradiance caching being used in a feature animated film.

In 2006, Krivanek et al. introduced neighbor clamping and adaptive caching, reducing the area in which poor estimates are visible and increasing the density of cache points where a visual discontinuity of irradiance is detected, respectively. Neighbor clamping works by looking at nearby cache points when a point is added to the irradiance cache and checking whether or not the radius of the cache point being added is geometrically plausible. This process helps prevent cases where hemisphere sampling misses small, nearby scene objects, or rays leak through geometry because of numerical precision problems. Also when adding a cache point to the irradiance cache, adaptive caching can detect whether or not interpolation between nearby cache points will result in a visible discontinuity. Once detected, this discontinuity can be prevented by reducing the radius of the cache point to be added and nearby cache points, consequently increasing the local density of cache points.

At SIGGRAPH 2008 work was presented for enhancing the smooth appearance of indirect illumination by increasing the area that irradiance cache points overlap. This change causes a simple blurring of the indirect lighting function an irradiance cache represents. More cache points are used in any given interpolation, reducing the influence of outliers, trading local accuracy for a generally smoother appearance.

This project's main purpose was to become more familiar with VTK, and TCL/TK, as well as gain some skill at hacking data formats.

Part 1 : Height Fields

With this part of the assignment we plotted two different data sets as height fields. The first data set was a fragmented R2->R1 function, with both sets of values stored in separate files. All I had to do was read the two files in and then combine them into a set of 3d points. These points were then triangulated, and a picture was drawn from this 3d data. This part of the assignment was relatively easy, because all I had to do was modify, very slightly, a file on the class webpage. What I ended up with was imageWarp1.tcl, and the images below, which I am not sure whether or not they are correct.

The second set was a 2D gray-scale image. The values at each pixel were used to create a third-dimension of height data. This image took even less editing of a file, again available on the class webpage. The results are below.

Part 2: Contour Maps This second part of the assignment was much more challenging. With this part of the assignment, reading in the data files and converting then plotting them was the trivial part. The challenging part was then to program a GUI to select one of two data-sets, and to change the values which control the image, interactively. TK is a pretty straight-forward software package, and after a little internet searching, I was able to build a pretty good-looking GUI. I decided to fix the 3d view, seeing as the contour maps are both 2d. This trivial simplification, made for a lot cleaner user interface. One thing I would like to change, but haven't figured out yet, is the initial slider values. I would like them to actually have viewable values when the application is opened up, so that the user doesn't have to change the values just to see an image. I'm sure I will figure out how to do this in future projects. Again, all the methods used are pretty standard and straight-forward. After a very brief search, I found all of the VTK filters I needed, I just needed to build in the user interface to interact with these filters. The results are at contour.tcl, and a screenshot of the program can be seen to the right. Questions Q What properties does a dataset need to have in order to have contour lines that make sense (and contribute to the visualization)? A It needs to be continuous and fairly smooth in all of its dimensions. Data that doesn't fit this criteria will make contour lines that don't "make sense." A noisy data set with only high-frequency data will produce contour lines which really don't tell you anything since most of this high-frequency data will be lost with contour lines. Q Where are a few places that these properties can be found? A The data sets in this project are great examples, especially Mt Hood. I can't think of a more useful (or perhaps widely-used) application of contour lines than in cartography. It also seems like there are many more places where you might find this kind of continuity. Another data set from this project, infra-red radiation is a good source. If you think of how heat dissipates, so evenly through most of the things around us, this makes a lot of sense in a contour-map representation.

Color Maps

Part A - Interactive Color Mapping

To the left you can see my visualization of Mt Hood, with height field and color map. To create this specific image and color-map, the first step was to read in a grayscale image with VTK. The scalar values at each pixel were then extracted. Geometry was then created by using these scalar values as z coordinates, making a third dimension to this originally flat image. The color map was then created, by taking two values (this particular image was done in RGB color space) and stepping between them with a simple for loop, and interpolating values for each R, G, and B channel linearly. Finally, this newly created color map is aplied to the height field. In vtk functions, the process went like this: ->read file ->vtkImageMagnitude (extract scalars) ->vtkImageDataGeometryFilter(put magnitude into geometry) ->vtkWarpScalar(warp magnitude values by certain amount) ->vtkMergeFilter(Merge geometry with scalars) ->vtkElevationFilter(Set values for color assignment range) ->vtkPolyDataMapper(map color map onto data)

This visualization to the right differs from the Mt Hood image, in that we are now working in HSV color space (This is the default visualization, currently saved by the saveView.tcl file). This image, by limiting the scale only to hue changes, shows well the change between positive and negative, by using mostly two colors, and blending between them in a very distinct, abrupt way. It also differs from the Mt Hood data in the fact that this data did not come from an image, but a set of discrete data samples, which then had to be triangulated to form a solid surface. What do you think works best, or what are the benefits of the different approaches? (with/without height fields) It seems to me that for certain data, it helps a lot to convert the data into a height field, especially for data that makes sense as one solid surface (such as the Mt Hood data). The height field in combination with color map shows you elevation information you probably wouldn't be able to visualize as well with just one or the other. The Thorax data doesn't seem to benefit too much from applying the height field, but at the same time, applying the height field does not seem to hinder the data. I think the height field is usually worth just the extra level of interactivity you get by having a third dimension. Which one is better? What are the differences? (RGB vs HSV) I find the HSV color model much more intuitive. It seems a lot easier to get a good color scale by using the HSV sliders than by using the RGB sliders. Pretty much any combination of extremes with HSV will give you a good color scale. Also, tweaking the scale to get the image to look better is much easier in HSV. The advantage to RGB seems to be the ease of creating complementary color schemes relatively easily. Like the blue/yellow, magenta/green, etc. scales. It all really depends on your data. However, it seems a lot harder to get a nice discretized-looking scale in RGB, when in HSV all you have to do is make a Hue scale.

Part B - Extra Data set

tell us what your images show in it I found it relatively difficult to find free scientific visualization data on the internet, but ultimately, I came across a grayscale .jpg of ocean elevation data around the South Atlantic and Indian Oceans. I found a Photoshop plug-in and converted this .jpg to a .pgm file. After that, the process was identical to visualizing the Mt Hood data. I kind of like the idea of having a blue color for where the ocean is supposed to be, and a more brown color for the land. I think that this yellow-blue color map worked out pretty well in dichotimizing the land and ocean, while still giving a good sense of the depth of the ocean floor in certain areas. I think that if the elevation data for land were not completely flattened out, this visualization would not be nearly as effective. In the end, this visualization is great at identifying the deepest parts of the ocean.

Part C - Bivariate Color Mapping

This part of the assignment involved using a color map which is bivariate. Using a bivariate color map on a data set, allows you to attempt to display an extra dimension of information at each point that is colored. I played around with quite a few bivariate color maps, but couldn't find too many that worked that well (In letting you visualize more data than a normal color map). Since VTK does not support bivariate color maps, you have to sort of hack it. Basically, you just create a very big univariate color map, but treat it like it is just a bivariate map whos rows have been collapsed down into one big long row. All you need to do is just figure out how to index into this one-dimensional array in a two-dimensional way, this is done pretty easily with a pair of nested 'for' loops, with one loop counting rows and the other columns.

document which one is best

I like the bivariate map I used below, because the two colors are easily discerned between, so that when you look at the image you can tell exactly which directions the gradients of Mt Hood's surface are increasing. This kind of color map, where the direction of the variance in color is easily discernable, seems to work much better than a bivariate color map which is more focused on showing correlations between two sets of data. Showing a correlation isn't really necessary at all in this Mt. Hood data set. I think the color map can be improved by mapping this specific data to a greater range of values, perhaps in a non-linear way.

MORE IMAGES:

Isosurfaces

Files Submitted:

isoSurface.tcl - Both programs for this assignment in one, with GUI to switch between modes
REPORT.html - this document
*.png - output images

Two Isosurfaces

Here you can see both the skull and face isosurfaces extracted from the volume data. The skin has an alpha value of .55. Which isosurfaces look the most interesting, and how did you find them? The isosurfaces that look the most interesting are the ones that show solid, whole structures of the volume data. This is why isosurfaces work so well on this head data set, because the skull can be separated out of the volume data well, and so can the shape of the head. I found these surfaces by creating a slider in my GUI which changed the isosurface currently viewed. This slider can really only be used interactively on the smaller data sets. It is much too slow on the full sized version of the data. I just slid the slider until I found a point where a nice solid structure was visible. To create these isosurfaces, I just used the vtkContourFilter, and then fed this data into the vtk mapper, then a vtk actor.

Univariate Curvature Color Maps

In these next images I have used univariate color maps derived from curvature data to color the isosurfaces with. The first two images below use only the magnitude of the principle curvatures (i.e. sqrt(k1*k1+k2*k2)). While the second two images use the mean curvature (i.e. 1/2*(k1+k2)). In addition to creating the isosurvaces as above, the vtkProbeFilter function had to be used after the contour filter to apply the color maps to the isosurfaces.

Describe how the two values relate to the shape of the iso surface.

With the curvatures magnitude images the color values on the surface are quite easy to decode. As the colors move from cyan to red on the hue scale, we get increasing curvature magnitude. The closer to red you are on the hue scale, the more "curved" the surface at that point is.

With the mean curvature values, we can tell much more about the surface at these points. I used a hue scale that does not wrap around. From this data we can establish a relationship between k1 and k2. We need the extra physical data the isosurface offers us because with the mean curvature, unique physical characteristics will get mapped to the same color. For example, a flat plane and an equal-but-opposite curvature saddle point will be colored the same. The mean curvature, with my hue map, really discretizes the various areas of this isosurface, so you can get a quantitative idea of curvature behavior on the surface.

What do you think works best, or what are the benefits of the different approaches?

I think with this familiar face model, that the curvature magnitude image works much better than the mean curvature images. I don't think this would be true for an isosurface of something I am not so familiar with, or haven't seen before. Just looking at the 3d rendering of the face and skull, you can get a good idea of where the saddle points, valleys, peaks, etc. are, and the curvature magnitude color map lets you get a good idea of where the surface changes dramatically. The mean curvature maps just add too much mess and redundancy to the data. However, with less familiar data, I think the mean curvature color map would be more helpful. It definately differentiates convex and concave surfaces quite well from each other, something the magnitude color map can't do.

Face Isosurface with Curvature Magnitude Hue Color Map

Skull Isosurface with Curvature Magnitude Hue Color Map

Face Isosurface with Mean Curvature Hue Color Map

Skull Isosurface with Mean Curvature Hue Color Map

Volume Rendering

Color Compositing Transfer Functions

Here you can see a comparison between two renderings: one directly rendered from volume data with some transfer function(above), and one where two sets of isosurfaces have been triangulated from volume data, and then rendered(below). This volume renderer casts rays into the scene, and intersects voxels. The transfer function takes the values at these intersected voxels and assigns a color and opacity to each pixel, as a composite of the transfer function value at every voxel intersected along a ray. Describe your transfer functions, what relationship do they have to the isovalues shown in your isosurface rendering? This particular transfer function maps opacity values of 0-0.05 to voxel values 30-70, linearly. It then spikes up to opacity 0.7 at voxel value 100. The color moves linearly between a light brown to white, from voxel values 25.0-100.0. This transfer function attempts to show the skull isosurface shown in my isosurface rendering, by spiking the opacity right around 100, the value of this isosurface. It also shows some of the mummy wrappings by slowly increasing throughout the range of these isovalues. Do you think volume rendering the mummy dataset offers a clear advantage over isosurfacing? For this particular dataset, I do believe that volume rendering shows a clear advantage over isosurfacing. For the last project, the skull and skin were much better defined. Isosurfacing is good at bringing out these solid, well-defined volumes. However, for this mummy data, the skull is much more fractured and un-even. Also, the wrappings around the skull are uneven and hard to see a shape in. The volume rendering of the mummy presents a much more solid, less-noisy image of the skull. You can get a real feel for the shape of the skull. Unlike in the isosurface image, where the surface is noisy and fractured.

Maximum Intensity Projection Renderings

To the right we have a comparison between maximum intensity projection (MIP) volume rendering (above) and composite volume rendering (below). We have seen composite volume rendering above. Composite volume rendering involves compositing the transfer function value for each voxel along a ray. MIP volume rendering involves just displaying the voxel with the maximum intensity along any given ray. What are some advantages and disadvantages of MIP versus compositing-based volume rendering? You can see that in the MIP image you lose a sense of a third dimension. It seems as if the mummy data has been flattened, probably because you can see through everything, and it looks kind-of like an x-ray. However, when you can interact with the MIP rendering, the rendering regains this third dimension. The MIP image is more clear than the composite volume rendering. If the dense parts of the volume data are what you are interested in, MIP is definately the algorithm you want to use. Basically, MIP cleans up the rendering by emphasizing this one attribute of the data. However, you kind of lose the solid structures of things, since you can see through some of the data. The teeth blend together, as does the skull. Again, though, this seems to be remedied by making the rendering interactive. What you do lose are interesting non-dense characteristics, like the ears and eyeballs. In some instances, these are probably every bit as interesting as the bone structure.

Vector Fields

1. Test Volumes

	This first test volume clearly shows a source critical point with glyphs.
	This second test volume shows a saddle point with streamlines.
	This third test volume shows a spiral sink point with streamlines, all three critical points in each test volume are at (15, 15, 15).

2-4. Challenge Volumes - Critical Points

The first challenge volume has 3 critical points.
The second challenge volume has 5 critical points.

5. Critical Point Visualizations

Volume 0, CP2 For this volume I chose stream lines, since it is a saddle point. I found all of these critical points by moving a small cube with an XYZ GUI widget. Also, I used the VTK PointSrc class to create groups of random points in sphere of space. With these streamlines, the points were then used, with vector data, to do integration with.
Volume 0, CP1 This point is a source. I did not use glyphs, so with this visualization, you have to take my word for it. In a larger visualization, you could spot this critical point by the colors around it. The red objects in this image, as in the last, are the critical points. The small dot off in the distance is the same saddle point pictured above.
Volume 1, CP4 In this critical point from the second challenge volume, I have decided to use glyphs to ensure that you can tell that this is a source critical point, and not a sink. The glyphs use the same point source as the streamlines, however, there is no integration here. Probably, a point is paired up with its nearest vector, and this value is used to create the glyph orientation, length and color.
Volume 1, CP2 Here we have a center node. You can see the box I use to find critical points in this picture. Also, you can see my hue color map as the streamlines are drawn closer and closer to the critical point, where in this case, vector velocity goes to zero.

6. Global Challenge Volume Visualizations

Challenge Volume 0
	This first visualization turned out alright, and I'm still not sure how to make it better. Instead of using random points to generate streamlines from, I used two parrallel planes. Together, the two planes capture all three critical points. The lines start out at points evenly placed on each respective plane. The blue streamlines originate from the bottom plane, and the yellow ones from the top. You can see the saddle point off to the left, the center point towards the bottom, and the source point almost at the middle of the image. You also get a good idea for the flow of the entire vector volume.
	Here I have added isosurfaces, to attempt to get an even more global idea of what is happening. The isosurfaces represent areas where vector magnitudes have dropped below .8047. The center point is located within the red globe at the bottom of the image. You can see the saddle point directly left of it. Also, you get a good idea of where the flow is quick, and where it is slow.
	In this third visualization of the first challenge volume, I have removed some of the clutter. You can still see both the saddle and center critical points, but now you can see how the field travels outside of these points. I created this image from only a single plane generating source points for integration.
Challenge Volume 1
	For the second challenge volume, I realized that every single critical point was on the z=20 plane. It seemed quite natural to therefore create all point sources on this specific plane. The visualization for this volume turned out much better than for the first. Here you can see the source with the four center points spinning off down the flow.
	This was a pretty flat visualization of this sample z=20 plane. I turned up the number of source points, and down the propogation of the streamlines. What you get is a visualization that stays pretty well within this plane. You can see clearly the center points in red, and the source point in green. Looking back, this visualization may have come off better with glyphs, since then you could get a better idea of the vector flow.
	This is the third and last visualization of the second challenge volume. I wanted to see what was happening outside of the z=20 plane, so I set the propogation quite high, and bumped down the number of source points. You can see that as these vectors come off the source, the loop around to all travel in almost the same direction. Also, it seems that after the center points, the vector field descends quite a bit. In general, getting good vector visualizations is a very difficult task. I found that building features into my GUI was probably the easiest way to improve visualizations. That way, you can see the results of changes interactively. Also, getting a good idea of what source points are going to produce good visualizations is very helpful. The critical points give you a very good guide as to where you should be placing your sourcepoints.

Tensor Fields

Strain Tensors

These first two images are just simple isosurfaces of the length volume of this Strain Tensor data set and the vector magnitude volume from the vector field data set, from left to right, respectively. They are both taken at value .7725. If there is some kind of correlation between these two images, I can't quite see it. It does seem like the one on the right could fit into the one on the left, however, it wouldn't be close to a perfect fit. It seems to me that the "length" of these tensors should be more visually correlated with the vector magnitude. Then again, I'm not exactly sure how these vectors relate to the tensors. I assume they are the principle eigenvectors, but I am not sure.
	The next three visualization employ both tensor glyphs, and vector glyphs. The tensor glyphs show the magnitude of the three eigenvalues, in relation to each other, as well as the direction of the eigenvectors. The box sizes and orientations encode all of this information. I colored the boxes with the vtkMergeFilter, as directed on the class webpage. The vector glyphs are simply oriented in the direction of the vector, and scaled proportional to the magnitude This particular critical point is a center point.
	This second critical point is a source.
	This third critical point is a saddle point. You can see the directions of the strain tensors and vectors change as everything around this critical point goes in, and then everything above and below goes out. Each of these visualization was created by using vtkPointSource around a critical point. Both the tensor glyphs and vector glyphs used these points. That is why there is a vector glyph paired with every single tensor glyph.
Here I have compared the streamlines from the last project, with "hyperstreamlines" from the tensor data. vtkHyperStreamline would not run on my computer, so I attempted to simulate these hyperstreamlines with the vtktubefilter. Unfortunately, with my simulations, the radius does not change, nor does the orientatiation twist. However, I think this visualization is a little bit more effective than my very cluttered streamline image. You definately get a general feel for the strain tensor flow.

Which tensor visualization technique (isosurfaces of a derived scalar, glyphs, hyperstreamlines) is the most effective, and why?
For this particular strain tensor dataset, I think the hyperstreamlines are the most effective. They can convey a global sense of the tensor data, quite clearly. The tensor glyphs were not too effective without the vector glyphs, and using these glyphs on a global scale did not work much at all. However, for the next volume, glyphs are much more effective than anything else. They seem much more suited for diffusion tensors than strain tensors.

Describe the relationship you see between the strain tensor and the local vector field.
From the critical point images, it seems like the vector field travels through the strain tensors in the direction of the minor eigenvector.

Diffusion Tensors

Here I have visualized the brain diffusion tensor data with vtkTensorGlyphs. Instead of using vtkPointSource, as in the last visualizations, I used vtkThresholdFilter with the anisotropy volume. This allowed me to display glyphs wherever the anisotropy of the diffusion tensor is high. This should filter out all of the highly-directional matter in the brain, called the white matter, where the brain pathways are. The color map is applied according to anisotropy as well. The most anisotropic part is in the center of the brain, where the two lobes are connected.
Here I have used the same tensor glyphs as above, but I have included an isosurface of the very isotropic parts of the brain. I wanted to get a good outline of the outside of the grey-matter in the brain. I have also made this isosurface transparent in the color mapping.
	These three visualizations implement all three visualization techniques: tensor glyphs, hyperstreamlines, and isosurfacing. The only addition from the last set of visualizations are my simulated hyperstreamlines. For these, I extracted the major eigenvector from the tensor data to create the streamlines, and then used the vtkTubefilter to volumize the streamlines. Again, the only drawback of this approach is the inability to change radius with changing minor eigenvectors, and the inability to see any twisting of these streamlines. However, they do show, more clearly than the glyphs alone, this very directional area of the brain.

How did you decide where to place the glyphs?
The assignment said that we were only interested in the white matter of the brain. This is the anisotropic part of the brain. We were also given an anisotropy volume, with scalar values derived from the three eigenvalues. I first used isosurfaces with a slider in my GUI to find a value that showed good separation between white and grey matter. I decided 0.5 looked pretty good. Then, I just used a threshold filter on this volume to take out all points below 0.5.

How did you determine where to start the hyperstreamlines?
I saw the highly isotropic area in my other visualizations, and then used my little cube with X, Y, and Z sliders to find the approximate coordinates of this area. I then used the vtkPointSource to create random points in a sphere around this area. My hyperstreamlines then originated from these points.

Why is tensor visualization hard?
I think the main reason why tensor visualization is so hard is because you have so much data. We can barely simulate three dimensional scalar fields of values well with volume rendering. With nine times the data, it makes sense that visualizing tensors would be an order of magnitude more difficult. The more data of each tensor you try to display, the more cluttered your visualization becomes. The more you reduce these tensors to less dimensions for visualizations, the less you can visualize from the tensor. You can't know everything that is going on in a tensor data set with a single visualization. But through interactivity and several sets of visualizations, you can accomplish this task pretty well.

My renderer can output in ppm, and rgbe. PPM is easy to code, and I had an rgbe writer from another renderer, so it was easy to put in. HDR images are nice for debugging, sometimes. None of these output format are supported in the openGL gui. You just have to hardcode them in. I will fix this in the future. I just have to get used to using opengl to only display pixels and not render anything.

This is a cropped screen shot of my openGL ray-tracing viewer

Performance template

For this program I created Shader, Lambertian, Surface, SurfaceList, Light, LightList, Camera, and PinholeCamera classes. I also made Context, HitRecord, and Scene classes, for general rendering infrastructure. My SurfaceList class has a hit function and does a linear hit search of all of the surfaces that are listed in it, when hit is called. Each surface has a shader pointer, and all my shaders will be sub-classes of the shader class. When something is hit, the shading function uses the LightList and colors the pixel. It gets information from the Scene class, the Context class, and the HitRecord class. The Scene class holds pointers to the surfaceList, lightList, etc.

This infrastructure has worked quite well for this scene, and I think it will work well for more complex scenes. I will be able to add more Shaders and more surfaces without having to change very much architecture.

Here are my two required images.

Here you can see my "creative" image. I have just added a bunch of spheres and another light, and made everything pretty symettrical. Also, I used my interactive viewer to take all of these images. You can see a screenshot of it below. As you can see, there are no widgets or sliders or anything. The only way to interact, right now, with it, is through the keyboard (for file writing), and with the mouse. The left mouse button moves the viewpoint, the middle one zooms in and out, and the right one rotates around the look-at point (used by holding down these buttons). I used GLUT, and the glut timer function to periodically update the image, every 30 ms. I still haven't done a pseudo-random pixel render-order. That is on my to-do list.

Performance Template

Required Image

Creative Image/ Extra Credit

You should be able to recognize this little piece of terrain. It is looking south at the point of the mountain. My hometown is off to the foreground and right in this image (Riverton). The 'sun' is a disk. That is why the shading is flat, and the 'moon' is a sphere. My little flying machine is made up of a triangle, a sphere, and a box. This particular height field is 1375x1044.

In this assignment, I added box, triangle, disk, ring, and heightfield to my renderer. I made disk and ring separate classes, though I don't think it matters either way. I also implemented bilinear patches to use in conjunction with my height fields, although they could be used independently. I used the box and bilinear patch intersections that were linked from the class webpage. I am using barycentric coordinates for my triangle intersection. My scenes are represented by a scene class which holds a surface list, light list, camera, and everything else needed to render any particular scene. The scene is initialized with a member function which I just hardcode all the details into, and thus have to change for every new scene.

Performance Template

Required Image

Creative Image

Extra Credit

L->R Lambertian, Phong, Cook-Torrance (with Varianing rms, color, and diffuse/specular/ambient terms

The extra credit shader I implemented is a Cook-Torrance shader. I implemented it straight off the 1982 paper. It worked out pretty well, and I even used the real Fresnel term and not the Schlick approximation. The rms term for microfacet distribution controls well how tight the highlight is. I figure since C-T can look quite diffuse and quite specular, I would include both a lambertian shader and a phong shader in my comparison images.

So I have added 4 shaders in this assignment: Phong, dielectric, and metal shading. I pretty much implemented the things right off of the class slides. Originally, my dielectric shader was just adapted from another renderer. It even already had Beer's law implemented. I had problems though, so I just started from scratch and followed the design in the class slides. I didn't implement any of the enhancements discussed in class. I may think about implementing the 'inside of' flag, but I'm not sure how much of a speed improvement it will make once I have an efficiency structure in place. I didn't implement the tree pruning, because I think, later, I will change this renderer into a path tracer. Or, I just think if the rendering is over a half second or so, it is already beyond interactive, how much, doesn't seem to matter too much anymore.

Performance Template

1 sample/pixel

9 stratified samples/pixel, Triangle Filter, 2 pixels wide

9 stratified samples/pixel, Sinc Filter, 2 pixels wide

I didn't hardcode any of this into my raytracer. I just added a couple loops to my render loop and added some temporary code for the sin function image. I didn't want to create the infrastracture to reuse samples, and I think I will just stick with the box-filter for my renderer if I am not going to reuse samples, and it is pretty easy to make an implicit box filter without having to add any extra rendering architecture. For these 9 sample/pixel images, I just did 49 samples/pixel, and then tested if the jittering made them fall within the 2 pixel wide filter (I guess the samples in the corners have a 1/4 chance of being included, and the side pixels have a 1/2 chance of being included. Which means I averaged 25 (interior) + 10 (out of 20 side) + 1 (out of 4 corner) = 36 samples/pixel (2 pixel wide filter -- still the 9 samples/pixel density))

My image is just my creative image from the last assignment. With the anti-aliasing, it looks a lot better. What I would be interested in seeing is a rendered image where you can tell the difference between a high samples/pixel box filter and maybe a high samples/pixel sinc filter. It is pretty easy to see with this well-behaved sin function. I just want to know that it is going to make a difference for a non-trivial number of standard renderings.

Performance Template

Required Image

Creative Images

I decided to implement a BVH. I was going to finish a grid too, but I had some problems, and won't have time to finish it this week. My BVH is a pretty standard binary tree, where each node has a bounding box, and pointers to two other surfaces. It is built with a standard top-down approach, by splitting the primitives into two groups along either the x, y, or z axis, and at each level of the tree this axis changes. This process recurses until there are only either 1 or 2 primitives left, at which point, the tree is built.

My creative image is a model a friend built of his wifes wedding ring. It works out to be about 100,000 triangles. I used maya to split the model into three different models, so that I could apply separate shaders to each one. However, the surrounding stones turned out to use the pretty much the same shader as the center stone, since I realized that this renderer does not have Beer's law implemented, so I couldn't make my stones different colors. They use different indexes of refraction, however, not that this is that noticable. Even with these issues, I still think the results are pretty cool. I'm not sure my friend ensured that all of these surfaces have outward facing normals, but it looks alright to me.

Performance Template

Required Image

Creative Images

I only added 2 new shader classes for this assignment: Checkerboard and MarblePhong. I also added a Texture class and a few texture sub classes, one to look up colors from an image, and one to return a solid color. In the end, however, I didn't end up using the solid color texture class. Instead, whenever I wanted to add the ability to extract colors from an image in a shader, I just added a texture pointer and set the default value to NULL in the constructor. I then have a branch in my shader to see whether or not this Phong/Lambertian/etc. shader is using a texture. I am not sure if this branching is faster than the virtual function look-up, but it was at least easier to implement.

For my creative image I decided to do a displacement mapping. I couldn't find an earth elevation image that would be easy to use for displacement mapping the earth textures we have, so instead, I used the night-lights image as a displacement map. I figure that the brightness of the area is pretty indicative of the population density. So that is what this is an image of. I think I could have gotten slightly better results if I first would have blurred the night lights image so that the data was more spread out and didn't make these very sharp peaks.

Performance Template

Required/Extra Credit Image

So it's not right, is it? I can't figure it out. I have been through each piece of code line by line at least 20 times, but to no avail. However, I did get my shadow algorithm to work, so hopefully that will make up for my colors being off.

I followed the implementation in the slides almost exactly (obviously not exactly enough). However, instead of putting my shader in a box, I made a new surface just for volume shaders. This surface had a bounding box and a special shadowHit function. The regular hit function just calls my VolumePhong shader after the bounding box has been hit. Also, since my bounding box has a function which returns both the near and far hit points I don't need to call the intersect routine twice. My shadowHit function in my Volume surface class calls a simplified attenuation function in the VolumePhong shader class. If the ray is attenuated to a dark enough opacity, then true is returned for the shadow hit function, otherwise false is returned. The VolumePhong/ColorMap classes were all done according to the class slides and the functions already written on the class webpage.

Performance Template

VolumePhong

Creative Image

Extra Credit Image

For this assignment all I had to do was create a new Instance class. My instance class behaves as described in the class slides, it is just a general instance class that stores a 4x4 Matrix. My infrastructure does not care about unit-length ray directions, so I didn't have to do anything special there. I just multiplied my ray origin by the entire matrix, and my ray direction by the upper 3x3 portion of the matrix. Then once my hit routine returned my normal and hit point, I multiplied the normal by the inverse of this upper 3x3 matrix, and the hit point by the inverse of the whole matrix.

For the extra credit image I realized my triangle class is pretty bloated (with per-vertex normals, uvs, etc), and 100 bunnies can't even fit into memory. For the second part, all I could fit were 40. The reason why my load time is so slow in the set-up time on my pre-computed performance template is that I just read the same file in 100 times, and it is an ASCII ply file, so it is quite slow. I also left the computation of per-vertex normals in my PLY reader, so this slowed the thing down even more. I was just too lazy to write a routine that takes a surface and multiplies it by a matrix, so I had to rely on the matrix that can be passed to my PLY reader.

Performance Template - Instancing

Performance Template - Pre-computed

Creative Image

Extra Credit Images

My creative image is a pretty standard-looking monte-carlo ray-traced image, except I used two shaders we have been using in our other programs. I used the phong shader on the texture-mapped globe, and I used our metal shader on half of the checkerboard. The other half of the checkerboard is my monte-carlo metal shader, so that the differences between sharp and blurry reflections can easily be seen. The other two spheres in the image are monte-carlo lambertian shaders. On the red sphere, you can see some color bleeding from the globe. All I did to create this image was add shaders to my infrastructure, shaders which recursively call my trace function instead of explicitly shading from point lights. This particular image is 400 samples/pixel.

My extra credit images show of a depth-of-field effect, easily created with monte-carlo ray tracing. I had already implemented a thin-lens camera model when I implemented my pinhole camera, so I didn't have to add anything for my extra credit images. You can see the three different levels of focus in both the triangles, and in the checkerboard plane. My extra credit images are 100 samples/pixel.

Creative Images

The first image is my backdrop for what was going to be a nice looking rainbow, something I spent 24 hours trying to get working last weekend. The ground is a texture-mapped heightfield. The heightfield is just elevation data from the web, while the texture is an aerial photo of the same area. The background is just a cylindrical map that I referenced into. I used it for shading but not lighting. There is a directional light where the sun is.

The second image shows a monte-carlo glossy surface, and environment map lighting.

The third image shows a full spectral rendering of the same scene, however, now you can see small little rainbows in the diamond. It definately adds something substantial that was missing before. The color matching isn't perfect because, in order to interface with rgb textures, I have just associated the rgb values with bins of wavelengths 400-500 for blue, 500-600 for green and 600-700 for red. Even with the crudity of this system, the color matching is still decent.

I had added quite a bit to my renderer in order to do a rainbow, but none of it amounted to any decent images, so I decided to show a few images to show the current state of the renderer, and I think they, together encompass everything this renderer can do right now.

Program 1 was a simple demonstration of anti-aliasing in ray-tracing. The geometry consists of an infinite checkerboard, colored alternatively black or white based on a two dimensional oscilating tringonometric function.

Rays were sent out from the eye, all passing through a screen rectangle, and then either hitting the geometry, or traveling too far without hitting anything. With only an infinite plane, the hit function can be generalized to work more quickly and accurately. Specifically, any ray going from the eye through the plane that is not parrallel with the tangent or binormal vectors of the plane WILL hit the plane. With a ray, a+tb, where a is the vector pointing to the eye, and b is a vector pointing to part of a pixel on our screen, we only need to take solutions where t is positive.

This is really beside the point of our first program, but it is still interesting to think about how exactly you go about intersecting a ray with an infinite plane. The point of the program was to show the incredibly high variance and slow convergence of this kind of stochastic ray tracing.

We took regular interval samples, random samples, jittered sampling, and cubic b-spline filtering each at 1, 9, 25, 100, 10000 samples per pixel. The images were all 512x384 pixels. This means that at our highest sampling frequency, we sent out almost 2 billion rays. Even with this incredibly simplistic model, the rendering with my implementation still took about 12 minutes to complete at the highest frequencies. That is about 2 million rays/second.

The point of listening all of these huge numbers is just to show you what a brute force solution ray-tracing is. It probably isn't true that 10,000 samples/pixel are entirely necessary to render this infinite checkboard perfectly, perhaps you can get away with a fourth or a tenth of that. But still, with such a simple model, if you look at the 100 samples/pixel images in my gallery, you will see how very imperfect they are. Raytracing just needs a lot of samples, that's all there is to it.

Regular Samples: Samples taken at regular intervals of a specific pixel. This kind of sampling can often hide, very consistently high-frequency information, by taking samples at intervals which are factors of the regular high frequency information.

Random Samples: Samples taken at random points within a single pixel. This method does not spread out sample points as evenly as regular sampling. It is very possible for many samples to bunch up and give redundant information, requiring even more samples.

Jittered Samples: Samples taken at regular intervals, but 'jittered' to place them randomly within a specific area. It is like dividing up any given pixel into sub-pixels, and then sampling randomly in each one of these sub-pixels. This is almost the best of both worlds of regular and random sampling, and the only thing I know of that beats it is the much more complicated poisson disk sampling, which ensures all samples are a certain distance apart, but still randomly placed within a pixel. Although, this algorithm is way too complicated for my tastes. The problem with Jittering is that, like random sampling, it still creates high frequency data from low frequency information. If you look at my Program 1 images, you will see that the Jittered sample at 1 or 9 samples/pixel still create noise very close, which is completely absent in the regular sampling images. Although, the regular sampling image have the more annoying problem of creating patters with the distant part of the plane which certainly do not exist.

Cubic-Bspline filter: Can be used on any of these sampling methods. A cubic b-spline can be implemented by summing together three randomly generated numbers in the range (-0.5,0.5). Probabilistically, these sums will produce a result with an expected value of 0, surrounded by a smooth bell curve probability density function. This has the effect of taking any regular sampling intervals, and perturbing them slightly, with less and less probability the further away you get from your regular sampling intervals.

Program 1 images

Thin-Lens Camera

Program 2 was an implementation of a simple thing lens camera. The same screen rectangle was used to create ray directions, as in the last program. However, the eye, or the origin of the ray is now perturbed slightly so as to model the depth of field effects that are unnavoidable when doing anything but pin-hole photography.

A very thin lens is modeled at the eye. Every ray which originates on this thin lens and goes through the image plane at a specific pixel, is sampling 3d space for that specific pixel. If your pixels are now seeing the world with these perturbed origin-rays, you can imagine that anything beyond this specific image rectangle will get more and more blurry the further away things are. Also, objects close to the eye and in front of our image plane will also appear blurry, as they are also being sampled by rays which do not form a straight line from the center of the eye, through the screen.

This is precisely the depth-of-field effect we are after. While it does not physically model an actual camera lens, and lacks some of the effects of real photography, it is good enough for most purposes.

The Thin-Lens-Camera is sampled at an even density throughout. This is accomplished by taking two random numbers on [0,1) and multiplying one by two pi, and by taking the square root of the other and then multiplying it by the thin-lens-camera radius. The first number becomes the azimuthal angle phi of our thin-lens disc, and the other tells us how far away from the center to sample. This second number must first be square-rooted, otherwise, there will be too many samples close to the center of our disc. Since, as you travel from the center to the outside of a sphere the area of a circle covered by a given angle increases quadratically.

Program 2 images

Naive Path Tracing

Program 3 was the implementation of a "Naive Path Tracer" with support for mirrors, glass, diffuse, and phong reflectance. As in the other two programs, rays were sent out from the eye (or thin-lens-camera), through the image rectangle, and out into the geometry of our 3d-world.

A path tracer takes these rays and bounces them off objects in the world until either a certain number of bounces are reached, or the ray hits a light. The information from this light is then recursively reflected back through the ray's adventure bouncing in the 3d-world, to the screen, where it is recorded at whatever pixel it originated. This is kind of a backwards way of looking at how light transport in the real world really works.

In the real world, light originates at lights and bounces on surfaces and through surfaces until it reaches our eye. Our eyes then interpret whatever changes have taken place to the light along its journey to our eye. Whether it be absorbtion, reflection, refraction, etc. In our naive path tracer each 3d object that is hit will perform some calculation on the light and change it in some way (If the world didn't change light at all, we wouldn't be able to see anything but the same light from all directions).

If a ray from our eye hits an object defined as glass, it will be refracted, and reflected. If a ray hits a mirror, it will be reflected, perfectly about the surface normal. If a ray hits a diffuse surface, it will be absorbed a little and reflected at some random angle, if enough of these random reflections are done at this surface, we can get a good idea of the illumination at that point. If a ray hits a "phong" surface it will be absorbed a little, and then reflected at an angle probabalistically close to the perfect angle of reflection. If after bouncing around, these rays do not hit a light source, they will not add any illumination to the pixel from which they originated. If they do, as I said before, the light will be recursively attenuated until it returns to the eye.

This kind of ray-tracer is very simple, and will give a non-biased solution to the light transport of a given scene. The calculations must be done from the eye to the lights, because you know that every single ray you send out from the eye is a visible one. The same is not true if you were to send out Rays from the various light sources in a scene and hopefully trace them back to the eye.

Program 3 images

We have roughly 365.24 days a year, the time it takes the earth to make a complete orbit of the sun. I would like to break down the number of days in the year into equal parts. This will remove one of the inefficiencies I see with our current calendar: remembering which months have 30 days and which months have 31 days. Unfortunately, 365 doesn't break down very nicely. 365 has the very succint prime factorization of 5*73. Since, in most parts of the world, there are four distinct seasons, and I would like to represent that in my calendar somehow, the number 365 simply will not do. I'm going to work with 364.

364 breaks down into 2*2*7*13. If we want to keep something that most closely respembles our current calendar, we would have 13 months of 28 days each, with 7 day weeks. Adding in a day somewhere, along with a leap day using the current method. This has the benefit of creating months, all with the same number of days, but we have lost the ability to have an equal number of months per season, 3 for each winter, spring, summer, and autumn.

This is what I suggest: Either (1) 4 months of 91 days each, or (2) 12 months , with a 3 months pattern of 28, 28, 35 days (or 4, 4, 5 weeks). Also, the first day of the year will not be in any month, nor will it be a day of the week. It will simply be "New Years Day." Also, that night will be the winter solstice. On leap years, a day will be added exactly half of the year after New Years, which will also not be the part of any month, nor a day of the week. This may sound wonky to many, however, it comes with a very distinct advantage. Every day of the year will always be on the same day of the week. The first day of every month will always be the same day of the week. Any date in any month will always be a certain day of the week. Brilliant.

If you use the hi-lo count system, I have produced a card counting
decision table with index numbers from -10 to 10 for Wendover: SDh17chart.pdf

This chart is for the single deck games, no double-after-split,
double-on-anything, split aces only once, and dealer hits a soft 17.
For the longest time, this was the only game offered in Wendover, but I
have found a few shoe and two-deck games in recent visits.

If you're interested in learning about card counting, I recommend the book "Professional Blackjack." It has many different decision charts based on different casino rules. Also, it will give you an understanding of the math behind card counting and how it gives players an edge. It will also help you understand why you can't expect to always (or ever) make money counting cards.

There is so much crappy software out there. There is a lot of crappy shareware software with annoying nag screens, free programs which are poorly written, and of course overpriced commercial software. For almost every case of software that you either have to pay for, or is of this annoying shareware variety, there is a nice little freeware program that does the job better. Over the years I've used a lot of different software and I think I've found the best for most of the things you'll do on a computer.

Freeware

• Web Browser: Chrome     //Fast, no wasted pixels
• PDF Reader: Chrome   //Fast, good for feature-less reading
• Simple Text Editor: Notepad++     //Fast, simple (also use as LaTex editor)
• PDF Writer: PDFCreator    //No-nonesense open-source PDF writer
• FTP: FileZilla     //Finally a good, practically perfect FTP/SFTP program
• E-mail: Gmail     //Still miss folders a little, but love me my google
• Image Viewer: Irfanview     //Have only used for rare formats since Picasa 3
• Photo Organization: Picasa     //Brilliant Google software
• Video Player: MPC Home Cinema     //Cleanest player around for windows
• Movie/TV Organization: XBMC //Perfect program for your hard drive full of movies/tv shows
• Audio Player: Foobar2000     //Just plays audio files, infinitely customizable
• DVD Ripper: DVDShrink     //Program I used to rip all my DVDs, 
• Bittorrent Client: uTorrent     //Haven't switched torrent clients since I found this
• Calculator: Emu48     //Haven't found a better RPN calculator
• Window Manager: WinSplit Revolution //For fast window move/resize
• Unzipper: 7-zip //Clean, faster
• Disk Mounting: Virtual CloneDrive    //Just does one thing well
• DVD Movie Writer: DVDFlick     //Haven't used much, but seems simple

• Photo Editing: Photoshop
• Operating System: Windows     //Good balance between do it 16 ways with Linux and do it my way with OSX
• IDE: Visual Studio 2010 Professional     //Messy, but still better debugger and user experience than anything else I've tried (free on DreamSpark)