Analyze 7.5

Writing files in Analyze format is extremely simple. Save your intensity data of the image point at the lower left corner to a file (*.img) as signed integers (16-bit) and append all the other points, row by row.

The content of this file is specified by writing a header file (*.hdr). This is decribed in the [url=http://msi.stoeckli.net/forum/viewtopic.php?t=9]BioMap File Format[/url] topic.

In order to get a mass scale in the plot window, a *.t2d file is required. Just write the m/z values as single precision floats (32-bit) to the file (just do it once, all the image points use the same m/z values).

[b]And remember: [/b] No spaces in the file name (unix origin 🙁 ) and not more than 32768 data points in the spectrum…

I did some experimentation with a 3×3 pixel .img file, with 4 intensity data points for each pixel. I used your [url=http://msi.stoeckli.net/forum/viewtopic.php?t=9]VB code[/url] to create the header.
You advised to put the intensity data in the first dimension, and this is also in the code for the header:
[code:1]ah.dime.dims(0) = 4
ah.dime.dims(1) = DPoints
ah.dime.dims(2) = XPoints
ah.dime.dims(3) = YPoints [/code:1]
However, when I do this, BioMap reads the 1st dim as X-data, the 2nd dim as Y-data and the 3rd dim as datapoints (Z). Hence I get a rectangular image on screen (4×3 pixels, with 3 slices) instead of a square (3×3 with 4 slices). Only when I put the datapoints in the 3rd dim, it looks OK. When dealing with real spectra, of course, it would be much nicer to keep the intensity data together as you suggest. What am I doing wrong?

I’ve been writing a Java routine to extract relevant data from the three files you mentioned (hdr+img+t2m), but there seems to be some confusion on the number of bytes used by the data types in the files. I thought I might mention my own experiences so others can compare.

[b]img-file:[/b] You mention that this file holds a long string of signed values of 4 bytes (32-bit). This however is not always the case and depends on the particular setting of the ‘datatype’ variable in the hdr-file (offset 70). In my particular hdr-file this variable holds ‘4’ which (according to the Analyze 7.5 specs) means SIGNED_SHORT. As a short only uses 2 bytes (16-bit), the img-file will be only half as large. Of course, this all depends on the particular settings used when writing the files. Best to interpret the hdr-file first…

[b]t2m-file:[/b] An earlier post mentions that the t2m-file holds an array of single precision floats of 64 bits. I suspect this is a typo as a single always only takes up 4 bytes or 32 bit, while a double type takes up 8 bytes or 64 bits. Anyway, for my particular t2m-file it was an array of 4-byte floats.

Let me know if I’m holding the wrong end of the stick here 😉 , but it seems to be working fine for the data files I have access to.

[i][b]Warning for Java-devs:[/b] The MSI-files are typically written according to little-endian byte ordering. Java uses the network byte ordering scheme (big-endian) (also used in the TCP/IP-protocol) by default. This means that you need to convert your bytes before interpreting them as a numeric value.[/i]

One of my collegues is writing a macro to convert Excalibur files to Analyze 7.5 format for use with a homebuilt DESI system. In terms of specifying values for the x,y,z dimensions of the .hdr file we are going to have to do that manually at the moment. Am I correct in thinking that x and y simply define the grid size used i.e. for a 10mm x 10mm image using 0.5mm increments that is x = 20 and y = 20 ? And although I have read the posts about the z dimension being defined by the spectral data I am unclear what this actually means. A simple explanation as to how to define this in a simple type in box entry system such as the one we are intending to use for x and y much appreciated.

Malcolm