Use case: regionprops on dask arrays

[m-albert]

Issue to discuss the following: A use case / question that often comes up is how to best apply regionprops to dask arrays. At least to my knowledge, there's no clear go-to workflow for this currently. Maybe dask-image can help with this.

[m-albert]

I'm copying here a comment by @vbrow29 from #403:

P.S. to your point about map_blocks for distributed regionprops, I tried several approaches with my data (3-channel fluorescence images + segmentation mask) and it seemed that no matter what I tried, dask was holding onto references to image chunks longer than necessary which led to an aggregation of unmanaged memory, eventually spilling terabytes of data to local node storage which then killed my runs. I found that running find_objects first to get the bounding boxes of each cell from the mask, then running regionprops in parallel on each cell was both fast and memory-efficient, allowing me to extract regionprops features from an image with ~1.5 million segmented cells in a few hours without exceeding my job's memory limit (~700GB distributed over 64 cores w/ 4 threads each).

The pipeline @vbrow29 describes sounds super useful and performant on such a large dataset. One idea would be to implement this in dask-image to provide a dask array compatible extension of the scikit-image implementation.

[m-albert]

I've just seen there's a related issue here: #231.

Some comments:

By John:

We've discussed in other issues and offline adding regionprops. So thanks for surfacing this as a proper issue. That doesn't exist today, but agree this is very valuable and seems worthwhile to include.
One thing worth noting that may help in the short-term is under-the-hood we use labeled_comprehension to implement these different measurement functions. So this can be a good way to shoehorn in one's own label-based computation.
cc @jni (who also likely has thoughts here 🙂)

By Genevieve:

I think some of the holdup for a version of regionprops in dask-image was to do with the #97 function.
But as I recall, there are a fair few 'easy' properties we could be supporting, several tricky ones, and a few very hard things to do. We shouldn't let the hard stuff completely block progress on supporting the easier things.