Fix hamamatsu signal type

[jlaehne]

Description of the change

The hamamatsu reader was trying to set the signal_type to the Signal1D subclass Luminescence instead of the Signal2D subclass TransientSpec when lumispy is available.

Progress of the PR

• Change implemented (can be split into several points),
• update docstring (if appropriate),
• update user guide (if appropriate),
• add a changelog entry in the upcoming_changes folder (see upcoming_changes/README.rst),
• Check formatting of the changelog entry (and eventual user guide changes) in the docs/readthedocs.org:rosettasciio build of this PR (link in github checks)
• [n/a] add tests,
• ready for review.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.22%. Comparing base (94f9aa9) to head (1f71d6e).
Report is 95 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #209      +/-   ##
==========================================
+ Coverage   86.21%   86.22%   +0.01%     
==========================================
  Files          82       82              
  Lines       10552    10549       -3     
  Branches     2293     2293              
==========================================
- Hits         9097     9096       -1     
+ Misses        935      933       -2     
  Partials      520      520              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ericpre]

This is a lumispy implementation details, but wouldn't be better to have "Transcient" as signal_type and use the signal_dimension to map to the correct class depending if there is an energy axis or not?

[jlaehne]

The streak camera gives images with one axis being wavelength and one time, so this reader should not come across 1D signals.

[ericpre]

Sorry, I was not clear: I was suggesting to use Transient here in order to use it for both the LumiTransient and LumiTransientSpectrum class, which would require changes in lumispy and would fix behaviour reported in LumiSpy/lumispy#204: when changing signal_dimension, hyperspy will map to the correct class.

I have just asked myself the same questions as in LumiSpy/lumispy#5 (in particular, does it make sense to have a signal containing dimension with signal type of different nature (energy/wavelength versus time)?

If the discussion on the structure of transient signal can be resolved for good soon, should we wait for the relevant changes in lumispy and update accordingly this PR? If not, we can merge this PR, but I imagine that it will need to be changed when the structure of the transient classes are fixed (currently, I don't think that it is fully compatible with the hyperspy signals paradigm)

[jlaehne]

OK, my misunderstanding was that signal_type is directly linked to the signal class. But a Signal2D can actually have a signal type from a 1D class.

For the moment it would be the quickest fix to directly set LumiTransientSpectrum to allow for the energy conversion, but from what you outline, it could also be done downstream by discovering the signal_dimension and then using the correct LumiTransientSpectrum class? So currently, there is no added value of using Transient here instead of Luminescence, but in the long run, there should be dedicated functionalities for the two different signal types combined in one class.

Thus, to resolve this issue it would be a possibility to allow for a list of signal_type upstream in hyperspy, where the order determines what axes the signal types correspond to.