Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-14814

Change invalid pixel handling by Exposure::getCutout

    Details

    • Type: Improvement
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: afw
    • Labels:
      None
    • Story Points:
      2
    • Sprint:
      AP F18-2, AP F18-3
    • Team:
      Alert Production

      Description

      Currently, Exposure::getCutout returns "blank" pixels (in the sense of e.g. Exposure(dimensions)) for parts of the cutout that extend off the edge of the original image. The more natural behavior to veteran stack users is to fill the off-image pixels with the value of afw::math::edgePixel.

      I propose that, if the NO_DATA flag has been deleted (e.g., with Mask::removeMaskPlane), getCutout should return edge pixels with a blank mask but with value and variance conforming to edgePixel's behavior. However, I'm open to throwing an exception instead.

      This ticket shall modify getCutout as described and add unit tests for pixel values, which we neglected to do before.

        Attachments

          Activity

          Hide
          rhl Robert Lupton added a comment -

          Why not just add NO_DATA back into the mask?

           

          Show
          rhl Robert Lupton added a comment - Why not just add NO_DATA back into the mask?  
          Hide
          krzys Krzysztof Findeisen added a comment -

          Because side effects lead to bugs – especially when they affect global state that's used by everybody else. For example, as I understand it there's no guarantee that the new NO_DATA would use the same bit as the original one, and certainly whatever code saw fit to remove the flag would not work as expected.

          If it shouldn't be possible to have a mask without NO_DATA, enforcing that in Mask itself is much safer than trying to patch it in unrelated code.

          Show
          krzys Krzysztof Findeisen added a comment - Because side effects lead to bugs – especially when they affect global state that's used by everybody else. For example, as I understand it there's no guarantee that the new NO_DATA would use the same bit as the original one, and certainly whatever code saw fit to remove the flag would not work as expected. If it shouldn't be possible to have a mask without NO_DATA , enforcing that in Mask itself is much safer than trying to patch it in unrelated code.
          Hide
          krzys Krzysztof Findeisen added a comment -

          Hi Jim Bosch, could you review this issue? Thanks!

          Show
          krzys Krzysztof Findeisen added a comment - Hi Jim Bosch , could you review this issue? Thanks!
          Hide
          jbosch Jim Bosch added a comment -

          I've found the afw GitHub PR that Jira seems to be unaware of - were there any others?

          Show
          jbosch Jim Bosch added a comment - I've found the afw GitHub PR that Jira seems to be unaware of - were there any others?
          Hide
          jbosch Jim Bosch added a comment -

          Looks good.

          Show
          jbosch Jim Bosch added a comment - Looks good.
          Hide
          krzys Krzysztof Findeisen added a comment - - edited

          No, just afw#383. It's strange that it still can't find it the next day, though.

          Show
          krzys Krzysztof Findeisen added a comment - - edited No, just afw#383 . It's strange that it still can't find it the next day, though.

            People

            • Assignee:
              krzys Krzysztof Findeisen
              Reporter:
              krzys Krzysztof Findeisen
              Reviewers:
              Jim Bosch
              Watchers:
              Jim Bosch, Krzysztof Findeisen, Meredith Rawls, Robert Lupton
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Summary Panel