Page MenuHomePhabricator | MITK

Opacity rendering errror in 3D Multi Widget
Open, HighPublic

Description

Try this:

Load two 3D grayscale images so that you have in data manager whereby the images should be on an position so that they overlap. Then you have in data manager:

-> Img1 (Opacity = 1)
-> Img2 (Opacity = 1)

In 2D as well as in 3D multi widget planes the Img1 is painted first so that you cannot see Img2 at the overlap. Now change the opacity of Img2 from 1 to e.g. 0.8. Normally, on the overlay, Img1 should remain (works in 2D), but suddenly Img2 appears in 3D!!!

Event Timeline

Anja + Stefan: Figured out that the new image mapper cannot solve this problem. => RFD

The new renderer from Thomas should be aware of transparent objects.

There is not really anthing to discuss. The new mapper/the rendering pipeline has to take care of this.

lodron added a subscriber: lodron.Jul 28 2011, 10:39 AM

i also have an same problem on an RGB image:

when i load the RGB image and change the level window the color changes in 2D views but not in 3D

(In reply to comment #4)

i also have an same problem on an RGB image:

when i load the RGB image and change the level window the color changes in 2D
views but not in 3D

We are aware of this issue. It will be fixed shortly after the new VTK rendering is merged into the master.

This should be verified again with the new ImageVtkMapper2D. I guess we can just transfer the code from the 2D mapper to the 3D mapper to solve this issue.

Still to verify.

This bug is still valid.

Medium importance, since its very old bug.

Trying to fix this issue for 3D after the next release.

This bug could not be fixed within the 2013-06 release and has medium severity. Setting target milestone to unspecified.

This bug could not be fixed within the release 2013-06. Setting its target milestone to unspecified

T16163 contains nice screen shots of the issue here.

Bug is getting old ... Increased severity. Can be done by anyone.

We checked the layer order of the images in the 3D mapper (Geometry2DDataVtkMapper3D). Everything seems to be correct there.

We discovered a strange setting in the mapper:

imageActor->GetProperty()->SetOpacity(0.999);

/* HACK! otherwise VTK wouldn't recognize this as translucent surface (if LUT values map to alpha < 255 improvement: apply "opacity" property onle HERE and also in 2D image mapper. DO NOT change LUT to achieve translucent images (see method ChangeOpacity in image mapper 2D) */

Changing the value to 1.0 or removing the line had no effect on the bug.

Current release is finished. Reseting target milestone...

Passing this to sandy because she was working on the bug.(In reply to Gerald

kolbch added a subscriber: kolbch.May 14 2014, 4:47 PM

I have tested this behavior in a pure vtk environment. it seems that the order of images is ignored by vtk if both images have an opacity of 1.0.

A (dirty) way to ensure that the images are rendered in the correct order is to set the maximum opacity of each image node to 0.999

What is the status here? Won't fix?

It can be fixed. but it is either dirty (opacity = 0.999) or by rewriting parts of the Geometry2DDataVtkMapper3D: the props containing the images can for example be converted to imageActors which have a layer property.