Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

byteswap problem #57

Open
mshemuni opened this issue Mar 21, 2018 · 2 comments
Open

byteswap problem #57

mshemuni opened this issue Mar 21, 2018 · 2 comments

Comments

@mshemuni
Copy link

I'm not sure if this is the place to write the issue.

I am using Linux Mint 18 and tested this problem with both Ubuntu 14.04 and 16.04 and all were 64bit systems.
Sorry I have some modules and methods so there's no point to share the whole code but basically I read fits file like:

from astropy.io import fits as fts

hdu = fts.open(src, mode='readonly')
data = hdu[0].data 

then I pass the data to sep as below:

from sep import Background, extrac
from numpy import asarray as ar

bkg = Background(data)
data_sub = data - bkg
all_objects = ar(extract(data_sub, 1.5, err=bkg.globalrms))
all_objects = all_objects[all_objects['flag'] == 0]

at line bkg = Background(data) error below occurs:

valueerror: input array with dtype '>f4' has non-native byte order. only native byte order arrays are supported. to change the byte order of the array 'data', do 'data = data.byteswap().newbyteorder()'

I added the line data = data.byteswap().newbyteorder(). Nothing changed. I had the same problem. With and without the suggested line.

I figured it out. The data returned by astropy has dtype=float32. And I just changed dtype by float64 as shown below and everything was ok.

data = data.astype(np.float64)

I think I must be able to use 32bit data type in a 64bit system.

@kbarbary
Copy link
Owner

You're right that you should be able to use float32 on a 64-bit processor. A common misunderstanding about 32-bit versus 64-bit processors is that "32" and "64" refer only to the native integer size, but doesn't have anything to do with floating point numbers. Both types of processors have both native 32-bit and 64-bit floating point units.

data = data.astype(np.float64) likely converts to the native endianness (little endian), so that's why it worked.

After doing data = data.byteswap().newbyteorder() and before passing data to any SEP function, data.dtype should be dtype('<f4'). Can you check this?

@mshemuni
Copy link
Author

I took a look to dtype and it says: float64.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants