DM-55521: update coadd processing tasks to work with lsst.images - #1334
Conversation
2dbea16 to
7b592c6
Compare
taranu
left a comment
There was a problem hiding this comment.
Looks good; see comments and questions.
I assume most of this is going to be tested through CI pipelines but can anything be covered by basic unit tests here, e.g. _ensureMaskPlanes?
| doc="Task to deblend an images in multiple bands" | ||
| ) | ||
| idGenerator = SkyMapIdGeneratorConfig.make_field() | ||
| imageType = ChoiceField( |
There was a problem hiding this comment.
Hmm, are you anticipating keeping this around and adding to allowed at some point, even after legacy is deprecated? Or did you mainly want better documentation via the allowed dict than you'd get from a boolean Field?
There was a problem hiding this comment.
I'm not planning to keep it around forever, but on this ticket I really wished that useCellCoadd had been a ChoiceField instead a boolean, because then I would have been able to use that instead of inventing another config field and leaving useCellCoadd sort of dangling in a lot of cases. So this is probably fighting the last war, but I figured I'd leave room for a plot twist in the migration just in case.
| `lsst.images.cells.CellCoadd`] | ||
| Coadds to deblend. | ||
| bands : `list` [`str`] | ||
| Names or the bands for ``coadds`` (zip-iteration compatible). |
There was a problem hiding this comment.
Are there lists that aren't zip-iteration compatible, or do you just mean that the bands have to be in the same order as the coadds?
There was a problem hiding this comment.
Yes, I mean it should have corresponding elements in the same order.
| "CoaddPsfFitSubConfig", "CoaddPsfFitSubTask", "CoaddPsfFitTask", | ||
| ] | ||
|
|
||
|
|
There was a problem hiding this comment.
Accidental, or did you think a new import was going to be needed?
| doc="Task to fit PSF models for a single coadd", | ||
| ) | ||
| idGenerator = SkyMapIdGeneratorConfig.make_field() | ||
| image_type = pexConfig.ChoiceField( |
There was a problem hiding this comment.
Would it make sense to define this once in a module somewhere, or is it safer to duplicate?
There was a problem hiding this comment.
The docstrings pretty much always differ, even if only slightly sometimes.
| "output images are lsst.images.cells.CellCoadd.", | ||
| dtype=str, | ||
| default=( | ||
| "Background subtracted from the image when generating the Object catalog. " |
There was a problem hiding this comment.
Would it make sense to put this string in a separate module, if not the whole Field?
There was a problem hiding this comment.
Yeah, I'm not super comfortable having all of this full-pipeline context here, either. But I didn't identify any alternatives that I liked a lot better.
Some options:
- Just move it to a module-level constant in this same module, so it's at least importable on its own and a little less buried.
- Make the default empty or much more generic, and override it in drp_pipe.
If you like one of those better, I'm happy to go with it.
There was a problem hiding this comment.
I slightly prefer the first option.
| backgrounds.append(emptyBg) | ||
|
|
||
| if cell_coadd is not None: | ||
| cell_coadd.image.array[...] = exposure.image.array |
There was a problem hiding this comment.
Huh... is there any functional difference between [...] and [:] and .flat?
There was a problem hiding this comment.
In this limit, if you do .flat on both of them, I think it'll amount to the same. But [...] on a 2-d array like this actually resolves to [:, :] (i.e. still 2-d), so it would definitely behave differently if broadcasting was in play, and there may be other differences as well.
| results.outputSources = sources | ||
| return results | ||
|
|
||
| def _ensureMaskPlanes(self): |
There was a problem hiding this comment.
Is this for (current or future) backwards compatibility if running on coadds without newer masks like SPIKE? It's worth a comment regardless.
There was a problem hiding this comment.
Added this docstring:
"""Ensure the global mask dictionary has all of the mask planes
needed for PixelFlags algorithms.
When mask planes are added, this essentially guarantees that the
corresponding PixelFlags columns will be wholly False, and usually
we'd prefer to remove them from the configuration. But those config
changes imply a schema changes, and that's not always viable (e.g. on
a release branch).
"""
Adding error information to metadata doesn't do much if we write it to disk first.
Unlike other changes so far on this ticket, this one only modifies 'runQuantum'/connections and leaves 'run' only supporting Exposure as input. Fixing that would make everything a lot messier unless we do a lot of work, like making cell-coadd aperture corrections a true BoundedField and/or dropping MultipleCellCoadd as a supported connection type (RFC-1193).
This only touches the connection/runQuantum level; run still only works on lsst.afw.image.Exposure.
In the long term, it would be better to un-configure those PixelFlags columns, but that changes the schema and hence isn't viable for something we want to backport to v30.
e3e75a8 to
bfb8637
Compare
There's just so little test scaffolding for these tasks available that it doesn't seem worthwhile to add all of that just for a little change like this. Of course that's self-perpetuating, but I can at least confirm that |
0333799 to
82b9d23
Compare
No description provided.