Details
-
Type:
Story
-
Status: To Do
-
Resolution: Unresolved
-
Fix Version/s: None
-
Component/s: afw
-
Labels:
-
Story Points:6
-
Epic Link:
-
Sprint:AP F18-4
-
Team:Alert Production
Description
Per Jim Bosch's Community post, we should keep track of whether an Exposure is a surface brightness or fluence image (bool in ExposureInfo should be fine), and which of those a PhotoCalib maps from and to (probably a 3-value enum: SB->SB, SB->F, F->F). This ticket is just to add this metadata, we'll make use if it in other tickets, e.g. to ensure than an image input into PhotoCalib.calibrateImage() is of the correct type.
Attachments
Issue Links
- relates to
-
- Done
Activity
Then this really sounds like a knee-jerk reaction that needs to be thought through some more and RFC-ed before implementation.
Paul Price
added a comment - Then this really sounds like a knee-jerk reaction that needs to be thought through some more and RFC-ed before implementation. The reason I want to attach the flag to the Exposure, not PhotoCalib, is because there can be multiple PhotoCalibs (e.g. one from processCcd, one from jointcal), and those may not be directly attached to the Exposure (e.g. the jointcal one lives in a different butler datasetName). Hence the two different flags, one in ExposureInfo, the other in PhotoCalib.
Question of RFC aside, this is definitely a property of the Exposure. And it would be very helpful to indicate if an Exposure is surface brightness or fluence if it could be either.
Per discussion (John Parejko, Jim Bosch, Eric Bellm, John Swinbank) of 2018-10-30, we agreed that this is a) more complicated than thought, b) not actually necessary to complete DM-11783. Punting it to the future.
Or in the flat-construction tasks, to be propagated to ISR with the flats. Haven't thought too deeply about it.
I haven't thought too deeply about this either, yet, but it seems like a pretty important aspect of the image (though I think I'd slightly prefer to attach it to PhotoCalib rather than ExposureInfo directly). Might mostly be useful for downstream ad-hoc analysis, but I could imagine e.g. asserting that the image is fluence when doing photometry (once we actually make the pipelines do that) or that they're surface-brightness when running background estimation.