Details
-
Type:
Story
-
Status: To Do
-
Resolution: Unresolved
-
Fix Version/s: None
-
Component/s: obs_base, obs_cfht, obs_decam, obs_lsst, obs_subaru
-
Labels:
-
Urgent?:No
Description
DM-22655 re-emphasized to me how inconsistent our obs packages are regarding their datasetTypes for raw and calibration exposure datasets (bias/dark/flat), with pixel types ranging from I, U, F, and high level types of Image, MaskedImage, DecoratedImage, and Exposure. At the very least, we want one consistent type for `raw` so that converted gen2 repositories all use the same registry type for `raw`. If we can also make the calibration types self-consistent, so much the better.
I would advocate for the pixel type for raw to be float32, as the first operations we perform on raws in `ISR` are floating point (and as Merlin Fisher-Levine and Colin Slater have pointed out to me, all of the ISR corrections are dealing with things that happen before the ADC), so doing the conversion immediately may save us some trouble down the line, and saves us the trouble of ensuring that ISR calls convertIntToFloat before doing any math where the int/float difference might matter (e.g. obs_decam failing crosstalk if the raw type is non-float).
Similarly, I would advocate for the high level type to be Exposure, which Tim Jenness attempted to fix on DM-19570. This would let us deprecate ensureExposure and possibly DecoratedImage.
Even though we are planning to phase out the gen2 system, we want to be able to convert existing gen2 repos, and doing this will help ensure gen3 consistency as the gen3 registry type is typically pulled from the gen2 mapper type.
As long as having the raw type be float isn't incompatible with them being ints on disk then I agree with all of the above. (I'm sure that's the case, but that's the only thing I wanted to check).