GNU 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: |
Mohammad Akhlaghi <makhlaghi>![]() |
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.
|
Mohammad Akhlaghi <makhlaghi>![]() |
Depends on the following items: None found
Items that depend on this one: None found
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.
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.
I then ran the same commands before. The resulting image can be seen attached to this message. Here is the new catalog:
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...