alive-research / slicer-liver Goto Github PK

Add the distance maps computation UI based on the prototype design in #34

• My initial thought is that this is an attribute/property of vtkMRMLResectionDispalyNode

• Another thing to check is whether there is an interpolated value in the vtkMRMLScalarVolumeNode that could be used.

• Check whether this implies a new transfer of the texture. I believe not

• Add GUI elements to support this

• Add support in the vtk widget representations for enable/disable.

The liver markups may not make a lot of sense as standalone markups. As a first approach I would hide them form editors and unregister them fom the UI

• The README file should contain more information
• The README file should correct the naming

Here we will modify the Markups Bezier Surface components to transfer the 3D volume representing the distance maps to a 3D texture.

Discussed in #29

Describe the bug
When trying to add endpoints for the centerline calculation the user interface don't allow setting points in all parts of the selected structure. The issue seems to be that vtkOctreePointLocator::FindClosestPoint that is being used to find the closest point on the structure don't really provide the closest point to most of the structure.

To Reproduce
Steps to reproduce the behavior:

1. Select the Liver module
2. Press "Reload and Test"
3. Choose LiverSegmentation000
4. Select "hepatic" as "Reference Model"
5. Press "Add segment" and try to select points on the vessels
6. Now the white marker only show up for small parts of the vessels, and not for the whole structure

Expected behavior
I expect the white marker to show everywhere on the selected structure

Screenshots

Desktop (please complete the following information):

• OS: Ubuntu
• Version 20.04

Additional context
Printing out the self.__distance shows that the distances gotten from vtkOctreePointLocator::FindClosestPoint are incorrect, suggesting that this function don't work for this model.

Currently Dockerhub only got one image on aliveresearch: aliveresearch/slicer-build.
This is based on the Centos7 slicer/slicer-base image, and isn't the best solution for the Slicer-Liver project.

I'm not allowed to create new repos for aliveresearch on Dockerhub, that's why we have been using olevs/slicer-build-ubuntu2004.
@RafaelPalomar Can you create aliveresearch/slicer-build-ubuntu2004 in Dockerhub?
I can update the documentation in https://github.com/ALive-research/ALive-Docker, and upload the new Docker image when I'm allowed.

As for now, the UI does not change when the nodes change programmatically

I'm thinking about a JSON format for the resection, which should include, state, control points for markups and resection margin. The version of the file format should be included (v1.0).

Also the nodes for storing the MRML information should be created

Describe the bug
When executing Liver.py to build the UI, Python interpreter fails in loading the library qSlicerLiverResectionsModuleWidgetsPythonQt on Windows 10 (Liver.py line 178). The library file it is compiled and exists in the solution directory. Other modules are found and loaded correctly.

To Reproduce
Steps to reproduce the behaviour:

1. Configure the project for VS 2019 v16
2. Compile in Debug mode for Windows 10 (x64)
3. Open Slicer, install the Liver extension
4. Open the liver extension, this will execute Liver.py to build the UI an trigger the error.

Expected behaviour
To load the qSlicerLiverResectionsModuleWidgetsPythonQt library an complete the execution of Liver.py

Screenshots

Desktop (please complete the following information):

• OS: Windows 10 (version 21H1, build 19043.1415)
• Version: Slicer 4.13.0, Slicer-liver updated to 27.01.2022

Additional context
The libraries are compiled as static (.lib) instead of dynamic (.dll)

Here we will modify the visualization of the Bezier surface to allow the visualization of the distance maps

Grouping control points (external, internal)

Output for reference:

