ParaView/Image Compressor Configuration: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
m (moved Image Compressor Configuration to ParaView/Image Compressor Configuration: associate this page with ParaView)
Line 33: Line 33:
The following chart show typical performance characteristics of the compressors when configured using the Compressor Pre-sets drop down menu in comparison to using no compression at all. Note that the configurations used for these tests make use of the recommended settings rather than settings that would prduce the fastest results. The test consisted of an image produced using the Hierarchical Fractal source and forcing 200 interactive renders using ParaView's Play Test feature. The results, presented in the following histograms and table, are organized by network and compressor. The benchmarks were made in Jun 2009. Three networks have been employed. The first row of results was taken on localhost connection running both ParaView client and server on a 2 x 2.5GHz Core 2 Quad with 32 G of ram and a Quadro FX 3700 video board. The second row of results was taken running ParaView client on the same workstation while running the server on a 2.6 Ghz Core 2 notebook with 4 G of ram and an GeForce 9800M GS video board over a 100 Mb lan. The third row of results was taken on with the client running on the same workstation and the server running on a compute node of UCSD's cluster nashi over a broadband connection and a 1 hop ssh tunnel. While this doesn't make for a good comparison of the compressors themselves on technical grounds, it does provide useful information about the overall system performance in typical use cases. Testing that illustrates isolated compressor performance are presented in the following section.
The following chart show typical performance characteristics of the compressors when configured using the Compressor Pre-sets drop down menu in comparison to using no compression at all. Note that the configurations used for these tests make use of the recommended settings rather than settings that would prduce the fastest results. The test consisted of an image produced using the Hierarchical Fractal source and forcing 200 interactive renders using ParaView's Play Test feature. The results, presented in the following histograms and table, are organized by network and compressor. The benchmarks were made in Jun 2009. Three networks have been employed. The first row of results was taken on localhost connection running both ParaView client and server on a 2 x 2.5GHz Core 2 Quad with 32 G of ram and a Quadro FX 3700 video board. The second row of results was taken running ParaView client on the same workstation while running the server on a 2.6 Ghz Core 2 notebook with 4 G of ram and an GeForce 9800M GS video board over a 100 Mb lan. The third row of results was taken on with the client running on the same workstation and the server running on a compute node of UCSD's cluster nashi over a broadband connection and a 1 hop ssh tunnel. While this doesn't make for a good comparison of the compressors themselves on technical grounds, it does provide useful information about the overall system performance in typical use cases. Testing that illustrates isolated compressor performance are presented in the following section.


[[File:Pv-compressor-defaults.png|none|frame|1024px|Preset configuration results, 200 samples per test case.]]
[[File:Pv-compressor-defaults.png|none|frame|1023px|Preset configuration results, 200 samples per test case. The best results are highlighted in yellow.]]


The specific configuration employed is documented in the following table.
The specific configuration employed is documented in the following table.

Revision as of 17:05, 28 December 2013

Configuration Dialog

ParaView has a number of settings that affect remote interactivity. This section discusses how to enable and configure ParaView for image compression.

Compressor Configuration Dialog

A - Remote Render Threshold

One of the most important settings is the Remote Render Threshold. If checked this will enable remote rendering above the specified geometry size. If unchecked remote rendering will be disabled altogether. When remote rendering is enabled images are rendered in parallel on the server, either using Mesa in software or on server hardware using OpenGl. Each frame of the visualisation is shipped to the client to display. When remote rendering is disabled the geometry (a VTK dataset) is transfered from the server to the client, where rendering takes place. Geometry is often larger than the rendered image and thus shipping the geometry can be a costly operation. However once the geometry is received one can interact with the visualization at local rendering rates. The image compressor is only applied when remote rendering is enabled. To enable parallel remote rendering check the Remote Render Threshold and set the value to 0.

B - Interactive Sample Rate

During interaction the Interactive Subsample Rate setting will be used to down-sample the rendered image before sending from server to client. This can significantly reduce the size of the rendered image, and thus reduce the image transfer time. Down-sampling drastically reduces the quality of the delivered image, so it best not to exceed 3 pixel setting. In most cases a setting of 2 is acceptable. For very fast networks disabling down-sampling altogether may be the best option.

C - Image Compression

