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.

Sure, here it is:
https://phabricator.mitk.org/rOBSHYPPOPYa340b927d14acdef69cea4e64b92524270066920

After talking with Marco, I have looked for the whereabouts of dockerfiles (liver-mri and multiorgan-seg), working commits for MITK (a0dedffb74d) and for MBI-builds (56ad5bf7064) and trained models. @schererj: I sent you this information via email in October 2020, and shared the trained models on the network drives. Can you confirm? What information do you need to keep the shape models operational?

In T28332#223158, @kleina wrote:

I updated the draft in the branch directly (same file).

• I did not change the send/recv to scatter/gather. In my opinion send/recv makes more sense, but we can discuss this.
• In my opinion, we maybe don't need the "cleaning up" up the mpi_processes here, because it might be taken care of by our current implementation.

Let me know when you had time to look at it and if there are any questions. I'd like to discuss it a bit.

Could you point me to the commit? I cannot find it ?!?

Hm, due to the facts that (1) the feature is missing since 2016 and no one ever complaint, (2) it is not documented in the help and (3) I am not sure why one would like to behave differently when clicking in an area that is segmented, I would just skip the code path. Yes.
But I would go further then. You don't need the whole inside check any more. I would completly remove everythin below line 332 and directly call OnMousePressedOutside(nullptr, interactionEvent); then.

I've started a draft for a message to send around, found here if you want to have a look or add something: https://hub.dkfz.de/s/HzpkipeWRkq3K8K

I quickly modified the code to see if this works potentially. For this I set m_PaintingPixelValue to 1 for both cases and used the OnMousePressedOutside-function also for a mouse pressed inside:

m_PaintingPixelValue = inside ? 1 : 1;

I started looking into this and what I found inside mitk::RegionGrowingTool::OnMousePressed:

if (inside)
      {
        MITK_DEBUG << "Clicked inside segmentation";
        // For now, we're doing nothing when the user clicks inside the segmentation. Behaviour can be implemented via
        // OnMousePressedInside()
        // When you do, be sure to remove the m_PaintingPixelValue check in OnMouseMoved() and OnMouseReleased()
        return;
      }
      else
      {
        MITK_DEBUG << "Clicked outside of segmentation";
        OnMousePressedOutside(nullptr, interactionEvent);
      }

Looking at the file history it doesn't look like that was implemented in MITK at anytime.
So we can actually discuss if we want to allow such a functionality and if, what the obstacles are.

Obviously it was not clear what we are expecting here so I will close this task and refer to two new tasks for the specific topics mentioned here:

• Where to put "publicly available" / "shareable" test data --> availability: T28480: [Checklist] [Test data] Define publicly available location to store user test data
• Which data to use for specific checklists --> suitability: T28481: [Checklist] [Test data] Define publicly available user test data