[vtkusers] Data spacing affects volume rendering quality?

Elvis Stansvik elvis.stansvik at orexplore.com
Mon Sep 12 10:34:04 EDT 2016


I believe I've now found yet another post (this time from 2001!) describing
what I see:

    https://itk.org/pipermail/vtkusers/2001-June/006846.html

In this thread, Lisa points out two things:

>
> Hello Alex,
>
> One other thing to note is that the transfer functions are not
independent
> of scale. The scalar opacity function indicates how much opacity is
> accumulated per unit length. Scaling your volume by 0.1 means that you
need
> to adjust this table accordingly.
>
> Lisa
>
> At 11:05 AM 6/18/2001, Lisa S. Avila wrote:
> >Hello Alex,
> >
> >I believe the comment stating that the sample distance is in voxel
> >coordinates is out-of-date. When Actor and Volume merged (quite a long
> >time ago) the Volume obtained a UserMatrix and 3 component scaling, and
> >the sampling distance changed to world distance. So, if you scale your
> >volume by 0.1 you should do the same to your sampling distance.
> >
> >One limitation (this is true of Actors and Volumes) is that non-uniform
> >scaling is not handled correctly for gradient calculation. For correct
> >rendering, change the aspect of the volume in the ImageData rather than
> >the Volume.
> >
> >Lisa

Given the age of that thread, I have to ask: Which of these things are
still true? Must I always compensate my opacity transfer function taking
the scale into account?

Lisa later explains how to do this:

    http://www.vtk.org/pipermail/vtkusers/2001-June/006860.html

Is this what I must do? At the moment, my different volumes share the same
transfer function (in fact, the same volume property). But do do this
compensation, I'd have to give them each their own opacity transfer
function.

But, do you think this is all that I have to do to get the rendering I want
no matter the scale of the input data?

Thanks for any advice,
Elvis

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

> 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/72cfdbbd/attachment.html>


More information about the vtkusers mailing list