[vtkusers] Data spacing affects volume rendering quality?

[Elvis Stansvik]

2016-09-12 14:01 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:

> Hi all,
>
> I've just noticed the there's a large difference in rendering quality if I
> decrease the spacing of my data (using vtkGPUVolumeRayCastMapper).
>
> I found this very old post from 2007 about the same problem:
>
>     http://public.kitware.com/pipermail/vtkusers/2007-March/040559.html
>
> I was originally using a data spacing of 0.12, which is the voxel size in
> centimeters for the particular volume I'm working with (stored in our data
> files), but after I tried to divide it by 100.0 during loading, rendering
> quality dropped considerably. The reason I wanted to do this is because
> it's more convenient if VTK world coordinates are in meters in this
> particular application, not centimeters.
>
> Anyone know why volume rendering quality seems dependant on the data
> spacing?
>

I now found another more recent post from 2014 which describes in more
detail what I seem to experience as well (seemingly also with no answer):

    http://public.kitware.com/pipermail/vtkusers/2014-March/083311.html

I get the expected rendering when the spacing is ~1.

Must I make sure that my volumes have a spacing ~1? I'm willing to abandon
the idea of having VTK world coordinates == meters and introduce another
scale, but it's a bit cumbersome as I'm working with multiple volumes which
I add to the renderer at once, and not all of them will have the same
spacing. This means I must first analyse the volumes I'm going to load a
priori, and calculate a factor common to them all that will bring all of
their spacings as close to 1 as possible :(

Would be great if someone in the know could chime in. Is there some
workaround? Can I instruct the mapper to "expect" the small spacings I want
to work with?

Elvis


> Thanks for any clarifications!
>
> Elvis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160912/f5c4dacb/attachment-0001.html>