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

Associate documentation with new Mask planes

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: To Do
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: afw
    • Labels:
      None
    • Team:
      SQuaRE

      Description

      It's possible to add and remove mask planes dynamically, and their bit values get correctly written to FITS headers if that's how you choose to persist the Masks. Unfortunately, the only way to guess what they mean is to scrutinise the name.

      Please add the ability to associate a doc string with each mask plane, which should be persisted along with the data, and made available in sensible ways in the Mask API.

        Attachments

          Issue Links

            Activity

            No builds found.
            rhl Robert Lupton created issue -
            swinbank John Swinbank made changes -
            Field Original Value New Value
            Team Data Release Production [ 10301 ]
            Issue Type Story [ 10001 ] Improvement [ 4 ]
            swinbank John Swinbank made changes -
            Rank Ranked lower
            swinbank John Swinbank made changes -
            Team Data Release Production [ 10301 ] SQuaRE [ 10302 ]
            Hide
            swinbank John Swinbank added a comment -

            This is similar in spirit to the request to document the flags generated by measurement algorithms. As such, I'm assigning it to team SQuaRE and linking it to DM-6887 & DM-6655 in the hope that Jonathan Sick & colleagues will give us a steer about how best to approach it. Ultimately, though, I expect afw-side implementation and actually writing the docs may be a Pipelines deliverable.

            Show
            swinbank John Swinbank added a comment - This is similar in spirit to the request to document the flags generated by measurement algorithms. As such, I'm assigning it to team SQuaRE and linking it to DM-6887 & DM-6655 in the hope that Jonathan Sick & colleagues will give us a steer about how best to approach it. Ultimately, though, I expect afw-side implementation and actually writing the docs may be a Pipelines deliverable.
            swinbank John Swinbank made changes -
            Link This issue relates to DM-6887 [ DM-6887 ]
            swinbank John Swinbank made changes -
            Link This issue relates to DM-6655 [ DM-6655 ]
            Hide
            swinbank John Swinbank added a comment -

            On the subject of mask planes, I note the Jim Bosch comment on Slack of 2018-02-05:

            It now effectively means "this pixel was interpolated in one of the inputs and that's okay because we think the interpolation was good...

            I think that's actually what `interpolated` was always supposed to mean, actually, but there were bugs in how we set INTRP and SAT in ISR that made it safest to flag on whether a pixel was interpolated rather than why it was interpolated. There should now always be an additional "why" flag set whenever INTRP is, and we should prefer to do filtering on those. For example, we're much better at interpolating CRs (can usually be trusted) than saturation (generally cannot).

            This seems like something that should be included in the new documentation.

            Show
            swinbank John Swinbank added a comment - On the subject of mask planes, I note the Jim Bosch comment on Slack of 2018-02-05: It now effectively means "this pixel was interpolated in one of the inputs and that's okay because we think the interpolation was good... I think that's actually what `interpolated` was always supposed to mean, actually, but there were bugs in how we set INTRP and SAT in ISR that made it safest to flag on whether a pixel was interpolated rather than why it was interpolated. There should now always be an additional "why" flag set whenever INTRP is, and we should prefer to do filtering on those. For example, we're much better at interpolating CRs (can usually be trusted) than saturation (generally cannot). This seems like something that should be included in the new documentation.
            jsick Jonathan Sick made changes -
            Assignee Robert Lupton [ rhl ] Jonathan Sick [ jsick ]
            Hide
            jsick Jonathan Sick added a comment -

            Sounds good. Yes, step 1 is figuring out where to integrate the docs with the code, and then how to pull that information out usefully.

            Show
            jsick Jonathan Sick added a comment - Sounds good. Yes, step 1 is figuring out where to integrate the docs with the code, and then how to pull that information out usefully.

              People

              Assignee:
              jsick Jonathan Sick
              Reporter:
              rhl Robert Lupton
              Watchers:
              John Swinbank, Jonathan Sick, Robert Lupton
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:

                  CI Builds

                  No builds found.