Skip to content

DM-55521: update coadd processing tasks to work with lsst.images - #1334

Merged
TallJimbo merged 9 commits into
mainfrom
tickets/DM-55521
Aug 13, 2026
Merged

DM-55521: update coadd processing tasks to work with lsst.images#1334
TallJimbo merged 9 commits into
mainfrom
tickets/DM-55521

Conversation

@TallJimbo

Copy link
Copy Markdown
Member

No description provided.

@TallJimbo
TallJimbo force-pushed the tickets/DM-55521 branch 12 times, most recently from 2dbea16 to 7b592c6 Compare July 23, 2026 22:37

@taranu taranu left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I mean it should have corresponding elements in the same order.

Comment thread python/lsst/pipe/tasks/fit_coadd_psf.py Outdated
"CoaddPsfFitSubConfig", "CoaddPsfFitSubTask", "CoaddPsfFitTask",
]


Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Accidental, or did you think a new import was going to be needed?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Accidental; fixed.

doc="Task to fit PSF models for a single coadd",
)
idGenerator = SkyMapIdGeneratorConfig.make_field()
image_type = pexConfig.ChoiceField(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to define this once in a module somewhere, or is it safer to duplicate?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docstrings pretty much always differ, even if only slightly sometimes.

Comment thread python/lsst/pipe/tasks/multiBand.py Outdated
"output images are lsst.images.cells.CellCoadd.",
dtype=str,
default=(
"Background subtracted from the image when generating the Object catalog. "

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to put this string in a separate module, if not the whole Field?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I slightly prefer the first option.

backgrounds.append(emptyBg)

if cell_coadd is not None:
cell_coadd.image.array[...] = exposure.image.array

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh... is there any functional difference between [...] and [:] and .flat?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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):

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this for (current or future) backwards compatibility if running on coadds without newer masks like SPIKE? It's worth a comment regardless.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
@TallJimbo

Copy link
Copy Markdown
Member Author

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?

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 ci_lsstcam definitely fails without that _ensureMaskPlanes fix.

@TallJimbo
TallJimbo merged commit 77d882f into main Aug 13, 2026
4 checks passed
@TallJimbo
TallJimbo deleted the tickets/DM-55521 branch August 13, 2026 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants