HomeVolocityGeneralFactors affecting playback speed through a multi Z plane image sequence in the XYZ view

3.35. Factors affecting playback speed through a multi Z plane image sequence in the XYZ view

When playing through a time series data set you might notice that it is ok in the XY plane mode, but when switching to the other viewing modes such as XYZ, XZ, YZ it is a lot slower.

Once the image has been displayed on the first occasion the performance increases because the volume is cached in memory, we just need to copy out the voxels into a displayable image. If you skip between the same two timepoints performance should be better, however when playing through lots of timepoints eventually the memory cache will push out some of the data so it has to be reloaded again and so the benefit of the cache is reduced.

To explain further - the time series is slow to play through in the XYZ viewing mode because of the time it takes to extract the XZ and YZ planes from memory into a displayable image.

A single XY plane is stored with each voxel sequentially in a linear memory buffer. A very simple example would be a small 3x3 image filled with zeros. To the user this appears on screen like this:-

0 0 0
0 0 0
0 0 0

In the computer's memory it is stored like this:-

0 0 0 0 0 0 0 0 0

The computer knows the width of the image so it knows when to display the next row as the image is drawn.

If we extend this idea into 3D and add a second and third plane filled with ones and twos, the memory may now look like this:-

0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2

Viewing the second plane is easy. We just grab the block with the ones in and display it on screen. The problem is when we want to display a non XY plane.

To display the XZ plane we have to extract the right voxels and then pack them into a sequential block so that the computer can display them. The XZ plane would appear in memory as follows:-

0 1 2 0 1 2 0 1 2

This process of extracting out the XZ and YZ planes is inefficient. The problem is that because the voxels are not located in the same place there is a copy step to extract them into a displayable image. To do this the entire volume must be loaded into memory. With XY you don't have this problem, the computer only needs to load the strip of memory we are displaying. So loading XZ and YZ planes can be quite slow where there are a lot of Z planes present, if there are 100 Z planes then that is 100 times more data to load for the XZ plane than the XY so it will be relatively slower.


Example - 22GB Image Sequence, each timepoint = 700MB

If your fast HDD can read/write data at a rate of 100 MB/s, the first time you play through the 22GB sequence it is *going* to take 7s for each timepoint to load.

time to load each timepoint = size of timepoint (MB)/disk speed (MB/s)


700MB/100MB/s = 7s to load each timepoint

If the Read/Write speed of the HDD is not optimal i.e. it is anything lower than 100 MB/s then this will clearly take longer.


What can we do to maximise the performance?

As explained above, the bottleneck is the time it takes to read the image data from disk into memory. Better performance will be possible with faster storage such as using solid state disks, faster RAID controllers or Fibre Channel storage. More RAM might help to overcome the latency incurred when data is pushed out of the cache.

Another point to bear in mind is that if the HDD's are already quite full then this might incur additional latency...where possible free up HD space.

Check the Volocity session log to see if AV software is installed and whether the on access scanning feature is running. If AV software is installed and the on access scanning feature has been enabled then potentially it will significantly inhibit performance when viewing the first timepoint (as it would need to scan the entire dataset/image sequence).

To assess the hardware i.e. disk speeds etc you can install 3rd party software on the workstation, an example of a 3rd party application would be SiSoft Sandra, that will at least give you the disk speeds, from that you can maually calculate the *theoretical* read/write time for a specific data set.

This page was: Helpful | Not Helpful