From: Fred Dech (fred@cerulean.bvis.uic.edu)
Date: 10/26/2000 12:52:14
jason allen bryan wrote:
>
> it sounds like linear interpolation is the culprit.
> i can only assume you're using bilinear or trilinear interpolation if
> you're using volumizer to view datasets (although you may not, and if not
> then i don't know what the problem is). i suspect if you switch to nearest
> neighbor interpolation the problem will go away, but then your image
> quality is severely reduced, and nobody wants that.
you're correct, Jason.
we're using voInterpolationTypeScope::_3D when creating our
voBrickSetCollection.
possibly we need to be dealing with 4 byte RGBA data, rather than 1 byte,
pseudo-colored data. initially we were, and i believe that these inter-
polation artifacts were not visible, or at last not as pronounced. the
performance with RGBA data was, however, not good.
--fred
> suppose you have 2 adjacent voxels, one with a value of x, the other
> with y. it probably doesn't matter what channel the assignment is in, so
> lets assume it's all of them. when those 2 voxels get rasterized, a pixel
> on the screen gets a color which is a weighted sum of the colors of the
> voxels it is closest to. assuming bilinear interpolation in this case,
> this results in some linear combination of x and y. so what happens to a
> pixel which is between the 2 voxels? it gets some of one color and some of
> the other. now for colors this is good b/c it reduces aliasing in the
> resulting image. but for mutually exclusive regions like in your dataset,
> this is very bad. pixels on the edge of a voxel are blended with
> surrounding voxels, which changes their region index. during a subsequent
> lookup, the pixels are actually getting a value from the wrong region.
> one solution is to use nearest neighbor interpolation, but your images
> won't look that great. another is to enable the color lookup only during
> texture download. if you've got a copy of the volume in main memory, the
> values are mapped (with no interpolation) during texture download and
> subsequently rendered correctly. the only draw back is you now have to
> download the entire volume with each change in the lookup table. this may
> or may not be a problem, it depends on your application.
> if you'd like to discuss this more offline, i'm available. i've actually
> got a prototype algorithm going which allows a 4-channel volume to have
> arbitrary opacity and region information encoded in the alpha channel, and
> i can use a lookup table to modify the opacity of whole regions of the
> volume in real time. for example, i have a medical dataset of a human head
> with the skin, brain, bone, blood vessels, and a tumor segmented out, and
> i can change the opacity of every region in any combination. the algorithm
> also allows each voxel to have its own opacity independent of its region,
> so edges in the volume are rendered with less aliasing. i make use of the
> lookup during texture download as mentioned above. frame rates will drop
> if you are constantly changing the opacities of different regions, but for
> the application i'm working towards, this is acceptable.
> hope this helps!!
>
> -jason
>
> +--
> |
> | Jason Bryan
> | Director of Software Development
> | Interface Lab - Ohio Supercomputer Center
> | 1224 Kinnear Rd
> | Columbus, Ohio 43212
> | (614) 292-1051
> | www.osc.edu/Biomed
> |
> +--
> |
> | Discovery is seeing what everyone else has seen
> | and thinking what no one else has thought.
> | - Albert Szent-Gyorgi
> |
> | Anyone who has never made a mistake has never tried
> | anything new.
> | - Albert Einstein.
> |
> +--
>
This archive was generated by hypermail 2b29 : Thu Oct 26 2000 - 14:34:58 PDT