# GNU Astronomy Utilities - Bugs: bug #66043, One pixel offset in PSF subtraction

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

# bug #66043: One pixel offset in PSF subtraction

 Submitter: Raul Infante-Sainz Submitted: Tue 30 Jul 2024 04:06:10 PM UTC Category: Installed scripts Severity: 3 - Normal Item Group: Output not reasonable Status: Fixed Privacy: Public Assigned to: None Open/Closed: Open

## Discussion

Wed 31 Jul 2024 06:44:02 AM UTC, comment #2:

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!

Raul Infante-Sainz <infantesainz>
Tue 30 Jul 2024 06:19:46 PM UTC, comment #1:

Thanks for finding and reporting this Raul.

Just one question: can you explain the term 'int(\$1/2+0.5)' in the comments on top of it? In particular, why not 'int(\$1/2)+1' (which is easier to interpret: division by 2 may give a float, so we convert it to an integer and add one).

Tue 30 Jul 2024 04:06:10 PM UTC, original submission:

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

Raul Infante-Sainz <infantesainz>

## Attached Files

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

No files currently attached

## Dependencies

Depends on the following items: None found

Items that depend on this one: None found

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