search

clEsperanto / pyclesperanto_prototype

GPU-accelerated bio-image analysis focusing on 3D+t microscopy image data
http://clesperanto.net
BSD 3-Clause "New" or "Revised" License
210 stars 46 forks source link

erode_labels also relabels all labels #330

Open MariusCausemann opened 9 months ago

MariusCausemann commented 9 months ago

Hi, I noticed that the erode_labels function not only erodes the labels, but also applies a relabel_sequential to the eroded labels. I see that this might be useful in some cases, but I think it is somewhat unexpected behaviour (and for my applications undesirable). Would it be possible to either remove the relabel_sequential in https://github.com/clEsperanto/pyclesperanto_prototype/blob/413e3fadbff7d5db07c98d614cd5e2d2a94ae38c/pyclesperanto_prototype/_tier4/_erode_labels.py#L66C9-L66C27 or make it optional (preferably in erode_labels and e.g. opening_labels, etc.)?

Best, Marius

PS: thanks for the great library!

haesleinhuepf commented 9 months ago

Hi @MariusCausemann ,

yes that's because non-sequentially labeled label images cause issues in various python libraries down-stream. Consider applying the strategy here to conserve labels.

I may turn this into a clesperanto-function if more people need it.

Thanks for the suggestion!

Best, Robert

MariusCausemann commented 9 months ago

Hi Robert, thanks for your quick reply! Your suggested strategy for recovering the original labels fixes the problem for erode_labels. However, it seems complicated to me to first relabel and then recover the labels. Wouldn't it make more sense to separate the erode and relabel functionalities? Besides, the recovery strategy isn't that simple anymore when using opening_labels or closing_labels. Maybe an optional argument keep_labels could work?

I use these functions on chunks of a dask.array and the relabeling leads to different new labels for the same original label on each chunk of the image.