segmentation: scissors

Hello everyone,
I have problem we the tool scissors in segmentation menu. It started to be very laggy like minutes to do just simple cutting.

My workflow didn’t change, but i started experience these long waiting periods.
I usually segment a vessel with fast marching (segmentationeditor extension), apply it, and try to cut off some parts in 3d view windows with the scissors tool, which takes form a few minutes to even half hour in more vast and complex cut. The workflow is similar to that presented on youtube: “make hollow” from ParkLab research. The problems occurred on version 4.9 and didn’t disappear after upgrade to 4.10.1

I work on iMac 2017y, Mojave OS; I7 4.2Ghz, 64GB ram; AMD Radeon 580 8gb
In my opinion the hardware and software should be enough.
What can I do with the issue?

Did you try disabling “smoothing” under show 3d? it significantly reduces the computing time Capture%20d%E2%80%99%C3%A9cran%20(249)

It used to work well but something changed. I always worked with smoothing and was fine. Moreover, turning off smoothing don’t help.
The strange thing is that the same scans are working normally on slower computer (MacBook pro 2015y).
Now it looks like during scissoring the slicer is not responding and it takes long minutes to deal with it. On the other computer just 2 seconds. I tried reinstalling slicer, cleaning disk, computer. The other things work super fast. Therefore I think it is something wrong with Slicer.

Could you please send us a data set with that you can reproduce this issue? (upload to dropbox/onedrive/etc. and post the link)

I enclose the dataset I discovered the problem. I do aorta segmentation with fast marching. I do some over segmentation that i have leakage on the spinal vertebra. When i cut the spine off in 3D view, Slicer is not responding for about 30 minutes. When I use scissors tool but in the saggital/axial view then cutting is very fast.
Unfortunetly, the enclosed CT is not the only one. Currently, I have the same problem with all CTs when trying to cut the bigger surface. I worked fine 2-3 months ago. I don’t know what happened.

I’ve tried the processing that you describe on your data. Cutting is fast for me in all views, on a 3-year old PC with 16GB RAM (see this video: https://1drv.ms/v/s!Arm_AFxB9yqHtvxvfwJOk1vLFwnv7Q).

Do you see any errors in the application log?
Do you have similar issues if you use simple thresholding to extract the vessel?

1 Like

. I recorded my screen, but the mac wheel of death is not being recorded (apple is clever:)))
logs as on the movie. https://www.dropbox.com/s/ui4wsp6kk7enlis/Nagranie%20z%20ekranu%202019-03-5%20o%2019.23.50.mov?dl=0

For treshold segmentation is the same. The method of segmentation doesn’t matter. Smth wrong when working on 3d rendering data. I tried 3d volume renderings on Horos and they work fine.

I reinstalled Slicer with removing ~/.config/NA-MIC, but without improvement. Are there any other files that slicer could left after uninstalling?

Can you run XCode instruments to see what the application is doing?
How is the memory usage while the computation is in progress?
Any messages in the application log (menu: Help/Report a bug)?

my CPU and memory usage is as following :

bug report Dropbox - bug report.docx - Simplify your life
and there is nothing wrong in application log

i tried Slicer under bootcamp Windows on the same iMac and it works pretty fine 4-5 sec lags when cutting big areas. So the problem is on MacOS

Can you run XCode Instruments to see what the application is doing? It can tell in what function Slicer spends time, which can help a lot in narrowing down what the issue can be.

https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/debugging_with_xcode/chapters/debugging_tools.html

https://help.apple.com/instruments/mac/current/#//apple_ref/doc/uid/TP40004652-CH6-SW11

I’ve downloaded Xcode app but I have no idea how to load in 3d slicer
Could you help with that part?

You start 3D Slicer as usual, then launch Instruments, choose attach to process, and select the Slicer process. I don’t have a Mac, so I cannot help with specific instructions, but you should be able to find them by searching the web and if you have questions then Mac users should be able to help.

@pieper

Disable (or uninstall) CleanMyMac X.

disabling CleanMac X didn’t help.

i attached the Slicer process to Xcode Debugger. However I am not sure the data is correct
22 15

Easiest is to select the Slicer entry in the mac Activity Monitor and then select Sample Process from the gear menu. This gives you most of the same information as Xcode instruments.

