Hi everyone,
I’m using a Slicer version 4.13.0-2021-06-03 for Windows.
I noticed that the function “Masking - Editable area - Inside segment XXX” doesn’t seem to apply to the “Erase” function of the “Segment Editor” (it works correctly only with the “Paint” function)
Thank you very much for your support!
MB!
Please try with the latest Slicer Preview Release and let us know if it does not work as you expect.
I was able to reproduce this.
@Sunderlandkyl can you have a look at this? If it is not an easy fix then you can submit a bug report and post the link here.
@Michele_Bailo As a workaround, you can create a temporary segment and paint with that instead of erasing. When you finished “erasing” then you can remove that temporary segment.
@Michele_Bailo As a workaround, you can create a temporary segment and paint with that instead of erasing. When you finished “erasing” then you can remove that temporary segment.
Yes, this is exactly what I have been doing for the past months. But I thought I’d tell you about it because I wasn’t sure if I was doing something wrong or if there were other ways.
Thank you so much for your availability!
Has this been looked into at all?
Thanks!
-Hollister
Here I have Segment 1 and Segment 2 painted. I have selected the “Erase” effect, selected Segment_1 in the segment table as my active segment, changed the editable area to “Inside Segment_1” and placed my cursor over the boundary line.
Then when I click to erase, it erased only inside Segment_1 and did not erase Segment_2 as well which had been contained inside my erase circle.
I could also select Segment_2 as the active segment, then select “Inside Segment_1” and oddly edit another segment (Segment_1) that doesn’t match my currently active segment (Segment_2) in the segment table.
Thanks James. My use case is slightly different:
I have multiple segments visible and multiple hidden. I want to erase all visible segments but leave hidden unchanged. If I click “erase all segments” AND select editable area inside all visible segments, when I erase, it erases ALL segments, not just the visible ones.
Hopefully that makes sense…
@Sunderlandkyl should be able to have a look at this when he gets back from vacation in a week or two. You can ping him here or submit a bug report at issues.slicer.org and assign the issue to Kyle Sunderland.
Sounds good, no rush. In the meantime I’ve been using your suggested workaround to make a new segment, paint that, and then subtract. Thanks!
There is no need to subtract: if you enable overwrite then it is enough to paint in the new segment. In the very end you can delete that new segment.
I don’t seem to be able to reproduce the issue.
Can you clarify if the setting that is causing the unexpected behavior is “Editable area” or “Modify other segments”?
Sorry for the slow reply.
I think my confusion was the inconsistency in behavior between scissors and erase. In scissors, there is an “Apply to all segments” checkbox, which is actually “apply to all visible segments”. I thought (incorrectly) that the “Erase all segments” checkbox would behave similarly, but it does exactly what it says it does - erase all segments, visible or not. The tooltips for both checkboxes (which I had turned off, unfortunately) do document the appropriate behavior correctly.
Erase all segments does work correctly with Editable area set appropriately, I do not see any issue with that.
So I guess this is a case of “nothing to see here, move along…”
Thanks!
We should probably update the wording to clarify these meanings based on the confusion you faced which I’m sure others face as well.
“Apply to visible segments” and “Erase all segments” could be options where using “all” is only used when referring to visible and non-visible segments.
@hherhold see if the following naming change proposed by @Sunderlandkyl makes sense
We used the “Apply to all segments” as checkbox label to keep things simpler and shorter (to increase the chance that users read and understand the label). However, this is the second time that users report the current behavior as an error, so it seems that the current label is misleading and using a longer but more accurate label is justified. We’ll proceed with the changes that @Sunderlandkyl proposed.
This change makes sense to me.
Thanks!
