While refactoring our FITS reading code as part of
DM-15500, I noticed that we currently permit reading into images with pixel types that cannot represent all values of the on-disk type (for example, we allow an on-disk int64 image to be read in as a uint16 in-memory image). It's not clear to me from looking at the code whether this was intentional, and it seems a bit dangerous.
Instead, I propose we only support the following conversions:
- any integer or floating point -> any floating-point (potential loss of precision, but no overflow)
- any unsigned integer -> any larger signed integer
- any signed integer -> any not-smaller signed integer
- any unsigned integer -> any not-smaller unsigned integer
Please note that I am proposing this change just because avoiding overflow seems like the right thing to do; if there is a use case for the current behavior, I'm happy to retain it. I do see lots of tests in afw using conversions that could overflow, but I haven't yet seen a case where it looks anything other than incidental.
We could also go a bit further and prohibit conversions that would entail a loss of precision, but it's much easier for me to imagine valid use cases for those conversions.