search

c3-time-domain / SeeChange

A time-domain data reduction pipeline (e.g., for handling images->lightcurves) for surveys like DECam and LS4
BSD 3-Clause "New" or "Revised" License
0 stars 4 forks source link

Background subtraction for images going into coaddition #186

Closed guynir42 closed 2 weeks ago

guynir42 commented 5 months ago

Seems like we will have to input background-subtracted images to the coaddition algorithm, if only so that inpainting will not be completely messed up. Maybe there are other good reasons. I don't see why we shouldn't do that.

Need to think when to do this subtraction, if it will be like the alignment stage, or even at the same time as alignment? Or should it happen inside the coadd class?

rknop commented 5 months ago

I'm fine with requiring background-subracted images going into coadd. We shouldn't require that for subtractions, though. (Alard/Lupton, at least, handles non-background-subtracted things with just a zero-order term.)

Because background subtraction is fraught, I wouldn't make it a side effect of anything unless that thing needs it. So, I wouldn't make it part of alignment. I believe the right way to do it is define a general background subtraction interface and implement a few different algorithms. Allow it to be run on its own. But, also, within coadd, perform it with the requested method (where "don't do anything, it's already subtracted" is a valid method).

guynir42 commented 5 months ago

I generally agree with that.

So the Background object will not live in the pipeline but it can be a thing that lazy-constructs on each Image object based on the Provenance parameters?

Then it pops into existence whenever needed, applies the cached background scalar or map that it has when you want (which could be zero if the background was already subtracted) and then you call it whenever you need?

Another question is: which provenance should it live in? The alignment parameters live in the prov of the coadd/subtracted image, and implies what should be done to the upstream images. In the background case it should probably live in each individual image's provenance. Should we make "background" a dictionary that is a part of the preprocessing parameters? That seems like the natural place to put it, although it may get measured later (in extraction) in which case we will have a problem going back and changing an already stamped provenance.

guynir42 commented 3 weeks ago

Addressed by #308