How to handle spacing

While looking at some recent PRs (ellipsoid drawing), I realized that I don’t know how code that takes into account spacing is supposed to work. Does spacing transform the whole problem, so that all inputs are considered to be in that space, or do we convert inputs with the spacing scaling. In that PRs case, that’s what happened, and it confused me quite a bit.

So, I was wondering if @jni and others who worked on introducing spacing would be willing to write up a few paragraphs in the user guide on how spacing works, also to educate developers?

Hmmm, that’s a very interesting one! Probably we should discuss in person because the answer is definitely “it depends!” I think when drawing, you’re dividing the sizes by the spacing, so that the output image has that spacing, and when you measure things using that spacing in that image they will come out to have the right values. But for e.g. regionprops.area you multiply by the spacing to give the area in “natural” units.

Probably an interesting idea would be to think about spacing having units (e.g. µm), and how would that change the API. I think we might want to have a goal for skimage2 that spacing with units (using e.g. pint) would be an allowed input. And this might make thinking about the API easier (in the same way that dimensionality analysis makes remembering formulas and calculations easier. :joy:

1 Like

I think it’s a good principle to assume as little as possible about the input. So this suggestion worries me a bit. The way I understand spacing, the algorithm usually cares about the ratio of sampling rates / steps instead of the actual unit. If that’s correct, why should we make our API more complicated and restrictive than necessary?

Though, I’m not against accepting units from pint or similar if they work without compromising on a unit-agnostic API. And of course always open to arguments. :wink:

Oh this is exactly the idea! Definitely would not compromise that. :blush: But in some situations (e.g. regionprops), it’s really good to have the unit support built-in.

1 Like

And btw, pint works pretty hard to try to have Quantity arrays work seamlessly where NumPy arrays work. So this might not be a lot of work on our end.