- User Since
- Aug 1 2016, 12:10 PM (77 w, 2 h)
Thu, Jan 18
Fri, Jan 12
It is now possible to load and save a BaseData-object. This required the following changes:
- Wrapping the mitk::BaseData : In Order to be able to handle these types of Data
- Helping SWIG dealing with Vectors: IOUtil::Load returns a vector of BaseData. Therefore swig had to know how to handle those vectors. The way to do it is to include std_vector.i in the i-file. Then all instanciations of std::vector<a> needs to be initialized using a %template construction. Did this so far for BaseData and the standard c types.
- Wrap itk::SmartPointer: While IOUtil::Load returns SmartPointers, IOUtil::Save requires Basic Pointer. It is therefore necessary to be able to handle the Smartpointer-Structure directly from python. Luckely, Swig has the ability to wrap Smartpointers rather easy. I.e. it detects overloaded -> Operators (as for our smartpointers) and wraps the functions calls directly so that there is nearly no difference between Natural Pointers and Smartpointers within the scripting language. It further allows to access all SmartPointer-methods. For more information refer to the links at the end.
- mitkIOUtil, mitkBaseData, and itkSmartPointer do contain some macros. As only parts of the C++ code are evaluated in order to create the Scripting interface, it is neccesary to redefine these macros (either fully or as "dummy" version).
Updated current implemented. Successfully wrapped mitk::IOUtil , but there are still some bugfixes, workarounds. The most limiting so far are:
- Saving is not possible, because mitk::IOUtil::Load () returns a Smartpointer, while mitk::IOUtil::Save expects a standard pointer.
- The Include-Path for mitkIOUtil.h is hard coded right now. It is necessary to add this include-path to the swig-file. I added it as a hard-coded command as a workaround. Better solutions might be possible / need to be evaluated.
Thu, Jan 11
Solved both problems:
- The created project must have the same name in cmake and the corresponding .i - file.
- A .py-wrapper is created in the folder MITK-build/Wrapping/Python (for windows). Copy this wrapper file to the library folder (Where the pyd -object is)
- Execture steps 1-3 from above. The module can then be loaded without the the underscore, for now it is PythonMITK.
It is now theoretically possible to load the created module:
Pushed new branch T24046-SwigBasedPythonWrapping.
Tue, Jan 9
Mon, Jan 8
Dec 6 2017
Nov 15 2017
Sep 20 2017
Aug 11 2017
Aug 10 2017
Aug 9 2017
Merged Screenshot Tool
Pushed new branch T22687-AddResamplingAndMaskCleaningGUI.
Pushed new branch T19480-IntegrationOfBugfixesForRadiomics.
Aug 8 2017
Aug 7 2017
Jul 13 2017
Jul 6 2017
Jul 3 2017
Jun 28 2017
Jun 27 2017
Apr 11 2017
Pushed new branch T19600-ActiveLearning-WindowsFixes.
Apr 10 2017
Created a BasicImageProcessing Module that contains Basic Imaging MiniApps.
Moved Dicom2Nrrd into this module from Diffusion as it is not diffusion-specific.
Pushed new branch T22714-Dicom2NrrdIntegration.
Apr 7 2017
Apr 3 2017
Thanks for the hint, but I need a simple GUI-solution to keep the support-effort as low as possible. It will also be handy for my own experiments.
Mar 31 2017
Mar 22 2017
Jan 16 2017
Jan 13 2017
Jan 12 2017
Jan 11 2017
Jan 9 2017
Dec 23 2016
Dec 21 2016
Nov 29 2016
Nov 25 2016
Oct 20 2016
Oct 13 2016
Sep 16 2016
Pushed new branch T19480-BugfixesForRadiomics.
Sep 14 2016
Aug 2 2016
Bug is caused in line 95 of mitkLabelSetImageConverter
[fe81df]: Merge branch 'bug-19265-CreateSceneSerializerForLabelSet'
2015-08-25 14:50:26 Michael Goetz [9f767e]
COMP: Removed test that is no longer possible due to low-level writer
[668adc]: Merge branch 'bug-19265-CreateSceneSerializerForLabelSet'
2015-08-25 13:49:46 Michael Goetz [eaf4e1]
Moved Data structure to autoload submodule and removed old .lset extension
[5b5887]: Merge branch 'bug-19263-SegmentationContinuedAfterRestart'
2015-08-25 16:15:29 Michael Goetz [066ee1]
Added LabelSetImage support to statistics
Found a bug in statistic bundle. It was not possible to use it with LabelSetImages. Fixed this too.
I don't think that this bug is related to T14652. Although 14652 helped to detect this bug, it contains rather cosmetic changes and does not influence the rendering behaviour.