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.