Hello,

I am not sure if anyone received this note before, but I had posted a question about a week ago and got some answers, so here is my latest response. I have included the other messages in chronological order from top to bottom (so my latest message is on the bottom). Any ideas?

-Ellen

Author: Rich Hammett (---.nimh.nih.gov)
Date:   10-06-03 12:01

>Ellen Shlossberg wrote:

> I am transferring some +tlrc image files from my Solaris 2.6
> system to a Linux Red Hat 9 system. I used 2swap to reverse the
> bytes, but when I looked at the reversed-byte images in afni on
> the Linux machine, they came out fuzzy and wrong. When I looked
> at the original "Sun-format" files on the Linux, they were
> mostly correct. Why is it not necessary to reverse the bytes
> for Linux?

In case somebody more knowledgeable doesn't get to this...

AFNI can automatically detect the need to fix byte order.

I haven't looked at it in a while, but I would suspect that
2swap failed for at least one reason: byte swapping is not
just a two-byte process. Entire "objects" (byte, char, int,
float, etc) have to be swapped end to end.

> Also, when I looked at the sun-format Functional Images
> (created with MannWhitney and editted with 3dmerge clust), the
> functional image was wrong. Reversing the bytes on this one did
> not help either.

So, these are AFNI BRIKs? If not, what format are they?
If so, at what step did you convert them?
If nobody else comes up with an easy answer for this one, I'll
need more detail about your files, and probably need some
sample data.

When you create an AFNI BRIK, it notes what the byte ordering is of the
file. AFNI also knows what the byte ordering of the platform it's running
on is. So it fixes it as it runs. I think Bob recommends just leaving them
in their original format, and let AFNI keep track of it, as long as you're
working in AFNI, but I'm sure he'll correct me if I'm wrong.

rich




Author: Ellen Shlossberg (134.174.9.---)
Date:   10-10-03 17:10

HI,

thanks for the prompt reply.

The images I can view correctly are:
AFNI BRIKs. They are short, +tlrc BRIK and HEAD files with size 176*208*176 and converted to AFNI format by "to3d -spct -prefix filename -view tlrc -xFOV176R-L -yFOV 208A-P -zFOV 176I-S 3D:0:0:176:filename "

The transform functions created with Mann Whitney are:
Dataset Type: Inten+Ztest (-fizt)
Byte Order: MSB_FIRST
Storage Mode: BRIK file
short
created from the file types mentioned before

I then extracted parts from the Mann Whitney images with 3dmerge and this is the image that comes out wrong. It's information is:
Dataset Type: Intensity (-fim)
Byte Order: MSB_FIRST
Storage Mode: BRIK file
number of value stored at each pixel = 1
created with : 3dmerge
and 3dmerge flag: -1clust

When I look at the 3dmerge-d file on linux, whether I reverse the bytes on the 3dmerge-d file or not, neither image looks like the one I can see on the Sun (which is where they were created to begin with). Do you know what I could have done wrong or could do to fix this?

Also, can I give any more information to help you?

Thanks,
Ellen