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

Create multiband classes

    XMLWordPrintable

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: afw
    • Labels:
      None
    • Story Points:
      54
    • Sprint:
      DRP S18-5, DRP S18-6, DRP F18-1, DRP F18-2
    • Team:
      Data Release Production

      Description

      Create python classes for multiband exposures, images, and heavy footprints. These would essentially be python wrappers that take in a list of exposures (for example) and create a data cube with views to it that are slices in multiple dimensions. This would simplify the interface to multiband data and prevent developers from duplicating code.

        Attachments

          Issue Links

            Activity

            Hide
            fred3m Fred Moolekamp added a comment -

            Good point Ian Sullivan, I like the idea of supporting iteration in the multiband classes.

            That's a good point about filter names. Really filter is just a keyword, and perhaps should just be changed to key since it is only used to identify different images. For most cases key will just be the filter name.

            With just a quick glance at afw, I'm not sure I see how TransmissionCurve would be used as a multiband class. Can you give me an example of the type of behavior that you see useful?

            This also goes for camera and chip dependent chromatic effects. I've never dealt with this before so I'm not sure what would be useful.

            Show
            fred3m Fred Moolekamp added a comment - Good point Ian Sullivan , I like the idea of supporting iteration in the multiband classes. That's a good point about filter names. Really filter is just a keyword, and perhaps should just be changed to key since it is only used to identify different images. For most cases key will just be the filter name. With just a quick glance at afw, I'm not sure I see how TransmissionCurve would be used as a multiband class. Can you give me an example of the type of behavior that you see useful? This also goes for camera and chip dependent chromatic effects. I've never dealt with this before so I'm not sure what would be useful.
            Hide
            jbosch Jim Bosch added a comment -

            That's a good point about filter names. Really filter is just a keyword, and perhaps should just be changed to key since it is only used to identify different images. For most cases key will just be the filter name.

            I think this is a good idea, but it might imply renaming all of these classes to something that implies "consistent dictionary" rather than "multiple filters".

            With just a quick glance at afw, I'm not sure I see how TransmissionCurve would be used as a multiband class. Can you give me an example of the type of behavior that you see useful?

            This also goes for camera and chip dependent chromatic effects. I've never dealt with this before so I'm not sure what would be useful.
             

            While I suppose we could create a MultiBandTransmissionCurve, if it doesn't do anything more than a simple dictionary of TransmissionCurves I'd rather not. Having multi-band versions of everything we have per-band would be a huge proliferation of classes.

            Camera- and chip-dependent chromatic effects should be represented by TransmissionCurves (every Exposure should have a TransmissionCurve, and that tells you what its throughput is). I think that's mostly orthogonal to these multi-band classes, but Ian Sullivan, please feel free to make a proposal to augment them if you need them to do more than what they do now.

            Show
            jbosch Jim Bosch added a comment - That's a good point about filter names. Really  filter  is just a keyword, and perhaps should just be changed to  key  since it is only used to identify different images. For most cases  key  will just be the  filter  name. I think this is a good idea, but it might imply renaming all of these classes to something that implies "consistent dictionary" rather than "multiple filters". With just a quick glance at afw, I'm not sure I see how  TransmissionCurve  would be used as a multiband class. Can you give me an example of the type of behavior that you see useful? This also goes for camera and chip dependent chromatic effects. I've never dealt with this before so I'm not sure what would be useful.   While I suppose we could create a MultiBandTransmissionCurve , if it doesn't do anything more than a simple dictionary of TransmissionCurves I'd rather not. Having multi-band versions of everything we have per-band would be a huge proliferation of classes. Camera- and chip-dependent chromatic effects should be represented by TransmissionCurves (every Exposure should have a TransmissionCurve , and that tells you what its throughput is). I think that's mostly orthogonal to these multi-band classes, but Ian Sullivan , please feel free to make a proposal to augment them if you need them to do more than what they do now.
            Hide
            jbosch Jim Bosch added a comment -

            Review complete, comments on the PR. I did not look at the docs, as I got the impression that others had already done that.

            Show
            jbosch Jim Bosch added a comment - Review complete, comments on the PR. I did not look at the docs, as I got the impression that others had already done that.
            Hide
            fred3m Fred Moolekamp added a comment -

            I think this is a good idea, but it might imply renaming all of these classes to something that implies "consistent dictionary" rather than "multiple filters"

            I think that the main feature is a consistent bounding box and alignment, so perhaps AlignedImage, AlignedFootprint, etc? If not, does anyone else have any suggestions? Otherwise, since the most common use case will be for multiband images, I'm also fine with just keeping the current names and more sophisticated users like Ian Sullivan will understand that in some cases a sub-filter keyword might be needed to distinguish images using the same filter.

            Show
            fred3m Fred Moolekamp added a comment - I think this is a good idea, but it might imply renaming all of these classes to something that implies "consistent dictionary" rather than "multiple filters" I think that the main feature is a consistent bounding box and alignment, so perhaps AlignedImage , AlignedFootprint , etc? If not, does anyone else have any suggestions? Otherwise, since the most common use case will be for multiband images, I'm also fine with just keeping the current names and more sophisticated users like Ian Sullivan will understand that in some cases a sub-filter keyword might be needed to distinguish images using the same filter.
            Hide
            jbosch Jim Bosch added a comment -

            I'm fine with the current names, or something like AlignedImageDict (I do think we need a suffix that indicates a container rather than a single item, but the Aligned prefix is a good idea).

            Show
            jbosch Jim Bosch added a comment - I'm fine with the current names, or something like AlignedImageDict (I do think we need a suffix that indicates a container rather than a single item, but the Aligned prefix is a good idea).

              People

              Assignee:
              fred3m Fred Moolekamp
              Reporter:
              fred3m Fred Moolekamp
              Reviewers:
              Jim Bosch
              Watchers:
              Bob Armstrong, Fred Moolekamp, Ian Sullivan, Jim Bosch, Paul Price
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.