GitLab

While updating a code base from VTK 8 to VTK 9 we tracked down a change that had to be corrected by manually setting the vtkRenderer's SetBackgroundAlpha to 1.0 in order to retain the desired background color.

0546373c

When you have a pipeline with

1. A vtkRenderer that uses FXAA, and
2. A vtkWindowToImageFilter that pipes to anything like a vtkImageExport or vtkPNGWriter, and
3. The buffer type of the vtkWindowToImageFilter is set to RGBA, then

the default value of 0.0 for the vtkRenderer results in losing the background color via the above commit's updated FXAA code. The commit (correctly) forwards the alpha channel, rather than always using a hard coded 1.0. Below is a simple reproduction using vtkPNGWriter to keep things simple, but it seems like the background color gets lost somewhere in vtkWindowToImageFilter since the original code was using vtkImageExport.

CC @mwestphal who believes the solution should be setting a default somewhere. I think changing the default for the vtkRenderer's opacity from 0.0 to 1.0 may have other undesirable effects, but perhaps there is something in vtkWindowToImageFilter or something else that can detect FXAA first and override? Not sure how common this is, probably anyone doing offscreen rendering and FXAA is affected. Perhaps when the buffer type is set to RGBA, if the opacity of the governing renderer is 0.0 you could set a "smart override" there, but then you would prevent anyone who actually does not want a background from being able to do this. Perhaps just documenting it (somewhere) is a good solution?

• vtk_opacity.cpp
• CMakeLists.txt

Sample outputs demonstrating that FXAA with RGBA loses its background color with the default 0.0 background alpha, but this does not happen with RGB:

RGB, 0.0

RGB, 1.0

RGBA, 0.0 (default config for vtk)

RGBA, 1.0