Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Format of output of functions that return parameter values for a map #3111

Open
jlaehne opened this issue Mar 17, 2023 · 2 comments
Open

Format of output of functions that return parameter values for a map #3111

jlaehne opened this issue Mar 17, 2023 · 2 comments

Comments

@jlaehne
Copy link
Contributor

jlaehne commented Mar 17, 2023

Functions such as valuemax and indexmax return a BaseSignal with 2 navigation dimensions and 0D signal, which theoretically makes sense, but is inconvenient for plotting as it plots including the navigator, which makes little sense for 0D signals, and the colormap cannot be changed.

In contrast, either estimate_peak_width or as_signal for parameters of a fit both return the transposed signal, thus Signal2D object without navigation dimensions and the spatial axes as signal axes, which is more convenient for plotting - and is okay in the sense that it is just an image of values for the different positions.

We should consider unifying the behavior. As it is an api change, would make sense to do that for the 2.0 release.

@CSSFrancis
Copy link
Member

CSSFrancis commented Mar 18, 2023

I agree that this is annoying sometimes but I'm trying to think of a consistent way to apply this.

My gut reaction is that the map function should not transpose the signal as that could cause some pretty confusing cases.

  1. How are ragged signals handled. They technically have 0 signal dimensions but shouldn't be automatically transposed.
  2. What about a function that can reduce multiple dimensions like the sum function. s.sum(axis=s.axes_manager.signal_axes) and s.sum(axis=s.axes_manager.navigation_axes) both returning only signal axes would be confusing and break some code both downstream and in the package.

That being said there are a couple of places in pyxem where we do transpose signals after the map function to make them easier to work with so maybe I'm thinking of this in the wrong way.

Plotting wise I agree that passing navigator_kwrds when plotting is annoying but it would be easy to check if a signal is only navigation dimensions and if so then have navigator_kwds = kwargs.

I don't know if this is terribly helpful other than another voice saying this is annoying and I don't know the proper way to fix it.

@ericpre
Copy link
Member

ericpre commented Mar 20, 2023

There is an issue with transposing automatically: it seems obvious when the navigation dimension is 1 or 2 but otherwise how to determine which axes needs to be transposed to the signal space?
If is something that needs to be done at the workflow level or the domain specific functions, providing that there is no ambiguity with the navigation dimension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants