I just tried to retrieve data from dicomserver.co.uk and I am able to query and kind of retrieve data. A repeated retrieve even tells me that existing files are overriden. At least that is what the console output tells me. But where are the retrieved images supposed to be stored? And shouldn't the retrieved images appear somewhere in the DICOM editor?

To make our live a bit easier. I would say it is a data problem ;).

oh so I forgot to send it: But this is, what my browser had cashed: "Yes, so I recently tested it, with the current release."
But also, if I remember correctly, this was due to the Phantom dataset we have as the default dataset:
I removed a few slices at the end, and now it is working.

@gaoh Ping

Could be the same issue like in T28816: [Segmentation] "New Segmentation" dialog to small

We have to check if the property is applied or the reason for no difference is that the rate is to small.

@a178n Could you check if the error still exists as soon as T29185 is landed?

Ok, I got it working as well. Thanks!
We can mark it resolved.

In T28808#238579, @a178n wrote:

I expect a circle in the cross-hairs, akin to Shape: cross or vertex. But there is None. Is this expected behaviour?

@gaoh Would you be so kind and verify that the problem still exists? Thanks.

I expect a circle in the cross-hairs, akin to Shape: cross or vertex. But there is None. Is this expected behaviour?
@s434n is right. Vertex is almost invisible although exists.

still valid?

Just had a talk with @kalali :

• yes loading is a problem, I don't know whether that was also a problem back then. The multilabel segmentation utilities does not allow to select multilabel images
• the main problem still persists: I cannot select a layer and a label that I want to modify with the plugin (this selection needs to be possible for all selected label images). In this particular case I wanted to add a small fraction of label_image_2_layer1_label1 to label_image_1_layer1_label1 using the 'union' tool

@kalali told me that adding this functionality seems to be already on your (Stefans?) todo list, so everything is great :-)
From my side there is absolutely no time pressure to solve this as we were able to run the required steps with a simple python script instead

will be covered by Flowbench in conjunction with T29157.

this is partially alread covered or will be covered by T29159.

Hi there! 🙂

Hi there! 🙂

Hi there! 🙂

Hi there! 🙂

@kislinsk Do we want to close this task, because of 2ef49f51d547?

I was not able to reproduce this problem anymore - should be solved with the mentioned task above. I will close this now, let's keep an eye on the correct (de-)activation of the segmentation tools.

@kislinsk Do we want to close this task, because of 2ef49f51d547?

Correction to my previous comment: all options are rendered. The only thing is, that the "Vertex" option is hardly visible because it is so small in the 2D views. Since the vertex does not change size with the scale property, I would assume this is by design.

Trying with Windows 10 as well as Ubuntu 20.04, I can only reproduce the option "Vertex" making problems. Everything else seems to work, but this option is not shown in any of the 2D views, only in the 3D view. I used openMeAlone.mps and PointSetForPic3D.mps.

@isensee Ping!

Is it now solved with the new release and ITK 5.x?

Are we keeping Watershed for the next release? I'm currently testing it because of T28641: [Segmentation] Improve Watershed tool documentation and it just stops at 59%.

I tested with MITK v2021.10 and the current state of develop and have the same behavior as @kalali: unconfirmed 3D interpolated surfaces (and contours) are drawn in green. To me this also looks like what is expected from the checklist.
I also get the <segmentation-name>_3D-interpolation node.

I tested this with the recent branch of D601 and with MITK 2021.10 and for me the 3D interpolated surface is drawn in green. Also I didn't find the wort "red" in the segmentation interpolation checklist. Can someone verify, e.g. @s434n?
The code in QmitkSlicesInterpolator::QmitkSlicesInterpolator clearly states m_InterpolatedSurfaceNode->SetProperty("color", mitk::ColorProperty::New(SURFACE_COLOR_RGB));, with float SURFACE_COLOR_RGB[3] = {0.49f, 1.0f, 0.16f};.

This task will be invalid after T28142: [Segmentation] Remove plugin redundancy with MultiLabelSegmentation is done, if the assumption by @kislinsk holds true.
Meanwhile a fix for image validation should have already been merged, see D533.

In T28886#232894, @kalali wrote:

Please check if the problem persists now with T28903: [Segmentation] Monitoring of segmentation nodes in views is error prone/ not safe. merged into develop.

Please check if the problem persists now with T28903: [Segmentation] Monitoring of segmentation nodes in views is error prone/ not safe. merged into develop.

@isensee Could you give some information regarding the question (see comment above) . Thanks.

Is this still a valid issue?

Found the problem in the code. Will be solved by T28903

Yes, sorry I didn't highlight it ;):

can you provide the files necessary to reproduce the problem outside of a container? (so at least image, seg and the scene file you generate automatically, and the call of MITK Workbench you use.)

Please someone have a look at this task and try to understand / reproduce what is happening here.

Identified the problem. The dicom data uses the temporal position (0020,0100) tag and associated tags to encode the "temporal"/spectral axis. This is a valid approach for MR images but yet not supported by our reader (currently only acquisition time and trigger time are interpreted). To make such kind of data properly readable we also have to support temporal positions.

Lowering the priority since it is hard to reproduce without any more information and terminal/console output. I am sure that somehow these obscure tools can be forced to crash independent of the hardware. An unsolved question from last release is still: do we want to keep these tools anyway since they are basically unusable for any user and even developer with code insight.

I cannot reproduce it with the latest Windows snapshot installer. I used Pic3D.nrrd + RenderingTestData/PointSetForPicD.mps.

The level window widget really is too cryptic and has too many hidden features and behaviors. At least we need to clarify how it is working / applied currently and what we would expect. With multiple data sets there won't be an optimal solution that pleases everyone as us is dependent on taste/workflow.

it still is very relevant and I have a master student working on the project right now. Is there a chance to contact you directly via Email?

In T28320#229111, @kalali wrote:

@floca, should we also add this for the upcoming release?

@floca, should we also add this for the upcoming release?

If the issue is still relevant and the missing information is provided, we can revive the task.