Correcting Sampling Seams in Parallel Rendered Volumes

November 5, 2016

A common approach to volume render big datasets is splitting the data into blocks and rendering each block in a separate pass.  A final image is then constructed by orderly compositing (back-to-front) the images rendered with each block (a process known as bricking).  A variety of artifacts can arise when using bricking due to discontinuous data sampling, gradient computation at the edges, etc.  One common artifact is that block seams become apparent thus lowering the final composite image quality.

seams_0_current_arrow
A wavelet volume rendered as 4 blocks with the GPU Mapper. Seam artifacts due to discontinuous sampling are clearly seen near the center planes at the edges of the blocks (black arrows).

Parallel volume rendering in ParaView works in a similar fashion, different data blocks are rendered in separate processes and are then orderly composited together into a final image. Former versions of ParaView would show visible seams when rendering volumes in parallel.  Certain improvements in the GPUMapper will alleviate these sampling artifacts as of ParaView 5.2 (OpenGL2).  Specifically,

a.  Sampling Distance: First, the ray sampling distance used by both the GPU and CPU mappers in ParaView was equalized.  vtkFixedPointVolumeRayCastMapper (CPU) has an internal mode (LockSampleDistanceToInputSpacing) which would further decrease the sampling distance passed by vtkSmartVolumeMapper, making artifacts more evident in the GPU mapper.  To
correct this, LockSampleDistanceToInputSpacing was enabled in the GPU mapper.

seams_1_equalizedSpacing_arrow
After correcting for (a.). Seams faded out, as expected with a higher sampling rate, but are still visible at the block-edge planes.

b.  Cell-texture-coordinates to Point-texture-coordinates:  VTK defines its data set abstraction as points or cells. Cell data maps directly to OpenGL texture-cells however, point data does not given that VTK defines its points at the cell corners.  In order to adjust point data to the center of the OpenGL texture cells a transformation with a scaling diagonal and a translation vector needs to be applied.  Although the ray entry and texture limits were being adjusted, the ray step was not scaled accordingly,  this would introduce a slight source of error in point data sets (as in the case of the wavelet) which would maintain the seams noticeable even with a reduced sample distance.

seams_2_cellToPoint_stepAdjusted
After correcting for (b.). No sampling seams are visible.

Next Steps

During interaction-time the sampling distance is increased which causes the sampling seams to become visible again.  It is possible to further correct the visibility of this artifact during interaction-time by offsetting the entry point in each brick to be a multiple along the entire ray (entry would be computed from the eye pose to make sure it is a multiple for each different brick). Additional work is needed to address the gradient computation at the edges in order to correct other artifacts present when shading is on.

Leave a Reply