[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #59726] MakeCatalog's --halfsumradius under estimates effective rad
From: |
Mohammad Akhlaghi |
Subject: |
[bug #59726] MakeCatalog's --halfsumradius under estimates effective radius |
Date: |
Fri, 18 Dec 2020 20:33:19 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0 |
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/
- [bug #59726] MakeCatalog's --halfsumradius under estimates effective radius,
Mohammad Akhlaghi <=