In T26451#186376, @jsolislemus wrote:

Apologies, but I am not sure I understand your first questions, but given your last statement:

No problem. A now fixed typo made it hard to understand.

OK. But we definetly should talk about it before it is approached.

@kalali: Sharp eyes and good work. As far as I can see this is a proper solution to fix a state a had not covered in my implementation. The handling of invalid timepoints is still okay. As the documentation only guaranties that negative invalids will be 0. For all others there are no garanties and developers use GetTimeBounds() to check wether they request legal time points or not.

In T25804#185436, @kalali wrote:

This would be necessary if we want to use the render window manager with the mxnmultiwidget and the mentioned task (T25483).

Hm, ok. Then the log output is somehow inconsistent, with what is loaded into the workbench.
@kislinsk How do one enforces the more detailed log? The loging console is capable to show more information then given in the atached log.

In T26451#184491, @jsolislemus wrote:

(1) Using the Open File button -> Selected the (autoselect) -> NOT clicking on "apply the same to the remaining files" (file MitkWorkbench_MRIreadeAutoselect.log and looking as in the screenshot attached). The images were loaded individually, and not as a single dicom.

Regarding this workflow: I have another question. How many files did you select in the dialoge? One file of the stack as selection would be sufficient.

@jsolislemus Thanks for the info. If I understood it correctly also the official installer shows this problem. Could you please do me a favor and check with the official installer if you have the same loading problem, if you do not use the DICOM browser, but instead the normal file open dialog or dragNdrop. With this information we can narrow it down a bit more.
Thanks.

It would be helpfull to see the log output in order to see if a different reader configuration was choosen and which. Please activate the log window and check the out put of the read process.

@kompan : Thanks! I think we should remove the arxiv version, as the final paper is open access to. Thanks.

@steint I think I would have made it slightly different, but this is more a case of tast than hard facts (at least I have no good arguments against it right now ;).
So bottom line: We should go with the changes. Thanks. If we learn that something is missing, nothing stops us to revisit and refactor.

@kompan: Could you be so kind and take care when you have some time left? Thanks!

@kompan: Could you be so kind and take care when you have some time left?

@kislinsk Shouldn't we raise priority, if we run otherwise in a licesnsing gray zone?

In T26029#181806, @kausch wrote:

I merged it, we only pushed the branch

It affects every branch that containes the ModelFit module and tries to build it with VS 2017 >=15.9.11

Result of the discussion:
At the current state we voted against moving to core.

Result of the discussion:

Code coverage can be checked now.
And everything is setup up to use it with codecov.io

I think it would be nice but is no show stopper, because we could, as a work arround, use a chartline that only contains the highlited point(s).

Without a fundamental rework of the rttb build mechanics the only way to sooth the problem is to explicitly check if all prerequisits are fullfilled and if not give a meaningfull cmake error message.

@hentsch / @kislinsk : Shouldn't we already set QmitkPlotDialog/QmitkPlotWidget/QtHistogram to deprecated then. To give us sooner then later the posibilite to realy remove the code from the codebase. If I see it correctly, that would also gives us the possibility to reomive Qwt as a third party package from MITK. What do you think?

Pushed new branch T25941-Improve_mapper_view_user_manuel.

@kislinsk Thanks for the hint.

I have concerns with the latest commit. See comments there. You can come by and ask if you have any questions.

The fix is not good and has several problems. See comment above. If it is not clear how to handle it properly, just drop by an I can explaine.

@kislinsk Stefan, you said you reworked this pragma for MITK? Does it implie any changes for 3rd party projects?

Pushed new branch T26287-Perfusion_crash_when_converting_signal.

It seems to beeing correlated with the addition of the generated concentration node to the data storage. If the nodes are not added to the datastorage, I cannot provoke a crash. This is at least concistent to the finding that there is also no proplem if we calculate the concentration beforehand.

Narrowed down the point where it crashes.

Pushed new branch T26265-Connect_error_multinodeselectionwidget.

Pushed new branch T23808-Image2ImagePropertyRelation.

😄

Can you reproduce your problem now with the fix, that helped me out?

Pushed new branch T26219-Crash_by_selection_widget_after_close_project.

Found it.

OK, I have narrowed it further down.

@kalali @kislinsk , added you two has you have some experience with at least either rendering/mapper or selection concept. May be you have additional ideas.

The problem occured in context of selection widgets and may be could be patched for selection widgets in context of T26218.

This assumption was incorrect :(. Even if the widget properly release the node if it is deleted the problem still occures?!?