The internal LDM data management can be used with any data source or file format, but this may require converting data “on the fly”. VolumeViz will automatically split the data into tiles and automatically create lower resolution tiles (for example if the data is tiled but not multi-resolution). This conversion adds some time during the initial loading of the volume, so VolumeViz provides an LDM specific file format (.ldm) that is optimized for loading tiled, multi-resolution volume data. Benefits of the LDM file format include:

However applications can also use VolumeViz with proprietary tiled (and optionally multi-resolution) data formats by implementing a custom volume reader. We will explain custom volume readers in a later section.

VolumeViz provides the SoVolumeConverter^{( C++ | Java | .NET )} class and example applications for converting volume data to LDM format. This is explained in Section 1.2.6, “Converting to LDM”.

Normally an LDM data set consists of two files: a “.ldm” text file containing the file header and a “.dat” binary file containing the data values. It is only necessary to specify the “.ldm” file name to SoVolumeData^{( C++ | Java | .NET )}. The name of the “.dat” file is specified in an XML tag inside the “.ldm” file. Loading an LDM file does not require any special coding. VolumeViz will automatically use the SoVRLdmFileReader^{( C++ | Java | .NET )} class to load files that have the “.ldm” (or “.lda”) extension.

The LDM header file contains XML tags that specify the volume characteristics (dimensions, extent, etc) and some additional information computed by the LDM converter such as min/max values and a histogram. The header file for the example data set we have been using in this chapter looks (approximately) like the following. Note that these tag names are reserved for VolumeViz and are not guaranteed to be the same in future releases. Applications should not modify or use these tags directly. However applications may freely add additional custom tags to the header file. Retrieving custom tags is explained in the next sub-section.

<?xml version="1.0" encoding="utf-8" ?>
<VolumeInformation>
  <OriginalFile>\OIVHOME\src\VolumeViz\3DHead.vol</OriginalFile>
  <Size>     <U>256</U> <V>256</V> <W>109</W> </Size>
  <TileSize> <U> 64</U> <V> 64</V> <W> 64</W> </TileSize>
  <DataType>byte</DataType>
  <DataFilename>3DHEAD.dat</DataFilename>
  <NumSignificantBits>8</NumSignificantBits>
  <CoordinateSystem system="">
    <Origin>-1 -1 -0.596094</Origin>
    <TotalExtent>
       <U>2 0 0</U>  <V>0 2 0</V>  <W>0 0 1.19219</W>
    </TotalExtent>
  </CoordinateSystem>
  <Min>0</Min>
  <Max>255</Max>
  <Histogram>
    <V>0</V><N>330794</N>
    <V>1</V><N>1044520</N>
    <V>2</V><N>1279654</N>
    . . .
</VolumeInfo>

In this section we will discuss:

Compressed data

An LDM file can store the data for each tile in a compressed format. This can significantly reduce the amount of disk space required to store large volumes. Compression using JPEG (lossy) and GZIP (loss-less) algorithms is standard in VolumeViz. Applications may use any compression algorithm by deriving a new class from class SoDataCompressor^{( C++ | Java | .NET )}.

VolumeViz can even keep tiles loaded into system memory in their compressed format in order to reduce the amount of system memory required to load large volumes. This is the default behavior for compressed LDM files. Tiles are decompressed, as needed, before transferring data to the GPU. To reduce memory usage, the decompressed tiles are considered temporary and are stored in a “tile cache”. This cache is separate from, and in addition to, the LDM main memory.

	Using a compressed data file with the default tile cache can significantly reduce rendering performance! The tile cache size is only 50 tiles by default. In a large volume this may not even be enough tiles for a single slice. You should either increase the tile cache tile or disable the compressed tiles in memory option.

Alternatively the application can disable this feature by setting the environment variable LDM_USE_IN_MEM_COMPRESSION to 0 (see class SoPreferences^{( C++ | Java | .NET )} for setting environment variables programmatically). In this case compressed tiles will be decompressed (once) when they are loaded from the volume reader.

Customized LDM header (custom tags)

It is often useful to store additional information in the LDM file header using custom XML tags. The standard volume converter does not automatically carry over format specific information that may be important to the application later. For example medical applications typically want to carry over information from DICOM tags and seismic applications typically want to carry over information from the SEGY header like the range of line numbers. In the next section we will explain how to add custom tags to the LDM file header during the conversion. Here we will show how to get the information from those tags when loading an LDM data file.

For example we could add the following (example) tags to the header file. Note the LDM volume reader’s XML parser is basic and only supports text and additional tags inside a tag. There must be both an open and a close tag for each tag.

<MY_SEISMIC_SURVEY>
  Some text
  <InlineRange>    720 978 3 </InlineRange>
  <CrosslineRange> 460 658 3 </CrosslineRange>
</MY_SEISMIC_SURVEY>

	It is important that the name of the custom tag section is unique and does not conflict with LDM tag names that exist now or are added in the future. We recommend embedding your company or organization name.

The LDM volume reader automatically scans and stores all the XML tags in the file header. (So it is also possible to query any of the standard LDM tags.) Let’s assume for this discussion that we put all our custom tags inside one custom tag that serves to create a logical section in the XML file. This is convenient because we can make one check to see if this “section” tag exists. The first step is to get the LDM volume reader from the SoVolumeData^{( C++ | Java | .NET )} node. Next we ask the reader for our section tag by name. This returns an SbXmlTag^{( C++ | Java )} object. We can ask this object if the requested tag actually exists. If it does then we can get the text inside this tag and we can loop over the sub-tags inside our “section”.

---

C++

SoVRLdmFileReader* pReader =
                          dynamic_cast<SoVRLdmFileReader*>(pVolData->getReader());
SbXmlTag mySectionTag = pReader->getXmlTag( "MY_SEISMIC_SURVEY" );

if (mySectionTag.exist()) {
  SbString mySectionText = mySectionTag.getText();
  for (SbXmlTag t = mySectionTag.getFirstChildTag();
       t.exist();
       t = t.getNextSiblingTag()) {
    SbString tagName = t.getName();
    SbString tagText = t.getText();
  }
}

---

.NET

SoVRLdmFileReader Reader = (SoVRLdmFileReader)VolData.GetReader();
SbXmlTag mySectionTag = Reader.GetXmlTag("MY_SEISMIC_SURVEY");
if (mySectionTag.Exist()) {
  string mySectionText = mySectionTag.Text;
  for (SbXmlTag t = mySectionTag.FirstChildTag; t.Exist(); t = t.NextSiblingTag) {
    string tagName = t.Name;
    string tagText = t.Text;
  }
}