Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiband fitting with empty spots #474

Open
mkuemmel opened this issue May 5, 2022 · 2 comments
Open

Multiband fitting with empty spots #474

mkuemmel opened this issue May 5, 2022 · 2 comments
Assignees
Milestone

Comments

@mkuemmel
Copy link
Collaborator

mkuemmel commented May 5, 2022

When fitting on a multi-band data, it is not clear what happens at empty spots (data=weight=0.0) in one band. While the auto_flux is 0.0 in that band the fitted flux values are non-zero and the bulge-to-total ratio indicates often that "something" was done:
empty_g

Also the residual image is negative at object positions:
image_g

We need to clarify what happens in this situation and what should happen. I would expect that for a marginal coverage in one band there are no results in that band or at least there is a corresponding flag.

The data is available here (auto_flux[0]=0.0 selects the relevant sources):
https://deepdip.iap.fr/#folder/627396c26c26b9d0d2c5e1a5

@ayllon
Copy link
Member

ayllon commented May 6, 2022

Just to confirm that this happens with iterative and 'classic' fitting, so it is not something new.

Cutouts for the fitting are limited in size, so it should be possible to just remove the frame model as if it was outside the limits if the whole cutout is masked.
The fitting engine will see if the flux parameter was not used and set it to NaN. The flag PARTIAL_FIT will be set.

If the parameter was used, even on a prior on a color (which could make sense to impute missing pixels?), it will
be accessed and present on the output. The flag will not be set.

There may be literal corner cases where a handful of pixels are not masked, so the frame is not removed. This will not be caught directly, although I think the error column can hint at this because they tend to be tiny (O(1e-10) even less).

I imagine that doing a final raster of the model on the frame and counting how many pixels are affected (not masked), we could identify the two last scenarios. However, it still makes sense to keep the value if it was used by the fitting (priors).

I think we will probably need an additional set of flags, one per model frame.

@mkuemmel
Copy link
Collaborator Author

A long discussion in a telecon revealed different opinions on how to proceed:

  • doing nothing since from a computational point of view everything is okay;
  • forcing users to provide priors since these objects should end up to remain at the prior solution;
  • using flags (per group or per measurement image) to mark problematic cases;
  • using a filling factor such as "fraction of valid pixels" (per group or per measurement image) such that the user select trustworthy measurements;

@marcschefer is looking into what can be done concerning providing additional information such as a flag or a filling factor. This topic will be re-discussed soon.

@marcschefer marcschefer added this to the 0.20 milestone Nov 18, 2022
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

No branches or pull requests

3 participants