| IvrView - interactively apply different transfer functions to volume rendered images |
| IvrView (no command line options) |
|
When working with Direct Volume Rendering (DVR), one of the
more substantial problems is to find a useful and
aesthetically pleasing transfer function to apply to a
volume. Unwise choices in opacity can lead to invisible or
obscured features, and misuse of color can lead to some
pretty garish images. Compounding the problem is the problem
that Direct Volume Rendering can take a substantial amount
of time for large datasets, and one may need to wait several
minutes or more before seeing the result of applying a
transfer function. This substantially cuts down on the
number of iterations one is willing to make to find a good
transfer function. The IVR system (IVR file format + IvrView) drastically increases the editability of transfer functions by providing a scheme in which the most time-consuming part of volume rendering (transformation into screen-space plus interpolation) is performed only once and the results stored in a (rather large) file. Once that step is complete, the file can be loaded into IvrView, and different transfer functions can be applied in a matter of a few seconds. Combined with a transfer function editor such as cmed, interactive editing of transfer functions is thus possible. |
| At present, there are no command line options to IvrView. All interaction is done via the GUI, as described in the next sections. |
| Open IVR... (Ctrl-o) |
| Opens a dialog box allowing you to choose a .ivr file. Note that these files are large, and may take a while to load, during which period the dialog box will remain open but unresponsive. |
| Open Colormap... |
|
Opens a dialog box allowing you to choose a colormap file to
use as a transfer function. Currently, the only supported
format is a text file of the form: N R G B A R G B A ... Where N is an integer describing the number of entries to follow, and each of the R, G, B and A are floating point numbers in the range of [0,1]. (values greater than 1 may be used to 'overheat' certain colors, or to make certain features more opaque) |
| Reload colormap (Ctrl-r) |
| Reloads the current colormap file and re-applies it to the volume. Useful for when you are actively editing the colormap in an external colormap editor and want to view the changes. |
| Save colormap |
| (Unimplemented) |
|
The area just below the menu bar is where the rendered image
will be displayed. Currently, this is fixed at a size of
640x480 pixels. When an ivr file is loaded, one can peek at the RGB value of any pixel by clicking on it. The pixel location and the RGB value (expressed as floating point numbers in the range [0,1] are printed to the console. |
| Directly below the drawing window are several text-boxes containing information about the currently loaded file, including the scalar range of the data in the volume, the "volume depth", which is the length of the longest ray segment intersecting the data, and the locations of both the volume and colormap files |
| Here, one can make a number of changes to affect the rendered image. After a change to any one of the settings, the settings may be applied by hitting the Render button, or equivalently, hitting the return key on the keyboard. Each setting will be described below: |
| Clip |
|
Set a clipping range for rendering - only samples that fall
within this range will contibute to the image. The distances
are measured from the start of each ray, which in most cases
(especially when the viewpoint was chosen to be inside the
volume) is the eye-point. Not the most important
setting. Upon loading a new IVR file, this range is set to encompass the entire dataset. |
| Colormap Range |
|
Together, the colormap range and the colormap itself define
the transfer function to be used. The transfer function
affinely transforms the colormap range to the range [0,N-1],
where N is the number of color entries in the color map.
Values outside the scalar subrange are clamped to 0 or
N-1. Upon loading a new IVR file, the colormap range is set to the actual scalar range of the data in the file. For single frames in an animation, however, you probably want to pick a single colormap range for the whole animation. |
| Color Scale |
| A brightness factor - each red, green, and blue component of the final image will be multiplied by the color scale. |
| Compositor |
|
You can change the compositor being used, which determines
how the alpha channel of the colormap is interpreted. For the compositor descriptions below, we use the following definitions |
| sample[n] |
| The value of the n-th sample along the ray in back-to-front order |
| width[n] |
| The width of the n-th sample interval along the ray. |
| F[v] |
| The transfer function, applied to the value v. The result is an RGBA tuple |
| color[n] |
| The result of the preceding n compositing operations. |
| c.rgb c.a |
| For an RGBA color c, these return just the RGB components or the alpha components individually. |
| c.rgb*a |
| Shorthand for: c.rgb*c.a |
| Additive |
|
In the additive compositor, no sample is considered opaque -
instead, the contributions of each sample along the ray are
summed together (weighted by the width of the sample
interval) color[0] = {r=0,g=0,b=0} color[n] = color[n-1] + (F(sample[n]).rgb * width[n]) |
| Bock |
|
The algorithm used by Dave Bock's original AMR renderer: color[0]=0 temp.rgb = color[n-1].rgb*a + (F(sample[n]).rgb*a * (1-color[n-1].a)) color[n].rgb = color[n-1].rgb + temp * width[n] |
| Over |
|
This implements the standard over-operator for compositing,
which is probably the one you want to use, as it allows for
both opacity and emissivity. opacity = F(sample[n]).a * width[n] color[n].rgb = (F(sample[n]).rgb * opacity) + color[n-1]*(1-opacity) |
| Ideal |
| The ideal is meant to do a full integration of opacity and emissivity, as opposed to the coarse approximation performed by the over operator. It is not quite functional yet. |
|
There are some restrictions to using IvrView: The pre-transformed volume (stored in .ivr format) represents only a single point of view, so you can't navigate around the data being rendered. There are hardware-accelerated direct volume renderers which do allow such navigation, however they tend to be lower quality, and not as accurate for previewing. The images produced from IvrView are very close to the output from a high-quality software render. Another restriction is that the pre-transformed .ivr files must be especially produced by a volume renderer. While the IVR format is quite simple (see ivr(5)), the only renderer which outputs in that format is the amore AMR renderer. |
| amore(1) ivr(5) |