[vtkusers] Data spacing affects volume rendering quality?

Elvis Stansvik elvis.stansvik at orexplore.com
Mon Sep 12 14:21:01 EDT 2016 

2016-09-12 20:00 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
> Den 12 sep. 2016 5:35 em skrev "Elvis Stansvik" <elvis.stansvik at orexplore.com>:
>>
>> 2016-09-12 17:04 GMT+02:00 Sankhesh Jhaveri <sankhesh.jhaveri at kitware.com>:
>>>
>>> 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.
>>
>>
>> Thank you, that indeed did the trick. Setting it to 0.0006 (my volume spacing) and rendering is back to normal. I'll do some more testing to see that I can achive similar looking result with multiple volumes with different spacing, but I'm hopeful it is now solved.
>>
>> Again, thanks a lot. Not sure I would have found this myself.
>>
>> I'll have to rewrite the app slightly such that each volume has its own vtkVolumeProperty (at the moment they share the same), but that should be no problem.
>

I realize now my mail below is filled with some backwards thinking, so
replying to myself.

> Hope it's okay with some last questions, because I want to know what
> I'm doing by setting this option and why it "works", and I'm not sure
> I fully understand yet.
>
> If I understand correctly VTK, by default, calculates the opacity
> based on the opacity transfer function and the sample distance (aka
> step size, the distance traveled by the ray). Is this correct? (It
> looks like it, from these lines in vtkVolume [1]).
>
> You said that by default "[...] the sample distance is computed as 1/2
> the average spacing throughout the volume.". But if the sample
> distance is based on the spacing, and the opacity is based on the
> sample distance, then how come a volume looks different (opacity-wise)
> when it is scaled (or equivalently, its spacing is altered)?

This of course makes perfect sense. Spacing -> sample distance ->
opacity. Change the spacing and you change the opacity.

>
> I think I tried (can't quite remember and I'm back home now) to check
> if the AutoAdjustSampleDistances option was turned on, and I think it
> was. I didn't turn it on explicitly, so perhaps this is the default
> (and not 1/2 average spacing)? My question then is, with this option
> turned on, is the opacity completely independent of the volume
> spacing, and only a function of the performance of the computer and
> the desired frame rate? If so, that would explain what I was seeing.

It probably isn't just a function of the performance/target frame
rate, but also of the spacing. And _that_ would explain what I was
seeing. (Backwards thinking from me here as well...).

> But (!), if that's the case, then shouldn't I have gotten good result
> when I turned the option off and set the sample distance explicitly
> (using SetSampleDistance) to 1/2 of my data spacing? (The result still
> looked strange when I did that).

This I still don't quite understand. To me it seems that this should
have worked just as well as using the
vtkVolumeProperty::SetScalarOpacityUnitDistance option ..?

> Now, the vtkVolumeProperty::SetScalarOpacityUnitDistance() option.
> When I called it with my volume spacing, I seem to have gotten the
> result I wanted. Is this because it hardwires the opacity calculation
> to use the given value when correcting the opacity, instead of using
> the sample distance?

Why this works now makes perfect sense to me. Since I'm setting it's
the unit I'm setting, it effectively normalizes the opacity correction
calculations. It will be as if my volume had a spacing of 1.0.

Elvis

>
> Any and all clarifications are much appreciated!
>
> Elvis
>
> [1] https://gitlab.kitware.com/vtk/vtk/blob/master/Rendering/Core/vtkVolume.cxx#L747-750
>
>
>>
>> Elvis
>>
>>
>>>
>>>
>>>
>>>
>>> Sankhesh Jhaveri
>>> Sr. Research & Development Engineer | Kitware | (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 | (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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

More information about the vtkusers mailing list