Fix hamamatsu tiff reader if x axis not calibrated

[jlaehne]

Description of the change

Fixes reading error when Hamamatsu tiff file contains ScalingXScalingFile="Other" and not an address in the file (not calibrated axis).

Progress of the PR

• Change implemented (can be split into several points),
• [n/a] update docstring (if appropriate),
• [n/a] 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.

Minimal example of the bug fix or the new feature

from rsciio.tiff import file_reader
file_reader("hamamatsu.tiff")
# Your new feature...

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.84%. Comparing base (4e67875) to head (ae06aa1).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #347   +/-   ##
=======================================
  Coverage   87.84%   87.84%           
=======================================
  Files          85       85           
  Lines       11242    11246    +4     
  Branches     2082     2084    +2     
=======================================
+ Hits         9875     9879    +4     
  Misses        868      868           
  Partials      499      499           

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

[jlaehne]

pre-commit.ci autofix

[CSSFrancis]

Looks like a pretty simple bug fix!

[CSSFrancis]

How does this fail currently. If for example the "ScalingXScalingFile" were set to "custom" would this fail again?

Maybe consider something like a try --> except in the else statement so that the data is still loaded but it throws a warning saying the scale could not be properly loaded.

I think in general we should try to always return everything we can get even if parts of the metadata aren't loaded properly becuase file formats are always a bit of a moving target.

[jlaehne]

In principle yes, but normally it contains an address in the file where the axis is saved - if that is not the case it is set to "Other". That is not documented: http://www-bl20.spring8.or.jp/detectors/manual/HelpHiPic.pdf (Appendix D, E). However, I do not expect hamamatsu to have different keywords that can go there in place of an address, so I think it might even be better to get an error if there is yet another situation and not do a try and except for situations that are not documented.

[ericpre]

Generally speaking, I am on fence regarding @CSSFrancis's suggestion:

• in principle this is sensible, if there is a warning to suggest to report this issue to avoid a silent failure (here calibration not loading).
• in practise, raising an error motivates user to report error, while a warning will be ignored usually (and a source of noise or polluting log, notebook, etc. for some users) and it means that there is a risk that it doesn't get fixed!