User Details
- User Since
- Aug 1 2016, 12:10 PM (233 w, 3 d)
Yesterday
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.
Tue, Jan 19
As far as I have described above, yes.
OK, then increasing the DCMQI version to 1.2.3 before our next release seems to be the most sensible fix, doen't it?
Mon, Jan 18
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.
Is your statement also valid for 5e-5? Beause 1e-5 would not be enough in that case.
Sun, Jan 17
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.
Sat, Jan 16
Mon, Jan 11
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!
Sat, Jan 9
Tue, Jan 5
Will be fixed (is fixed already) by the rework done in T28118.
Mon, Jan 4
What do you mean with different. Different in there behavior or a different selection of tools.
Dec 22 2020
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.
Will be fixed (is fixed already) by the rework done in T28118.
Dec 17 2020
Dec 16 2020
Which node is it? you can look up the name if you look into caaaaa.xml
Dec 15 2020
could you provied (e.g. via nextcloud) such an invalid scene file?
Dec 14 2020
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. :)
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.
Dec 13 2020
- Could you provide also a SS example. As it should also work with SS and I would like to know the reason.
- A MAC version will be available with the next public MITK release (planned for next january).
- 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?
Dec 10 2020
@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.
Dec 9 2020
@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.
Dec 8 2020
@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:
- if the problem still persists
- What OS do you use?
- Could you provide any kind of example data for us to reproduce the error?
Dec 7 2020
May be. We would need to test it.
@neher do we have suiteable testdata?
Dec 4 2020
Thanks. No it works again.
Dec 3 2020
thanks for taking care. ❤
Dec 2 2020
Unclaime as I currently have no time to work on it. Will take on it again, if I have time or some else;)
Nov 30 2020
Thanks for the answers!
Nov 28 2020
@gaoh Could you please specify which PACs you used to provoke the error. Or did it have this problem with multiple systems?
Nov 27 2020
- 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.
Nov 24 2020
@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!
Nov 23 2020
🤞
I do not activly work on that issue.
Nov 22 2020
Nov 16 2020
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...
Nov 11 2020
@kalali was ist still an open issue?
Still needed
Nov 3 2020
Nov 1 2020
@kislinsk do you have an opionon which option to choose UX wise?