Scissors's Fill Inside operation issue

Hello again,

I have applied the scissors’ fill-inside operation to segment 1, but I am encountering the following issues:

  1. At minute 0:52, you will notice that the operation is not entirely applied to the part where it is scissored. Some gaps are still visible.
  2. From minute 1:00 to 1:05, why does the output of the operation blink rapidly?
  3. Starting from minute 1:22, the output of the operation almost disappears intermittently.

Slicer version: Preview Release 5.7.0

Please find the attached video link:

Did you check the slices? Your screenshot only shows the 3D rendering. It is possible that slight smoothing differences makes one model appear on top of the other.
In my test (with 5.6.1) the cross sectional slices shows the correct behavior.

BTW, if your goal is to split the segment_1 into two mutually exclusive segments, then you shouldn’t use “allow overlap”.

Yes, I checked the slices, and the effect was clearly visible on them, just as in your screenshot.

Regarding the smoothing difference, I achieved the desired results after disabling surface smoothing:

However, the rendering issue, particularly surface glitching/blinking, still persists when i rotate the model.

At some point, the overlapped segment just completely disappears.

@lassoan, @pieper, Could you please confirm this is really a rendering bug?

If you have coincident surfaces then yes, you would expect rendering issues.

1 Like

With the cutting you created a sharp edge that the smoothing reduces, which causes the band near the cut. Since the binary labelmap representation has finite resolution, if you want to produce smooth surface output then there will be always gaps or overlaps.

You can choose between flying edges + Windowed sinc smoothing / surface net algorithms, depending on what is better suited for your application:

Flying edges, no smoothing, showing binary labelmap representation in slice view:

Flying edges with smoothing, showing closed surface representation in slice view:

Surface nets with smoothing, showing closed surface representation in slice view:

All these differences are fraction of a voxel’s size. If such small changes matter in your specific application then you can increase the resolution of the binary labelmap representation.

Farther away from the cut, the two surfaces are the same, which causes the flickering known, which is a rendering phenomenon known as Z fighting (a screen pixel randomly gets rendered by one surface or the other).

These discussions are interesting and it may be useful in understanding capabilities and limitations of various processing and rendering algorithms. However, if your goal is to prove substantial equivalence between different software for a 510k submission then at some point you will have to specify clinically acceptable tolerance. You can then ignore all differences that are much smaller than this tolerance.