Re: Extraction of data from bricks

New Message Reply Date view Thread view Subject view Author view

Dave Akers (dla@sgi.com)
Tue, 17 Aug 1999 10:32:31 -0700


Hi Mark,

What kinds of filters are you implementing? You might be able to perform
the filters on a brick-by-brick basis, saving you a lot of time and effort.
(You can just use simple pointer-arithmetic to address voxels within a
brick.)

If you can't do it brick-by-brick, you'll have to write your own routine to
extract the data into your temporary contiguous buffer. There's no way
through the API to de-interleave the data once it's in that form, so you
would have to take into account the addressing issues regarding
interleaving. To get the offset of interleaved brick data, just multiply
your original offset by 2 and add the texture select ID..

Note that there is a
voAppearanceActions::volumeUnoptimize(voBrickSetCollection *) method call,
but all this does is delete the texture objects allocated by
volumeOptimize(). Typically you would make this call just before deleting
the volume object itself.

Let me know if this helps.. I may not yet be understanding exactly what it
is that you want to do.

-Dave

Mark Davey wrote:

> Hi,
>
> I wish to implement some filters on the data that has been loaded into
> volumizer. I guess the simplest way of doing this is to copy the entire
> data set from bricks into a contiguous chunk of memory, perform the
> filter and reload the bricks.
> I have a number of reasons why I do not wish to keep multiple copies of
> the same data set in memory so I want to create a temporary copy used
> just during the filtering process.
>
> However, how does volumeOptimise affect things if INTERLEAVE_2WAY has
> happened as part of the optimisation process?
>
> The question really then is as follows: Can I UnOptimise the
> bricksetcollection before attempting to extract the data. After
> reloading the bricks can I then volumeOptimise as I did when first
> loading the data into volumizer?
>
> Finally, does anyone have any code segments demonstrating an efficient
> way of handling data when it could be in a number of different formats
> and bytes per channel. I would be looking to write code within which the
> format etc. of the data was kept as transparent as possible.
>
> 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.


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Nov 01 1999 - 14:21:40 PST