multi-resolution initialisation

[herjy]

So far the multiresolution initialisation is done outside scarlet, but I'm going to formalise it now. It's not a lot of code, but it can be done either of two ways:

• I think it's better done by passing an optional parameter to tell the current initialisation classes to call an init function that will generate the multiresolution coadd and then do the detection as it would normally do (at the moment I generate the coadd outside scarlet and feed it with an artificial observation that contains the coadd: not ideal).
• The other option is to dedicate an initialisation class and a function to perform these tasks, but I see this repeat a lot of the code of existing classes and find it inelegant. Since @pmelchior normally has the last word when it comes to architecture, I'll let you decide.

[herjy]

Another key point is how to do the coadd. Currently, I interpolate low-res images to high-res and sum everything together after rescaling the total flux in each image. This works in practice, but the interpolation introduces correlated noise that worries me a little. Since it is just initialisation, this does not need to be a super mathematically correct solution, but I'm worried about the the estimation of the background cutoff.

Another option I have tested is to denoise all images before coadding them and adding gaussian noise afterwards so as to not mess pieces of the code that might try to estimate the noise in a noise-free image (although I am not sure any of these are in the intialisation path). I have a very robust wavelet filtering method implemented in my branch that does that really well.

On top of that, this ignores the psf completely. I don't think it's paramount especially given that the hr image where the model lives is in the coadd, but it could be explored.

[fred3m]

A while back I tried to put initialization code in scarlet and @pmelchior balked, believing that it isn't our responsibility to make too many decisions for end users. So I created the scarlet_extensions package to handle my init functions and any other methods that I may need in the future for scarlet processing.

So one thing that we could do, to include the work from @pmelchior and his students, @herjy , and myself, is to make a more formal extensions package with different initialization schemes and other code that is too specific to the use case for the main scarlet repo but will be useful for other researchers.

However, if the way that you initialize sources doesn't have any decision making and will be the same (up to a few configuration parameters) every time, for every user using multi-resolution data, then it probably is suitable for inclusion in the main scarlet repo.

[herjy]

So I think this is a different conversation unless I'm mistaken. I'm talking about initialisation, which scarlet does, and not detection that, I know @pmelchior is against for "ok" reasons. Am I misunderstanding you? Though I have things to say about detection and they go exactly in your direction. I'd be happy to implement my multi-resolution detection in the scarlet extensions.

[herjy]

Here I was talking about the initialisation of multi-resolution sources. So far I have used ExtendedSources on synthetic observations that contain coadds I made myself, but my point is that ExtendedSource should handle the coadd process for multi-resolution data. and the question here is how exactly. This is closely linked to issue #172 but focuses the discussion on how multi-res sources should be initialised.

[fred3m]

Note, this comment is meant to address both you comments above in this issue and initialization issues raised in #172 .

I'll be curious to hear @pmelchior 's opinion on this. In the past we've had trouble deciding exactly where to draw the line when initializing sources. For example, he was very much against putting in a function that used any kind of logic to decide which source class to use (eg. is an ExtendedSource, MultiComponentSource, or PointSource most appropriate for a given source in the input catalog).

During that debate we settled on allowing code that initializes the base source classes that we expect most users to choose, with a minimal number of parameters, but no initialization that restricts those models, decides when a given model is appropriate, or even checks that the model is valid. This means, for example, that I have to have specific code in my scarlet_extensions module that checks that a source initialization is valid (ie. the morph or SED aren't all zeros or Nans), or that it can be initialized (ie there is non-negative flux at the peak location in some subset of observed images), how to fall back to less complex models (MultiComponentSource->ExtendedSource->PointSource), and whether or not the source is on the edge of the chip and might need to be shifted by a larger amount.

So if we want to keep the current design model then where your initialization goes will depend a lot on what your code is doing and how restrictive it is. Obviously we need some way for users to initialize multi-resolution sources, but in my mind in order to go in the main scarlet repo it would have to be general enough that (nearly) everyone doing multi-resolution deblending would use those methods/classes with only a few configurable parameters. If there are multiple ways to initialize multi-resolution sources then we can implement each of those separately, but the logic to choose which one would have to be held outside of the main repo.

[herjy]

I get you, so far my implementation is very general. It conserves the previous API, but adds the possibility of declaring initialisation as suggested in #172 .

As for the method, I have implemented only one so far, which is interpolation and summation, without any consideration of how the noise or the psfs behave through this process. I like the idea of having all implementations available. I'll implement the wavelet one and have a keyword let the user select it.

[pmelchior]

I haven't yet read #172, but so far, I see consensus here. I'm not sure why this is an issue, sounds more like a discussion to me.

To clarify the design philosophy we have: Components create hyperspectral models from parameters, but don't know what values, constraints, step sizes to give them. That's the job of XYZSource. I see them as a recipe to define a model for an astrophysical entity. This is why they are exposed to the user, and why they code in scarlet should be general-purpose. Beyond that, I envision source models to form a repository of their own, to which users can contribute/share their implementations. This would be very useful for science platforms.

In short, if you have a better way of initializing from multi-resolutions, that should go in scarlet implementation of ExtendedSource.

[herjy]

This issue was solved in PR #173, by way of coadding images from multiple resolutions after interpolating LowResObservation images to the frame resolution. This also adresses issue #172 .