vtkDebugLeaks has detected LEAKS!
Class "CellMap" has 1 instance still around.
Class "vtkEmptyCell" has 1 instance still around.
Class "vtkAlgorithmOutput" has 1 instance still around.
Class "vtkMRMLNodeReference" has 1 instance still around.
Class "vtkObservation" has 1 instance still around.
Class "9vtkBufferIfE" has 2 instances still around.
Class "9vtkBufferIdE" has 1 instance still around.
Class "vtkTypeInt64Array" has 8 instances still around.
Class "vtkInformationExecutivePortVectorValue" has 1 instance still around.
Class "vtkObserverManager" has 1 instance still around.
Class "vtkInformationExecutivePortValue" has 1 instance still around.
Class "vtkInformationIterator" has 1 instance still around.
Class "vtkMRMLModelNode" has 1 instance still around.
Class "vtkEventBroker" has 1 instance still around.
Class "vtkInformationStringValue" has 1 instance still around.
Class "vtkInformationDoubleVectorValue" has 3 instances still around.
Class "vtkCellArray" has 4 instances still around.
Class "vtkPolyData" has 1 instance still around.
Class "vtkTimerLog" has 1 instance still around.
Class "vtkInformationVector" has 4 instances still around.
Class "9vtkBufferImE" has 1 instance still around.
Class "vtkFloatArray" has 2 instances still around.
Class "9vtkBufferIiE" has 5 instances still around.
Class "vtkCommand or subclass" has 7 instances still around.
Class "vtkIntArray" has 5 instances still around.
Class "vtkIdList" has 6 instances still around.
Class "vtkInformation" has 14 instances still around.
Class "vtkDoubleArray" has 1 instance still around.
Class "vtkIdTypeArray" has 4 instances still around.
Class "vtkCollection" has 2 instances still around.
Class "vtkUnsignedLongArray" has 1 instance still around.
Class "vtkCellData" has 1 instance still around.
Class "vtkFieldData" has 1 instance still around.
Class "vtkPointData" has 1 instance still around.
Class "vtkPoints" has 2 instances still around.
Class "vtkStreamingDemandDrivenPipeline" has 1 instance still around.
Class "vtkTrivialProducer" has 1 instance still around.
Class "vtkInformationIntegerValue" has 25 instances still around.
Class "vtkTagTable" has 1 instance still around.
Class "9vtkBufferIxE" has 12 instances still around.

`

#34 should be used as base for this

This should include:

• The control polygon.
• The control points
• The resection exceeding the parenchyma

This should include:

• Enable disable the resection margin box depending on distance map selector
• Visualization update of the resection margin

Describe the bug
Warning about already registered vtkMRMLMarkupsSlicingContourNode, vtkMRMLMarkupsDistanceContourNode and vtkMRMLMarkupsBezierSurfaceNode:

Warning: In ../../Libs/MRML/Core/vtkMRMLScene.cxx, line 536
vtkMRMLScene (0x55b8c2d16440): Tag MarkupsSlicingContour has already been registered, unregistering previous node class vtkMRMLMarkupsSlicingContourNode to register vtkMRMLMarkupsSlicingContourNode


Warning: In ../../Libs/MRML/Core/vtkMRMLScene.cxx, line 536
vtkMRMLScene (0x55b8c2d16440): Tag MarkupsDistanceContour has already been registered, unregistering previous node class vtkMRMLMarkupsDistanceContourNode to register vtkMRMLMarkupsDistanceContourNode


Warning: In ../../Libs/MRML/Core/vtkMRMLScene.cxx, line 536
vtkMRMLScene (0x55b8c2d16440): Tag MarkupsBezierSurface has already been registered, unregistering previous node class vtkMRMLMarkupsBezierSurfaceNode to register vtkMRMLMarkupsBezierSurfaceNode

To Reproduce
Launch Slicer and observe the terminal output

Expected behavior
These warnings should not occur.

Desktop (please complete the following information):

• OS: Linux
• Version: v0.9

Compute distance maps between the tumor and the rest of the image or parenchyma in image space

• Manipulating the bezier surface for a resection after its placement is very slow. This is due to the property of the display node that considers snapping to surface. Resections do not need this and should default to unconstrained

vtkMRMLScalarVolumeNodes are adequate data structures to hold distance maps. However, their use is very extended in 3D Slicer and can lead to the situation that someone selects a medical volume as a distance map. To avoid this, volumes computed by distance maps functionality should be the only selectable ones. As a solution I propose to derive a new type that will prevent regular volumes to be used.