x11

This driver draws into a new window on 24-bit Directカラー, 8-bit Pseudoカラー, or 1-bit monochrome displays under the X11 window system. The driver dynamically determines whether the X11 display system has a 24-bit Directカラー, or 8-bit Psuedoカラー visual available and behaves appropriately for each. If neither of the above is available, the default visual is used as a 1-bit monochrome display. The size of the inside of the window is determined from the image resolution. The window can be moved, closed and reopened without affecting output.

After rendering is completed or aborted, the window remains on the screen. The window is removed only when the window is selected for focus and a q is typed on the keyboard. For 8- or 1-bit displays, after rendering is completed, an image-improvement process takes place and the image is redrawn. Monochrome images are dithered, and 8-bit images are redisplayed using a color map selected by the median cut color selection algorithm and dithered (see カラー Image Quantization for Frame Buffer Display, Paul S. Heckbert, Proc. SIGGRAPH '82, pp. 297-307).

In order to view a color image properly, the colors should be adjusted for the monitor. If this isn't done, images will usually appear to be too dark. The x11 display driver does this using a technique called gamma correction using a gamma value of 2.0 to approximate the color response of most color monitors. A different gamma value can be used by setting the DSPYGAMMA environment variable; for example,

DSPYGAMMA=2.6

will cause the driver to use a gamma value of 2.6 instead of the default. If the image appears washed out (bright), lower the gamma value (usually not below 1.0). If the image is too dark, raise the gamma value (usually not above 3.0). A gamma value of 1.0 will display the image unaltered on a display that has the color correction handled in another fashion.

windows

This driver draws into a new framebuffer window, on Windows systems. The size of the inside of the window is determined from the image resolution. The window can be moved, closed and reopened without affecting output.

After rendering is completed or aborted, the window remains on the screen. The window is removed by the normal methods, or when a q is typed on the keyboard. The image window also supports one additional command: when s is typed, the currently display image will be saved to disk with the filename specified in RiDisplay, if possible.

tiff

This driver produces an output file in Tagged Image File Format (TIFF). It can be used to store "r", "rgb", "rgba", "rgbz", and "rgbaz" images in 8-, 16-, or floating point 32-bit-per-component resolutions. The TIFF file created employs LZW compression; 8, 16, or 32 bits per sample; one, three, or four samples per pixel; and a planar contiguous configuration.

The tiff driver also has special configuration options to control the resolution information written into the output file as well as the compression used for output. These may be set from the RiDisplay parameter list or through the configuration file.

The TIFF compression scheme can be controlled by setting the parameter "compression", which takes a string value that should be one of "lzw", "packbits", "deflate", "pixarlog", or "none". The default value for the compression scheme may be set by adding the following line:

/display/tiff/compression  compression-scheme

where compression-scheme is is one of the above strings. If no compression scheme is specified, LZW compression is used.

The TIFF resolution unit can be controlled by adding the parameter "resolutionunit", which takes a string value that should be one of "inches", "centimeters", or "none". The default value for the resolution unit may be set by adding the following line:

/display/tiff/resolutionunit    unit

where unit is is one of the above strings. If no units are specified the default is "none".

If the TIFF resolution unit has been defined as above, the TIFF resolution values can be controlled by setting the parameter "resolution", which takes a value that is an array of two floats specifying the resolution in the x and y directions. The default value for the resolution values may be set by adding the following line:

/display/tiff/resolutionunit  xresolution,yresolution

where xresolution, yresolution are floating-point numbers separated by a single comma. There should be no spaces between the comma and xresolution. If no values are specified, values of 100.0 are used, except in the case where no units are specified, in which case values of 1.0 are used.

The default image size and pixel aspect ratio are set through the configuration file as follows:

/display/tiff/xres  xresolution
/display/tiff/yres  yresolution
/display/tiff/par   pixelaspectratio

sgif

This display driver writes Silicon Graphics, Inc., image files. It supports three or four channel files (mode "rgb", or "rgba") with 8 or 16 bit per channel depth. The files produced can be read by programs using the SGI "img" library or SGI "img" utility programs like "ipaste" and "izoom".

alias

This driver produces an output file containing RGB information. In addition, the driver will interpret the alpha channel by writing a separate 8-bit Alias Matte output file, and will handle z data by writing a separate 32-bit Alias or Composer depth file. Thus, the driver can handle "z", "rgb", "rgba", or "rgbaz" images. The alias driver creates a file whose name is specified in the RiDisplay call. The Matte file, if any, will have the additional suffix .mask, and the Depth file will have the additional suffix .depth.

When writing depth data, the driver will by default write Alias depth files. This behavior can be changed with an additional parameter, "zformat", which can be either "composer" or "alias".

targa

This driver supports Truevision, Inc. of file type 2, which is an uncompressed RGB or RGBA image (selected with RiDisplay modes "rgb" or "rgba").

The targa driver allows images to be merged over an existing TGA file. This option is selected by using the "merge" parameter to RiDisplay. If this option is selected, the existing file must have the same name as that specified with RiDisplay and it must be of the same x and y dimensions and file type.

cineon

This driver produces an output file in Kodak's Cineon image file format. It can be used to store RGB images in a 10-bit-per-channel, logarithmic encoding, as preferred by Kodak's Cineon software suite.

The cineon driver creates a file whose name is specified in the RiDisplay call. It accepts pixel data in either 8- or 16-bit-per-channel quantized integer format, or 32-bit floating-point format. These values are companded by the driver to 10-bit log, for optimal registration with film's recordable color range. Because 10-bit log can encode and store colors that are "brighter than white", use of full floating-point (unquantized) RGB output is recommended for best use of the format's capabilities. The format only supports RGB image files (mode "rgb"), and any alpha channel supplied by the renderer is ignored.

The cineon driver also has special configuration options to control the log codes that are used to compand the data that is written into the output file. These may be set from the RiDisplay parameter list or through the configuration file.

The Cineon companding equation be controlled by adding the parameter "setpoints" to the RiDisplay parameter list. The parameter takes an array of two integers, which represent the 10-bit code used to represent 1% Black, and the 10-bit code used to represent 90% White (see Kodak's Cineon documentation for explanations of these values). The default values for these setpoint codes can be set by adding the following line to the rendermn.ini configuration file:

/display/cineon/setpoints  black,white

where black and white are integer values separated by a single comma. There should be no spaces between the comma and white. If no values are specified, the standard default values of 180,685 are used.

softimage

This display device driver produces an output file in the Softimage Picture File Format. The driver supports 8-bit "rgb" or "rgba" images, with or without RLE compression.

The softimage driver has one configuration option to determine whether the output undergoes run length encoding compression. This can be controlled by setting the parameter "compression" in the RiDisplay parameter list. The parameter takes the value of "rle" or "none", to enable or disable compression, respectively. The default setting is "rle".

mayaiff

This driver produces an output file in the Maya Image File Format. The driver can generate 8-bit or 16-bit RGB along with an optional 8-bit or 16-bit Alpha channel and optional 32-bit Z data; thus, this driver supports the "rgb", "rgba", "rgbz", and "rgbaz" display modes.

shadow

This display driver produces an output file containing depth (mode "z") information in the shadow map texture file format, which is a proprietary format peculiar to PRMan. The shadow map texture format is accepted by the renderer for use in light shaders that produce shadows via the shadow() shadeop.

The shadow driver has two configuration options. The "minmax" parameter can be set to a value of 1 to indicate that the generated shadow should be a minmax shadow map, suitable for use in soft shadow generation. By default this option is disabled (has a value of 0). The "format" parameter can be set to a value of "tiff" or "pixar" to indicate the format of the output texture map; it defaults to the value specified for /prman/textureformat in rendermn.ini.

zfile

Zfile is a PRMan display driver that produces an output file containing depth (mode "z") information. The zfile format is accepted by the renderer and the txmake utility program as the depth image required to make a shadow texture map.

The file format is peculiar to PhotoRealistic RenderMan. It has the following form:

Header:
Bytes   Description
0-3     magic # (0x2f0867ab)
4-5     width (short)
6-7     height (short)
8-135   shadow matrices (32 float values, 16 each for NP and Nl)

Image Data: (immediately follows)
width*height IEEE floats

deepshad

Deepshad is a PRMan display driver that produces "deep texture files", which store more information per pixel than a normal texture. These files are stored in a proprietary format peculiar to PRMan. The primary usage of this driver is to generate deep shadows, which are accepted by the renderer for use in light shaders that produce shadows via the shadow() shadeop. In order to do so, the usual shadow map setup must take place (see Making Shadows with RenderMan), and the display mode must be specially set to the value "deepopacity", which indicates that the given file contains deep shadow transparency information. For example:

Display "out.dshad" "deepshad" "deepopacity"

will generate a deep shadow file out.dshad.

This display driver can also produce "deep compositing files". These files are similar to standard images produced by other display drivers, but may be used to faciliate deep compositing applications. No special display mode is necessary to produce these files. For more information, consult the Deep Compositing application note.

The deep shadow display driver has the special property that multiple subimages can be appended to a single file in a single render. This happens automatically when multiple Display lines referencing the same filename are issued within a single FrameBegin/FrameEnd pair.

The deep shadow driver accepts several configuration parameters:

int[2] tilesize

string compression

string type

string subimage

string volumeinterpretation

openexr

This driver supports OpenEXR, a high dynamic-range image, floating point file format developed by Industrial Light & Magic.

When using this display driver for rgba or Z output, you should turn rgba and Z quantization off by using a floating point Quantize statement, e.g.:

Quantize "rgba" 0 0 0 0
Quantize "z"    0 0 0 0

As of PRMan 17, the driver supports an optional "int asrgba" option, which takes the first four channels and always calls them RGBA.

This display driver also supports the output of image channels other than "rgba" using the Arbitrary Output Variable mechanisms.

This driver maps RenderMan's output variables to image channels as follows:

By default, the "preferred" channel type is the value specified for /display/openexr/type in rendermn.ini, which can be either "half" (16-bit) or "float" (32-bit). If not specified therein, it defaults to "float". The preferred type can be changed by adding a "type" argument to the Display command in the RIB file. For example:

# Store point positions in HALF format
Display "gnome.points.exr" "openexr" "P" "string type" "half"

The default compression method for the image's pixel data is the value specified for /display/openexr/compression in rendermn.ini, which may take the value of "none", "rle", "zip", "zips", "pixar", "b44", or "piz"; if not specified therein it defaults to "zips". You can select a different compression method by adding a "compression" argument to the Display command. For example:

# Store RGBA using run-length encoding
Display "gnome.rgba.exr" "openexr" "rgba" "string compression" "rle"

Note, the OpenEXR display driver also supports the -recover option which allows prman to restart rendering where it aborted if the same file is rendered a second time.

Starting with PRMan 17, the driver supports both scanline and tile-based file output by adding a "storage" argument to the Display command that can be either "scanline" or "tiled". For example:

# Store RGBA using in a tiled format
Display "gnometiled.rgba.exr" "openexr" "rgba" "string storage" "tiled"

The default is scanline-based output, which is the format written by previous versions of PRMan. The new tiled format optimizes the amount of internal buffering needed, which can reduce the display buffer memory footprint, especially for large images with many display channels and non-horizontal bucket orders. Note that the -recover option works only for horizontal and vertical bucket orders with the tiled format.

Starting with PRMan 17, the driver supports the injection of arbitrary metadata. This is done by passing named parameters with the form "exrheader_$key", where $key will be the name of the attribute as it shows up in the OpenEXR header. For example,

Display "myfile.exr" "openexr" "rgba" "string exrheader_author" ["Bob"]

Will result in exrinfo myfile.exr reporting:

author (type string): "Bob"

Any number of attributes of this form can be passed, with any inline type (e.g. "string", "int", "int[2]", "float", "float[4]", etc).

texture

This display driver produces an output file that will be accepted directly by the renderer for use in the texture() shadeop. The image will either be in TIFF format or in Pixar's mipmapped texture file format, which is a proprietary format peculiar to PRMan. 8-, 16-, and 32- bit (floating point) image output is supported. Images rendered using this display driver must have power of two dimensions - no attempt will be made to resize the image when using this driver.

The texture driver supports several configuration options. The "pattern" parameter can be set to a value of "none", "diagonal", or "all" in order to control the mipmapping mode; the default is "diagonal". The "smode" and "tmode" parameters control the wrap modes of the texture and accept the values "black", "clamp", or "periodic"; the default is "black". The "format" parameter can be set to a value of "tiff" or "pixar" to indicate the format of the output texture map; it defaults to the value specified for /prman/textureformat in rendermn.ini.

Note that for proper 16 bit output, one must use Quantize 32767 0 32767 0, and not the usual Quantize 65535 0 65535 0. This is because PRMan's system currently expects signed, not unsigned shorts.

pointcloud

The pointcloud driver is the default geometry driver used by bake3d(); it cannot be selected as a display driver for RiDisplay. This is the only format currently supported as an input format to brickmake and RiBrickMake. Documentation on this format can be found in the application note Baking 3D テクスチャs: Point Clouds and Brick Maps.

When rendering using netrender, grids that overlap bucket boundaries can get shaded more than once. If the grids have shaders that call bake3d(), baked points from those grids will be sent to the display driver multiple times. For some uses of point clouds the extra points won't matter, but for other uses (e.g. subsurface scattering) they do matter. In such cases, the duplicate grid points can be eliminated in the display driver by setting the parameter EliminateDuplicateGrids to 1 on a DisplayChannel line. (The default is 0.) Here is an example of the syntax:

DisplayChannel "float _area" "float EliminateDuplicateGrids" 1

rib

The rib driver is a geometry driver that can be used by bake3d(); it cannot be selected as a display driver for RiDisplay. The rib driver is selected by using the parameters "driver" "rib" in bake3d(). This driver creates RIB files containing PRMan grids represented as RiPoints, RiCurves, or RiPointsPolygons. Point, normal, and all other variables specified as name/value pairs to bake3d() will be emitted as geometry vector information.

When rendering using netrender, grids that overlap bucket boundaries can get shaded more than once. If the grids have shaders that call bake3d(), baked points from those grids will be sent to the display driver multiple times. For some uses of point clouds the extra points won't matter, but for other uses (e.g. subsurface scattering) they do matter. In such cases, the duplicate grid points can be eliminated in the display driver by setting the parameter EliminateDuplicateGrids to 1 on a DisplayChannel line. (The default is 0.) Here is an example of the syntax:

DisplayChannel "float _area" "float EliminateDuplicateGrids" 1

wavefrontobj

The wavefrontobj driver is a geometry driver that can be used by bake3d(); it cannot be selected as a display driver for RiDisplay. This driver creates files in the Wavefront .obj format, containing PRMan grids represented as points, lines, or faces. Due to restrictions in this format, only geometric point, normal, and texture coordinates (only if s, t are in the bake3d() optional data list) will be emitted; no other information (including any optional bake3d() name/value pairs other than s, t) are supported.

multires

The multires display driver provides high-performance rendering of the multi-resolution images produced by PRMan in re-rendering mode. While this is the preferred display for re-rendering, it supports a limited set of pixel types: 3 or 4 channels of byte or floating point images.