If the goal is just cropping then approximate alignment is good enough. Probably you don’t even need to rotate the ROI (since it should not matter that you include a little bit more in the cropped image), but if you want to rotate then apply a transform and use the sliders.
You can align slice view with the implant by showing the implant using volume rendering and then dropping 3 markups fiducial point on the top surface and copy-pasting this code into the Python console.
In tomorrow’s Slicer Preview Release, we’ll add computation of principal axes directions of segmented objects, so you’ll be able to get the implant long axis automatically from there. You can crop&downsample the volume before segmentation if you find that that the segmenting the whole implant is too computationally demanding.
if there is a way of dragging the 8 corners of the ROI box independently the problem will be solved i guess if that is possible. or if there is a way of transforming the ROI box around the center of the segment.
When you copy-paste the Python code snippet then it should make the red slice view coplanar with the 3 markups fiducial points. I’ve slightly modified the code (it used integer vectors instead of floating-point vectors), please try again.
You can orient slice viewers to orthogonal orthogonal directions by changing the last argument of sliceNode.SetSliceToRASByNTP call from 0 to 1 or 2. Then you can use Scissors effect in rectangle mode to draw an axis-aligned ROI.
However when I try to do it with ROI box the box was cropping the volume as usual (with the angle) . I expected it to work the same way as the Scissor but it did not.
However i transform the ROI with “Local” settings and after some playing around with the slides it managed to crop the volume the way i wanted to. Otherwise the ROI was still behaving as earlier screenshots unlike the scissor square. If the ROI is working just like the scissor effect things would be much easier for us but we can manage with this way also.
Is there a way of getting the ROI to work the same way as the Scissor square ?
As @Juicy suggested setting the center of rotation option i am keeping as a last resort because we have about 80 sets of data to analyse and with no easy way of finding the center of implant it would be bit of trouble. But i tried that way also and can get it to work in that way also.
From the 3 markup points, you can create a transform that rotates the ROI. In fact, you can fully position and rotate the ROI based on a few markup points (e.g., 3 coplanar points to define the position and orientation of the front face of the ROI and a 4th point to define the opposite face).
With latest Slicer Preview release that you download tomorrow or later (rev28754), you can position the ROI on an object automatically as shown in this example:
So, you can almost fully automate your workflow by first segmenting the implant using thresholding (if you have multiple implants then you can separate them using Islands / Split islands to segments), run the example script above to place the oriented ROI boxes automatically, then adjust them as needed.
I am looking forward to this new build and this will solve many of our and many of others problem in analyzing. This is very exciting…
What we are trying to do is something similar to this and for the record we had the idea independent of this paper before we came across about a week ago.
So what we are doing is this to analyse the total volume and the bone volume…
Our other problem is we when we grow the margins our computers are not powerful enough to grow over 0.1 mm on these data sets. We grow each ring 0.1 mm at a time which takes about 2-3 minutes to do that as well. We want to use 0.5 mm rings but when we try to grow at 0…5 mm at the same time the Slicer hangs…
My system is i7-8550U CPU @ 1.80GHz, 16Gb DDR4 2400 MT/s and NVidia Geforce MTX150 4GB.
But i guess noting can be done apart from upgrading the hardware specs.
@Sunderlandkyl worked on this and there is an almost-complete pull request that speeds up large margin computations by 10x or more:
You may also find “Split Volume” effect useful: if you segment the implants with thresholding, split the segments using Island effect, then Volume Split effect cuts out only the implants (with a predefined padding around it) automatically, to separate small volumes.
The ROI scripts works perfectly how ever I need to “enter” "twice " for it to draw the box every time. Is this expected ?
I downloaded the latest rev 28755 (linux) build but i was not able to figure out to do this without the script as you showed it earlier ? Can you point me in the right direction.
As i mentioned earlier due to lack of processing power in our machines, we need to grow the margin 0.1 mm at a time. We need 3 zones each 0- 0.5, 0.5- 1 and a 1 - 1.5 mm bone rings. So at this way we need to do it 15 times in one sample and we looses the count too in the middle
Is it possible to do a loop for script like grow 0.1mm at a time for 5 times ? It should basically behave the same as manually doing it 5 times ?
I will make a feature request also for this. If the segment editor have a option to apply the same effect repeatedly for “x” number of times. Even though this looks like a redundant and similar function i think in lower specs computers this will be useful if it works the way i think it would.
It’s not expected and I didn’t experience this. Maybe just a screen refresh issue. You can try forcing re-rendering fixes it.
I don’t know what you are referring to.
Simply running the method recursively would lead to inaccuracies because if the kernel is small then it does not approximate a sphere perfectly. The pull request by @sunderlandyl mentioned above will take care of the performance issue in Margin and Hollow effects.
I am sorry i was referring to this. I was expecting that this ROI positioning can be done without the use of the script from the rev 28754 above.
If you think it is not very accurate we will have trouble analyzing the data. Do you have any idea how long the that pull request will take to materialize ?
As the same time is their any work around other than finding a better computer ! we have ordered a workstation but it will take time it seems and we are in hurry on this one.
The oriented bounding box, principal axes, etc. will most likely be used as part of automated workflows, so I’m not sure if it is worth spending time with converting the script to a module. You need to keep using the script or add it to your own processing module.
@Sunderlandkyl might be able to give you an estimate. If it’s very urgent for you: since the work-in-progress part of the pull request does not affect core functionality, you can copy the relevant part of the effect (compute distance map and threshold it) into your own script.
Thank you for the clarification. The script works well for our case so nothing much needed from that aspect.
It is very urgent as we plan to present on this by march. we have around 100 samples of this. If you have some time can you please look at the data if it is nothing too much for ask.
We need to grow three zones (0-0.5 mm, 0.5 - 1mm & 1- 1.5 mm) unfortunately we have dont have a way to measure if this is a error in growing 1mmx5 vs 5mmx1. We want the total volumes of each zone calculated.
If you and @Sunderlandkyl could guide me to add this functionality to a script to enhance performance i am very in to trying this out.