Issue Ilastik (pix segmentation + boundary segmentation & multicut)

Dear Ilastik developers,

We want to report a bug . We are using the modules 1) pixel classification routine, followed by 2) Boundary based segmentation with Multicut.

The bug creates extra superpixel areas/segmented regions, presumably derived from the bottom layers of the z-stack. However, these extra areas are maintained and shown in the upper parts of the stack (on the right side of the images), where there should be background - as the is no signal to create boundaries in these layers. Training with multicut to try to remove them does not solve the problem. Pls See screenshot of the output w/ incorrect regions circled in in red.

We have used Ilastik versions 1.3.2 and 1.3.3 and running them on a Mac (OS Mojave 10.14.4, w/ 16) and we’ve also reproduced the same bug in a Windows machine with the same data set- bug seems platform and version independent.

The following files might allow you reproduce the bug (pls click the link below to download them:
https://r3.res.outlook.com/owa/prem/images/folder_16x16.png)Bug_Report_Ilastik](https://caltech-my.sharepoint.com/personal/nicopel_caltech_edu/_layouts/15/guestaccess.aspx?share=Ev9J6ZTWiPxBjVv9zoBv2FkB21orkxGbXTcZlyo06ZMYRg)

The file has:

  1. Input image confocal stack.
  2. Pixel classification project file - with trained data.
  3. Resulting annotated probability mask from pixel classification used as input for Boundary based segmentation w/ multicut
  4. The Boundary based segmentation w/ multicut project - with trained data set.
  5. The Boundary based segmentation w/ multicut output.
  6. A detailed description of what I am did procedure wise.

Please contact us back in case you think this can be fixed, or if you want additional input. We would love to use this platform for multiple projects going on at the lab now.


best regards,

Nico

Hi, Has anyone perhaps been able to look at the bug? Any input would be greatly appreciated.

Hi @nicopel,

a tiny disclaimer: my background is not biology, so I might call things not the right names ;).

Let me start off with a little background: In the multicut every pixel will be assigned to an object. So the best thing you can achieve in the multicut is for the background to belong to one big object (or several bigger disconnected ones).

I had a quick look at your data (thank you very much for supplying it) and it seems that there is not a lot of boundary evidence to “close” the objects in z-direction for many objects. While our superpixel algorithm can cope to some extend with unclosed boundaries, this is definitely too much. The supervoxels there just proliferate through the whole z-extend then. Just consider the following two screenshots of your pixel classification project:

Here you can see that the boundary does not extent in z-direction.

Here is an alternative view with window-level adjusted. the boundary in z-direction (here: left-right) is not very pronounced. Furthermore, without this boundaries it is not clear where the supervoxel should stop:

I see multiple possibilities to go on from here, depending on what you are trying to achieve as a final result:

  • if you can live with “throwing away” some of the objects, then I think you can filter them by certain criteria: e.g. exclude all objects that touch the boundary of the image volume (they will be incomplete anyway). Also filtering the objects by size might also do the trick already (the
    “proper” objects seem to be pretty regularly sized).
  • If it is possible at all for you to get an image with slightly better z-resolution (with boundaries more pronounced), then redoing the pixel classification taking special care that the objects have boundaries in all three dimensions
  • You could also think about not using the multicut at all. If you manage to get a good seed segmentation from the nucleus channel, you could perform seeded watershed (with the nuclei as seeds) on the distance transform of the boundary map. Well, under the assumption that there will be only on nucleus per cell, but I guess that might not always be the case.

On a side note: Looking at your pixel classification project I have noticed that there are many annotations with thick brushes. The problem with a large number of annotated pixels is that is slows down training a lot without giving any benefit. A good annotation strategy is to start with very few, thin brush strokes and go to live update. Then correct the classifier where it is wrong.