Hey Marco, I had uploaded the models there back in the days:

I agree on that. I had some problems with that with the new mxn-multiwidget. The topic was also mentioned in T27613: Improve reinit behavior.

The same issue seems to apply to the normal workbench, so this container has also to be updated to the current master

Thanks. I think restricted access to code and models makes a big difference in the sense of preparatory work, code cleaning. model licensing etc.. ;) So that's why we thought it would be good first step to resolve all technical issues. Moving code and models to a public location would be another thing then.

Ok, but this makes not a big difference, right?
Here's what I think would be good for us:

• A single Dockerfile build-able without any local files
• The needed source-code should be downloaded via a direct git clone within the Dockerfile
• Internal usage would allow to pass credentials as build-args to git
• Models should be downloaded via curl during the build-process as well
• There should be two stages:
  1. Download and build source-code + download and unzip models
  2. Execution environment (incl. the models) - but without build dependencies, build tree etc

Pushed new branch to rMITK MITK: bugfix/T28487-MitkMRSignal2Concentration_handle_exceptions.

Thanks @schererj , maybe one information was missing: as a first step we thought about making this build-able internally, so as part of the Kaapana/Dcipher-internal repo (option 2 in my comment above from March 25th)

The problem is the MBI branch, which is afaik not public.
If there is a working Dockerfile, which can be publicly build, I'm happy to include it.
Additionally the models need to be put somewhere to be downloaded (also public in this case).
Hope this helps.

So I modified the "Assert"-functions to directly encapsule the CPPUNIT_ASSERT_MESSAGE calls in that function as you suggested. The error still occurs and now the problem is that I can't see where the error occurs because it happens inside the "Assert"-function (which is the same for each test). So that is not an option. Any other suggestions? I could split the test to test each node individually.

Ok so I found a bug for the test in line 320. This showed some complex behavior with the level window manager, which I don't want to address here.
However, the test in line 288 still randomly fails - when debugging in that line the test does not fail but fails in line 292.

Yes, I agree that this is not the most straight forward way to do it. There was a reasoning behind it to do it that way.
I will think about it - but currently it seems as if something is not correct with the tests, in a way that I am actually expecting wrong test results - so I need to rethink the expected results and change the true / false arguments accordingly.

Hm, I cannot answer this without looking into this in detail but a first step could be to improve the AssertImageForLevelWindowProperty function or maybe even encapsule the CPPUNIT_ASSERT_MESSAGE calls in that function instead the other way around since the error message one does receive currently doesn't tell much about what actually failed since it could be any or all of the three checks.

@norajitr thanks for the follow up. Could you attach the two (?) Dockerfiles here and post the network drive path? Maybe someone else from Kaapana (internal) could have a look then, too.

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.

Since I modified and merged T28250 I wanted to continue here. I still get failed tests in line 288 and in line 320:

assertion failed
- Expression: AssertImageForLevelWindowProperty(false, true, false)
- "imageForLevelWindow" property not correctly set

assertion failed
- Expression: AssertImageForLevelWindowProperty(true, false, false)
- "imageForLevelWindow" property not correctly set

I narrowed it down.

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

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

@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.