[vtkusers] Data spacing affects volume rendering quality?

Mon Sep 12 10:43:25 EDT 2016

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

> 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.
>

I gave the above a quick try with my volume, changing my transfer function
from

    opacity->AddPoint(0.000, 0.00);
    opacity->AddPoint(0.500, 0.00);
    opacity->AddPoint(2.000, 0.70);
    opacity->AddPoint(3.500, 1.00);
    opacity->AddPoint(20.000, 1.00);

to

    opacity->AddPoint(0.000, 1.0 - std::pow(1.0 - 0.0, 1 / 0.0006));
    opacity->AddPoint(0.500, 1.0 - std::pow(1.0 - 0.0, 1 / 0.0006));
    opacity->AddPoint(2.000, 1.0 - std::pow(1.0 - 0.70, 1 / 0.0006));
    opacity->AddPoint(3.500, 1.0 - std::pow(1.0 - 1.0, 1 / 0.0006));
    opacity->AddPoint(20.000, 1.0 - std::pow(1.0 - 1.0, 1 / 0.0006));

and got the attached result, so not quite there yet :( Scaling the opacity
transfer functions like this seems to not be enough to get the same
rendering as if I had hardcoded the spacings of the volume to 1 (instead of
0.0006).

Anyone know what else I have to do?

Elvis

> 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/0405
>>>>> 59.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/7ba7acab/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: result.png
Type: image/png
Size: 36974 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160912/7ba7acab/attachment.png>