Performance of Initial Compression

Images and Animations §5.8

in each of the test volumes, resulting in a maximum of 2097151 nodes. Thus the depth parameter is varied between I and 6 for each of the levels, for the creation of the octree compressed volumes.

5.5.1 Constructio n without Node Compression

5.5. 1. 1 Performance

The performance tests covered the three distinct stages of the construction process:

I. Initial construction of octree data structure from the raw data.

2. Reordering of then des into breadth-first order.

3. Gathering of raw data pertaining to leaf nodes ofthe octree.

The graphs in figures C.l to C.4 depict the performance of the octree compression algorithm (without using node compression) over each of the four test volumes. Each vertical section of the graph represents an increasing octree depth (the left most section represents a depth of I, while the right most section represents a depth of 6). Inside each section the lower limit is varied through the range mentioned above.

We expect that the execution time of all stages of the compression should increase steadily as the depth of the octree increases and as the lower level is increased (i.e. More data is excluded) the execution time should drop.

By analysing the graphs one can pick up the following trends:

• The initial octree construction process is the most expensive of the three stages.

• The initial construction process becomes progressively more expensive as the octree depth increases, but not dr matically. An advantage of no more than a second is gained by using a depth of 3 or 4 over a dept of 6.

• The reordering process has a negligible impact on the performance.

• For very small lower limits the performance is noticeably slower, but as the lower limit increases the algorithm performs better, initially at a logarithmically decreasing rate, then at an almost linear rate.

• If one examines the total times on the graphs one can see that a worst case time of around 6 seconds can be expected, which considering that this process only has to be executed once initially, is very acceptable.

The most surprising aspect of these results is that the total time taken to compress the volume using deeper octrees is not necessarily slower than using a shallower octree. This is good as it means that a deep octree can be used (which can represent the volume closer) without incurring a large overhead.

5.5. 1.2 Compression

The results of the volume compression at each of the six octrees depths mentioned above, are presented in figures C.5 to C.S.

In the results of each test case both the compressed volume size is presented as well as the optimal compressed size (calculated by counting the number of opaque voxels in the volume).

The compression of the volumes is expected to increase at an almost linear rate as the depth of the octree increases due to the closer representation of the actual volume. The compression ratios for lower threshold levels are expected to be much lower than higher levels due to the amount of low density material common in volume data. In the case of a very deep octree the compression should approach the optimal limit. (i.e. Only voxels which are above the threshold are stored at all.)

From the graphs it can seen that:

• For greater octree depths the compression rapidly approaches the optimal levels.

• As the lower limit increases from very small values (<40), the improvement in compression is dramatic. This is probably due to the removal of low density values such as those for air. From this level onwards the improvements in compression ratio depend on the nature of the volume.

• The octree compression closely approaches optimal compression for a depth of 6 and a fairly high lower limit.

• From these results ne can thus conclude that using a depth of 6 is definitely the most advisable as the compression ratios achieved are vastly superior to those at lower depths, while the time taken for the algorithm to execute is negligibly slower than for other depths.

The results were very much as we expected except that the compression ratio did not come as close to the optimal level (for greater octree depths) as we expected. This indicates that the octree is not closely representing the natural structure of the volume as accurately as we intended, and thus leads us on to considering adding furt er nodes to the octree method.

5.5.2 Construction with Node Compression

When using node compression each node is simply compressed according to the specified lower-level threshold. The node-compression algorithm makes use of the run-length-encoding scheme, but does however check to see if the resultant node would be larger if compressed (this can happen if a region is very noisy), and then does not compress it. Thus the choice of test volume and threshold level could drastically effect the results.

Once again levels I through 200 are calculated, each at octree depths of I to 6.

5.5.2.1 Performance

As with the previous section figures C.9 to C.l2 depict the performance of the octree construction phase, except that the data gathering phase is now replaced with a data compression phase, which further compresses the data in each of the leaf nodes.

