[vtkusers] opacity functions and vtkVolume scaling

Lisa Sobierajski Avila lisa.avila at kitware.com
Wed Jun 20 02:19:27 EDT 2001


Hello Alex,

My intent was NOT for you to override VTK code, but for you to (at your 
application level) modify your opacity transfer functions based on your scale.

What you did resulting in the same image because you disabled the 
correction - this means that whatever the sample distance is will be the 
"unit" used in the opacity transfer function. Then you applied the same 
scale to both your volume and your sample distance. If you try to change 
your sample distance you will have an incorrect image because you will not 
correct for the sample distance change.

What you should do is "fix" your opacity transfer function for your volume 
scaling so that you can correctly use any sample distance. Here's what 
you'll need to do:

Let's say you have an opacity of a and you are scaling by k. Your new 
opacity a' would be:

a' = 1.0 - POW(1.0 - a, 1/k)

To show that this works, let's say your sample distance goes from 1.0 to k. 
This means that when the opacity is corrected for the sample size:

a'' = 1.0 - POW(1.0 - a', k)

by substitution:

a'' = 1.0 - POW(1.0 - (1.0 - POW(1.0 - a, 1/k)), k )
a'' = 1.0 - POW(POW(1.0 - a, 1/k), k)
a'' = 1.0 - (1.0 - a)
a'' = a


So if you run all of your scalar opacities through the function

a' = 1.0 - POW(1.0 - a, 1/k)

whenever you scale, you should keep a constant (within the precision of the 
rendering) volume rendered image. I would recommend keeping the original 
function around and always scaling absolutely from that rather than 
relative scaling where error will accumulate.

Lisa

  At 09:24 AM 6/19/2001, alext at win.tue.nl wrote:


>   Hello Lisa,
>
>   Following your hint that opacity functions are not scale independent, I
>tried to obtain a volume rendering app independent on the scaling of the
>vtkVolumes as follows:
>
>   - I scaled the SampleDistance by the vtkVolume's scaling factor, let's 
> call this K.
>   - I adjusted the opacity functions simply by disabling the 'correction'
>     that VTK did for them automatically. To do this, I had to override
>     UpdateScalarOpacityforSampleSize(), to make it use the non-scaled
>     ray-sampling step size. In this way, I attempted to make the opacity
>     non-relative to the volume scale. Since 
> UpdateScalarOpacityforSampleSize()
>     is NOT virtual, I had to override the places where it gets
>     called, namely vtkVolume::InitializeRayCasting and 
> vtkVolume::InitializeTextureMapping.
>
>Running the application, I got indeed the same volume rendering for any 
>scale of the
>vtkVolume object. It would be nice, I think, if the end-user could achieve 
>this effect without having to
>subclass the VTK code as I did. One potential use is an application where 
>several actors/volumes have to be mixed
>in a scene, e.g. by translatinig/scaling them. If we want the appearance 
>of the volumes to be the same,
>irrespective of their scale, we need something like the above.
>
>One last problem is that SHADING seems not to work ok after what I did 
>above. Somehow, I get shading,
>but the values seem to be all too bright. Do I miss something? Or 
>alternatively, is there a way to
>obtain what I aim at - same appearance of volume rendered vtkVolumes 
>irrespective of their scale - without the
>overriding of UpdateScalarOpacityforSampleSize that I attempted?
>
>Thanks in advance for any hints,
>
>  Alex
>
>-----------------------------------------------------------------
>  Dr. Alexandru C. Telea      | Technische Universiteit Eindhoven
>                              |
>  E-mail   : alext at win.tue.nl | Dept. of Mathematics and
>  Office   :  HG 7.71         | Computer Science
>  Tel.     : +31 40 247 5008  | PO Box 513
>  Secretary: +31 40 247 4416  | 5600 MB Eindhoven
>  Fax      : +31 40 246 8508  | The Netherlands
>                              |
>  URL      : http://www.win.tue.nl/math/an/alext
>-----------------------------------------------------------------
>
>
>
>the same rendering effect - after modifying the ray sample
>step - in the following way:
>
> >
> > 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
> > >
> > >
> > >
> > >
> > >At 10:57 AM 6/18/2001, alext at win.tue.nl wrote:
> > >
> > >
> > >
> > >>   Hello all,
> > >>
> > >>   I have stumbled on a very unexpected behavior of the vtkVolume's 
> transform
> > >>with respect to the vtkVolumeRayCastMapper. Basically, I took one of 
> VTK's
> > >>example (e.g. volProt) and added a user-matrix to the vtkVolume that did
> > >>nothing but scaled the volume uniformly to e.g. 0.1 times the initial 
> size.
> > >>Then I used the vtkVolumeRayCastMapper to volume render the volume.
> > >>Surprisingly, the z resolution of the image was extremely bad. The 
> noticed
> > >>effect is very similar to subsampling the volume along the rays or 
> setting
> > >>the camera's clipping range incorrectly such that not all the zbuffer's
> > >>precision is used.
> > >>   It looks to me that this is a bug in VTK. I tried other transforms 
> on the
> > >>vtkVolume, such as rotations and translations, and all went ok. But 
> scaling
> > >>the volume, namely with a scale factor < 1, seems to destroy the sampling
> > >>precision along the rays of the raycaster.
> > >>
> > >>   I thought first that I had to adjust the SampleDistance member of the
> > >>vtkVolumeRayCastMapper, i.e. to make it smaller because the volume is now
> > >>smaller. However, it didn't help mcuh to improve the rendering quality -
> > >>moreover, the vtkVolumeRayCastMapper.h file states that this distance 
> is in
> > >>volume coordinates, so it should be insensitive to scaling of the volume.
> > >>Then I thought I should adjust the camera clipping range differently.
> > >>However, when printing the bounding-box based computation of the camera
> > >>clipping range of vtkRenderer::ResetCameraClippingRange(), I saw that the
> > >>clipping range is correctly computed to take into account the smaller
> > >>volume.
> > >>
> > >>   Has anyone notices these rendering artifacts when scaling a 
> vtkVolume with
> > >>a factor < 1? Is there any way to cope with such volumes? I can't 
> increase
> > >>the scaling factor of vtkVolume really, since my application passes it
> > >>together with other transform info in a SetUserMatrix() call - so I 
> have to
> > >>stick with a sclaed vtkVolume.
> > >>
> > >>   Any help is very welcome,
> > >>
> > >>   Alex Telea
> > >>
> > >>-----------------------------------------------------------------
> > >>  Dr. Alexandru C. Telea      | Technische Universiteit Eindhoven
> > >>                              |
> > >>  E-mail   : alext at win.tue.nl | Dept. of Mathematics and
> > >>  Office   :  HG 7.71         | Computer Science
> > >>  Tel.     : +31 40 247 5008  | PO Box 513
> > >>  Secretary: +31 40 247 4416  | 5600 MB Eindhoven
> > >>  Fax      : +31 40 246 8508  | The Netherlands
> > >>                              |
> > >>  URL      : http://www.win.tue.nl/math/an/alext
> > >>-----------------------------------------------------------------
> > >>
> > >
> > >
> > >_______________________________________________
> > >This is the private VTK discussion list. Please keep messages on-topic.
> > >Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
> > >Follow this link to subscribe/unsubscribe:
> > >http://public.kitware.com/mailman/listinfo/vtkusers
> >
> >
> > _______________________________________________
> > This is the private VTK discussion list.
> > Please keep messages on-topic. Check the FAQ at: 
> <http://public.kitware.com/cgi-bin/vtkfaq>
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/vtkusers
> >
>
>
>_______________________________________________
>This is the private VTK discussion list.
>Please keep messages on-topic. Check the FAQ at: 
><http://public.kitware.com/cgi-bin/vtkfaq>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/vtkusers






More information about the vtkusers mailing list