[openvl-devel] vlVolume

[Susan F. <sf...@cs...>]

I have made several changes to vlVolume to accomodate huge volume data sets. 
The current version has much redundancy that I plan to fix as follows:

For the cleanest implementation of Volume File I/O that supports selectively 
reading partial volumes and combining volume files into a single volume, I 
would like to do (before the next release of OpenVL):

Read/ReadVolumes(filename,info,readFileInfo,readPos,readDim,format,useFileExt)
	Only filename is required.  All other input items take on default values when 
not supplied.
	If info is not supplied readFile info is used. If readFileInfo is not 
supplied, it is read from file(s).
        For ReadVolumes filename contains a list of filenames. For efficiency 
there is an option to provide a
	filePath and List object instead.

Read volume slabs (full x,y slices, up to full volume) starting at a selected 
slice (z dimension).

Prior to calling the fileio read plugin vlVolume::read should do
	fseek(fp,info.headerSize+slicesize*startSlice, SEEK_SET)
NOTE: This require removing all fseek's from f3d, ppm, volvis-slc and vox read 
plugins.

Allow for translations between input data type and volume data type with 
functions copyRGBtoRed
copyRGBtoRGBA and copyREDtoRGBA. These replace cropRGBtoRed, etc. because 
input is cropped into m_pVolData. Use copyDataT for for cropping data of the 
same type. By treating slice as a special case of slab we can remove 
vlVolume::readImages. Use vlVolume::m_inputData (was m_pSliceData) for input. 
The dimensions of the slab and the volume are obtained from m_inputData and 
m_pVolData, respectivly. Only the volume section specified is written. Slab 
volumes will be truncated if they attempt to write outside the defined volume 
area. For efficiency input volumes of of the same datatype and dimension as 
the volume object are read directly into m_pVolData. 

Any comments?

Susan