@s434n and I tried this on Windows and Linux. It looks like, if you load the data via "classical drag'n'drop", it works as expected. If we use the DICOM browser to load the exact same dataset, we can reproduce @nolden's issue.

Interesting.

Ok, we tested it on several machines and it is as described above: After loading via DICOM Browser we can confirm the issue.

If you load a RTStruct via DICOMBrwoser, the node has a special "visible" property for stdmulti.widget3 (the 3D view). You can enable/disbale it via the Properties plugin. #Workaround :-P

I narrowed it down.

The drag'n'drop version uses mitkIOUtil to load the structs and sets the properties via

AbstractFileReader::SetDefaultDataNodeProperties

The DICOM browser version uses the DICOMEventHandler to set the properties like this:

mitk::DataNode::Pointer structNode = mitk::DataNode::New();
                  structNode->SetData(countourModelSet);
                  structNode->SetProperty("name", aStruct->GetProperty("name"));
                  structNode->SetProperty("color", aStruct->GetProperty("contour.color"));
                  structNode->SetProperty("contour.color", aStruct->GetProperty("contour.color"));
                  structNode->SetProperty("includeInBoundingBox", mitk::BoolProperty::New(false));
                  structNode->SetVisibility(true, mitk::BaseRenderer::GetInstance(
                      mitk::BaseRenderer::GetRenderWindowByName("stdmulti.widget0")));
                  structNode->SetVisibility(false, mitk::BaseRenderer::GetInstance(
                      mitk::BaseRenderer::GetRenderWindowByName("stdmulti.widget1")));
                  structNode->SetVisibility(false, mitk::BaseRenderer::GetInstance(
                      mitk::BaseRenderer::GetRenderWindowByName("stdmulti.widget2")));
                  structNode->SetVisibility(true, mitk::BaseRenderer::GetInstance(
                      mitk::BaseRenderer::GetRenderWindowByName("stdmulti.widget3")));

I commented the special visibly for each render window out and it seems to fix the problem, but I am not sure what was the reason for it in the first place. Git blame pointed me towards @hentsch and @kislinsk

I would like to discuss this one.Why is there even two completely separate ways of loading the same dataset? Does this make sense?

In T28455#223933, @kleina wrote:

like to discuss this one.Why is there even two completely separate ways of loading the same dataset? Does this make sense?

I can not tell ad hoc which code would makes more sense. But I can tell directly that it makes no sense that the loading mechanisms execute different code to populate the properties. We had a simelar problem with doses once.

Discussed it in the MITK meeting:

• Quick fix will be to delete the explicit visibility settings that I already commented out.
• We agreed to do this as a fix for this task but then create a new task to actually look into the data loading in more detail and find out why there are two ways and what is the difference.

Pushed new branch to rMITK MITK: bugfix/T28455-rt-struct-3d-visibility.

Deleted branch from rMITK MITK: bugfix/T28455-rt-struct-3d-visibility.