[bug #59726] MakeCatalog's --halfsumradius under estimates effective radius

[Mohammad Akhlaghi]

URL:
  <https://savannah.gnu.org/bugs/?59726>

                 Summary: MakeCatalog's --halfsumradius under estimates
effective radius
                 Project: GNU Astronomy Utilities
            Submitted by: makhlaghi
            Submitted on: Sat 19 Dec 2020 01:33:17 AM UTC
                Category: MakeCatalog
                Severity: 3 - Normal
              Item Group: Output not reasonable
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

MakeCatalog has the '--halfsumradius' option (new name for recently added
'--halfradiusobs' option, see Commit c4877bc3
<http://git.savannah.gnu.org/cgit/gnuastro.git/commit/?id=c4877bc3>) for
measuing the radius at half the sum of the total sum of the profile.

In an ideal world (no neighbors/deblending, no PSF and no noise) should be
equal to the effective radius. However, as shown below, the actual returned
value under-estimates the effective radius even in an ideal world!

With the commands below, you can reproduce the problem: we are first building
two Sersic profiles (fourth column of 'in-cat.txt') in an image. Both have an
effective radius of 10 pixels (fifth column of input), but the first one has
Sersic index (n, sixth column) of 1 while the second has a Sersic index of
10.


# Input catalog (one Sersic index 1 profile and one Sersic index 10)
$ cat in-cat.txt
1 300 300 1 10 1  0 1 1 10
2 700 700 1 10 10 0 1 1 10

# Build the mock/ideal image:
astmkprof in-cat.txt --oversample=1 --output=values.fits

# Make a label image from the mock image
astarithmetic values.fits 0 gt 2 connected-components --output=label.fits

# Use the labels and values to generate a catalog
astmkcatalog label.fits -h1 --valuesfile=values.fits \
             --ids --halfsumradius --output=out-cat.txt


The output catalog is shown below: for the n=1 profile, '--halfsumradius' has
been measured as 8.33 pixels and for the n=10 profile, 5.92.


1      8.33 
2      5.92 


I think this is happening because of the way MakeCatalog currently measures
the radius: it sorts the pixels by flux (starting from the brightest) and
comes down until the sum of the sorted pixels equals half the total. Then it
counts how many pixels there were and estimates a radius from that.

However, within a profile, more than one pixel can have the same/similar
value. In effect by stopping at the first pixel that gives half the total sum,
we are discarding the whole outer circumference of the profile. So when the
profile is flatter (like n=1), the radius is being under estimated by 1 pixel.
But for very sharp profiles (where the gradient is even stronger), it can be
greatly under estimated.

I think a better way would be to use the elliptical distance of the sorted
pixel that contains half the total flux.

This bug was found with the help of Joanna Sakowska.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59726>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/