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

Missing FilterLabel in testdata_jointcal raws

    XMLWordPrintable

Details

    • Bug
    • Status: Won't Fix
    • Resolution: Done
    • None
    • afw
    • 2
    • AP S21-4 (March)
    • Alert Production
    • No

    Description

      While investigating DM-28236, Parejkoj 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

            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.

            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.

            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 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

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

              Dates

                Created:
                Updated:
                Resolved:

                Jenkins

                  No builds found.