search

vrodgom / statmorph

Python code for calculating non-parametric morphological diagnostics of galaxy images.
BSD 3-Clause "New" or "Revised" License
42 stars 15 forks source link

centroid coordinates do not take segmask, or noise, into account #7

Closed npirzkal closed 5 years ago

npirzkal commented 5 years ago

Values computed for the first moments/centroids seem wrong in some circumstances and the centroid can some times be well outside of the segmap. It might be a bug in skimage as the following _cutout_stamp_maskzeroed_no_bg leads to a centroid of 0.2, 3.07.

[[ 0. 0. 0. 0. 0. 0.

          1. 0.
    1. ] [ 0. 0. 0. 0. 0. 0.
          1. 0.
    1. ] [ 0. 0. 0. 0. 0. 0.
          1. 0.
    1. ] [ 0. 0. 0. 0. 0. 0.
          1. 0.
    1. ] [ 0. 0. 0. 0. 0. 0.
          1. 0.
    1. ] [ 0. 0. 0. 0. 0. 0.
          1. 0.
    1. ] [ 0. 0. 0. 0. 0. 0. -0.07184662 0.01405155 0. 0.0648425 0. 0.
    1. ] [ 0. 0. 0. 0. 0. 0. 0.07072073 0.18174913 0.08616358 -0.14542499 0. 0.
    1. ] [ 0. 0. 0. 0. 0. 0.
  15. 0.31161529 0.0283908 -0.03631837 0. 0.
    1. ] [ 0. 0. 0. 0. 0. 0.
  17. 0.09580147 -0.14492505 -0.01777303 -0.12393956 0.
    1. ] [ 0. 0. 0. 0. 0. 0.
      1. -0.16527912 0. 0.
    1. ] [ 0. 0. 0. 0. 0. 0.
          1. 0.
    1. ] [ 0. 0. 0. 0. 0. 0.
          1. 0.
    1. ] [ 0. 0. 0. 0. 0. 0.
          1. 0.
    1. ]]
npirzkal commented 5 years ago

The issue is the slightly negative values in the input background subtracted image. photutils.source_properties(data, segm, error) or photutils.source_properties(data, segm) compute xc,yc = 7.2,7.53 while skimage.moments computes xc,yc = 0.23,3.07

vrodgom commented 5 years ago

Sorry for my slow response. I was traveling last week.

What you point out is something I discussed at some point with Jen while writing this package. We think it is a feature rather than a bug, as I try to explain below (sorry for the long answer).

Indeed, the negative pixels essentially "push" the centroid in the opposite direction. However, I do not see anything wrong with this, since it is part of the mathematical definition of the centroid. Additionally, in a background-subtracted image, the negative values are a reflection of the background noise and should tend to cancel out throughout the image. The example you provided seems like an extreme case of a very small, noisy source, so statmorph would probably not like it anyway for the rest of the measurements (i.e., the bad measurement "flag" will definitely have a value of 1).

It is worth mentioning that photutils "solves" this issue by simply ignoring all negative pixels during the calculation of the centroid. While this might be the desired behavior for some applications, we do not think this is the right approach for morphology, generally speaking. The negative pixels contain valuable information, and the calculation of the centroid would become too sensitive to the segmentation map if they are neglected, especially in noisy images.

For example, consider a 2D Gaussian function with a lot of noise, and suppose that for some reason the segmap is an off-center rectangle, such that the source lies on the left-hand side of the segment (see figure below). If negative pixel values are included in the centroid calculation, you still get roughly the correct position (blue circle), even with such a poorly constructed segmap. However, if negative pixels are removed from the calculation, a bias is introduced by the right-hand portion of the segment, which now carries a net positive "weight", shifting the centroid to the right (red circle).

example_cropped

I hope the above makes sense. In any case, most of the measurements carried out by statmorph do not rely on the centroid directly, but on more robust estimates of the center of a source, such as the point that minimizes the asymmetry.

npirzkal commented 5 years ago

Hi

Thanks for the answer. I agree that negative pixels should not be ignored. However, what I was reporting was the effect of a negative pixel outside of the segmentation footprint of the object.

N

Sent from my iPhone

On Oct 30, 2019, at 03:30, Vicente Rodriguez-Gomez notifications@github.com wrote:

 Sorry for my slow response. I was traveling last week.

What you point out is something I discussed at some point with Jen while writing this package. We think it is a feature rather than a bug, as I try to explain below (sorry for the long answer).

Indeed, the negative pixels essentially "push" the centroid in the opposite direction. However, I do not see anything wrong with this, since it is part of the mathematical definition of the centroid. Additionally, in a background-subtracted image, the negative values are a reflection of the background noise and should tend to cancel out throughout the image. The example you provided seems like an extreme case of a very small, noisy source, so statmorph would probably not like it anyway for the rest of the measurements (i.e., the bad measurement "flag" will definitely have a value of 1).

It is worth mentioning that photutils "solves" this issue by simply ignoring all negative pixels during the calculation of the centroid. While this might be the desired behavior for some applications, we do not think this is the right approach for morphology, generally speaking. The negative pixels contain valuable information, and the calculation of the centroid would become too sensitive to the segmentation map if they are neglected, especially in noisy images.

For example, consider a 2D Gaussian function with a lot of noise, and suppose that for some reason the segmap is an off-center rectangle, such that the source lies on the left-hand side of the segment (see figure below). If negative pixel values are included in the centroid calculation, you still get roughly the correct position (blue circle), even with such a poorly constructed segmap. However, if negative pixels are removed from the calculation, a bias is introduced by the right-hand portion of the segment, which now carries a net positive "weight", shifting the centroid to the right (red circle).

I hope the above makes sense. In any case, most of the measurements carried out by statmorph do not rely on the centroid directly, but on more robust estimates of the center of a source, such as the point that minimizes the asymmetry.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

vrodgom commented 5 years ago

OK, that sounds strange. The _cutout_stamp_maskzeroed_no_bg property represents the region of the "postage stamp" cutout that corresponds to the segment of interest, setting all the other pixels (background and other sources) to zero. Therefore, the pixel that you mention (the one at [9, 10] with value -0.16527912?) must be inside the footprint of the object by construction, since it has not been set to zero in _cutout_stamp_maskzeroed_no_bg.

Could you perhaps post the corresponding segmentation map? From the _cutout_stamp_maskzeroed_no_bg posted above, I'm pretty sure the corresponding region of the segmap would look like the following:

  [[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
   [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
   [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
   [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
   [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
   [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
   [0, 0, 0, 0, 0, 0, 1, 1, 0, 1, 0, 0, 0, 0],
   [0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0],
   [0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 0, 0, 0],
   [0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0],
   [0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0],
   [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
   [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
   [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]]

If the footprint of the object according to your input segmap looks different from this (possibly with a label different from 1), then there is definitely a problem somewhere.