Slicing TransientSpec about lumispy HOT 22 OPEN

This touch on the fact that the LumiTransientSpectrum doesn't fit well with the hyperspy signal paradigm: this class have signal axes with signal type of different nature and when there is a dimensionality reduction of the signal dimension, the signal will be mapped to a class of the same signal_type, which is not possible because there is no 1D signal counterpart.

To fix this, here are two options:

• keep the existing class structure and find a mechanism to patch all function with dimensionality reduction in the LumiTransientSpectrum class.
• Remove the LumiTransientSpectrum and set the energy/wavelength axis to a navigation axis.

The first option defies the hyperspy signal paradigm and I suspect that this will be very messy. The second is clean and simple.

from lumispy.

Well, the issue is that TransientSpec basically inherits from two different Signal1D classes for the two axes and HyperSpy so far does not support two different signal types for a single object. A third (and my prefered) solution would be to expand the HyperSpy signal paradigm and allow for something like signal_type being a list.

The issue is that neither the energy/wavelength nor the time axis should be a navigation axis. We can have linescans or maps of both types of 1DSignals, as well as of this 2DSignal and I would find it even more confusing to then add a non spatial dimensionality to navigation.

The essence is that this type of signal is a new use case that so far was not covered by hyperspy. If a signal had multiple signal dimensions, these were always of the same type.

from lumispy.

The issue is that neither the energy/wavelength nor the time axis should be a navigation axis. We can have linescans or maps of both types of 1DSignals, as well as of this 2DSignal and I would find it even more confusing to then add a non spatial dimensionality to navigation.

This is usual to have non spatial dimension as navigation dimension, these can be time, stage tilt, energy (for example energy filtered TEM), angular dependence of diffraction pattern, etc.

The essence is that this type of signal is a new use case that so far was not covered by hyperspy. If a signal had multiple signal dimensions, these were always of the same type.

The motivation behind the core concept of splitting dimensions between navigation and signal dimension is to be able to naturally operate on the signal dimension and map it to all (or a subset of the) navigation axes and vice versa for operation applied on navigation axes. When there is something special to do about a specific axis, this can be customised using transpose, etc. - see for example, the in situ diffraction data (pyxem/pyxem#900), where time correlation analysis has been implemented. @CSSFrancis may be able to comment more on this.

Maybe it would be useful to have an example of operations that needs to operate on several signal axes of different signal type to justify having together in the signal space?

from lumispy.

There is a number of reasons, why I would like to have both as signal axes (and why it is not comparable to a stage tilt or angular dependence series):

1. We will have the use case of maps of streak camera images, and we would get a mixture of axes types in the navigation dimensions.
2. People are used to display/view streak camera data as images - if one of the axes is a signal axis and one a navigation axis, hyperspy would plot the data differently than expected.
3. We have both types of axes as different signals recorded with dedicated detectors (CCDs for spectra and time-correlated single photon counting for transients).
4. For both types of signals, the modelling functionality will be used.

As a consequence, the two axes are of equal relevance and I do not see which of the two should become the navigation and which the signal axis.

Probably the most common use case will be that people use slicing to reduce the image to either time or wavelength dimensions by integrating over certain intervals of the other axis and then model the 1D data. However, doing so both ways for the same image!

Changing the hyperspy paradigm and allowing different signal_types within one class might be the more universal approach, but without other use cases, it would indeed be a tedious task to implement that properly.

Writing wrappers in LumiTransientSpectrum for all functionalities with dimensionality reduction that handle the assignment of the correct signal_type might then be the most feasible way to go.

from lumispy.

Point 1 to 3 seems fine to me (or will need small changes) using current hyperspy. Having navigation axes with different type (spatial, time, etc.) is usual.
For point 4, are you thinking of 2D model? Currently, there is only Gaussian2D, so I assume this would be two different sigma for the two different axes. If the only situation where you both axes to be in the signal axes, this can be done by transposing the axes and create the model in a workshop.

As a consequence, the two axes are of equal relevance and I do not see which of the two should become the navigation and which the signal axis.

One way to addressed this is by being explicit and documenting how to convert from one to another and what does it mean for visualisation and processing.

from lumispy.

For point 4, are you thinking of 2D model? Currently, there is only Gaussian2D, so I assume this would be two different sigma for the two different axes. If the only situation where you both axes to be in the signal axes, this can be done by transposing the axes and create the model in a workshop.

A Gaussian2D would not be appropriate for the type of data - but so far I am not aware of anyone actually modeling that in both dimensions. Instead, it is common to model and plot individual slices (at different times or different wavelength ranges) to evaluate the evolution of the data.

from lumispy.

@jlaehne This is an interesting point. My opinion on this is strongly correlated with performance of the map function. Where the signal axes should be the ones you are actively operating on and navigation axes should be everything else.

In this case it seems like you might have two signals with one being the transpose of the other if you want to operate on both separately. If you want to do as @ericpre suggests fitting a 2D function to a 2D image actually sounds like it would be an interesting thing to try.

What about supporting convolving 1D models to create 2D models?

In the long run we could make the map function operate on any axes but I would still use that as an exception rather than the rule.

from lumispy.