The Image Compression check box is used to explicitly enabled or disable ParView's image compressor. Compression of rendered images can improve remote interactivity. During interaction rendered images are down-sampled and compressed before transmission reducing the amount of data sent in many cases by a couple of orders of magnitude. The compressor stage adds significant overhead to the rendering pipeline, however for slower Internet connections the image delivery time is much larger than the compressor run time. For very fast networks the compressor will tend to reduce interactivity and should be disabled.

D - Squirt Compressor Configuration

When image compression is enabled, the Squirt image compressor, can be selected and configured here. Squirt is a run-length-encoded (RLE) compression algorithm designed by Sandia National Lab. As is the case with many RLE compression algorithm it is fast, but achieves relatively low compression ratio's compared to alternative compression algorithms. Squirt's primary strength is its speed, therefore it is most effective when used on very fast networks where the image transmission times are comparable to other compressor's run time. The Squirt algorithm can optionally apply a colorspace reduction mask during the run length computation. Applying the color space reduction mask tends to make runs longer when neighbouring pixel's vary only in the least significant bits. It is a clever implementation in that it reduces the color-space while introducing no new colors to the de-compressed image. When set to its highest reductions this can produce visual artefacts in the de-compressed image when runs cross actor boundaries. For this reason it is best to use Squirt at 16 bits per pixel (bpp). There is no performance hit when applying the color space reduction, so one might as well always apply it. Squirt's color-space reduction is only applied during interaction, preserving full image quality for still renders. The decompressed image color space can be selected using the slider. There are six settings, labeled by the bits-per-pixel in the decompressed image. The settings range from 24 bpp (no color space reduction) to 10 bpp (14 bit colorspace reduction).

E - Zlib Compressor Configuration

When image compression is enabled, the Zlib image compressor, can be selected and configured here. Zlib is public domain implementation of DEFLATE, the scheme originally used in pkzip. This is a loss-less compression scheme that works well on images and has been used in png image standard. The algorithm has fixed memory requirements independent of input data size, and never inflates data. At its highest settings the Zlib compressor achieves compression ratios an order of magnitude or so higher than Squirt. The trade off, is as is often the case, speed as runtime for zlib compressor is an order of magnitude longer than Squirt. However, when connecting to a ParaView server over a network the runtime is much smaller than the image delivery time and as a result one can see an improvement in frame rates by using the Zlib compressor.

The Zlib compressor has a number of configuration options. The first setting is Level and can be selected by using the spin box. This is a number between 1 and 9, where level 1 sacrifices compression ratio to achieve faster run time, and level 9 sacrifices runtime to achieve higher compression ratio. The second setting is the color space. This setting is selected using the slider. There are 5 settings available ranging from 24 bits-per-pixel to 9 bit-per-pixel. Unlike Squirt the Zlib colorspace reduction algorithm introduces new colors in the decompressed image, and the lower colorspace settings produce significant color changes in the decompressed image. For this reason it is recommended not to go bellow 15 bits-per-pixel. The color space reduction is performed in a pre-compression pass, which imposes a performance and memory penalty. For these reasons it's use is only recommended on relatively slower networks. Finally, the Strip Alpha setting can be used to reduce the image size by removing the alpha channel prior to compression. If selected this setting is applied during the color space reduction and has a similar performance and memory hit. For these reasons it's use is only recommended on relatively slower networks.

F - Compressor Pre-sets

In an effort to facilitate configuration, especially for those new to ParaView, a number of pre-set configurations are provided via the Compressor Pre-sets drop down menu. The pre-sets do not guarantee the best achievable performance nor the highest image quality, rather they provide a compromise where relatively good performance is obtained in conjunction with relatively good image quality. It is important to recognise that the overall rendering performance is highly system, and network dependent. The available pre-sets have been designed to be a good starting point in your search for optimal settings for your particular system and network.


Preset Configuration Performance Benchmarks