The Sample Process of not responding 3d Slicer looks like this https://www.dropbox.com/s/ghj54e8pqd9jauw/Slicer%20sample.docx?dl=0

Thanks for posting that - it does look like most of the time is spent executing the scissors, so maybe there’s a very inefficient code path that stalls on mac.

@lassoan is there a test for the scissors so we can compare the exact operation on multiple platforms?

    +                                                                     2564 qMRMLSegmentEditorWidget::processEvents(vtkObject*, unsigned long, void*, void*)  (in libqSlicerSegmentationsModuleWidgets.dylib) + 382  [0x128e29b5e]
    +                                                                       2564 qSlicerSegmentEditorScissorsEffect::processInteractionEvents(vtkRenderWindowInteractor*, unsigned long, qMRMLWidget*)  (in libqSlicerSegmentationsEditorEffects.dylib) + 445  [0x128fc1a2d]
    +                                                                         2564 qSlicerSegmentEditorScissorsEffectPrivate::paintApply(qMRMLWidget*)  (in libqSlicerSegmentationsEditorEffects.dylib) + 205  [0x128fbe1dd]
    +                                                                           2564 vtkStreamingDemandDrivenPipeline::Update(int, vtkInformationVector*)  (in libvtkCommon-8.2.1.dylib) + 254  [0x11c3f3d8e]
    +                                                                             2564 vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*)  (in libvtkCommon-8.2.1.dylib) + 1120  [0x11c3f39a0]
    +                                                                               2564 vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*)  (in libvtkCommon-8.2.1.dylib) + 1228  [0x11c3cd61c]
    +                                                                                 2564 vtkCompositeDataPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*)  (in libvtkCommon-8.2.1.dylib) + 107  [0x11c3c885b]
    +                                                                                   2564 vtkDemandDrivenPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*)  (in libvtkCommon-8.2.1.dylib) + 61  [0x11c3cde9d]
    +                                                                                     2564 vtkExecutive::CallAlgorithm(vtkInformation*, int, vtkInformationVector**, vtkInformationVector*)  (in libvtkCommon-8.2.1.dylib) + 69  [0x11c3d32c5]
    +                                                                                       2564 vtkImageStencilAlgorithm::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*)  (in libvtkImaging-8.2.1.dylib) + 65  [0x11bade4a1]
    +                                                                                         2564 vtkPolyDataToImageStencil::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*)  (in libvtkImaging-8.2.1.dylib) + 139  [0x11bd0281b]
    +                                                                                           1284 vtkPolyDataToImageStencil::ThreadedExecute(vtkImageStencilData*, int*, int)  (in libvtkImaging-8.2.1.dylib) + 2523  [0x11bd01efb]
    +                                                                                           ! 1013 vtkAOSDataArrayTemplate<float>::GetTuple(long long, double*)  (in libvtkCommon-8.2.1.dylib) + 217,28,...  [0x11bfa8519,0x11bfa845c,...]
    +                                                                                           ! 271 vtkStructuredGrid::GetPoint(long long, double*)  (in libvtkCommon-8.2.1.dylib) + 0,11,...  [0x11c28bb90,0x11c28bb9b,...]
    +                                                                                           1147 vtkPolyDataToImageStencil::ThreadedExecute(vtkImageStencilData*, int*, int)  (in libvtkImaging-8.2.1.dylib) + 2595,2603,...  [0x11bd01f43,0x11bd01f4b,...]
    +                                                                                           131 vtkStructuredGrid::GetPoint(long long, double*)  (in libvtkCommon-8.2.1.dylib) + 26  [0x11c28bbaa]
    +                                                                                           2 vtkPolyDataToImageStencil::ThreadedExecute(vtkImageStencilData*, int*, int)  (in libvtkImaging-8.2.1.dylib) + 2250  [0x11bd01dea]
    +                                                                                             2 vtkAOSDataArrayTemplate<float>::GetTuple(long long, double*)  (in libvtkCommon-8.2.1.dylib) + 213,217  [0x11bfa8515,0x11bfa8519]

There is no automated test for Scissors.

Most of the time is spent in vtkPolydataToImageFilter, which is a quite simple and robust filter, so I suspect that the input extent or resolution of the output image might not be computed correctly. Does the memory usage of Slicer jumps significantly when Scissors operation takes a long time?