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

Explore Brighter-Fatter Kernel fitting

    Details

    • Type: Story
    • Status: To Do
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: cp_pipe
    • Labels:
      None
    • Team:
      Data Release Production

      Description

      Investigate the robustness and performance of fitting the brighter-fatter kernel.

      The current approach works, but not always for all sensors and shows amp-to-amp variation. 1. What's the correct way to deal with this?
      2. Should the BF kernel itself be averaged across amplifiers and then applied to all?
      3. Should the BF kernel be average across sensors and then applied to all (matching) sensors?
      4. How should averaging work?
      5. Current work has just fit for high-level flats vs. low-level flats and constructed a fixed BF kernel. When should we start fitting the full Photon Transfer Curve?

      The current HSC processing uses the BF kernel from just once CCD and applies it to all of them.

      The above should be explored in the context of
      1. Real data, e.g. HSC, DES.
      2. Test-stand data of the LSST sensors.
      3. Consider exploring simulated data from DESC DC2

        Attachments

          Activity

          Hide
          wmwood-vasey Michael Wood-Vasey added a comment -

          Merlin Fisher-Levine Could you fill out what you think the next things to look at in the BF kernel generation should be?

          Show
          wmwood-vasey Michael Wood-Vasey added a comment - Merlin Fisher-Levine Could you fill out what you think the next things to look at in the BF kernel generation should be?
          Hide
          mfisherlevine Merlin Fisher-Levine added a comment -

          Responding point-wise

          1) I think we need to know the source of failures to answer that well... and what's meant by this amp-to-amp variation too

          2) I can't see how this would be meaningful really - once the gain is corrected for, the sensor area should be dealt with as one I think. And in the case where it isn't, I think one would want to do a spatial-BF-correction, and hence wouldn't be averaging. Obviously ampwise serves as a crude proxy for spatial, but again, that's not averaging, and is also not necessarily a sensible unit of sensor division (not saying it's not, but it's an interesting question).

          3) Maybe, but with sufficient input data it's hard to see imagine why that should be a win (though that doesn't mean it wouldn't be - to horribly paraphrase Feynman). If you did do this, how would "matching" sensors be determined? I feel like solving 1) is the real key here, though I admit if that turns out to be unsolvable then yes, these are good questions/lines of attack.

          4) I don't know, but I think in the above I'm saying it shouldn't be done, so maybe this is moot?

          5) Interesting, and how/when/should we ever, think about extending to NLO BF correction? If this becomes possible, what needs to change on the kernel generation front?

          Show
          mfisherlevine Merlin Fisher-Levine added a comment - Responding point-wise 1) I think we need to know the source of failures to answer that well... and what's meant by this amp-to-amp variation too 2) I can't see how this would be meaningful really - once the gain is corrected for, the sensor area should be dealt with as one I think. And in the case where it isn't, I think one would want to do a spatial-BF-correction, and hence wouldn't be averaging. Obviously ampwise serves as a crude proxy for spatial, but again, that's not averaging, and is also not necessarily a sensible unit of sensor division (not saying it's not, but it's an interesting question). 3) Maybe, but with sufficient input data it's hard to see imagine why that should be a win (though that doesn't mean it wouldn't be - to horribly paraphrase Feynman). If you did do this, how would "matching" sensors be determined? I feel like solving 1) is the real key here, though I admit if that turns out to be unsolvable then yes, these are good questions/lines of attack. 4) I don't know, but I think in the above I'm saying it shouldn't be done, so maybe this is moot? 5) Interesting, and how/when/should we ever, think about extending to NLO BF correction? If this becomes possible, what needs to change on the kernel generation front?
          Hide
          swinbank John Swinbank added a comment -

          Hi folks — can you fill me in as to the context of this ticket, please? Michael Wood-Vasey, are you filing this because it's a task you intend to undertake in the context of Science Validation, or because it's something you think Robert Lupton ought to do as Calibration Products Lead?

          Show
          swinbank John Swinbank added a comment - Hi folks — can you fill me in as to the context of this ticket, please? Michael Wood-Vasey , are you filing this because it's a task you intend to undertake in the context of Science Validation, or because it's something you think Robert Lupton ought to do as Calibration Products Lead?
          Hide
          wmwood-vasey Michael Wood-Vasey added a comment -

          #2. Something Robert Lupton should undertake (and then delegrate!) as Calibration Products lead.

          The completely context is that Robert Lupton asked me to file this ticket as a good thing for Andrés Alejandro Plazas Malagón to dive into.

          Show
          wmwood-vasey Michael Wood-Vasey added a comment - #2. Something Robert Lupton should undertake (and then delegrate!) as Calibration Products lead. The completely context is that Robert Lupton asked me to file this ticket as a good thing for Andrés Alejandro Plazas Malagón to dive into.

            People

            • Assignee:
              Unassigned
              Reporter:
              wmwood-vasey Michael Wood-Vasey
              Watchers:
              Andrés Alejandro Plazas Malagón, Chris Walter, John Swinbank, Merlin Fisher-Levine, Michael Wood-Vasey, Robert Lupton
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:

                Summary Panel