Category Archives: Resources

Rendering-related papers of the past 350 years

The Royal Society (full name: Royal Society of London for the Improvement of Natural Knowledge) is marking the start of its 350th year by putting pdf versions of 60 notable papers from its journal, Philosophical Transactions (founded in 1665) on the web.  Although all the selected papers are crucial to the history of science, I wanted to call out those particularly related to the fundamentals of rendering.

Almost all of Ke-Sen’s pages now up

Ke-Sen Huang has put up almost all the remaining pages that were taken down, after revising them according to ACM’s requirements:

The only pages not up yet are those for ACM’s Symposium on Solid and Physical Modeling (SPM) for the years 2005-2008.

More of Ke-Sen’s pages are back up (+ a new one)

Following the reinstatement of the SIGGRAPH 2009 page a few days ago, the following paper pages have been modified to the new ACM guidelines and are now back up:

This is a little less than half the pages that were taken down.

All this and Ke-Sen has also started to collect the Eurographics 2010 papers as well – the man’s a machine!

Things I learned from the ACM

Well, not just from the ACM, but also from people involved in the Ke-Sen Huang and ACM Publications situation.

  • ACM SIGGRAPH membership also gives you access to just about all computer graphics papers in the ACM Digital Library. This I knew already, but found that others haven’t realized it. Any conference sponsored by SIGGRAPH is available, from what I can tell, e.g. I3D. I noticed a few weeks ago that the SIGGRAPH 2009  Posters were not accessible to me through this benefit; the ACM fixed this problem when I reported it.
  • Deep linking, where one site links directly to content on another site, is not illegal. The EFF notes that deep linking has not yet been found to be illegal by the courts. However, linking to sites providing infringing (illegal) copies of a work for download is contributory infringement.
  • “Sweat of the brow” compilations, such as the white pages of phone books, are not copyright. There is no original expression involved, so the Supreme Court ruled such are not protected. Paula Samuelson’s article in the Communications of the ACM (Google Scholar hits here) is a fascinating overview. Titles are not copyright. Elements such as the order in a Table of Contents are in a gray area, from what I can see. The ordering and grouping of the articles into sessions may be copyright protected – the courts have not ruled, as far as I know. Changing that order on an external web page would then not be copyright, since it would be a different “original” expression. Alphabetized or numerical ordering is not copyright protected.
  • You do not need to enforce your copyright to maintain it, unlike a trademark. You can ignore an infringement and not lose your rights. So the argument that a copyright must be protected now in order to preserve it in the future is incorrect.

DX9 GPU Hacks

When I transitioned from PC to console programming in 2003, I was struck by the many graphics hardware features I now had access to which are not supported by PC APIs such as Direct3D and OpenGL (the latter is in slightly better shape due to its support of vendor extensions).  Some of these features are supported by newer iterations of Direct3D, but for many people Direct3D9 is still the target of choice (it is the newest version supported on XP, and it most closely matches the capabilities of current-gen consoles).

Over the years, graphics hardware vendors have implemented an array of undocumented, semi-official hacks around the Direct3D9 API to allow access to more hardware features.  Aras Pranckevičius has recently put up a very useful list of these.  I have not seen this information anywhere else – kudos to Aras for doing the work.

Do you really display PNGs?

Digging up the luma palette images reminded me of a useful PNG I made back around 1996 or so, back when this file format was quite new. A peculiarity of the PNG file format is that it stores alpha separately, unmultiplied. For 3D work it is the norm for the color stored to be premultiplied by the alpha. I won’t go into the how and why; this topic is covered in our book on pages 139-140 and is discussed on Wikipedia, among many other places.

One nice feature of premultiplied images is that you can just ignore the alpha channel entirely when displaying them for preview. This is equivalent to compositing the image over a black background. With PNG, you are required to examine the alpha channel and multiply the RGB by it in order to get the right color to display. Unmultiplied alpha has a 2D photo sense to it, the RGB image exists everywhere and the alpha is masking some part of it. The alpha is not an integral part of the pixel, as it is in 3D.

On to the image:

alpha_test

I cobbled this together to be able to quickly check if a particular piece of software was respecting the alpha channel in PNG. Back then, most software didn’t, so what would be displayed is “This viewer does not support transparency”. Today, it’s pretty rare to find such flawed PNG readers commercially (I couldn’t find a current example for you to try). Still, I’ve found this image useful as a quick reality check for whether software is using the alpha in a PNG.

Lest we forget, it was the LZW patent in the GIF format that helped popularize PNG as a patent-free alternative for the web. The Unisys patent finally fully expired back in July 2004, so it’s a moot point now, but for awhile this was a patent enforced for tens of millions of dollars, with over 2,000 licensees. My favorite quote on the whole controversy was from a flak at Unisys giving spin about their positive role enforcing a patent on a technology unknowingly used in a file format that they didn’t invent:

But Unisys credited its exertion of the LZW patent with the creation of the PNG format, and whatever improvements the newer technology brought to bear.

“We haven’t evaluated the new recommendation for PNG, and it remains to be seen whether the new version will have an effect on the use of GIF images,” said Unisys representative Kristine Grow. “If so, the patent situation will have achieved its purpose, which is to advance technological innovation. So we applaud that.”

Constant Luma Palette

I was looking around my image files and found this:

Constant luminance image

I made this incredibly hideous drawing back in 2001. What’s interesting about it is that if you convert this image to grayscale, using say Irfanview or XnView, it disappears entirely into a solid gray. Download and try converting it with your favorite image manipulation program (I refuse to insert a solid gray image of it here as “proof”).

Here’s the palette I used, in image form; the perl program for creating it is at the end of this post.

LUMA_PAL

