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
    • Epic Link:
    • 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

          relates to

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. DM-27169 Use FilterLabel in Exposure/ExposureInfo

          • Done

          Bug - A problem which impairs or prevents the functions of the product. DM-28236 get('calexp_filterLabel') does not return a full label for pre-FilterLabel data

          • Done

            Activity

            Ascending order - Click to sort in descending order
            Hide
            Permalink
            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
            Permalink
            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.

              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.