# Fix bug in strict monotonicity

XMLWordPrintable

## Details

• Type: Story
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
None
• Story Points:
1
• Sprint:
DRP F17-4
• Team:
Data Release Production

## Description

There is a bug in the strict monotonicity algorithm that occurs when a faint object is close enough to a bright object that its initial SED is a poor choice, and is closer to the SED of its brighter neighbor. In this case the algorithm completely fails.

To test the projection, I ran a deblend using only the symmetry operator, which resulted in the first attached image. I then ran the projection, which resulted in the 2nd image, which is not strictly monotonic. This ticket is to investigate the origin of this strange behavior.

## Activity

Hide
Fred Moolekamp added a comment -

The issue was due to running the deblender on images with an even number of rows and/or columns, not for the reasons specified in the ticket description. While the code had already been adapted to reshape the image in the deblender, the function that generates the strict monotonicity proximal operator (and has to be created before the deblender is run and the image is projected onto an odd number of columns and rows) would build the operator with the original number of rows and columns. The function deblender.nmf.reshape_img was already made to ensure that the image cube has odd rows and columns, so I updated build_prox_monotonic to check that the image has already been reprojected. This has fixed the issue.

Show
Fred Moolekamp added a comment - The issue was due to running the deblender on images with an even number of rows and/or columns, not for the reasons specified in the ticket description. While the code had already been adapted to reshape the image in the deblender, the function that generates the strict monotonicity proximal operator (and has to be created before the deblender is run and the image is projected onto an odd number of columns and rows) would build the operator with the original number of rows and columns. The function deblender.nmf.reshape_img was already made to ensure that the image cube has odd rows and columns, so I updated build_prox_monotonic to check that the image has already been reprojected. This has fixed the issue.
Hide
Fred Moolekamp added a comment -

Peter, here's a quick review that you can do when you get back. The relevant changes are in this commit

Show
Fred Moolekamp added a comment - Peter, here's a quick review that you can do when you get back. The relevant changes are in this commit
Hide
Peter Melchior added a comment -

If possible, can you attached an image that shows the correct behavior after the fix for the object above. If it's too hard to dig it up, don't, but for completeness sake it'll be good.

Show
Peter Melchior added a comment - If possible, can you attached an image that shows the correct behavior after the fix for the object above. If it's too hard to dig it up, don't, but for completeness sake it'll be good.
Hide
Fred Moolekamp added a comment -

I updated the ticket with the correctly modeled image.

Show
Fred Moolekamp added a comment - I updated the ticket with the correctly modeled image.

## People

• Assignee:
Fred Moolekamp
Reporter:
Fred Moolekamp
Reviewers:
Peter Melchior
Watchers:
Fred Moolekamp, Peter Melchior