In T28127#217604, @gaoh wrote:

@floca I might have found a dataset, where even the new number is not enough:
P:\Gao\mitk-testdata\

Hm, interesting... I say we but it under the category experience and close that chapter. If it reoccures we see how to handle it. Thanks for investigating it.

In T27498#217438, @kalali wrote:

I just came across this again:
For me the following happens:

1. I open the MITK workbench
2. open the Segementation View
3. below the image selectors a warning Please select an image is shown
4. both image selectors show a red warning
5. I open an image e.g. US4DCyl.nrrd
6. the warning below the image selectors changes to Select or create a segmentation
7. both image selectors still show a red warning
8. the image is not automatically selected

In T27703#217487, @kalali wrote:

Is this solved?

As far as I have described above, yes.

In T28039#217080, @kislinsk wrote:

I set the GIT_TAG of DCMQI locally to v1.2.3 and I can confirm that the data from above can be loaded.

OK, then increasing the DCMQI version to 1.2.3 before our next release seems to be the most sensible fix, doen't it?

In T28127#217365, @kislinsk wrote:

It depends. NODE_PREDICATE_GEOMETRY_DEFAULT_CHECK_PRECISION is only for checking in predicates;

As long as nobody has missused it so far, it is just used for that. ;) At least I have introduced it with this purpose and only used it there.

In T28127#217306, @kislinsk wrote:

1e-5 should still be conservative enough for the purpose of geometries.

Is your statement also valid for 5e-5? Beause 1e-5 would not be enough in that case.

The problem seems to be that DCMQI rounds the the orientation matrix values at the 5th decimal place when storing to DCM Seg.

Pushed new branch feature/T28118-Refactor_SegTool2D_and_derived_classes.

Ok. Found the problem. Should now be fixed with the new diff. At least it works on my PC now with the test files.

@fedorov Happy new year and thanks for keeping us up to date!

Will be fixed (is fixed already) by the rework done in T28118.

In T28118#216794, @kalali wrote:

Looking through the checklists I found that the 2D tools of the segmentation view are different than the 2D tools of the Multilabel segmentation (one more: Fast Marching is missing).

What do you mean with different. Different in there behavior or a different selection of tools.

In T28113#216778, @kalali wrote:

I haven't made up my mind about the best way to go, I'm open for suggestions. I just wanted to state that even the checklists state something different. So to align the tests with what the workbench actually does, we should clarify, how the tools actually behave or should behave.

In T28113#216776, @floca wrote:

• If the tool is deactivated (explicitly, by selecting another tool, by closing the view) all unconfirmed contours will be removed.

And this is not the case right now. Currently, a mask will be generated and drawn into the image.

Regarding the issue itself: I think it is a fundamental question of the capability of the tool. Auto confirm when closing the contour would
Pro: be a faster UX
Contra: won't allow to alter live wires before confirmation.

In T28113#216737, @kalali wrote:

I just found out that the Checklists also states the following:

Deaktiveren des Live Wire Tools
  Tool Icon verschwindet vom Mouse Cursor
  Die gelben Konturen werden weiterhin angezeigt, können aber nicht mehr bearbeitet werden

So even the experienced behavior does not fit the checklist test. We should clarify which workflow we want to provide.

Will be fixed (is fixed already) by the rework done in T28118.

Which node is it? you can look up the name if you look into caaaaa.xml

could you provied (e.g. via nextcloud) such an invalid scene file?

Do you have still problems with crashes? If yes, this is almost certainly not due to the GenericProperty thing, as they have no relevance for dose visualization and scenes without dose do not crash but also cannot load the GenericProperty.

Closed. @neher or who ever might stumple upon the prolem again, is welcome to open it again and provide data. :)

@neher or @jaegerp can someone provide test data? Otherwise I would close this task for now, because I cannot check or reproduce the problem without data.

Can D447 landed and this issue closed? If nothing speaks against it, it would be good, before I turning the rest of the seg tools upside down. Thanks.

@thomass This is the issue we talked about last week when you hat problem to use predicates to find some nodes by DICOM tags values.

1. Could you provide also a SS example. As it should also work with SS and I would like to know the reason.
2. A MAC version will be available with the next public MITK release (planned for next january).
3. Thanks for the example data. I have some questions regarding it:
   • a) acquesition 2592 containes 2 slices (with 21 time points/frequencies each). Is it meant to be one volume with 2 slices or are the 2 series but due to a multple slice sequence packed into one folder?
   • b) what is the list.txt (see https://phabricator.mitk.org/w/mitk/cest/cest_user_manual/#list-txt-frequency-offsets-%CE%B4%CF%89) you used so far?

@thomass Please check the patch provided by https://phabricator.mitk.org/D449. It should solve you problem I hope. Would be cool if you could give feedback.

@kompan What is the status here? Is it finish. If not, what has to be done to close it. Should be done before we make a release in january and if much is left, we should know what to do. Thanks.

@kompan Is this still open? You marked it in your report list as "in usage" or did you ment something else with "statsitical analysis of 17O data"?

@makr Could you please let us know:

1. if the problem still persists
2. What OS do you use?
3. Could you provide any kind of example data for us to reproduce the error?

@makr Sorry for not responding directly. I was not aware that the comment section was open and I was not subscribed to the document thus recieved no notification. I hope you are still interested. I moved the issued to T28089. Would be great if you could have a look and give feedback. Thanks.

In T22412#215903, @kalali wrote:

In T22412#93426, @goch wrote:

This crutch should be removed when redesigning the tools.

@floca I stumbled upon this and I was wondering if this crutch can be removed with the changes made in T27490.

May be. We would need to test it.
@neher do we have suiteable testdata?

Thanks. No it works again.

thanks for taking care. ❤

Unclaime as I currently have no time to work on it. Will take on it again, if I have time or some else;)

Thanks for the answers!

@gaoh Could you please specify which PACs you used to provoke the error. Or did it have this problem with multiple systems?

• Regarding 1: This is done to ensure that you are notfied if a problem arrises in the dcmsend step?
• Regarding 2: Do we have a test to verify if the problem still exists before we go into production with this? @gaoh: Was this a problem on the CTP side or on the DICOM4CHE side? So, did also other PACS like orthanc had the same problem?
• Regarding 3: This road I would only go, if we also have a test suite ready to benchmark the performance and to ensure that we don't have the same problem problem. What kind of reciever would you use here.

@thomass could you check if the problem was realy just cuased by slow network drive and is solved. If this is the case, could you close the task? If the problem still exists, may be the issue solved by Stefan is a solution.

@gaoh could you check if the problem is solved either with the branch or as soon as it is in develop?

I would see it positiv. No sense crying over spilt milk. Thanks for solving that problem!

🤞

I do not activly work on that issue.

Could it be that the test time out time is 600 sec? Because in the last month all tests runs of LabelSetTest with worked (as long as the duration was below 600 sec). All failed tests took longer then 600 sec.
For what ever reason under win the test is relativaly fast ~150-200 sec. Under linux/mac it is lurking arround 590 sec +- 25...

@kalali was ist still an open issue?

Still needed

@kislinsk do you have an opionon which option to choose UX wise?