This semester I took CS 530: Introduction to Scientific Visualization. It was my first graphics course as well as my first graduate-level course. It covered various methods of data processing and visualization of scientific data such as medical scans, physical simulations, or mathematical equations. The best part about the course is that we got to make pretty pictures.
For the first project, we implemented three forms of vector visualization. The vector field we used was the electric field created by a positively charged object at the center of the space surrounded by four negatively charged objects. First, we rendered the streamlines representing the paths of a particles along the field:
Second, we rendered the time surface, which is the expanding (or contracting) surface created by a set of points at a particular point in time:
Third, we rendered the flow volume, which is the "tube" with borders defined by the streamlines. This type of visualization shows the divergence or convergence characteristics of a vector field.
For the second project, we impelemented a surface rendering algorithm called marching tetrahedrons, which is a particular form of marching cubes. We rendered two datasets:
First, the electron density of a methane molecule:
Second, a prepared dataset of someone's head:
We used these same two datasets for the third project, but we rendered them instead using volume rendering with ray casting. The basic idea is that one shoots a ray out of every pixel of the image and accumulates color for each sample point along a ray that passes through the data.
Note that one can see both the brain and the skull in the following renders of the head data.
For the term project, students had to prepare a project proposal, implement the proposed visualization, and then write a 12-page paper on the project.
All in just two weeks.
We were "encouraged" to work in groups for this project, so Marc and I decided to work together. Our project proposal had three parts:
- Get some real medical data to visualize. In the previous three projects we had only used calculated data (as in the case of the electrical field and methane molecule) or prepared datasets (as in the case of the head).
- Render more than one surface. The surface rendering project only rendered one surface.
- Use the view orientation, color, and other parameters from the surface rendering to create a volume rendering. In all the projects, we had to type in parameters by hand or, in the case of my volume rendering project, create an initialization file with the paramters. We wanted to make the process easier.
We initially planned to use the CT or MRI scans of my leg implant. I called up my surgeon, but we found out that my scans had taken place before the hospital went completely digital. My surgeon's assistant— who went above and beyond searching for data for us to use— learned that a man with a soft-tissue tumor was getting an MRI one day last week. She got the technicians to burn a CD of the data, and I traveled to the office the next day to pick it up.
The data was ideal for the project. It was in a standard binary format called DICOM, which stands for Digital Imaging and Communications in Medicine. I read up on the standard, and wrote a reader in about two days. Here are some of the raw MRI slices direct from the machine:
While I was working on the DICOM reader, Marc was working on the user interface. Once those two parts were more or less functional, we started working on the rendering portions of the application. He took care of the surface rendering, greatly extending the project two code such that it could respond better to user input and render up to three translucent surfaces. Rendering three surfaces was more involved than it might appear because the triangles that form the surface must be drawn from front to back for lighting and transparency to work. Also, we needed to calculate the camera position and orientation for the volume rendering to work.
I built the volume rendering section such that it could take the view parameters from the surface section, make some good guesses about the volume rendering parameters, and output a ray cast image. Unlike project three in which rays traveled in parallel, we had to cast diverging rays to make the perspective appear the same as in the surface rendering.
We managed to iron out the last glaring bugs during the final stress-filled day before the due date. We traded off on writing the paper and programming up into the final minutes. Amazingly, we turned in the final CD and paper printout ten minutes before the midnight due date.
Despite having a ridiculously short time to implement the project, I think the final pictures speak for themselves:
Here we used the methane data to test the multiple surfaces. The first image is the GUI with the surface rendering; the second is the volume rendering.
Here is a rendering of one of the MRI data sets. It is looking at the back of the patient's thigh.
I feel that the following images made the project. The first picture is the MRI slice, the second shows the surface rendering, and the final picture shows the volume rendering. The tumor is obvious in the MRI slice and surface rendering. It is a little less visible in the volume rendering, but it is still there.
I have posted the application executable here if anyone would like to try it out. I have disabled the head and MRI data because the data files are so large. You can play with the surfaces of the methane data by adjusting the sliders on the right. Click and drag on the surface render window to rotate the molecule. Right-click and drag to zoom in or out. You can create a volume rendering by clicking the "Render" button.
A word of warning: I am ashamed to admit that the volume rendering leaks memory like crazy, so you may not want to run it more than two or three times before restarting the application. It will very likely crash if you render much more than that. Also, the volume renderings can take anywhere from one to five minutes, depending on your CPU speed and how much memory you have.