Mark Davey (mkd@medphys.ucl.ac.uk)
Tue, 20 Jul 1999 11:03:54 -0700
It seems as if the getVoxelAddr function is really only useful for
'reading' voxel values and not for 'writing' for the reasons that you
gave in your previous e-mail (i.e. there is not necessarily a
one-two-one mapping from voxel coordinates to memory addresses. )
It therefore seems that image processing will indeed require a separate
copy of the data set, which is a shame. As you know, many modalities can
produce huge amounts of data and having to store 2 copies in memory is
surely not the ideal solution.
Do you think that there is a chance that future versions of the
Volumizer will have better support for data manipulation, or do you
think that the official line will be to have multiple copies of the data
set and to re-load bricks.
Regards
Mark..
Robert Grzeszczuk wrote:
>
> Mark,
>
> Volumizer provides void *voBrickSet::getVoxelAddr(int x, int y, int z) method
> for the purpose of obtaining the address of a voxel given cits oordinates. The
> procedure determines which brick the voxel falls into and offsets it
> accordingly. Application needs to cast the pointer suitably before using it.
> For example, a voxel with external fromat of
> voExternalFormatTypeScope::INTENSITY and data type of
> voDataTypeScope::UNSIGNED_SHORT:
>
> unsigned short *myPtr =
> (unsigned short *)aVolume->getCurrentBrickSet()->getVoxelAddr(x,y,z);
>
> There are two issues with this approach. First, the mapping from the voxel
> coordinates to memory addresses is not unique. This is because one voxel can
> end up in more than one brick due to overlap. getVoxelAddr() will return any
> of the valid addresses in this situation. The second issue is that
> getVoxelAddr() is rather heavy weight so you should only use it sparingly.
> Interleaving adds an extra level of complication and is best avoided in
> processing heavy apps.
>
> If your application accesses the whole volume (or large subregions) you can
> typically modify your algortihms to process voxel data brick-by-brick so that
> only the address of the first voxel is needed (after that it's just pointer
> increments). A convolution based approach would lend itself easily to this
> approach.
>
> In certain situations this can lead to a problem, however. For example, if
> your application randomly accesses voxels (or small regions) you may have no
> choice but to keep two copies of the volume data in memory: a bricked one and a
> contiguous one. All updates would be performed on the original volume, which
> would be re-bricked as needed (e.g., write myReadBrick(memoryPtr,x,y,z,w,h,d),
> apply to each brick, re-apply volumeOptimize()).
>
> Keep in mind that Volumizer's goal is to make the visualization task easier.
> While bricking and overlaps make the processing task a little more involved,
> they do relieve you of siginificantly more tedious burden of managing large
> textures and efficient rasterisation.
>
> -rg
This archive was generated by hypermail 2.0b2 on Mon Nov 01 1999 - 14:11:13 PST