search

wtclarke / pymapvbvd

Python port of mapVBVD
MIT License
40 stars 25 forks source link

Big-endian host support? #35

Closed musicinmybrain closed 1 year ago

musicinmybrain commented 1 year ago

I’m working on packaging this for Fedora Linux as a dependency for spec2nii. One of the Fedora Linux primary architectures, s390x, is big-endian. It looks like pymapvbvd assumes that both the binary file format and the host running the code are little-endian. Is there any interest in making the code endian-independent in the future?

If the file format is always little-endian, this should mostly be a matter of making endianness explicit when creating a numpy array that is to be copied bytewise in or out of the file: for example, np.dtype('<u4') instead of np.uint32. However, there are a lot of places this would need to be done, and it would require some time and study for me to offer a careful patch—probably more time than I want to spend on it.

Would you like to support big-endian architectures, or is this something you are—understandably—not prepared to take the time to implement?

wtclarke commented 1 year ago

Do you think this affects a substantial proportion of potential users? If so, I'd be keen to work on something, if not, then I can't spend the time currently.

musicinmybrain commented 1 year ago

Do you think this affects a substantial proportion of potential users? If so, I'd be keen to work on something, if not, then I can't spend the time currently.

I can’t say for sure, but my best guess is no: the other big-endian platforms have mostly died out, and I suspect the intersection of s390x mainframe users and those who need to work with raw MRI data is a very small group of people at best.

If it ever becomes worthwile to work on this, I’m happy to help with testing. Otherwise, just having a record of your thoughts on the matter is appreciated. Please feel free to close this issue as “not planned.”