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

Use nan for saturation level to prevent masking

    Details

    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None

      Description

      The saturation level for each amplifier is specified in the AmpInfoTable and is of type int. However, the ISR code that masks saturated pixels checks if the saturation level is nan and avoids masking if so. An int can never be nan so saturation is always flagged. I am guessing we never noticed because all cameras set a reasonable saturation value.

      I want to fix this because I am adding an analogous level for setting the SUSPECT mask plane. It is used in the same way as the saturation level and set at the same point in the ISR code, but few cameras are likely to use it (at least initially), so a workable value for "do not mask" is important.

      I see two good solutions:

      • Keep saturation level an int but use a value of <= 0 to indicate "do not mask"
      • Make saturation level a float and continue to use nan for "do not mask"

      Is there a strong technical argument for one or the other? I can't think of one. float and int both have adequate dynamic range. I plan to add a field to AmpInfoTable, so the schema will change in any case. The ISR task detects saturation on a float32 image, but any casting is done once for many pixels, so the choice will not have a measurable effect on speed.

      My main desire is to pick something quickly and move on.

      Solutions I rejected:

      • Add a separate flag to the AmpInfoTable for "the saturation level is invalid". I want to avoid the clutter of an additional field and having two closely related values when one would suffice. And such a solution does not answer the question of which type to use for the saturation and suspect levels.
      • Specify a huge value to avoid masking. This works, but is hard to read. Also, we either have to test if the value is larger than the camera can output (which is non-trivial) or loop over all pixels. I prefer an obvious value such as nan or 0.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                rowen Russell Owen
                Reporter:
                rowen Russell Owen
                Watchers:
                Jim Bosch, Paul Price, Robert Lupton, Russell Owen, Simon Krughoff, Tim Jenness, Yusra AlSayyad
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End:

                  Summary Panel