You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
How are ragged signals handled. They technically have 0 signal dimensions but shouldn't be automatically transposed.
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.
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.
Functions such as
valuemax
andindexmax
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
oras_signal
for parameters of a fit both return the transposed signal, thusSignal2D
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.
The text was updated successfully, but these errors were encountered: