Currently any pixel values that are smaller than -1023 are rendered transparent. This is done to ensure that when multiple images are displayed on top of each other, smaller images do not cover larger images. This would otherwise be the case because the area outside of an image, but inside of the rendered frame (defined by the current WorldGeometry), also is resampled (and assigned a gray value of -1024 by default) and thus displayed.

THis can be called workaround, but it's difficult to find a better solution in this situation.

The lines of code to look at to understand how this works are:

mitkImageMapper2D.cpp: line 492

rendererInfo.m_Reslicer->SetBackgroundLevel( -1023 );

mitkGeometry2DDataVtkMapper3D.cpp: lines 136-142 (defines the lookup table with lowest entry set to translucent, line 142)

m_DefaultLookupTable = vtkLookupTable::New();
m_DefaultLookupTable->SetTableRange( -1024.0, 4096.0 );
m_DefaultLookupTable->SetSaturationRange( 0.0, 0.0 );
m_DefaultLookupTable->SetHueRange( 0.0, 0.0 );
m_DefaultLookupTable->SetValueRange( 0.0, 1.0 );
m_DefaultLookupTable->Build();
m_DefaultLookupTable->SetTableValue( 0, 0.0, 0.0, 0.0, 0.0 );

Defining a bool flag to control this behavior could be a good solution if this is not desirable.

hmm

then i do not really understand why this happens in my case:

A programmed a comparison tool which takes two (usually registered) images as input and calculates the absolute difference between them (using resampling to the same size, origin etc). The result (float) is stored into an mitk::Image and then visualized in a data node as helper object (so it is not shown in the data manager tree).

So i want to highlight parts where the registration does not work good (then the absolute difference should be much bigger zero). The absdiff image is overlayed over all other images (top most layer) and gray values are between 0 and FLOAT_MAXIMUM so there shouln't be a value with -1023. But when i change the level slider i can see the pixels of the backimages (and there is no property to turn the slider off). A user can now misinterpret this as a high value in the absdiff image and can wrongly think that the registration was not ok.

I am quite sure that my absdiff filter works correctly so there is no value = -1023!!!

Any suggestions?

(In reply to comment #2)

I am quite sure that my absdiff filter works correctly so there is no value =
-1023!!!

Any suggestions?

You are right, the range of non-transparent grayscale mapping is actually not always [-1023, +4095], but varies accoring to the currently set level/window.

The level/window determines the range of original pixel values which will be mapped to a black-to-white ramp through the lookup table. The lookup table has always 256 bins, and the lowest bin is set to translucent (because of the reason mentioned above).

In your case the application determines a default level/window. When you change this to say [3.0, 10.0] by using the level/window slider, all values <= 3.0 will be mapped to translucency.

So your initial suggestion of adding a bool property for controlling this sounds like a good option. You're most welcome if you'd like to work on this and send us a patch, otherwise we'll probably look into it in one of our next "bug squasing parties" :)

From a first look, the lines of code to control with this boolean flag are:

For 3D rendering: mitkGeometry2DDataVtkMapper3D.cpp, line 142

m_DefaultLookupTable->SetTableValue( 0, 0.0, 0.0, 0.0, 0.0 );

For 2D rendering: mitkImageMapper2D, line 1013

LookupTableProp->GetLookupTable()->ChangeOpacity(0, 0.0);

Resetting all bugs without active assignee flag to "CONFIRMED". Change status to IN_PROGRESS if you are working on it.

Hi,
what is the status of this bug? is this fixed?

Not yet fixed --> reassign to default

Still a feature of minor importance.