How do I transport image data to a system with swapped bytes?
Document Actions
Q18. How do I transport image data to a system with swapped bytes?
AFNI datasets created with versions 2.11 and later contain a flag in the .HEAD file that indicates the byte order of the data stored in the .BRIK file. When the dataset is loaded, if it consists of 2 byte shorts, it will be swapped if the CPU byte order differs from the file byte order.
For older datasets, you can go back and attach the header flag about the correct byte order with a Unix shell command of the form
find /top/dir -name \*.HEAD -exec 3drefit -byteorder NATIVE_ORDER {} \;
where /top/dir is the top of the directory hierarchy that
contains all your AFNI datasets.
Image data files themselves (e.g., scanner output) do not contain any information about the byte order of their data. If you do not know what the byte order of a set of image files is, try looking at them (with afni -im or with to3d). Images from the scanner will usually be non-negative. (Most image reconstruction programs take the absolute value of the reconstructed data as the last step in the process.) If there are negative values in such images, this means that the data is probably byte-swapped relative to the CPU on which you are using to3d. Negative values can and do occur in derived images (e.g., correlation coefficient maps).
You can manually byte swap image data files (including .BRIK files) using the programs 2swap (in pairs: ab->ba) and 4swap (in quads: abcd->dcba). Do NOT apply these programs to the .HEAD files! Also, if you byte swap a .BRIK file and the .HEAD file does contain a byte order flag, then you must fix the .HEAD file using the 3drefit command. Otherwise, AFNI will treat your data incorrectly, since you changed the actual byte order but not the byte order flag.
The program byteorder will print out the byte ordering used by the CPU on which it is run. The possible outputs are
- LSB_FIRST = Least Significant Byte first (Intel
computers):
If computers were decimal instead of binary, the number "ninety three" would be stored as "39". - MSB_FIRST = Most Significant Byte first (most
RISC processors):
If computers were decimal instead of binary, the number "ninety three" would be stored as "93".
[20 Sep 1999] AFNI programs now check input datasets to see if they have the byte order flag. If not, a warning message like this will be sent to the terminal:
*** Dataset r1:time+orig.HEAD: assuming byteorder MSB_FIRSTThis warning can be suppressed; see README.environment. All datasets created by versions of AFNI since May 1998 should contain the byte order flag.
Q12 contains a discussion of methods for byte-swapping image files before or during input to to3d.
If you wish to force all newly created AFNI datasets to be stored in a particular byte order, you can do so using the environment variable AFNI_BYTEORDER. Note that when reading in datasets that are byte-swapped relative to the CPU native order, AFNI programs must use malloc() to allocate memory. If the dataset is stored in the CPU native order, then mmap() can be used to directly map the .BRIK file into memory. This can save system swap space, which might be a consideration when using the AFNI package on computers with a tiny amount of RAM (less than 256 MB, say).
[19 Jan 2000] When the input images are shorts, to3d now checks if any of the values are negative. If there are negative voxel values, it displays a warning message. This is intended to help remind you to check to see if the images might need to be byte-swapped.
[Answer last changed 19 Jan 2000]
This FAQ applies to: Any version.
