-
Notifications
You must be signed in to change notification settings - Fork 33
ITStrF01
Here is an explanation of the ITStrF01 fileformat used by iontof in the following files:
- .ita
- .itm
- .its
- .shi
- .isi
- .spm
Note that this was done by pure reverse-engineering and that this documentation might not be 100% accurate with reality. Nevertheless this procedure seems to work well with a huge amount of data already treated and parsed by the developer.
The fileformat ITStrF01 is composed by 8-bytes forming the word "ITStrF01" followed by an unknown number of blocks of unknown size. The size can be found in the header of each block. The blocks form a filesystem type where the first block is "root" and its value is a list of children's block. The leaf-blocks are of type 00 19 00 00 00 or 80 19 00 00 00 and contains data.
Each block is composed by a header followed by its name and then its value/data. All values are in uint32.
N: gives the number of children of block types 01/03.
ID: If several blocks have the same name, then they should have different ID. It usually starts at 0 and increase monotonically for all following blocks. It was found that block which are overwritten (e.g. information about the mass calibration sf/k0) are increased, but the blocks of lower ID are not kept. In order to solve this issue pySPM.Block.goto
provides the lazy argument, which can be set to True in order to return the first children found of a given name without having to know its ID.
Only 4 different types have been encountered in ITA/ITM files. Those are:
Those block have no children and the value contains only data. The data type (string/int/float/etc.) is not written in the header. The user should know what is the type of data depending on the block path. Sometime key/values are stored.
Those block are block containing children. Similar to a folder. The value is then composed only of headers defining the name and position of all the children (see Value header and Child header below).
Big block are chunked in several smaller blocks. Type 01 are chunks in several blocks and all "Next-Block" are of type 03. The structure is exactly the same as 01 type though.
Those blocks have no children and contain data compressed with zlib. It usually stores array of data as a stack of floats.
Blocks of type 01 and 03 have children. There value thus start with a header composed of 41 bytes. The values a is equivalent to the block name, b to Block ID, c to N, d to length1, e is found to be equal to 0. It was found that nums×53 is equal to the block length, but it is unclear why.
The 41 bytes of the value header is then followed by several 33-bytes long block giving info for every children. All values are in uint32 or uint64 if not explicitly specified.
S: is usually 00, 01 or 80 and is the block Type of the child
Name offset: It's the offset in bytes between the beginning of the values to the start of the child name
f: unknown value. It seems to be =1 for blocks having data, meaning blocks of type 00 or 80 (128 dec)
The mass calibration is saved in MassScale/calib it contains pair of assign and mcp keys. mcp contains 10 doubles having values:
- t₀
- m₀
- δm?
- ?
- ?
- Amplitude
- other_amplitude?
- ?
- lower t
- upper t