Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-518

Image reading should reject conversions that could overflow



    • RFC
    • Status: Implemented
    • Resolution: Done
    • DM
    • None


      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.


        Issue Links



              jbosch Jim Bosch
              jbosch Jim Bosch
              Jim Bosch, John Parejko, John Swinbank, Kian-Tat Lim, Paul Price, Robert Lupton, Russell Owen, Tim Jenness
              0 Vote for this issue
              8 Start watching this issue


                Planned End:


                  No builds found.