Front Page Forums BioMap Analyze 7.5

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
  • #828

    I finally managed to understand the Bruker binary data file format (it’s fairly simple, after all. I’m still working out how they convert the data points to m/z values, but that should be no problem).

    So now I’m thinking of writing a small application which should batch process the data files into a format readable by BioMap. I understand you use the Analyze data format for this, so that is obviously my first choice. Some questions remain, however…

    Is it right that you create 3-dimensional Analyze data files, with the X,Y data in the first 2 dimensions, and the spectral data in the third dimension? If so, do you apply any processing with respect to the resolution, or do you use all the data points provided by the mass spectrometer, and store them in the third dimension?

    Also, I have read the Analyze 7.5 document from, but I’m still confused about how to write this 3D data format. Can you point me to a useful resource where this is documented?

    Markus Stoeckli

    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=]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…


    OK thanks! At first I was confused, but things are slowly starting to make sense now… 😳


    I did some experimentation with a 3×3 pixel .img file, with 4 intensity data points for each pixel. I used your [url=]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?

    Markus Stoeckli

    I verified the locations as indicated in the structure and it ckeckes out fine. You may use a hex editor to validate that your file was written correctly. The absolute locations are:

    offset 42: D Points
    offset 44: X Points
    offset 46: Y Points

    It might be an alignment problem with your compiler…



    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]

    Markus Stoeckli

    I completely agree with you and corrected my previous post. That’s how it should be:

    [b]*.img:[/b] 16-bit signed integers

    [b]*.t2m:[/b] 32-bit floats


    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.


    Markus Stoeckli

    X: number of image points in X direction (horizontal)
    Y: number of image points in Y direction (vertical)
    D: number of data points in mass spectrum

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.