[vtkusers] Data spacing affects volume rendering quality?

Sankhesh Jhaveri sankhesh.jhaveri at kitware.com
Mon Sep 12 11:04:41 EDT 2016 

Hi Elvis,

Sorry for not being prompt.

You shouldn't need to scale your transfer function. See
vtkVolumeProperty::SetScalarOpacityUnitDistance(). Changing it to target
spacing might do the trick.



*Sankhesh Jhaveri*
*Sr. Research & Development Engineer* | Kitware
<http://www.kitware.com> | (518)
881-4417




On Mon, Sep 12, 2016 at 10:43 AM, Elvis Stansvik <
elvis.stansvik at orexplore.com> wrote:

> 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/0833
>>>>> 11.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/df1f9ee6/attachment.html>

More information about the vtkusers mailing list