Set correct signal type of Hamamatsu tiff images, if lumispy is installed

[jlaehne]

Set signal_type of Hamamatsu streak images loaded from tiff format to TransientSpectrum (LumiTransientSpectrum class), if lumispy is installed.

Add tests to tiff and hamamatsu readers that run 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)
• add tests,
• ready for review.

[azure-pipelines]

There was an error handling pipeline event 4c4b94c0-44df-427b-a073-de66fb4b7e03.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.90%. Comparing base (c53293a) to head (238e3d6).
Report is 112 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #386   +/-   ##
=======================================
  Coverage   87.90%   87.90%           
=======================================
  Files          86       86           
  Lines       11269    11271    +2     
  Branches     2088     2088           
=======================================
+ Hits         9906     9908    +2     
  Misses        864      864           
  Partials      499      499           

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ericpre]

Would it be worth adding a build on GitHub CI that install extensions (lumispy, pyxem, etc.) to test this kind of thing?

[jlaehne]

Possibly. That is what the integration tests on the hyperspy-extensions-list repro are doing - but then it is not noticed as directly if something goes wrong. I can also add back the pragma: no cover and we leave it to the integration tests to run this part?

[ericpre]

That is what the integration tests on the hyperspy-extensions-list repro are doing - but then it is not noticed as directly if something goes wrong.

Indeed, but this can be tedious when fixing it or figure out what needs to be fixed. We could use the same approach as in hyperspy with a separate workflow that runs on demand (https://github.com/hyperspy/hyperspy/blob/RELEASE_next_minor/.github/workflows/tests_extension.yml) but we trend to forget about it and also it doesn't help with the coverage.

[jlaehne]

Adding such tests in #388

[ericpre]

Regarding the coverage, should we add back # pragma: no cover, to silent coverage warning and add a comment that this is tested in the integration test workflow but the coverage is not reported?

[jlaehne]

done