Robert Grzeszczuk (rg)
Mon, 19 Jul 1999 11:38:01 -0700 (PDT)
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
On Jul 19, 11:05am, Mark Davey wrote:
> Subject: Voxel Accessing Question
> Hello,
>
> The application we are writing here requires considerable modification
> to the volumetric data being rendered. For example we may wish to
> low-pass filter the entire volume, or flood fill a region with a given
> color/intensity. In particular we need to alter A SINGLE voxel within a
> brickSetCollection.
>
> This is probably a very simple question but here it is anyway.
> Assuming a multi-brick volume how do I efficiently access and modify
> voxels within this volume. I would like a simple addressing system
> treating the volume as either a
> 1D or a 3D array. Problems would include the need to cope with multiple
> bricksets as generated when performing 2D interpolation and different
> datatypes such as unsigned byte and unsigned short etc.
>
> Although I can see ways of doing what is needed, I just thought Id post
> the question to see the thoughts of others on this list.
>
>
>
> Regards
> Mark..
>
> --
> From: Mark Davey
> Dept. of Medical Physics, UCL.
>
> TEL: +44 (0)171 915 1673.
> FAX: +44 (0)171 837 9279.
>
> Institute of Laryngology and Otology,
> 330 Gray's Inn Road,
> London.
> WC1X 8GE.
>-- End of excerpt from Mark Davey
This archive was generated by hypermail 2.0b2 on Mon Nov 01 1999 - 14:11:13 PST