• home
• « prev
• next »
• index

Output Shaders

Output shaders are user-written functions to operate on frame buffers. They have access to every pixel in all available frame buffers after rendering, and can be used to perform operations like post-filtering or compositing.

Output Files

Writing frame buffers to files is enabled by specifying data type, file format and file name.

3.6 In framebuffer statements, adding the file properties to a buffer marks it to be written to the file. For multi-channel formats, the same file name may be given to several buffers to write them as multiple channels to the same file.

Deprecated In file output statements, if the data type is omitted and more than a single target data type is supported by a format, then a default data type is chosen that is assumed to be the "best" type for the given image format. This default type is underlined in the table below.

The data type implies the frame buffer type. There are special file formats for depth, vector, and label files, in addition to a variety of standard color file formats. By listing the appropriate number and type of framebuffer statements (or output statements), it is possible to write multiple files. For example, both a filtered file and the unfiltered version can be written to separate files by listing multiple framebuffer statements and output statements: one to write the unfiltered image, one that runs an output shader that does the filtering into a secondary buffer, and finally another one to write the filtered image from that buffer. Output statements are executed in sequence.

The following file formats are supported for image output:

* OpenEXR ¹ in mental ray supports the compression modes RLE (run-length encoding), PIZ (wavelet-based), ZIP (Huffman dictionary), and PXR24 ². The first three are lossless; PXR24 is lossy if the written data is stored in full floating-point precision and lossless otherwise. The fastest ones are normally RLE or ZIP; PIZ usually achieves better compression but is much slower. The OpenEXR manual recommends PXR24 for depth maps. Note, that mental ray defaults to RLE, previous versions were using ZIP compression by default.

Each of these file formats implies a particular default data type (the entry underlined in column "Supported data types"), like "jpg" implies 8-bit RGB, and "zt" implies Z. The data type may be overridden by explicitly specifying another data type, such as a 16-bit type, in the framebuffer statement (or output statement), as long as it is supported and appears in the above table.

Note, that mental ray will optimize the actual list frame buffers that actually need to be created from the requested types. For example, the standard RGBA color frame buffer stores 8 bits per component by default, but if any frame buffer statement references a 16-bit type, just a single color frame buffer with 16 bits per component may be actually created, because the 8 bit color data can easily and quickly be computed from that frame buffer.

The null file format is useful to create a stub file during rendering, that can be used to attach the imf_disp viewer, without leaving the file on disk when rendering finishes.

All mental images native file formats are following a simple layout: they contain a header followed by the image data. The header consists of a magic number byte identifying the format (as listed in table above), a null byte, width and height as unsigned shorts, as well as a version number as unsigned short. The image data are simply uncompressed values written pixel by pixel (with increasing horizontal x coordinate) and line by line (with increasing vertical y coordinate), beginning in the lower left corner (x = y = 0). The pixel data consists of one to four 8-bit, 16-bit, or 32-bit component values, in RGBA, XYZ, or UV order. All shorts, integers, and floats are big-endian (most significant byte first).

The available data types are:

The rgb_h and rgba_h data types are supported only for OpenEXR image file format. They cause the data to be written to the OpenEXR file in half-float format. mental ray's frame buffer is actually storing in full floating point precision. This allows to render in full dynamic range but avoid storage overhead by writing half-float values with less precision to the OpenEXR file.

The RGBE high dynamic range color data type can store RGB data whose components may exceed the value of 1.0, which is the normal limit for standard RGB data. There are two specialized file formats (HDR and CTH) for RGBE, but mental ray will also allow storing RGBE data in any 8-bit RGBA format, such as SGI RGB. This will result in images that can not be displayed by standard viewing programs because they would interpret the data as RGBA, but it has become common practice to use such formats to transport RGBE data to other tools that understand RGBE.

The floating-point RGBA data type "rgba_fp" allows color and alpha values outside the normal range (0…1), and no dithering is applied even if explicitly enabled. In contrast, any conversion to the 8-bit or 16-bit formats will clamp values outside this interval. Note that dithering tends to reduce the effectivity of RLE compression.

The difference between "vta" and "vts", and between n and m, is significant only when automatic conversions are done. The file contents are identical except for the magic number in the file header.

mental ray can combine samples within a pixel in different ways, called filtering or interpolation. The combination of existing samples can also pad the frame buffers to "bridge" unsampled pixels. Interpolation of colors, depths, normals, and motion vectors means that they are averaged, while interpolation of the labels means that the maximum label is used (taking the average label is not a good idea). Interpolation of depths only takes the average of non-infinite depths, and interpolation of normals and motion vectors only takes the average of vectors different from the null vector.

If interpolation is turned off for a frame buffer, the last sample value (color, normal, motion vector, or label) within each pixel is stored, and pixels without samples get a copy from one of the neighboring pixels. Interpolation off for depth images is an exception: rather than using the last sample depth, the min depth is used - this can be useful for compositing. Interpolation is on by default for color frame buffers (including alpha and intensity frame buffers) and off by default for depth, normal, motion vector, and label frame buffers.

3.6 Interpolation is controlled with the framebuffer filtering property.

Deprecated In backwards compatible output statements, it is turned on by writing a "+" in the beginning of the output type and turned off by writing a "-" there. For example, to interpolate the depth samples, write "+z" in the output statement:

• home
• « prev
• next »
• index

Copyright © 1986-2009 by mental images GmbH