Ticket #912 (closed defect: fixed)

Opened 10 years ago

Last modified 7 years ago

Detection fails for images with masked pixels that are NaNs

Reported by: rowen Owned by: rhl
Priority: normal Milestone:
Component: afw Keywords:
Cc: becker, rhl Blocked By:
Blocking: Project: LSST
Version Number:
How to repeat:

not applicable

Description (last modified by rowen) (diff)

The recent change to afw of convolution and warpimg setting edge pixels to (NaN, EDGE, inf) broke detection. Warping always outputs such edge pixels, and convolution does this by default. Thus a warped MaskedImage can no longer be input to detection (at least not without careful trimming -- which is not practical if the warping has rotated the image significantly).

This is a request for a way to get detection to ignore masked pixels. The user should specify which mask bits indicate a pixel to ignore (since some bits are innocuous, e.g. INTERP). Note that pixels may be masked without being set to !NaN and yet still be worth ignoring. For instance the output of warpExposure formerly had 0s for edge pixels (instead of NaNs) and the detection algorithm presumably would not be as efficient if it included such pixels.

It may also be useful to have detection ignore NaNs. The use case is running detection on a plain Image (not a MaskedImage). I am not convinced this is a good idea, but it is worth considering.

Change History

comment:1 Changed 10 years ago by DefaultCC Plugin

  • Cc rhl added

comment:2 Changed 10 years ago by rhl

I don't understand. Convolved images should not have NaNs, that information is carried in the Mask bits.

I don't expect to see NaNs? appear except in Images with the copyEdge flag set to false.

comment:3 Changed 10 years ago by rowen

  • warped images ALWAYS have NaNs? in their edges. There is no way to turn this off. We will be running detection on warped images.
  • convolved images DO have NaNs? in their edges by default (and convolved variance planes have inf). That is the LSST standard. The only time they won't have NANs is when one sets the copyEdge flag true, which was intended only to keep legacy code and outside party code happy. It was not intended for internal use. You signed off on that.

detection must be capable of ignoring masked pixels.

comment:4 Changed 10 years ago by rhl

  • Priority changed from critical to normal
  • Status changed from new to assigned
  • Component changed from meas_algorithms to afw

I did not sign off on always setting NaNs in masked images, for exactly this reason. In the ticket, I wrote:

My proposal would be:

  1. If the bool to set the EDGE pixel is true, keep the pixel values (even

for Image)

  1. Otherwise, set them to NaN as you're doing now in #806.

I should have said that the default value of copyEdge should be true, at least for MaskedImages (yes, this is a little tricky to implement). This was not designed only for legacy code; far from it.

I do not expect ever to use an un-trimmed warped image, so there won't be any NaNs there either. The input images for e.g. image subtraction will be over-sized to allow us to trim them.

Neither of these are reasons not to handle NaNs in the detection code (i.e. this ticket).

I have moved the ticket to afw, where the detection code lives, and lowered the priority as copying the edge pixels is usually the right thing to do anyway.

comment:5 Changed 10 years ago by becker

I expect to use detection on an untrimmed warped image today, if I can. In fact many of my unit tests expect to be able to do this. We can't just design this code to work with the ideal case of LSST 2 years in.

In any case, the edge pixels must be ignored, whether they be Nans or copied pixels.

comment:6 Changed 10 years ago by becker

Another use case is making the coadd :

We create an arbitrary Wcs solution to warp all input images to. We warp all input images to this coordinate system. This warped input image has been rotated, and thus has non-constant numbers of edge pixels around its perimeter. We then need to create a Psf matching kernel to match this image to our desired Template Psf. This requires running a detection stage on the image, which must then deal with an untrimmed warped image.

comment:7 Changed 10 years ago by rhl

  • Status changed from assigned to closed
  • Resolution set to fixed

Rather against my better judgement I've made this change in r10852; pixels that are NaN are now taken to be below threshold (i.e. not in objects).

In almost all cases this is not what you want to do; I am still not convinced by the comments.

comment:8 Changed 10 years ago by rowen

  • Description modified (diff)
  • Summary changed from Detection fails for images with NaN edge pixels to Detection fails for images with masked pixels that are NaNs

I was really hoping for a way to get detection to ignore *masked* pixels -- NaNs or not. But although I said this several times in email, just realized that the title and description of this ticket implied that I wanted detection to ignore NaNs instead of masked pixels. So I have updated the ticket title and description accordingly.

Ignoring NaNs will help immensely, so I am very grateful for the change. But in the long term I think it is important to be able to ignore masked pixels.

comment:9 Changed 10 years ago by rhl

Please read my comments, and tell me how masked pixels within objects should be treated. I handled the NaN case on the assumption that the main use case was NaNs at the edge of the field; for the general Mask case this will not be true, and a simple treatment of all masked pixels as being below threshold will not suffice.

Note that adding support for masks isn't a hard thing to code (a few lines of code, and a significant slow down unless things are restructured to allow the compiler to ignore the mask when not used); it just that I remain unconvinced of the value of this functionality.

comment:10 Changed 7 years ago by robyn

  • Milestone DC3b Apps Framework deleted

Milestone DC3b Apps Framework deleted

Note: See TracTickets for help on using tickets.