Robert Grzeszczuk (rg)
Tue, 20 Jul 1999 10:43:15 -0700 (PDT)
Volumizer's feature set is demand driven. If there is strong need to providing
this type of functionality, and there is a technically feasible solution, we
will consider providing it.
Do you have a specific interface for data manipulation in mind? Would it
still allow for virtualized voxel memory? Would you consider giving up the
ability to handle volumes that exceed the size of texture memory? Or tolerate
runtime cost of on-the-fly brick extraction? Or the cost associated with using
iterators to acces voxel data during processing? Is rendering speed more
critical than processing performance? Your feedabck would make the design task
significantly easier.
-rg
PS Note, that both seed fill and low pass filtering can be perfomed on a
per-brick basis with only slight modifications to the basic algorithms to
account for boundary conditions. Within the brick you can use conventional
pointer arithmetic to access voxels and don't have to worry about ambiguity in
coordinate-to-voxel_address mapping.
On Jul 20, 11:03am, Mark Davey wrote:
> Subject: Re: Voxel Accessing Question
> Hello,
> Thanks for responding.
> I understand that Volumizer's goal is to make the visualisation task
> easier, but I guess that hopefully this will not be at the expense of
> other operations to be performed on the data.
>
> 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
>-- End of excerpt from Mark Davey
This archive was generated by hypermail 2.0b2 on Mon Nov 01 1999 - 14:11:13 PST