We expect similar results to the method of not using node compression. The execution of the first two stages should be identical (as they do not change at all) however the third gathering stage is now replaced with a compression stage which should take noticeably longer. As the node compression is being performed using RLE compression (which has almost linear complexity) the performance of the compression stage should become better for deeper octrees and higher threshold levels as less data is being compressed. Due to the nature of run-length encoding it is possible for the "compressed" data to be larger than the original. The leaf-node compression algorithm however detects this problem, and will then simply store a particular node as-is, if compression would result in a size increase. This is then more likely to happen as the leaf-nodes cover more complex data better, which is what happens at greater octree depths.

The trends seen in the results are similar to those in the previous section.

• The duration of the algorithm tends to increase with depth, however the increase is not dramatic at all.

• The data compression stage can actually take longer than the octree construction phase for depths less than 3, however once the depth becomes greater the octree construction phase takes longer while the compression is faster.

• The performance of compressing the engine data set increases dramatically at level 140. This is due to the almost discrete nature of the density levels in the engine dataset and the fact that one entire density range is now suddenly being omitted.

These results are exactly as we predicted. The only unexpected feature of the results was that for deeper octree depths the node compression time can be less than a third of the total compression time.

This is much faster than was initially expected.

Once this compressed v lume has been transmitted to a workstation it is necessary to decompress each of the nodes for the rendering algorithm to function. Figures C.13 to C.16 depict the decompression time for each of the test volumes.

As with the compression stage we expected the execution time of the decompression to decrease with increasing octree depth and higher threshold levels.

From the graphs one ca see that this is exactly what happens. The worst case decompression time in all the results was still under a second which (considering it only has to performed once) is a very acceptable result. It therefore becomes clear that the use of node compression adds barely a few seconds of total performance drop to the whole compress-transmit-decompress cycle. If this method can then improve the compression noticeably then it is very worthwhile.

5.5.2.2 Compression

The compression ratios achieved by using node compression are presented in the figures C. 17 to C.20 in the same format as the results for non-compression of the nodes.

We now expect the compression of the volume to be a lot closer to the optimal level when the octree is deeper.

From the results it is noticeable that:

• The achieved compression ratios are almost constant across the various depths now, due to the leaf- node compression.

• Similar features as with pure octree compression are seen for higher depths, such as near-optimal compression for high lower-levels.

As expected the compr ssion ratios are now on average closer to optimal compression, except they are not as close as we wo ld have hoped. The most surprising aspect of the results is that the average compression ratios no longer increase as the octree depth increases. This indicates that any octree depth could then be used and a similar compression ratio obtained. However in a volume rendering system (as mentioned above) it is necessary to decompress these nodes once they arrive at the workstation in which case the data would be compressed according to the compression graphs presented in the previous section. Thus, considering that the node-compression provides an overall improvement in compression, it is still advisable to use a maximum depth with node compression. The performance penalties for selecting these parameters are still negligible considering a worst case compression time of7.5 seconds and a worst case decompression time of0.9 seconds.

5.5.3 Comparison with RLE Compression

To compare these previous results with those obtained using RLE compression, the same four volumes were compressed at each of the lower-threshold levels. A comparison is drawn below (Figure 5.8 to Figure 5.11) with the o tree method using node-compression and a tree depth of 6.

The compression ratios of RLE compression are generally fairly good and so we expected them to be very near the compression ratios achieved using octree compression. However when large areas of the volume are below the threshold the octree algorithm (due to the fact that it works in three dimensions) should represent the "empty space" more efficiently. Thus we expect octree compression to outstrip RLE compression for higher threshold levels.

Comparleon of RLE and Octree Compre•on on CT Heed Data•t

1 --0ctree RE i

N

e

! I

E ! I

Lave I

Figure 5.8 - Octree vs. RLE compression levels for the CT Head dataset.

Oomparleon of RLE and OclrH CompraSIIon on Engine Data•t

[- _ Octree •••••••

REJ

Figure 5.9 - Octree vs. RLE compression levels for the Engine dataset.

OompariiOn of RLE and 0c1ree Cclmpralllon on 1M Knae Da1a_.

1 -0ctree .. · · · · ·

I

ooanoo~~~---~--~~---~~~~~---~~~~~~~

ooanoo

7IXXXXXl