Investigate why there's a transpose operation that cannot be removed.

[adamltyson]

This comment from @matham highlights that there is a transpose that, if removed, causes errors.

In theory cellfinder shouldn't require a specific axis order, so it would be good to know why this tranpose is there.

cc @alessandrofelder

[matham]

I did find the cause, there is another place, here, where it's flipped. And both places have to be fixed to make it work. I ran into it during further pytorch stuff and removing both flips fixed the issue.

[adamltyson]

Thanks @matham, I think I'm missing something though, where is the second flip?

[matham]

Right, because in some places, the assumption seems to be that the order is x, y, e.g. here. Which means, when you pass planes to e.g. the ball filter, it needs to have that order. But I guess there was an assumption that the data comes in y, x, like in the link in the last message. So it has to be flipped to make it work with the filter.

But, if it used a consistent order with arbitrary dim1/dim2, it should not need flipping anywhere. And in my pytorch code that seemed to work ok.

[adamltyson]

Thanks for clarifying, I saw your previous link and it looked correct, because it was normal numpy axis ordering. So it seems like there's a mix of numpy and cartesian axis ordering, and we should decide on one.

Everywhere else in BrainGlobe where we've made this decision, we've gone with numpy, so I propose we do the same here. Any issue @brainglobe/active-devs?

[alessandrofelder]

so I propose we do the same here.

I agree!

[adamltyson]

This is more complicated than I thought, just because there are just so many references to axes in cellfinder. We can do three things:

1. Leave it as it is
2. Just remove the two flips as noted above
3. Go through the whole codebase and standardise (this looks like at least half a day of work)

Any thoughts?

[alessandrofelder]

My initial instinct would be to implement 2. soon (it's a concrete, scoped step that will avoid unnecessary computations) and leave 3. for a later time point, as we have more pressing issues in the roadmap?

[adamltyson]

Correcting these two flips doesn't seem to fix anything. Tests fail, and detection seems worse. I've opened #413 to track this properly.