[vtkusers] Data spacing affects volume rendering quality?

Elvis Stansvik elvis.stansvik at orexplore.com
Mon Sep 12 10:06:31 EDT 2016


2016-09-12 15:30 GMT+02:00 Sankhesh Jhaveri <sankhesh.jhaveri at kitware.com>:

> Hi Elvis,
>
> There are flags on the volume mapper that allow setting the distance
> between samples along the ray. By default, the sample distance is computed
> as 1/2 the average spacing throughout the volume. If you have
> AutoAdjustSampleDistances enabled, the mapper computes the sample distance
> each frame based on the time taken to render the last frame. For consistent
> quality, you should disable AutoAdjustSampleDistances and set the sample
> distance explicitly. That way, you can leave the volume spacing in the
> units you desire.
>

Hi Sankhesh,

Hm, I don't see why it shouldn't be able to automatically compute an
appropriate sample distance even with small volume spacings?

E.g. right now, I'm testing with a volume that has 0.0006 spacing in all
three dimensions and I leave the spacing as-is. The rendering looks like
the attached result-0-0006.png.

If I just hardcode the spacing to 0.1 (much closer to 1) instead, the
result is as shown in the attached result-0-1.png.

In both cases the same color/opacity transfer function is used, the
difference is just the data spacing (and as a result, how much space the
volume occupies in VTK the world).

Shouldn't the automatic adjustment of sample distances work in this case? I
think want that feature turned on, because I want the quality to degrade
when moving/rotating the camera, as it improves interactivity.

For testing, I tried disabling the AutoAdjustSampleDistances and hardcoding
the sample distance to 0.0003 (half my data spacing) with:

            volumeMapper->SetAutoAdjustSampleDistances(0);
            volumeMapper->SetSampleDistance(0.0003);

But the result was the same as in with the option turned on (as in the
first screenshot).

Any other ideas?

Thanks a lot for your help.

Elvis


>
> *Sankhesh Jhaveri*
> *Sr. Research & Development Engineer* | Kitware <http://www.kitware.com>
> | (518) 881-4417
>
>
>
>
> On Mon, Sep 12, 2016 at 8:56 AM, Elvis Stansvik <
> elvis.stansvik at orexplore.com> wrote:
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtkusers
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160912/4ae4e384/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: result-0-0006.png
Type: image/png
Size: 14321 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160912/4ae4e384/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: result-0-1.png
Type: image/png
Size: 62210 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160912/4ae4e384/attachment-0003.png>


More information about the vtkusers mailing list