In principle, if the image has an even number of pixels, both methods of computing the center give the same result. And this is the desired situation because the center pixel of an even number of pixels image is not well defined. The difference is when image size is an even number of pixels. Look at the centers provided by the two methods as a function of the number of pixels with the following lines:

for n in $(seq 0 1 9); do
    v1=$(echo $n | awk '{print int($1/2+0.5)}')
    v2=$(echo $n | awk '{print int($1/2)+1}')
    echo "$n    $v1    $v2"
done

It produces:

0    0    1
1    1    1
2    1    2
3    2    2
4    2    3
5    3    3
6    3    4
7    4    4
8    4    5
9    5    5

The first row says that for a 0 pixels image, the center from method 2 is the pixel number 1! While this situation makes no sense, the result is not consistent neither.

For even number of pixels images, the result is the same. This is fine and the good scenario.

The problematic situations is for the images that have odd number of pixels. For a 4 pixels image, should we consider that the center is pixel 2 or pixel 3?

From my experience, in this situations, the center use to be at the center computed by method 1. And that is the reason why I preferred method 1. But this is what I experienced. Let me know what do you think and if this makes sense or not.

Thanks for the comment!

There is a 1-pixel offset in the subtraction of the PSF. This issue can be tested by a very simple test: creating a gaussian image and subtract this image as if it were the PSF itself. The subtracted image should be zero, but it is not. A few lines to check/reproduce the problem:

$ psf=psf.fits
$ sub=sub.fits
$ img=image.fits

$ astmkprof --kernel=gaussian,5,3 --oversample=1 --output=$psf
$ cp $psf $img
$ bash psf-subtract.sh $img --psf=$psf --center=8,8 \
                       --mode=img --scale=1.0 --output=$sub

$ astscript-fits-view $sub

With the commit below this bug has been fixed.

https://gitlab.com/infantesainz/gnuastro/-/commit/8006670e