different results from find_transform and estimate_transform

[yas-nakajima]

different results from find_transform and estimate_transform

[yas-nakajima]

Just for your information. I don't think it is a bug of astroalign.

[IN]: 
imdata1 = fits.getdata('tSUPA00215715.fits')
imdata1.dtype

[OUT]:
dtype('>f4')

The dtype is already 32-bit float before executing np.array(imdata1, dtype="<f4"), but it needs to be "converted" to '<f4' to run aa.register.
It is strange and interesting.
Possibly a bug of astropy.io.fits?

[martinberoiz]

I honestly don't know much about endian issues and the FITS standard to know exactly what's going on, but this trick fixed the issue:

from astropy.io import fits

imdata1 = fits.getdata('tSUPA00215715.fits')
imdata2 = fits.getdata('tSUPA00215725.fits')

imdata1_fixed = np.array(imdata1, dtype="<f4")
imdata2_fixed = np.array(imdata2, dtype="<f4")

reg_im, footprint = aa.register(imdata1_fixed, imdata2_fixed)

I'll look more into this issue, but for now that should be a quick fix.

[yas-nakajima]

Thank you for your response.

By the way, this is a new issue and your reply is for the previous issue.

Best Regards

[martinberoiz]

Thanks for pointing that out. I've been thinking last weekend and this might be related to the FITS standard.

This is what they say in the PDF file:

The individual data values shall be stored in big-endian byte order such that the byte containing the most significant bits of the value appears first in the FITS file, followed by the remaining bytes, if any, in decreasing order of significance.

But most computers are actually in little endian.

The Intel x86 and AMD64 / x86-64 series of processors use the little-endian format.

I don't really know if the creators of FITS files take this into consideration when dumping binary data to the file (or if they should care). I'm not sure if astropy should flip the endianness of arrays to match the cpu either.