The following chart show typical performance characteristics of the compressors when configured using the Compressor Pre-sets drop down menu in comparison to using no compression at all. Note that the configurations used for these tests make use of the recommended settings rather than settings that would prduce the fastest results. The test consisted of an image produced using the Hierarchical Fractal source and forcing 200 interactive renders using ParaView's Play Test feature. The results, presented in the following histograms and table, are organized by network and compressor. The benchmarks were made in Jun 2009. Three networks have been employed. The first row of results was taken on localhost connection running both ParaView client and server on a 2 x 2.5GHz Core 2 Quad with 32 G of ram and a Quadro FX 3700 video board. The second row of results was taken running ParaView client on the same workstation while running the server on a 2.6 Ghz Core 2 notebook with 4 G of ram and an GeForce 9800M GS video board over a 100 Mb lan. The third row of results was taken on with the client running on the same workstation and the server running on a compute node of UCSD's cluster nashi over a broadband connection and a 1 hop ssh tunnel. While this doesn't make for a good comparison of the compressors themselves on technical grounds, it does provide useful information about the overall system performance in typical use cases. Testing that illustrates isolated compressor performance are presented in the following section.

Preset configuration results, 200 samples per test case. The best results are highlighted in yellow.

The specific configuration employed is documented in the following table.

NetworkCompressorConfigurationResults
Down sampling Comp. Level Colorspace Strip Alpha Frames per Sec. Avg Time Delta Eff. Compression ratio
Localhost None off -- -- -- 36.920602 0.027221 --
Squirt off -- 24 bpp -- 37.472987 0.026820 5.783940
Zlib off 1 24 bpp off 17.728161 0.056691 22.687400
Megabit Ethernet None off -- -- -- 0.727140 1.382092 --
Squirt 2 -- 16 bpp -- 6.513138 0.154307 14.150000
Zlib 2 6 18 bpp off 18.133360 0.055424 232.160000
Broadband/DSL None off -- -- -- 0.073678 13.639195 --
Squirt 3 -- 10 bpp -- 1.974782 0.508930 47.432200
Zlib 3 9 15 bpp on 4.012941 0.250446 519.818000

The Effective Compression Ratio is defined as the Rendered image size / compressed image size. Includes sub-sampling and colorspace reduction. The Time Delta is defined as the elapsed time in between successive image delivery. Includes rendering time, spatial subsample time, and colorspace reduction time.

Compressor Stress Tests

For this suite of tests we implemented zlib compression in ParaView so that a side by side comparsion of zlib and Squirt could be made under real world conditions. In these in-situ tests we seek to isolate the the compression scheme as much as possible and to stress test the algorithms in a worst case scenario. To this end in the render-server configuration dialog (Edit->Settings...->Render View->{General,Server}) we set the Remote Render Threshold to 0, disabled Image sub-sampling and set the LOD Threshold to 0. We set the Squirt compressor to loss-less mode at 24 bpp and zlib compressor to its highest setting which is also its slowest. The results summarized in the following table and histogram. For each scheme two renderings were used. The first is an outline of a two dimensional dataset. This rendering has large areas of uniform color and compresses well with both Squirt and Zlib resulting in interactive frame rates for both. The second rendering of a fractal image has a lot of color variation and is used to confound the compression schemes. It represents a worst case input that will cause Squirt compression ration to fall so low that frame rates are not interactive. In this case Squirt compression ratio drops dramatically to 2.9 and frame rates fall below interactive rates, with each frame taking on average 5.25 seconds. Zlib on the other hand delivers a 16.06 times higher compression ratio than Squirt resulting in a 4.39 times faster frame delivery rate. The speed up factor of 4.39 is a modest improvement, however zlib's average delivery rate of 1.2 seconds per frame is a significant improvement in interactivity over Squirts average delivery of 5.25 seconds per frame.

Timing results for 200 frames. Squirt results are plotted in the first row, Zlib in the second. Plots in the first column show timings of the dataset outline, plots in the second column show results for the fractal image.
Dataset OutlineFractal Image
SquirtCompression Ratio33.53972.93691
Avg. Seconds per Frame0.4781205.257553
ZLib-9Compression Ratio313.83847.1934
Avg. Seconds per Frame0.247824 1.197212
Avg. Speed Up1.929274.3915
Avg. Reduction Factor9.357216.0690

Input Datasets

The following images are screen shots taken from ParaView during the tests. We used a saved state file to insure the same initial conditions and a automated test script generated using ParaView's Tools->record Test feature to insure reproducability.

Images used for Frame Rate Benchmark
Dataset outline has large regions of uniform color, leading to very high compression ratio.
Fractal Image has lots of color variation which confounds the compression algorithms.