bugGNU Astronomy Utilities - Bugs: bug #59726, MakeCatalog's --halfsumradius...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitter:  Mohammad Akhlaghi <makhlaghi>
Submitted:  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

Sat 19 Dec 2020 01:49:55 PM UTC, comment #1: 

Nacho had a good suggestion to see the behavior at Sersic indices below 1 also (to confirm the hypothesis).

So I updated the input catalog to the one below (the Sersic index is the 6th column: I also added Sersic index 4), with everything else identical.


1 300 250 1 10 0.5  0 1 1 10
2 700 300 1 10 1    0 1 1 10
4 300 650 1 10 4    0 1 1 10
3 700 700 1 10 10   0 1 1 10


I then ran the same commands before. The resulting image can be seen attached to this message. Here is the new catalog:


1      8.21
2      8.33
3      8.04
4      5.86


The fact that it hasn't changed between Sersic index of 0.5 and 1 is probably due to the pixel size limit. It would probably be more clear at larger input effective radii. But I was expecting a larger difference of measured effective radius between Sersic index 1 and 4!

I feel that using the elliptical distance instead of pixel counting can improve this result. Let's see...


Mohammad Akhlaghi <makhlaghi>
Group administrator
Sat 19 Dec 2020 01:33:17 AM UTC, original submission:  

MakeCatalog has the '--halfsumradius' option (new name for recently added '--halfradiusobs' option, see Commit 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.

Mohammad Akhlaghi <makhlaghi>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #50520:  profiles.png added by makhlaghi (34KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by makhlaghi (Submitted the item)
  • -email is unavailable- added by makhlaghi
  • -email is unavailable- added by makhlaghi
  • -email is unavailable- added by makhlaghi
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-19 makhlaghi Attached File- Added profiles.png, #50520
    2020-12-19 makhlaghi Carbon-Copy- Added -email is unavailable-
        Carbon-Copy- Added -email is unavailable-
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code