Slicer merge requestshttps://gitlab.kitware.com/sjh26/Slicer/-/merge_requests2017-05-05T23:55:09-04:00https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/722BUG: Update Volume loading logic to consider default nodes properties2017-05-05T23:55:09-04:00Sam HorvathBUG: Update Volume loading logic to consider default nodes properties*Created by: jcfr*
This commit enables customization of the LabelMapVolumeDisplayNode
attributes by ensuring the custom properties set on the corresponding
default node are effectively re-used.*Created by: jcfr*
This commit enables customization of the LabelMapVolumeDisplayNode
attributes by ensuring the custom properties set on the corresponding
default node are effectively re-used.https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/628BUG: remove deprecated DICOM SEG export from Editor2016-11-21T21:22:59-05:00Sam HorvathBUG: remove deprecated DICOM SEG export from Editor*Created by: fedorov*
This functionality depended on now deprecated and non-existing functionality in
the Reporting module. The updated version of the Reporting module uses dcmqi,
https://github.com/QIICR/dcmqi, for DICOM SEG conversi...*Created by: fedorov*
This functionality depended on now deprecated and non-existing functionality in
the Reporting module. The updated version of the Reporting module uses dcmqi,
https://github.com/QIICR/dcmqi, for DICOM SEG conversion, which in turn has an
interface different from what is used in this implementation.
DICOM SEG export will be provided in the updated Reporting extension, which is
reusing Segment Editor components for editing. It is possible that this export
functionality will be available in the main application in the future.Steve PieperSteve Pieperhttps://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/605BUG: ExtensionBuildSystem: Update tests to illustrate #4247 failure2016-10-13T07:35:31-04:00Sam HorvathBUG: ExtensionBuildSystem: Update tests to illustrate #4247 failure*Created by: jcfr*
Issue report http://na-mic.org/Mantis/view.php?id=4247
```
$ ctest -C Release -R py_cmake_slicer_extensions
Test project /home/jcfr/Projects/Slicer-Release/Slicer-build
Start 7: py_cmake_slicer_extensions_index_...*Created by: jcfr*
Issue report http://na-mic.org/Mantis/view.php?id=4247
```
$ ctest -C Release -R py_cmake_slicer_extensions
Test project /home/jcfr/Projects/Slicer-Release/Slicer-build
Start 7: py_cmake_slicer_extensions_index_build_without_upload
1/4 Test #7: py_cmake_slicer_extensions_index_build_without_upload ............... Passed 7.05 sec
Start 8: py_cmake_slicer_extensions_index_build_with_upload
2/4 Test #8: py_cmake_slicer_extensions_index_build_with_upload ..................***Failed 12.53 sec
Start 9: py_cmake_slicer_extensions_index_build_with_upload_using_ctest
3/4 Test #9: py_cmake_slicer_extensions_index_build_with_upload_using_ctest ...... Passed 33.31 sec
Start 10: py_cmake_slicer_extensions_index_build_without_upload_using_ctest
4/4 Test #10: py_cmake_slicer_extensions_index_build_without_upload_using_ctest ... Passed 7.29 sec
```
To try to make sense of these test results, let's look at what is happening on the factory.
On windows, here are the steps
1. Every night "factory-south-win7.bat" [1] ends up invoking
```
`ctest.exe -S "C:\D\DashboardScripts\factory-south-win7-vs2013-64bits_slicerextensions_release_nightly.cmake" -C Release`
```
2. Then `factory-south-win7-vs2013-64bits_slicerextensions_release_nightly.cmake` is a CTest
script including [2] the generic driver:
`SlicerExtensionsDashboardDriverScript.cmake`
Note: that the test are also using that same generic driver.
3. Then, the driver script ends up invoking `ctest_start`, `ctest_configure`, `ctest_build`, .... [3]
4. That `ctest_build` calls end up building the "Regular" extension build project that is reported to fail above.
Still need to investigate ... to sort things out
---
[1] https://github.com/Slicer/DashboardScripts/blob/41593b8ec76c7f0aacaf44f9057431e89ed0fa6b/factory-south-win7.bat#L58
[2] https://github.com/Slicer/DashboardScripts/blob/41593b8ec76c7f0aacaf44f9057431e89ed0fa6b/factory-south-win7-vs2013-64bits_slicerextensions_release_nightly.cmake#L105
[3] https://github.com/Slicer/Slicer/blob/22d0074d67c21fd8c0c3b68bb0c284289bf01b10/Extensions/CMake/SlicerExtensionsDashboardDriverScript.cmake#L384
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/606BUG: ExtensionBuildSystem tests: Do not pass empty CMAKE_OSX_ARCHITECTURES2016-11-07T14:19:33-05:00Sam HorvathBUG: ExtensionBuildSystem tests: Do not pass empty CMAKE_OSX_ARCHITECTURES*Created by: jcfr*
Since it is valid to have build without an architecture explicitly
set (meaning no -arch x86_64 compiler flag), this commit do not force
an empty value in the CMakeCache.
Reported by: Nicole Aucoin nicole@bwh.harvard...*Created by: jcfr*
Since it is valid to have build without an architecture explicitly
set (meaning no -arch x86_64 compiler flag), this commit do not force
an empty value in the CMakeCache.
Reported by: Nicole Aucoin nicole@bwh.harvard.edu
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/579COMP: Fix windows compilation with Slicer_BUILD_PARAMETERSERIALIZER_S…2016-09-13T07:57:07-04:00Sam HorvathCOMP: Fix windows compilation with Slicer_BUILD_PARAMETERSERIALIZER_S…*Created by: vovythevov*
…UPPORT
The JsonCpp_LIBRARY needs to be passed to SlicerExecutionModel as a
CMAKE_ARGS because it contains the result of the ${CMAKE_CFG_INTDIR}
variable that needs to be evaluated.
cc: @jcfr, @lassoan
*Created by: vovythevov*
…UPPORT
The JsonCpp_LIBRARY needs to be passed to SlicerExecutionModel as a
CMAKE_ARGS because it contains the result of the ${CMAKE_CFG_INTDIR}
variable that needs to be evaluated.
cc: @jcfr, @lassoan
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/544Fix and test extension build system2016-07-07T23:22:48-04:00Sam HorvathFix and test extension build system*Created by: jcfr*
This topic will fix errors happening when building, testing or packaging extensions with dependencies.
It checks for the following:
- Generated description files are correct
- Submission to CDash are done
- Upload to...*Created by: jcfr*
This topic will fix errors happening when building, testing or packaging extensions with dependencies.
It checks for the following:
- Generated description files are correct
- Submission to CDash are done
- Upload to extension server are done
- CMakeCache.txt of built extensions contains expected variables (e.g _DIR variables, ...)
Remaining tasks:
- [x] Check list of requests done to mock server are the expected ones.
- [ ] Install packages extensions and check dependent one are also installed
Notes:
- To ensure the test run in reasonable time, extensions used in the tests contains only scripted module.
- extension sources used in the test are currently checked in the source (Testing/TestExtA, ...). I will revisit this to use the extension wizard.
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/530BUG: 2087 - Configuration of vtkSlicerVersionConfigure.cmake.in at bu…2016-06-13T17:58:42-04:00Francois BudinBUG: 2087 - Configuration of vtkSlicerVersionConfigure.cmake.in at bu……ild time.
vtkSlicerVersionConfigure.cmake was build at configuration time. As
reported in bug report 2087 [1], if one updates the source code of Slicer,
this file main not always be updated. This patch configures
vtkSlicerVersionConfig...…ild time.
vtkSlicerVersionConfigure.cmake was build at configuration time. As
reported in bug report 2087 [1], if one updates the source code of Slicer,
this file main not always be updated. This patch configures
vtkSlicerVersionConfigure.cmake at build time instead.
[1] http://na-mic.org/Mantis/view.php?id=2087
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/447BUG: Fixed the argument given to FileExists2016-01-19T22:59:53-05:00Sam HorvathBUG: Fixed the argument given to FileExists*Created by: ayamada0614*
The argument for FileExists function was converted from std::string to char type since FileExists requires const char\* argument. I failed to build Slicer application on OS X 10.10.5 by this part.
*Created by: ayamada0614*
The argument for FileExists function was converted from std::string to char type since FileExists requires const char\* argument. I failed to build Slicer application on OS X 10.10.5 by this part.
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/439BUG: Fix display node copy in CloneVolume2016-03-03T11:53:25-05:00Sam HorvathBUG: Fix display node copy in CloneVolume*Created by: agirault*
**Motivation**
If a volume is rendered through the Volume Rendering volume module then
cropped through the Crop Volume module, it is not possible to display the
volume rendering of the cropped volume: the original...*Created by: agirault*
**Motivation**
If a volume is rendered through the Volume Rendering volume module then
cropped through the Crop Volume module, it is not possible to display the
volume rendering of the cropped volume: the original volume would be
displayed instead.
**Reason**
In the Crop Volume module, the method `vtkSlicerVolumesLogic::CloneVolume`
was called. The volume and its first display node were cloned using
`vtkMRMLVolumeNode::CopyWithScene`, but the remaining display nodes were
ignored. This was resulting in having a cloned volume with references to
the original volume display nodes. In the case above, the display node of
type `vtkMRMLVolumeRenderingDisplayNode` was the same for the cropped and
original volumes, referencing the original volume for both of them.
**Fix**
In this commit only the first display node is cloned, and the other display
nodes are removed. Cloning a `vtkMRMLVolumeRenderingDisplayNode` would not be
as straightforward as copying a `vtkMRMLVolumeDisplayNode` since the display
node itself has a `VolumeNodeID`, a `ROINodeID` and a `VolumePropertyNodeID` that
would need to be created/updated.
This fixes the issue 4109: http://na-mic.org/Mantis/view.php?id=4109
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/438Cli infrastucture2016-01-06T17:31:36-05:00Sam HorvathCli infrastucture*Created by: vovythevov*
This pull request aims to solve issues when running CLIs from python.
The two cases that this solves are:
- Running CLI A and on CLI A completion, run CLI A another time.
- Running CLI A and CLI A in parallel.
...*Created by: vovythevov*
This pull request aims to solve issues when running CLIs from python.
The two cases that this solves are:
- Running CLI A and on CLI A completion, run CLI A another time.
- Running CLI A and CLI A in parallel.
This was previously addressed partially in pull request #358.
@pieper, @lassoan, @jcfr You looked at #358, would you mind looking at this one ?
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/435BUG: Fixed crash when calling widgetRepresentation().self()2016-01-06T13:10:42-05:00Andras LassoBUG: Fixed crash when calling widgetRepresentation().self()How to reproduce:
1. Go to endoscopy module (just an example, the behavior is the same for every scripted modules)
2. Copy-paste this into the Python console:
```
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.end...How to reproduce:
1. Go to endoscopy module (just an example, the behavior is the same for every scripted modules)
2. Copy-paste this into the Python console:
```
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
slicer.modules.endoscopy.widgetRepresentation().self()
```
=> memory is corrupted now and Slicer will crash very soon (e.g., if the above code copy-pasted again or any other operation is performed)
Problem:
Each time pythonSelf() is used to return an reference to Python, the reference count is decreased by one (when the temporary Python object is deleted).
See how the reference count changes using this code snippet:
```
import sys
for i in range(30):
w = slicer.modules.endoscopy.widgetRepresentation().self()
print("Reference count of widget object: "+str(sys.getrefcount(w)))
```
Solution:
When returning a reference to Python, the reference count has to be increased by one.
(for example, the same is done in CTK-build\PythonQt\tests\PythonQtTests.h)
This might (hopefully) also solve the frequent crash of Slicer on application exit due to double-delete of PythonQt widgets.
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/434BUG: Fix Slicer crash due to wrong value return in AddModel2016-03-03T11:53:05-05:00Sam HorvathBUG: Fix Slicer crash due to wrong value return in AddModel*Created by: agirault*
In `vtkSlicerModelsLogic::AddModel`, if the call to the storageNode
`ReadData()` failed, an error message was triggered and the node
removed from the scene, but `AddModel()` was still returning a pointer
to the `m...*Created by: agirault*
In `vtkSlicerModelsLogic::AddModel`, if the call to the storageNode
`ReadData()` failed, an error message was triggered and the node
removed from the scene, but `AddModel()` was still returning a pointer
to the `modelNode`, resulting in Slicer crashing.
The bug was encountered when loading a VTK Volume (DATASET set to
STRUCTURED_POINTS) and not selecting the 'Volume' description, since
the default description for the legacy VTK files is 'Model' in Slicer.
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/431BUG: Fixed vtkTransform::ApplyTransformMatrix crash2015-12-10T12:15:40-05:00Andras LassoBUG: Fixed vtkTransform::ApplyTransformMatrix crashHow to reproduce:
c=getNode('FullRainbow')
m=vtk.vtkMatrix4x4()
c.ApplyTransformMatrix(m)
Problem:
vtkTransform::ApplyTransform and vtkTransform::ApplyTransformMatrix are calling each other. Most of the time at least one is overridden,...How to reproduce:
c=getNode('FullRainbow')
m=vtk.vtkMatrix4x4()
c.ApplyTransformMatrix(m)
Problem:
vtkTransform::ApplyTransform and vtkTransform::ApplyTransformMatrix are calling each other. Most of the time at least one is overridden, so no crash occurs.
Solution:
Removed calling of vtkTransform::ApplyTransformMatrix from vtkTransform::ApplyTransform. If a class has a more efficient version of transform application for linear transforms then this call can be added to vtkTransform::ApplyTransform in that specific class.
Removed vtkTransform::ApplyTransformMatrix where it is not necessary (when it's just a more complicated and possibly slower version of ApplyTransform).
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/430BUG: Fixed crash in vtkMRMLTransformNode::GetMatrixTransformToNode2015-12-08T15:28:48-05:00Andras LassoBUG: Fixed crash in vtkMRMLTransformNode::GetMatrixTransformToNodeHow to reproduce the crash:
```
# Create transform hierarchy t1-t2-t3
t1=slicer.vtkMRMLTransformNode()
t2=slicer.vtkMRMLTransformNode()
t3=slicer.vtkMRMLTransformNode()
slicer.mrmlScene.AddNode(t1)
slicer.mrmlScene.AddNode(t2)
slicer.mr...How to reproduce the crash:
```
# Create transform hierarchy t1-t2-t3
t1=slicer.vtkMRMLTransformNode()
t2=slicer.vtkMRMLTransformNode()
t3=slicer.vtkMRMLTransformNode()
slicer.mrmlScene.AddNode(t1)
slicer.mrmlScene.AddNode(t2)
slicer.mrmlScene.AddNode(t3)
t2.SetAndObserveTransformNodeID(t1.GetID())
t3.SetAndObserveTransformNodeID(t2.GetID())
# Get t3 to t1 transform
m = vtk.vtkMatrix4x4()
t3.GetMatrixTransformToNode(t1, m)
```
The problem was caused by infinite recursion. There were no tests for GetMatrixTransformToNode and GetTransformToNode methods and they did not work well.
Also, the transform node heavily used recursion in several methods when only a simple iteration on the transform tree was needed, which made computation time magnitudes higher (although it was still very quick, so it was not noticeable) and made the code harder to read and debug.
Solution:
Replaced all the unnecessary recursive method calls by simple for loops.
Added tests for Get(Matrix)TransformToNode methods.
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/428BUG: Fix hide from editor flag on volume rendering nodes2016-04-01T13:59:51-04:00Nicole AucoinBUG: Fix hide from editor flag on volume rendering nodesThe volume rendering nodes are appearing in the Data tree
after the change to set the default of the hide from editors
flag to false on the MRML node superclass.
This change sets them hidden by default and sets up the
display node combo ...The volume rendering nodes are appearing in the Data tree
after the change to set the default of the hide from editors
flag to false on the MRML node superclass.
This change sets them hidden by default and sets up the
display node combo box to show them in the Volume
Rendering Inputs panel.
Issue #2906
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/411BUG: Enable high-resolution screenshots of slice views2017-10-15T00:37:13-04:00Sam HorvathBUG: Enable high-resolution screenshots of slice views*Created by: msmolens*
This commit enables rendering high-resolution screenshots of the slice views.
Previously the screenshots were scaled and interpolated after being captured at
screen resolution.
Alternative attempts to render thes...*Created by: msmolens*
This commit enables rendering high-resolution screenshots of the slice views.
Previously the screenshots were scaled and interpolated after being captured at
screen resolution.
Alternative attempts to render these screenshots, using vtkRenderLargeImage or
vtkWindowToImageFilter without offscreen rendering, resulted in incorrect
rendering of one or more of: the slice image, the annotations (ruler,
orientation marker, etc.), or lightbox mode.
Open issues are:
- Some text doesn't scale in the high-resolution screenshot (corner annotation,
ruler measurement, orientation marker labels)
- Ruler height is fixed
On Windows this depends on offscreen rendering fixes in
vtkWin32OpenGLRenderWindow: https://gitlab.kitware.com/vtk/vtk/merge_requests/992
Fixes #3885
Co-authored-by: Alexis Girault alexis.girault@kitware.com
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/405BUG: 2466, MRMLIDImageIO crashes with DWMRI volume2015-12-08T09:34:06-05:00IsaiahBUG: 2466, MRMLIDImageIO crashes with DWMRI volumehttp://www.na-mic.org/Bug/view.php?id=2466
Restore handling of b-values and gradients, and make code consistent
with DWIConvert: use the `sqrt(b/b_max)` scaling factor as documented
on the NA-MIC wiki page:
http://wiki.na-mic.org/Wiki/...http://www.na-mic.org/Bug/view.php?id=2466
Restore handling of b-values and gradients, and make code consistent
with DWIConvert: use the `sqrt(b/b_max)` scaling factor as documented
on the NA-MIC wiki page:
http://wiki.na-mic.org/Wiki/index.php/NAMIC_Wiki:DTI:Nrrd_format
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/401BUG: Fix slice bounds for volumes not RAS aligned2017-01-30T12:33:32-05:00Julien FinetBUG: Fix slice bounds for volumes not RAS alignedSee [#4077](http://www.na-mic.org/Bug/view.php?id=4077)
See [#4077](http://www.na-mic.org/Bug/view.php?id=4077)
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/404BUG: Fix crash on saving node named with a single number2015-11-11T12:03:27-05:00Nicole AucoinBUG: Fix crash on saving node named with a single numberA previous fix[1] to avoid crashes on windows when saving
volumes named "1:xxxx" leads to a crash when a node name
is just a single number (the first part of the check passes, but
crashes when trying to get the second character in the na...A previous fix[1] to avoid crashes on windows when saving
volumes named "1:xxxx" leads to a crash when a node name
is just a single number (the first part of the check passes, but
crashes when trying to get the second character in the name string).
This fix adds a string length check so that valid node names like
"1" or "2" will not cause a crash on save.
[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=24294
Issue #3991
https://gitlab.kitware.com/sjh26/Slicer/-/merge_requests/403COMP: Fix configuration error with VTK OpenGL2 backend2016-06-24T11:20:43-04:00Sam HorvathCOMP: Fix configuration error with VTK OpenGL2 backend*Created by: msmolens*
This commit fixes a CMake error when building Slicer configured with:
```
Slicer_VTK_RENDERING_BACKEND:STRING=OpenGL2
```
The error is:
```
39> Performing configure step for 'Slicer'
...
39> -- Found Qt4: C:/...*Created by: msmolens*
This commit fixes a CMake error when building Slicer configured with:
```
Slicer_VTK_RENDERING_BACKEND:STRING=OpenGL2
```
The error is:
```
39> Performing configure step for 'Slicer'
...
39> -- Found Qt4: C:/dev/Support/qt-4.8.7-64-vs2013-deb/bin/qmake.exe (found version "4.8.7")
39> -- Configuring Slicer with Qt 4.8.7 (using modules: QTCORE, QTGUI, QTNETWORK, QTOPENGL, QTUITOOLS, QTXML, QTXMLPATTERNS, QTWEBKIT, QTSVG, QTSQL, PHONON, QTSCRIPT, QTTEST, )
39> -- Configuring Slicer for [win-amd64]
39> CMake Error at C:/dev/SB2/VTKv6/CMake/vtkModuleAPI.cmake:120 (message):
39> Requested modules not available:
39>
39> vtkGUISupportQtOpenGL
39> Call Stack (most recent call first):
39> C:/dev/SB2/VTKv6-build/VTKConfig.cmake:67 (vtk_module_config)
39> CMakeLists.txt:790 (find_package)
```
When using the OpenGL backend the vtkGUISupportQtOpenGL module is built because
of the CMake setting VTK_Group_Qt:BOOL=ON. When using the OpenGL2 backend it's
necessary to explicitly enable the vtkGUISupportQtOpenGL module. In this case,
the module is not part of the Qt group. See [1].
[1] https://github.com/Slicer/VTK/blob/fe92273888219edca422f3a308761ddcd2882e2b/GUISupport/QtOpenGL/module.cmake#L1-L3