My goal was to make a palette where you could draw anything, knowing that if it were converted to grayscale (e.g., via a scanner, or printed on a monochrome printer) it would become illegible. A similar technique was used long ago as a copy protection scheme for documentation for some computer games: print black on dark red and a photocopier would typically return all-black. Perhaps publishers that are against Google Books’ scanning of their works will use such a palette someday… I can only hope not.

What I found interesting about this little experiment was how differently we perceive the various colors compared to the constant luma computed. Grayscale conversion is supposed to take colors with the same impact and give them the same gray level. In my drawing, that pink is way brighter than the gray clouds, and even the green streaks on the ground at the lower left are brighter than the rest of the ground plane. It makes me wonder if there’s some better conversion to grayscale that more closely matches our perception of impact. Wikipedia mentions luminance as just one strategy; are there others that work better (on average)? Info, anyone? Update: a keynote at I3D 2022 by Dr. Margaret S. Livingstone discussed this very effect in depth; see her book Vision and Art for information about it.

Luma

So what’s luma, versus luminance? It turns out that the formula we typically use to convert to grayscale is flawed, in that what should happen is that the color to be converted should be put in a linear space, converted to grayscale, then gamma corrected. By applying the grayscale formula (see below) to the displayed image data directly, what most every image manipulation program typically does, we get the order wrong. However, it’s a lot more work to “uncorrect” the gamma (make the image’s channels represent linear values), apply a grayscale formula, and then gamma correct. Long and short, the grayscale value computed without taking into account gamma is called “luma”, to differentiate it from a true luminance value.

You can find more about this in Poynton’s color FAQ and Wikipedia, and details about the difference this makes can be found here. Relevant quote from this last source: “…introduces a few image artifacts that are usually fairly minor. The departure from the theoretically correct order of operations is apparent in the dark band seen between the green and magenta color bars of the standard video test pattern.”

I decided to reformulate the palette today and see what it looks like with constant luminance instead of luma, by raising the normalized palette values to the power 0.45. There’s a definite difference, as expected:

lumapal10x luminancepal10x luminancepal8

Left is the original luma palette, zoomed up (hmmm, should have used nearest neighbor); middle is the luminance palette, with gamma correction; right is another “slice” of the luminance palette, having 0.8 being the highest linear green value. These right two images do look more equivalent in visual impact to me. So a better perceptual grayscale, I suspect, is to correctly account for gamma. Trying this rightmost palette out, the image becomes:

LUMINANCE_IMG

This looks a lot better to me, more equal. The green streaks on the ground are hardly noticeable now, for example. The pink house still looks a bit bolder than the rest, but otherwise is pretty reasonable. I’ll bet if I used the newer grayscale formula (see below) the pink might fade further—well, enough hacking for the day or I’ll never get this post done.

LCD brand does matter: my Dell LCD displays the image fine from most angles, the Macbook Pro screen definitely varies with vertical angle in particular, and it’s hard to know what the “right” angle is. Using Steve Westin’s old gamma page and aiming for 2.2 seemed to work.

In case you’re curious, here’s what the grayscale image looks like for this luminance-balanced image, using XnView:

LUMINANCE_grayscale

Which to me emphasizes the weaknesses of using luma instead of luminance: the house is darker, the clouds are lighter in grayscale? Not to my eye.

Gory Details

Conversion to luma Y’ grayscale uses a formula such as:

Y’ = 0.212671*R’+ 0.715160*G’+ 0.072169*B’

from Poynton’s color space FAQ; it’s the common form for contemporary CRTs.

Or older ones such as:

0 299
0 587
0 114
’ = ’
+ ’
+ ’

Y’ = 0.299*R’ + 0.587*G’ + 0.114*B’

from Poynton’s FAQ and used in his Digital Video and HDTV: Algorithms and Interfaces. This is the one I used back in 2001.

Or:

Y’ = 0.2904*R’ + 0.6051*G’ + 0.1045*B’

from Dutré’s useful Global Illumination Compendium – download it free.

Here’s the Perl program, which outputs to a PPM file.

printf "P3\n16 16\n255\n";
for ( $r = 0 ; $r < 16 ; $r++ ) {
    for ( $b = 0 ; $b < 16 ; $b++ ) {
        $red = $r * 255 / 15 ;
        $blue = $b * 255 / 15 ;
        # The 255 below can be set in the range 180-255 for different constant palettes.
        $green = 255 - $red*0.299/0.587 - $blue * 0.114/0.587 ;
        printf( "%d %d %d%s", $red+0.5, $green+0.5, $blue+0.5, ($b==15)?"":" " ) ;
    }
    printf("\n") ;
}

If you make the starting point for green lower than 180, the green channel would take on negative values.

printf "P3\n16 16\n255\n";
$gamma = 1/0.45;
for ( $r = 0 ; $r < 16 ; $r++ ) {
    for ( $b = 0 ; $b < 16 ; $b++ ) {
        $red = $r/15;
        $blue = $b/15;
        # The 0.8 below can be set in the range 0.703 to 1 for different constant palettes.
        $green = 0.8 - $red*0.299/0.587 - $blue * 0.114/0.587 ;
        # gamma correct
        $red = 255 * $red**(1/$gamma);
        $green = 255 * $green**(1/$gamma);
        $blue = 255 * $blue**(1/$gamma);
        printf( "%d %d %d%s", $red+0.5, $green+0.5, $blue+0.5, ($b==15)?"":" " ) ;
    }
    printf("\n") ;
}

SIGGRAPH 2009 Course Pages

The organizers of SIGGRAPH Courses often put up web pages dedicated to the course.  These typically have the latest version of the course notes and the slides.  I’ve found a bunch of SIGGRAPH 2009 course pages, and thought it would be convenient to have them all in one place:

SIGGRAPH courses are a consistently good source of information – if any of these courses are about a topic which interests you, you might want to take the time to read the course notes and slides.