- User Since
- Aug 1 2016, 12:10 PM (383 w, 6 d)
Aug 2 2023
I had a look as well: two voxels is really an edge case, given the current method it would only give a correct result for number of bins == 1 . But setting the number of bins to at most (number of voxels - 1 ) doesn't really help, it fails e.g. for three voxels. In general thinking a bit about it I came to the conclusion that limiting the number of bins (currently it's _minimum_ 10) would still not yield a correct median.
Jul 12 2023
Jun 22 2023
there is a DerivePointerAlignment option which basically unifies it on a file by file basis, in case there is no agreement. But I agree to Ralf with using the "left" style and put it next to the type
Mar 19 2022
Mar 17 2022
Just observed the same problem with latest "develop" of today.
Oct 14 2021
I found one last hint, about a possible interference with ccache , last try ...
I tried several things again, similar to described above, same situation.
Oct 5 2021
Jul 21 2021
Thanks Hanno. I think @schererj is the original author, so maybe he can comment or we discuss it in the meeting.
Jul 1 2021
So this task as an _evaluation_ task has a high priority in my opinion. If it turns out to be a bigger thing to replace please stop and we should discuss again
If this is not a big deal, i.e. if it really works after switching to the replacement there would be a big benefit. So it would be great if someone could at least try it and report some results, like how much work it would be. After that we could decide how to prioritize, but from my understanding it would make our Kaapana license task much easier
Jun 28 2021
Jun 22 2021
Jun 21 2021
Jun 8 2021
Jun 3 2021
This seems to be still an issue. Maybe there is new information out there or it could be re-tested with newer Windows versions / drivers?
May 17 2021
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.
May 14 2021
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)
May 10 2021
May 7 2021
May 6 2021
May 5 2021
Maybe something to keep an eye on: T28478 and https://github.com/InsightSoftwareConsortium/ITK/tree/master/Modules/ThirdParty/DCMTK
Apr 29 2021
Apr 21 2021
Apr 14 2021
@kislinsk thanks for taking over. The WIP stuff I put on github still could be useful, see comment above. let me know if I can help.
Apr 1 2021
Mar 25 2021
The topic came up in the Kaapana tech meeting again, because the current situation is causing problems there.
Mar 15 2021
Not sure if this is related:
@gaoh thanks for pointing there, I will close this one as a duplicate
Another option for testing is to use dicomserver.co.uk , I think it is preconfigured in the Workbench. It's a public DICOM endpoint and the data there differs, but 5 min ago I was able to reproduce the crash with a retrieval from there. Just activate the checkbox in the MITK config table , query last month, select a few patients and retrieve. Worked for me to reproduce the crash.
Mar 12 2021
Feb 19 2021
Interesting catch. There is no call to regex_match in our code. If I understand it correctly the stack object is just created to check if an exception happens during construction, but maybe this is just another variant of the issue described for the library. A possible workaround could be to explicitly create and destroy the regex objects in our code, with explicit exception catching and re-throwing.
@norajitr maybe a bit more background on the ticket for you:
Feb 18 2021
I would like to have files versioned / with different names. If it's necessary to have a download link that doesn't change I can help with a script to create a "latest" link, had that for MITK nightlies back in the days
Feb 12 2021
Feb 10 2021
I tried running the Workbench on Linux both with valgrind as well as AdressSanitizer. Unfortunately there is a lot of noise from memory leaks and stuff, but I did not spot anything obvious which could be the cause.
Feb 9 2021
I did not dive into Windows APIs, so I just hope you know what you are doing ;)
I did some Googling, it seems that starting with 2019 release, Windows 10 has a UTF8 mode. It's a bit difficult to enable: "old" control panel -> region -> Administrative settings -> Change System locale -> Enable UTF8
That's a thorough dive in the topic ... Yes, toUtf8(), and nicely prints the correct Umlaut in the message box, telling you the file doesn't exist ;) I only had a quick glance around, and since a lot of stuff goes though ITK, and ITK decided to stay with local 8bit as far as I understand, I also think this would be the way to go. But I could really live with declaring this a "Known issue". Maybe something on the application user level would be nice, like
if toUtf8 != toLocal8Bit then show error
Feb 8 2021
Ok, the GDCM unicode windows fix was introduced in the 3.0 series: https://github.com/malaterre/GDCM/commit/d4dfa144b941c6cc4da87f9795f7f5aba2bb7481
Ok, I did look around a bit more. To summarize, I guess going for the "local 8bit representation" seems to be the most feasible way, since ITK also assumes this and I think we have a lot of ITK file handling code.
Ok, I debugged to SetFileName @floca mentioned, it gets called from GDCMImageIO::InternalReadImageInformation in ITK
Mostly as a reminder I tried on top of the branch above:
Oh no, I can remember similar issues with German Ubuntu and "Arbeitsfläche" ... Basically, CI clients should probably always have a path compontent like /bäh / included to catch new issues like this one, and build system stuff, which is also a candidate.
Feb 5 2021
I don't know why this was not linked automatically: https://phabricator.mitk.org/D469
I was hoping a bit to include it in the release, if the release would e.g. be used for kaapana containers for a longer time this could be helpful at some point. But of course it's not strictly necessary.
Valgrind shows some reading beyond memory boundaries, around mitkCoreActivator.cpp:129 and 218. Since it is the last line of all the AddPropertyPersistence calls there and all the creating of temp objects in there, I was wondering if it could be some reference to deleted temp objects issues. Just an idea.
It's the CoreActivator if I read this correcty:
And I just tested: as expected the unit tests do pass, I think it has to be a side effect of dlopen'ing the activator
@floca the comment I mention was written by you, line 112, any spontaneous idea?
In addition, suppressing deprecation warnings is in most cases no solution that lasts forever
Feb 1 2021
Jan 27 2021
Additional comment: the missing library doesn't prevent the Workbench from starting, but some/all DICOM functionality is missing which can be confusing
Ok, I just re-checked: Ubuntu 20.04 still has librwrap installed , so installer works. For Fedora there is no workaround , so either
Jan 25 2021
Jan 21 2021
@kislinsk anyone from the MITK CI team who could take over?
Jan 19 2021
Jan 15 2021
Thank. New command-line interface looks nice, but the challenge is where to put the credentials, especially if you want to put the script open source like in the Kaapana dockerfiles.
Jan 14 2021
Dec 2 2020
PS: Chrome upload works but data doesn't show up in meta
Nov 27 2020
Nov 26 2020
I can confirm this fixes the issue, I can merge it tomorrow
Nov 24 2020
Nov 23 2020
I can confirm this patches fixes the problem. @kislinsk : hotfix oder feature branch?
diff --git a/Rendering/FreeType/vtkFreeTypeTools.cxx b/Rendering/FreeType/vtkFreeTypeTools.cxx index c54289dc60..03b899c4da 100644 --- a/Rendering/FreeType/vtkFreeTypeTools.cxx +++ b/Rendering/FreeType/vtkFreeTypeTools.cxx @@ -378,8 +378,7 @@ FTC_CMapCache* vtkFreeTypeTools::GetCMapCache() }
Nov 17 2020
Oct 20 2020
Ups ;) Replace with - or _?
Oct 19 2020
I was just about to add a note that there is the general question how to handle python in installers. I guess for just having the basic runtime available it would be ok to just load libpython3.so or libpython3.8.so and let the system take the right one from the right path. But on Windows I guess most people don't install Python in system locations. Anyway I think this could be fixed even with the current packaging if we need it for 2020, but I'm just reporting, no pressure from my side ;)