Eric Prestat

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...

> 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...

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,...

I really think that having a 2D signal with two different type of signal (here: time and energy) is what cause the issue/confusion here. As discussed above, there isn't any...

> Well, the first thing one usually does with the data is to plot it for visualization and the expected way to look at the streak camera data is an...

The ideas being a single separate library are: - independent development from hyperspy - this library can be used outside hyperspy - avoid dispersion of community efforts/knowledge - provide consistent...

My impression is that plugins or entry points is not right solution here and this is the wrong direction of travel, as this would facilitate dispersion of efforts. For example,...

> In principle, I am happy with either solution - just we need to know where to start the development of the new readers. I think that the approach [suggested...

If you need it to start now or very soon, yes, this is what I would do: start in the branch of a hyperspy fork and once the IO library...

Related to this issue, I needed something similar for Raman data to convert the signal to an uniform axis. I opened a pull request (https://github.com/hyperspy/hyperspy/pull/3410) to support making the axis...