- User Since
- Aug 1 2016, 12:10 PM (330 w, 4 d)
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
@kislinsk I think rMITK4f70ab9c4b4c47355f6cb725c48b8d3b3da81983 fixed it , but maybe you could just update to 1.2.4 instead of the hash. Or would this be something that could/should rather be done in a general "minor updates on all toolkits" task? Then this one could be closed resolved.
Ok, sorry, forgot to mention: the original issue seems to be resolved, tested using the latest snapshot https://www.mitk.org/download/ci/snapshots/Windows/MITK-snapshots_2021-04-30-windows-x86_64.zip
Given the dynamics of RACOON where this initially occured I would suggest to update dcmqi even to a more recent version. and if I understood correctly there were fixes to DCMTK as well related to DICOM SEG which originated from a MEVIS report, and could be adopted to choosing a patched DCMTK from the commontk organization on github.
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
Changes have landed . @neher could you test again using a nightly build?
Just submitted a Differential
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
I contacted dcmqi upstream, thanks @fedorov for the quick reply.
PS: Chrome upload works but data doesn't show up in meta
Nov 30 2020
I tested with the latest develop:
WARNING: SliceThickness is present and is 1. using it! ERROR: JSON parameter file could not be parsed! You can validate the JSON file here: http://qiicr.org/dcmqi/#/validators Exception details (probably not very useful): LargestUInt out of Int range #11.518# ERROR: An error occurred while reading the DICOM Seg file: JSON Exception: file could not be read. #11.520# ERROR: Unknown read error occurred reading /home/nolden/Downloads/Lungs_seg_Left lung_1.dcm
Nov 27 2020
Nov 26 2020
I can confirm this fixes the issue, I can merge it tomorrow