Friday, December 15, 2006

Gamma correction

Most graphics monitors have a "gamma" that gives a rough approximation to their non-linearity. For example, if we use an internal color space where all of R, G, B are stored as 0 to 1 values, then the physical spectra coming from the red part of the pixel would be:

output_red( lambda ) = max_output_red(lambda) * pow( R, gamma )

where gamma is typically a number around 2.0. Suppose gamma is 2.0. If we want to display a red that is 1/4 the maximum, the R would would store in a file to send to the display would be 0.5.

Note that all of this is not to make up for some "defect" in the monitor. When you use 8-bit per channel color representations, there are only 256 gray levels available. If you space these out so they LOOK evenly spaced to a human observer, that makes a perceptually uniform set of 256 grays and banding is minimized. But since human intensity perception is non-linear (think of the "middle gray" photographer's card which is physically about 1/5 the rreflectance of white paper), this means the monitor must be as well.

Monday, November 27, 2006

Opponent process color space

For many applications, opponent process color works better than RGB or other common graphics spaces. Opponent color encodes a greyscale channel along with two color channels that range red to green and blue to yellow. A simplified version is:

V = (R+G+B)/3
RG = R-G
BY = B - (R+G)/2

Note that the second two channels run -1 to 1.

Thursday, November 23, 2006

Moore's Law and Ray Budget

Moore's Law states the number of transistors on a chip will rise exponentially, and this has happened fairly steadily. A variation relates to performance, which for CPUs has doubled every two years or so. Another variation is that CPU performance per dollar has doubled every 18 months or so. In practice, the cost law implies you can buy more and better CPUs as time goes on. Finally, screen resolution has been on its own curve that doubles the number of pixels every 10 years or so.

What does this mean for rendering? About 27 years ago Turner Whitted ray traced a 640x480 image at about 1 ray per pixel. For the same money budget we can get about 18 doubling of performance, but we have 3 doublings or so in the number of pixels. So now we should be able to do 2.5 million pixels, each with 2^15 = 32k rays.

A caveat is that we want to use more objects. Fortunately, performance in practice is related to the log of the number of objects.

What does this all mean? The rendering community should raise its intuition for how many rays per pixel we can use in practice. In academics, where it is good to think 5-10 years out, we should be looking at another 6 doublings or so, and a million rays per pixel should then be reasonable.

Another way to compute ray budget is to assume 30Hz interactive ray tracing will become practical at 1 ray per pixel. For an 8 hour batch run using the same infrastructure, you can send 30*60*60*8 = 864k samples per pixel.

Bottom line: batch rendering algorithms should assume a million samples per pixel or so are available, and this should make new algorithmic possibilities practical.

Monday, November 20, 2006

Outer product

Given two three vectors the "inner" product is:


...........|X|
[x y z]|Y| = [xX + yY + zZ]
...........|Z|

Which we use all the time (dot product). There is
also an outer product:

|x|.................|xX xY xZ|
|y|[X Y Z] = |yX yY yZ|
|z|.................|zX zY zZ|

I'm not sure this is useful for anything in graphics, or even what this thing is operationally.

More on bilinear patch intersection

Because ray - BL patch involve solving a quadratic, I am concerned there will be "cracking" issues where rays sneak between adjacent patches. A cure for that would be to do four "ordered edge" tests on the ray and the patch edges. More information on such tests in in Andrew Kensler's and my recent triangle intersection paper. Note that Pluecker coordinates are not needed-- the easier to comprehend (for me) triple product test will do the job.

Friday, November 17, 2006

Ray tracing bilinear patches

I'm going to try to reimplement the displacement map method I did with Brian Smits and Mike Stark a few years ago. A key part of that method is intersecting bilinear patches. Given a ray o+tv and a patch with vertices p00, p01, p11, and p10 we have

o + tv = (1-u)(1-v)p00 + u(1-v)p10 + (1-u)v p01 + uv p11

This is three equations (x, y, and z) and three unknowns (t, u, v). The way Brian and I solved this was to eliminate t by using 2 of the equations and then solve the uv system directly. A similar approach is used in Shaun Ramsey et al.'s jgt paper. This has always been unsatisfactory to me because it chooses an arbitrary ordering of the dimensions. Perhaps a numeric solution would be more robust?

Another possibility is to use Kajiya's old trick. Consider the ray as the intersection of two planes

(p - p0) dot N0 = 0
(p - p1) dot N1 = 0

If you substitute
p = (1-u)(1-v)p00 + u(1-v)p10 + (1-u)v p01 + uv p11

into both the plane equations above then you get two equations in uv of the form:
Auv + Bu + Cv + D = 0 (1)
auv + bu + cv + d = 0 (2)

If you solve one of those for u and then plug it into the other, you get a quadratic in v. That leaves four possibilities of what to do first:

solve (1) for u
solve (1) for v
solve (2) for u
solve (2) for v

There is also a degree of freedom for which planes to use. In any case seems more stable than the three equations, 2 unknowns method above.

Image formats for realistic rendering

It is remarkable to me that there is no accepted standard for high dynamic range images that is based on CIE standards. Such a format should support XYZ and scotopic luminance V. A big dump with four floats per pixel would work fine, although of course more compressed formats are certainly straightforward. If anyone is aware of such a format that programs such as photoshop can read out of the box, please let me know.

Monday, November 13, 2006

How long before interactive ray tracing is on the desktop?

Solomon Boulos and friends in our group at Utah have their ray tracer going about 1 frame per second on one core of a 2GHz Opteron 870 with one ray per pixel at a million pixels. This is with full shadows and reflections so is slower than a lot of the numbers you see in the literature. For NTSC resolution (640x480) that would be more like 3-4 frames per second. So we'd need about 8 of those cores for fluid motion. So we are right on the threshold for such low resolutions. If Intel comes through with its 60 core chip, and ray tracing maps to it, then HDTV resolution and some multisampling should be straightforward. The Cell is also a possibility as shown by Carsten Benthin and his collaborators in their recent papers. We could get ray tracing even sooner if an ASIC is built. I don't see why a game box based on ray tracing would not be feasible now.