A Region class to keep track of labeled regions in a CrystalMap

[hakonanes]

Hi all,

I would like to add a orix.region module with a Region class, initialized with an integer array equal to a map size/shape with labels for distinct regions, to conveniently store information about grains, particles etc. I would like this to be a wrapper around scikit-image's skimage.measure.regionprops, which would give us A LOT of properties for each region. We could then use this class to more easily plot boundaries, wire frame unit cells, create spatial masks (boolean arrays) from properties, and much more.

This would introduce a scikit-image dependency. If there is some hesitancy regarding this, we could include this module as an option and scikit-image as an optional dependency.

[pc494]

This looks like it would a really really cool addition and it ties in really nicely with the density based clustering workflow. Feel free to tag me if you need input.

[hakonanes]

Glad to hear you would like this as well!

I think introducing the scikit-image dependency should be fine, since I think many people using orix already have scikit-image installed in their environment anyway.

[hakonanes]

I've started on this class, but it won't be ready for v0.6, so I've pushed it back to a v0.7.

I also think orix.map_feature.MapFeature is a better name, since Feature is too general. Although naming suggestions are welcome. Note that I don't think the average user will interact with this class directly, only via a Grains class inheriting from MapFeature (which can be particles, X-ray spectra correlated with orientation data etc.).

[pc494]

Naming is hard. Are Cluster or Region any good?

[hakonanes]

Region is good, and used by scikit-image for the regionprops (see link in top comment). Perhaps MapRegion is even better? But region is better than feature, definitely.

[pc494]

Something like what I have below as a definition (so that we know what we mean)

Region : Map points that belong to a "Region" are similar some way - often this will that they share an orientation and phase - meaning that they have been assigned to the same "cluster" by some upstream routine.

[hakonanes]

I've worked some more where I need this class, and I think MapRegion is an even better name than Region because then we avoid potential confusion with OrientationRegion and SphericalRegion.

[hakonanes]

Also, although scikit-image's regionprops() has lots of properties we would need from the start, I think it is best to build this class up from nothing, since regionprops() returns a list of RegionProperties, while we want a map with labeled regions to perform vectorized operations on, not loop over a list.

[pc494]

I agree that working with a list based object is going to be an issue. Seems best to just borrow the concepts that fit.

[argerlt]

(continuing the conversation from #392) @hakonanes you are right, this is close to what I was wanting to do with spatial decomp. Only difference is I planned on storing feature maps as using lists of nodes and vertices defining the boundaries similar to glumpy or qhull. Doing it as a node/connection vector map makes gpu-accelerated plotting easier, and makes plotting on non-square grids simpler. Then, the information that would have formed the raster maps can be stored per-pixel as CrystalMap properties, and Orix isn't locked into using only square gridded data. To your point though:

regionprops() returns a list of RegionProperties, while we want a map with labeled regions to perform vectorized operations on, not loop over a list.

Not sure which would be faster? a vector map would basically just be a 2D finite element mesh which is pretty easy to vectorize, but I have no intuition if it would be faster or slower than a raster map. I do know that to speed up plotting and allow for non-regular orientation maps, MTEX uses vector maps to do all plotting, as opposed to the plt.imshow() method Orix uses.

If no one does this in the next few months, I can give it a try with vector maps. I want to finish some of the other issues I've commented on first though, instead of overcommitting myself.

[hakonanes]

This sounds promising!

I think a MapRegions class can use such a list of nodes and vertices internally. How we determine attributes of each region we can decide later on.

Did you consider VisPy (https://vispy.org/) instead of Glumpy? At the bottom of Glumpy's poster on their README they state that the project "is a laboratory for experimenting ideas to be integrated into the VisPy project."

If no one does this in the next few months, I can give it a try with vector maps.

I think this is safe to assume. But yes, better to complete other outstanding issues first!

[argerlt]

Did you consider VisPy

Good point. Classically (and this is not fact based, just purely anecdotal). I've had better luck with glumpy, but vispy appears much more stable. I will keep this in mind