Create a ticket

Q100384: Render fails when merging multiple channels/AOVs in Katana via ExrCombine


When trying to merge multiple channels/AOVs into one EXR file in Katana, you may encounter render failures and errors due to a known OpenEXR and ExrCombine limitation.

The errors might look like the following:

Running command: ExrCombine
/tmp/katana_tmpdir_7664/sphere_diffuse5_Render_primary_rgba_square_512_linear.1.exr primary
/tmp/katana_tmpdir_7664/sphere_diffuse5_Render_direct_diffuse_direct_diffuse_square_512_linear.1.exr direct_diffuse
sss /tmp/merge.exr
Render stopped by signal: 6
CommandLineRender Error: doRender problem
Reason = Render stopped by signal: 6
Render error. Time elapsed: 6.33 s
Node 'Render': Render failed with a rendering error: Render stopped by signal: 6

The render failing might even result in a Katana crash with the following error in the stack trace:

[INFO python.MainBatch]: *** Error in `ExrCombine': free(): invalid pointer: 0x0000000000e8f1e0 ***



Katana natively supports only 4 channels, RGBA, for reading and rendering image data. However, it allows merging additional channels to create a multichannel EXR via an internal Katana utility called ExrCombine.

The ExrCombine utility was originally created for merging images with pixel data windows (dataWindow header attribute) of the same size because OpenEXR has limitations when writing multiple channels/AOVs into one EXR file. The EXR file will only be able to contain one dataWindow header attribute, and every channel/AOV will share the same dataWindow attribute value and will not be able to keep its own value within the merged EXR.

Therefore, ExrCombine does not support merging images of different pixel data windows.
If the chosen dataWindow attribute value does not encompass the data window sizes of all the AOVs you’re merging, the render will fail or Katana might even crash.

We have an existing feature request to improve the ExrCombine functionality once OpenEXR offer extended support for multiple dataWindow header attributes within the same file. This is logged as: TP 75636 - ExrCombine: Better support for images with different pixel data windows

Below are included various workarounds you can try, depending on your multichannel setup.


Creating render passes

Defining multiple channels/AOVs to merge into one multichannel EXR file can generally be done in Katana using renderer specific nodes, together with a RenderOutputDefine node that configures your actual render passes. 

Merging a number of render passes and triggering the ExrCombine functionality is done via an additional RenderOutputDefine node, set to 'merge' as output type. 

More information on creating render passes in Katana for different renderer are available in the this article: Q100370: Defining render passes using the RenderOutputDefine node


The EXR Data Window
Each OpenEXR file is described through a list of attributes found in the file’s header. Running a command like ‘exrinfo’ on a sample .exr file will print out the values of these attributes like so:

> exrinfo image.exr


file format version: 2, flags 0x0
channels (type chlist):
B, 16-bit floating-point, sampling 1 1
G, 16-bit floating-point, sampling 1 1
R, 16-bit floating-point, sampling 1 1
compression (type compression): piz
dataWindow (type box2i): (0 0) - (3799 1906)
displayWindow (type box2i): (0 0) - (3799 1906)
lineOrder (type lineOrder): increasing y
pixelAspectRatio (type float): 1
screenWindowCenter (type v2f): (0 0)
screenWindowWidth (type float): 1 

The value of the dataWindow attribute in this case is (3799 1906), meaning the window size of the pixels stored in the image file is 3799x1906. All OpenEXR files contain both a dataWindow and a displayWindow. In comparison, the displayWindow describes the area of the image that is displayed in a viewer. This area might be larger or smaller than the actual area for which data exists in the OpenEXR file.


Different dataWindow values

When attempting to combine images with different data windows via the ExrCombine utility, the merge process will use the dataWindow attribute value of the first input in the RenderOutputDefine node’s selected list of mergeOutputs parameters, as the dataWindow of the final output.


In this RenderOutputDefine node example screenshot, the first selected input of the mergeOutputs parameter is ‘primary’. For the final merged EXR created by the ExrCombine utility, the dataWindow header attribute of the ‘primary’ pass will be used.

If the dataWindow header attribute is smaller than the dataWindow of the rest of the channels/AOVs you intend to merge, the ExrCombine merge process may fail triggering the render errors referenced above.


The ‘primary’ pass

Please note that by default Katana will generate a primary pass whether you request its creation via a dedicated RenderOutputDefine node or not. The primary pass will be added to the mergeOutputs list as first entry, and be used to merge your additional channels into. If the primary pass data window does not encompass the overall data windows sizes of all the AOVs you're merging, then the merge operation will fail.If you don’t require the primary pass then you can disable it explicitly from the mergeOutputs list, and the dataWindow of the second pass in the list will be used for the merged EXR. In the screenshot example above, the dataWindow value used if ‘primary’ is disabled would be coming from the ‘diffuse’ pass.




The following recommendations can help bypass the limitations described above, when trying to merge multiple AOVs into one EXR file:


All your render channels/AOVs should have the same dataWindow header attribute value.

ExrCombine encounters problems when trying to merge a pass with a wider dataWindows into a pass with a smaller dataWindow. If all passes have the same dataWindows then such problems won’t occur.


The dataWindow attribute is encompassing the data windows of all other merged passes

The first pass in the mergeOutputs parameter selection list of the RenderOutputDefine node, should always have a wider dataWindow that can encompass the data windows of all other passes to merge. If you keep this in mind when defining your AOVs order in the merge process, you can avoid ExrCombine render failures due to trying to fit a wider dataWindow into a smaller dataWindow.

NOTE: Since the ‘primary’ pass will be created and selected by default in the mergeOutputs list of the RenderOutputDefine node, try deselecting it and only merging the EXR passes by themselves. The merge process will then use the data windows size of the first selected pass in the mergeOutputs list. If its size is not bigger than the size of the data windows of all other passes, the merge process will again fail.


Completely bypass the post render EXR optimizations via the exrOptimize parameter, for each merged pass. 

This forces the same dataWindow to be used across all merged passes.


By default, Katana post-processes color outputs and its internal 2D image processing does not preserve EXR header attributes. It relies on a standalone internal utility (exrcopyrenderattrs) to copy relevant EXR header attributes from the original image to the post-processed image.

These attributes are handled via the RenderOutputDefine node, convertSettings parameters described here:

The exrOptimize parameter is mainly used to optimize the image data window and 'shrinkwrap' the image by removing the redundant clear information around the edges. This happens by default and the EXR file will be written out in a manner optimized for efficient random tile-access.

Having the exrOptimize parameter set to ‘No’ will render out the entire image data window, skipping the optimization step and forcing the same dataWindow to be used. It should then allow rendering the merged EXR when dealing with different dataWindow attributes in the processed AOVs.

In some cases the performance might be slightly affected while processing the image, depending on its size. This is due to the exrOptimize optimizations being aimed at improving memory usage and performance for programs which process images in tiles.


Render AOVs using the 'raw' output which will return the raw rendered image as received from the renderer used.


Setting the type of the RenderOutputDefine node to ‘raw’ will allow rendering the image as received from the renderer and bypass any post render processing step. Katana won’t do any conversion on the output and the file will use the renderer written header attributes. This may help since it prevents any changes to the dataWindow attribute.

Was this article helpful?

We're sorry to hear that!

Please tell us why.
1 out of 1 found this helpful