Softimage SDK Programmer's Guide > Customizing Softimage using the SDK > Custom Fx Operators >

# Raster Inputs and Outputs

The number of raster inputs and outputs must be defined in the ufoProcessDefine user function. For each input or output, the library function ufoProcessRasterInDefine or ufoProcessRasterOutDefine must be called to define its identification and suggested working component combination. This can be RGB, RGB-Alpha, Alpha, or any.

If an input does not need to be connected for the effect to work, then ufoProcessSetRasterInOptional should be called to set it to optional. The default selection state for the optional input can be set with ufoProcessSetRasterInOptionalDefault.

UFO processes can support input and output rasters of nine different pixel types:

- 8-bits per component. Component range is 0 to 255.

  Function | Description
  --- | ---
  ufoRGB8PixelType | RGB packed UBGR (U is redundant 32-bits per pixel)
  ufoA8PixelType | Alpha 8-bits per pixel
  ufoRGBA8PixelType | RGB-Alpha packed ABGR 32-bits per pixel

- 16-bits per component. Component range is 0 to 16383 (14 bits).

  Function | Description
  --- | ---
  ufoRGB16PixelType | RGB packed BGR 48-bits per pixel
  ufoA16PixelType | Alpha 16-bits per pixel
  ufoRGBA16PixelType | RGB-Alpha packed ABGR 64-bits per pixel

- Floating point 32-bits per component. Component range is 0.0 to 1.0.

  Function | Description
  --- | ---
  ufoRGBFPixelType | RGB packed BGR 96-bits per pixel
  ufoAFPixelType | Alpha 32-bits per pixel
  ufoRGBAFPixelType | RGB-Alpha packed ABGR 128-bits per pixel

By default, the rasters supplied to the inputs and outputs can be of any of the supported raster types. There are generic pixel access functions, described later, which can be used to set and get RGB, RGB-Alpha, or Alpha normalized (0.0 to 1.0) component values, generating sensible results regardless of a raster's actual type. These functions are fine for many one-off or mathematically-intensive effects.

However, in the majority of cases, direct pixel access using pointers to pixel structures and using integer arithmetic will increase rendering performance, and may be necessary. In this case, the UFO code will probably only support a narrow subset of the entire possible combinations of input and output pixel types that may get connected to it. There are two ways to specify how input and output pixel type combinations may be converted to a combination that the UFO code supports. The recommended method is by supplying the ufoProcessSpecifyConvertPixelTypes user function. The pixel types of the rasters that will be supplied to the UFO process inputs and output are passed as arguments. If you would like the application to pre-convert the input rasters or supply a different type output to be converted after rendering, then the pixel type arguments should be changed.

Alternatively, although not recommended any more, the combinations of input and output pixel types supported by the UFO rendering code can be defined using ufoProcessSetPixelTypeCombinations. This allows multiple specifications of the desired pixel types for each input and output.

Some of the values used to describe desired pixel type values can indicate no specific pixel type or any pixel type of a specific component type. The full set of available values to specify a supported pixel type are:

- To specify any pixel type

  ufoAnyPixelType | any pixel type

- To specify any pixel type of a component type

  ufoAny8PixelType | any 8-bits per component pixel type
  ufoAny16PixelType | any 16-bits per component pixel type
  ufoAnyFPixelType | any floating point (32-bits per component) pixel type

- To specify an actual pixel type

      	ufoRGB8PixelType
      	ufoA8PixelType
      	ufoRGBA8PixelType
      	ufoRGB16PixelType
      	ufoA16PixelType
      	ufoRGBA16PixelType
      	ufoRGBFPixelType
      	ufoAFPixelType
      	ufoRGBAFPixelType