Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Labels:
-
Story Points:8
-
Epic Link:
-
Team:Data Release Production
-
Urgent?:No
Description
Eric Charles is doing EO testing and would like to be able to access the unadulterated raw pixel data for each amplifier. Currently he has to retrieve the raw with bounding boxes and has to revert flipping. This can be inefficient for a single amp.
The request is to add a raw.amp derived component that can return the amp pixel data and header exactly as it is stored in the FITS file.
Additional questions:
- Should there be a raw.amps to return all the amps in a dict/list?
- How does the amp number get passed to butler.get?
- Should bounding boxes be allowed to request a subset of an amplifier?
There might need to be some changes to daf_butler to support parameters for the derived component since currently all parameters are handled by the composite before the result is given to the derived component (so passing in bbox refers to a subset of the entire image before the derived component sees it).
Attachments
Issue Links
- is blocked by
-
DM-29505 Prototype per-amplifier raw image and camera geom classes
- Done
- relates to
-
DM-29987 Save Detectors with master calibrations
- Done
-
DM-29732 Allow butler to retrieve single amplifier images from (at least) biases
- To Do
-
DM-16412 Detectors obtained from Camera have wrong amplifer bboxes for untrimmed+assembled in obs_lsst
- Won't Fix
- mentioned in
-
Page Loading...
I think we definitely need to attach a Detector of some kind to the Exposure this method returns, or it won't be of much use, and it seems like constructing that out of in-untrimmed-assembled-coordinates Detector objects that come directly from the cameraGeom will be the vast majority of the work on this ticket.
Circa
DM-18610I had big plans for making cameraGeom more amenable to that sort of thing, which got handed off to Christopher Waters because Gen3 was (still) calling, and then it promptly got buried beneath a pile of CPP and ISR issues for Chris. As it stands, the cameraGeom design is supposed to only ever represent the bounding boxes in a particular, standard state (post-assembly for detector-level boxes, assembled+untrimmed for amplifier boxes), because all other boxes for other states can be derived from that, and it's supposed to be true that if you do butler.get("camera", ...)[N] or butler.get("raw", detector=N, ...).getDetector() or butler.get("calexp", detector=N, ...).getDetector(), you get exactly the same thing each time, because the cameraGeom isn't supposed to know the assembly state and certainly isn't supposed to have bounding boxes that depend on it.All that said, I believe there is long-standing code in various places (including the obs_lsst raw formatters, IIRC) that basically ignores that and does treat the Detector and Amplifiers as things whose bounding boxes should be modified as the Exposure they are attached to is, and, well, it mostly works anyway - if you don't read the afw docstrings about what various bboxes are supposed to mean too carefully, and are willing to ignore the various attributes that don't make sense at all for some states, and don't actually expect those statements about butler.get consistency. It drives me absolutely bonkers, but the people who work with it regularly seem to be doing okay, and I just don't have time (and I don't think Chris has time) to really fix it.
So, I am not optimistic about us solving that well anytime soon - at some level I think it's a symptom of us just declaring every image an Exposure instead of having different classes to represent different kinds of images and the states they can be in - and while whatever we do on this ticket needs to involve providing useful cameraGeom somehow, we need to be prepared to hold our noses about that making sense as part of a bigger picture if we want it to get done.