Robert Grzeszczuk (rg)
Wed, 30 Jun 1999 16:01:13 -0700 (PDT)
The phenomenon may be related to tiling imposed by IFL.
Have you tried working with util/mkcubes.cxx instead? This simple utility
computes a volumetric test pattern (a bunch of cubes with varying densities) in
a linear array of unsigned chars. Then, it saves it ina file with a call to
myWriteVolumeIfl(). If you can write a C routine that dumps your voxels into:
unsigned char volume[sizeX*sizeY*sizeZ];
you should be able to resolve some of the issues or at least narrow them down
to a single routine (myWriteVolumeIfl()).
Also, many of the demos spew out debugging information. What does voglCache
say when you run it with the volume you created? Does it report correct
dimensions? What are the brick sizes?
-rg
PS Do keep in mind that data I/O is not a part of Volumizer. You should
really write your own routine that reads an arbitrary subvolume (i.e., a brick
originating at (x,y,z) with sizes of(subsizeX,subSizeY,subsizeZ)) from your
volume. This may be easier than figuring out IFL code.
On Jun 30, 4:23pm, Aaron Jones wrote:
> Subject: volumizer-performer difficulties
> Hello,
>
> At work we are experimenting using Volumizer to display data, and I have
> run into some odd behavior, and was wondering if anyone could
> explain/give some insight/had the same problem.
>
> We are using the two ifl converters provided with Volumizer (iflfrombin
> and iflto3Dtiff) to convert from our image file system to tiff. The
> first problem that I was getting is that when using the iflfrombin the
> image came out perfect...just flipped across the x-axis.
>
> The next problem I encountered was that after converting to the tiff
> format, and then using iflto3Dtiff to stack them up and display them
> with perfvol, I was loosing essentially all images over approximately 30
> (turned out to be 32). Well, long story short, a co-worker of mine and
> myself came up with a "conjecture" that seems to govern pretty well how
> it will behave:
> 1. if the number of stacked up images is a power of two greater than
> 4, it will display properly at the power of two, and one less than the
> power of 2.
> 2. if the number of stacked is two less than a power of two greater
> than 4, perfvol crashes before it finishes loading.
> 3. if the number of stacks is less than that, any thing above the next
> lower power of two seemingly gets culled.
>
> To test this, I made a program to construct a small square in a 256 x
> 256 image (the square itself was 10x10), for simplicity let's call it
> 01.tif, and then an image that was 256x256 of pure black, again for
> simplicity Z.tif (Z for zeros).
>
> iflto3Dtiff Z.tif Z.tif Z.tif Z.tif Z.tif 01.tif 3Dimage.tif; perfvol
> 3Dimage.tif would fall into that second clause and perfvol crashes
> before doing anything.
>
> iflto3Dtiff Z.tif Z.tif Z.tif Z.tif 01.tif 3Dimage.tif; perfvol
> 3Dimage.tif would fall into the first category and all that will
> display is black.
>
> etc.
>
> What makes it more interesting is that the demos that came with
> Volumizer were anything but exact powers of two (77, 38, 77 respectively
> for CT.Head.Bone.char.tif, CT.Head.Small.char.tif, and CT.Head.char.tif)
> and the 3D tiff provided worked beautifully. However, I tried
> converting them with the two ifl manipulators and was not able to
> duplicate the results. Does anyone know why the number of stacked
> images(the z axis) seems to conform to this property? The x and y axis
> is understandable, as it is done in texture memory, but it seems odd
> that the z axis must also. Is this a side effect of iflto3Dtiff? Is it
> a problem with pfVONode? Is it an accident happening inside of
> Volumizer itself? Any insight or explanation would be GREATLY
> appreciated.
>
> Thanks for all help,
> Aaron
>
>-- End of excerpt from Aaron Jones
This archive was generated by hypermail 2.0b2 on Mon Nov 01 1999 - 14:02:51 PST