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

Missing FilterLabel in testdata_jointcal raws

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Won't Fix
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: afw
    • Labels:
    • Story Points:
      2
    • Sprint:
      AP S21-4 (March)
    • Team:
      Alert Production
    • Urgent?:
      No

      Description

      While investigating DM-28236, John Parejko and I found that some raws in testdata_jointcal were being read by afw as not having a filter, even though their headers presumably contain FILTER=HSC-R:

      CameraMapper DEBUG: Matching filters for id='HSC-R' and label=None are {FilterDefinition(physical_filter='HSC-R', lambdaEff=623, band='r', afw_name=None, lambdaMin=nan, lambdaMax=nan, alias=frozenset({'W-S-R+'}))}.
      

      While the filter is (correctly) patched at the obs_base level, this still points to a bug in the afw compatibility code. Find out why the label is not being populated and fix.

        Attachments

          Issue Links

            Activity

            No builds found.
            krzys Krzysztof Findeisen created issue -
            krzys Krzysztof Findeisen made changes -
            Field Original Value New Value
            Link This issue relates to DM-28236 [ DM-28236 ]
            krzys Krzysztof Findeisen made changes -
            Link This issue relates to DM-27169 [ DM-27169 ]
            krzys Krzysztof Findeisen made changes -
            Sprint AP S21-3 (February) [ 1072 ]
            krzys Krzysztof Findeisen made changes -
            Rank Ranked higher
            sullivan Ian Sullivan made changes -
            Sprint AP S21-3 (February) [ 1072 ] AP S21-4 (March) [ 1079 ]
            sullivan Ian Sullivan made changes -
            Rank Ranked higher
            sullivan Ian Sullivan made changes -
            Rank Ranked higher
            sullivan Ian Sullivan made changes -
            Epic Link DM-27906 [ 442554 ] DM-29214 [ 459218 ]
            Hide
            krzys Krzysztof Findeisen added a comment - - edited

            An example file is testdata_jointcal/hsc/SSP_WIDE/2015-07-15/01291/HSC-R/HSC-0034648-051.fits. This is technically an ImageF file, not an ExposureF file. Its header has a FILTER01 key mapping to "HSC-r". This key cannot be read by afw directly; it's translated to LSST conventions by the following code:

            • lsst.astro_metadata_translator.SuprimeCamTranslator and HscTranslator
            • lsst.obs.subaru.ingest.HscParseTask

            Note that lst.obs.subaru.HscMapper does nothing special with the filters, besides encoding the data ID filter in the exposureID.

            Since HscParseTask only affects the Butler registry, and not the individual files, I'm not clear at what point in the Gen 2 processing is the file supposed to have an "HSC-R" filter – unless it's in the very code that DM-27178 modified to print the above warning message.

            Show
            krzys Krzysztof Findeisen added a comment - - edited An example file is testdata_jointcal/hsc/SSP_WIDE/2015-07-15/01291/HSC-R/HSC-0034648-051.fits . This is technically an ImageF file, not an ExposureF file. Its header has a FILTER01 key mapping to "HSC-r" . This key cannot be read by afw directly; it's translated to LSST conventions by the following code: lsst.astro_metadata_translator.SuprimeCamTranslator and HscTranslator lsst.obs.subaru.ingest.HscParseTask Note that lst.obs.subaru.HscMapper does nothing special with the filters, besides encoding the data ID filter in the exposureID. Since HscParseTask only affects the Butler registry, and not the individual files, I'm not clear at what point in the Gen 2 processing is the file supposed to have an "HSC-R" filter – unless it's in the very code that DM-27178 modified to print the above warning message.
            Hide
            krzys Krzysztof Findeisen added a comment -

            I think the reported behavior is not actually a bug, but how loading of raw files (which do not conform to any standard besides FITS itself) has always worked; it's just that now we have a log message that announces the conversion that CameraMapper._standardizeExposure was always responsible for. I'm therefore closing this as Won't Fix.

            Show
            krzys Krzysztof Findeisen added a comment - I think the reported behavior is not actually a bug, but how loading of raw files (which do not conform to any standard besides FITS itself) has always worked; it's just that now we have a log message that announces the conversion that CameraMapper._standardizeExposure was always responsible for. I'm therefore closing this as Won't Fix.
            krzys Krzysztof Findeisen made changes -
            Resolution Done [ 10000 ]
            Status To Do [ 10001 ] Won't Fix [ 10405 ]

              People

              Assignee:
              krzys Krzysztof Findeisen
              Reporter:
              krzys Krzysztof Findeisen
              Watchers:
              John Parejko, Krzysztof Findeisen
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.