User Details
- User Since
- Aug 1 2016, 12:10 PM (453 w, 3 d)
May 6 2022
May 4 2022
I don't think this was finished / merged yet.
Feb 17 2020
Pushed new branch T27138-AddWidespreadCaseToHummelProtocolEvaluation.
Aug 30 2019
Looks like one solution to the problem. For the other tracking devices, however it seems to be solved by adding the line
May 27 2019
Apr 17 2019
Apr 14 2019
Apr 13 2019
Pushed new branch T26277-PhantomBasedUSCalibration.
Feb 19 2019
Feb 15 2019
Thanks for looking into this. Keep in mind that we should still keep the current implementation to grab images as it allows to grab far more than only from the Epiphan frame grabber. Once the feasibility of using the SDK is shown, we should think of integrating it as a separate video source that is dependent on the specific Epiphan SDK.
Thanks for this contributions! It seems there are some open issues regarding exception handling in the NDITrackingDevice.
Merged pull request as discussed on https://sourceforge.net/p/mitk/mailman/message/36525424/
Pushed new branch T26001-Replaced_GetLastError_for_ERROR_VALUE_in_Windows.
Aug 9 2018
This should be re-investigated. Not clear yet why a detection of a sudden change in coordinate values is not possible.
Detection of unplugging the sensor / the field generator is an important security feature.
Aug 3 2018
Jul 9 2018
Jul 6 2018
Pushed new branch T24893-ProvideReinitOptionInImageCropperForNonAxisAlignedGeometry.
Jun 28 2018
Jun 22 2018
Saving of tool axis should work now. @aguilera can you verify that behavior and test the correct application of the tip and axis when tools are loaded?
Pushed new branch T24909-CalibratedToolAxisNotSaved.
Pushed new branch T24910-ToolAxisCalibrationCrashAlpha.
Jun 15 2018
Added the missing check. @aguilera Can you test if it works for the use case with Aurora / Polhemus as well?
Pushed new branch T24910-ToolAxisCalibrationCrash.
Jun 5 2018
Both of these problems seem to be related to using the independent plugins USSupport and TrackingToolbox for an application specific workflow. The visualization is optimized for the data provided by these plugins (US images or tracking tools) to ensure that the views are initialized such that the image or tracking data is completely visible. The behavior is thus expected for a rather general purpose application such as the MITK workbench.
May 17 2018
I compiled the final MITK-IGT release notes to be mentioned upon release:
May 11 2018
May 8 2018
Pushed new branch T24750-GUIIssueNDIAuroraWidget.
May 7 2018
May 4 2018
May 3 2018
From my discussion with Patmaa earlier, it seems reasonable to decrease the image size as specified in the tags of the svg files (which is often huge e.g. 1792x1792 for arrow-down.svg in QmitkWidgetExt). Upon loading these images as e.g. button icons, Qt allocates memory for the specified size each time a widget containing this button is loaded regardless how they later appear in the GUI. Descreasing to e.g. 200x200 should still be sufficient for button icons even on high resolution displays.
May 2 2018
Pushed new branch T24744-TypeMismatchesInCLUtilities.
Apr 30 2018
Pushed new branch T24733-WarningsInTrackingToolbox.
Apr 27 2018
Pushed new branch T24739-FixTofUtilRenderWindowAnnotations.