I had a swift look into ITK and our code base and I would guess the following:

I guess that will be something that has to be fixed in the mapper. When looking into it, may be you also see the reason for T25445: MultiLabel segmentation mapper is very slow would be great.

@kompan FYI I think the loading error is a known/fixed issue (see above).

Discussion result: For now (MITK 2020) we well deactivate the skipping of empty slices. But such a support would make sense longterm, but it is also a bigger issue. I have opened a dedicated Task T27439: [Segmentation] Support of Mask/Segmentations that are cropped / do not cover the whole image grid for that.

Pushed new branch feature/T27438-fix-gcc10-errors.

I changed the superbuild to use ITK 5 with compatibilty and fixed some straightforward issues. This branch can be used for further investigations @floca : some ideas about the geometry issues would be very helpful. The migration guide has an overview on the topic but my experience in that area is limited

Pushed new branch feature/T27437-migrate-to-ITK-5.

The fix of the manual is in the master. As there was no more updates/questions, I will closed this task as resolved. @TE_Cork : If there is still an issue, please feel free to open the task again and to provide new information. Thanks.

Sorry for that ;)

I would also lower the prio here. As we now workarrounds and for fixed sized planarfigures the problem does not exist.

I have now removed the dysfunctional Clone for now. See D303

We need to adjust the path in O1: MITK Reviewer Group I afterwards.

Created global Maniphest filters for both examples above with 3 and 18 months.

dicombrowser it is.

We can save the filters in Phabricator and then manually do batch edits at specific times like before an official release or every once in a while.

There's a check in PlanarCircle that prevents control points to leave the image extents. We would need to change that check to fix this task.

Seems the reason this passes on all official clients is Debug vs Release. We currently only test release which ignores asserts. Thus, this should be investigated properly by tracing the problem, Windows and Linux are both affected

Plesae, could you add some more information (which version?, which OS?, is it reproducible with different images? Preferably an image that can be shared. E.G. something from the MITK-Data repository)
Thanks.

Hello, I ran into the same problem as you when running tutorial Step6. How did you solve it?

Hi, thanks for reporting the problem. I think it is caused by a known problem fixed by T27321: [DICOM reader] DICOM 3D+t image reader should condense only images of the same series.. To verify the assumption you could either:

1. test the loading with a current master build of mitk
2. or ensure that only the DCE dicom files are in the directory (e.g. no scout images or other sequences) while loading. This option would also be your workarround if you want to use an older version.

In T27031#192299, @kalali wrote:

It's not about identification under the hood but the name of the data in the histogram, i.e. the label of the legend. But it's probably low priority for now.

I keept the priority (as it is important im ML segmentation should be realy be able to replace everything) and moved it back into "MITK" as it is not realistic to make it in this cycle. We can reevaluate it later .

In T27266#197305, @kislinsk wrote:

In T27266#197253, @floca wrote:

So we have to make an auto load module for the planar figure IO. Right?

No, I think it is probably the last module that was never migrated to have an extra IO auto-load module.

@kislinsk I am somewhot confused, as your answer seems contradicting itself. Should we now have a IO auto load (sub) module for planar figure or not. If not, what do you propose?

Fixing this branch I will focus on enabling mask selection at all again. The support of ML is covered in T27435: [Registration] Mapper does not properly support LabelSetImages.

Ah perfect :) I was looking into a decathlon report which was apparently created with the master branch.

This seems to be a duplicate of T27325 and should already be solved on develop branch. Which version did you use?