ToF-SIMS data format?

[jat255]

I'm working on a metadata extractor for a client for TOFWERK ToF-SIMS data in https://github.com/datasophos/NexusLIMS. I'd rather the actual data I/O be done with HyperSpy so others can use it too!

The reader would go in RSciIO, but since we don't have an existing signal type for this, I'm thinking exspy would be the best place for the new signal? I plan to do the implementation part of this, but wanted to check it with folks before starting any work on it.

@ericpre @CSSFrancis @jlaehne, any thoughts?

[ericpre]

Are there any SIMS signals specific methods you are thinking to implement? If not, maybe at this stage it is not necessary to create a new signal? Otherwise, if there is no significant development foreseen (?), adding this signal to eXSpy sounds sensible form a pragmatic perspective: this is no point to create a new library, where very little development will take place!

Anyway, I guess, the HyperSpy Signal1D class would provide most of the useful functionality in term of visualisation, slicing, generic operation and machine learning.

I am starting to work with MS data mostly to do trivial things and I never look into it details yet, but I may need to in the near future! 😅
A couple of functionality that comes to mind:

• label peak position
• easily compare with spectrum from online database

What are your plans in term of implementing SIMS or MS specific functionality? I may try to talk to a few people that I know in this area to see what they think - in case this helps to inform if this should a separate library. As far as I know and from a quick search in internet, there is not much in the python open source community that can deal with multi-dimensional MS data, so I think that there is scope to do something useful.

[jat255]

I am by no means anything close to a SIMS expert, but I can pretend to be...

It appears the commercial software applies some sort of peak integration and mass calibration to the raw data, which would probably be good to have in eXSpy.

Otherwise, on a review of some SIMS literature and other packages I found, the following features are probably useful (though I would love to have some confirmation/comments from people who actually do SIMS). I don't think all of these are necessary for a first implementation, but just making some notes:

Potential features of new signal type

• Mass axis handling:
  • The default h5 data file produced by the TOFWERK software provides already calibrated data in FullSpectra/MassAxis and FullSpectra/SumSpectrum
  • There is also a FullSpectra/EventList dataset inside the h5 that represents the lowest level data, I believe each element is a list of raw values representing DAQ clock ticks from the time-to-digital converter. To know what mass a given timestamp corresponds to, you have to apply the mass calibration equation, as is done in the TOF-Tracer package in TOFFunctions.jl
  • The calibration relationship is non-linear (i = p1·√m + p2 for the most common mode), so methods that operate in mass space (peak picking, integration window calculation) need to account for this rather than assuming a linear axis. Since there are a couple different mass calibration approaches, I could see a recalibrate_mass_axis() function being potentially useful?
• Peak integration:
  • The standard approach appears to be to sum counts within a window around each nominal mass, but the optimal window width depends on mass resolving power. TOF-Tracer implements a resolving-power-based IntegrationBorders method that sets window edges at either m ± m/R or the midpoint between adjacent peaks, whichever is narrower.
• TIC normalization:
  • Depth profiles and spatial maps are typically normalized by Total Ion Count to correct for topography and sputter rate variation. I could envision a few helper methods:
    • get_tic(): Returns the TIC as a new navigation-dimension signal, useful to inspect the TIC map before deciding on a normalization strategy
    • normalize_tic(): Normalize the data as normalized_intensity(pixel, mass) = raw_intensity(pixel, mass) / TIC(pixel); converts the data to a fractional composition: "what fraction of all ions detected at this pixel were of this mass?" so all pixels now sum to 1.0 across the mass axis. TIC normalization is useful whenever you want to ask "what is the relative chemical composition here?" rather than "how many ions did we detect here?" since it removes instrument and geometry artifacts so that pixel-to-pixel or slice-to-slice differences reflect real chemistry.
    • normalize_to_peak(mass, window=0.5): This approach is mentioned a couple times I could find in the TOF-SIMS literature, described as "normalizing to a subset of selected peaks" in PMC10154066: "Normalizing to the sum of selected peaks... is often a good choice when looking at a subset of peaks from the spectra." A concrete worked example appears in the metal/metal oxide multilayer depth profiling study (PMC8739835), which normalizes to H⁻ signal intensity rather than TIC when profiling Ti/Si multilayers in H₂ atmosphere — because H⁻ is stable across layer boundaries while TIC is not. That same paper also demonstrates normalizing to Cs₂⁺ rather than Cs⁺ when Cs⁺ is saturated, illustrating the saturation-driven case.

Implementation proposal

I think a thin subclass of Signal1D (ToFSIMSSpectrum?) makes sense for this data type, together with a reader in RSciIO.

I agree that there seems to be a real gap in the Python ecosystem for multi-dimensional ToF-SIMS — pySPM covers IONTOF files but is not focused on FIB ToF-SIMS. The Bioconductor tofsims package is R-only. TOF-Tracer is julia.

I think an eXSpy signal class with for this would be a useful addition for the community. Scope-wise, I think it fits naturally to include in eXSpy, and since we don't have a ton of SIMS applications at this point, maintaining a whole separate package would likely be an unnecessary burden (though we could always split it off in the future if there's more development to do).

---

Some references

• PMC10154066 Back to the basics Part II — data processing and display: https://pmc.ncbi.nlm.nih.gov/articles/PMC10154066/
• How to normalize peak intensities for ToF-SIMS (ResearchGate community discussion): https://www.researchgate.net/post/How-to-normalize-peak-intensities-for-ToF-SIMS-data
• PMC1989146 Multivariate analysis strategies for ToF-SIMS images (TIC normalization context): https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1989146/
• ToF-SIMS in battery research — normalization limitations: https://pubs.aip.org/avs/jva/article/41/5/053207/2905250/ToF-SIMS-in-battery-research-Advantages

[ericpre]

This sounds good and interesting!
What you explain about the manual calibration makes me wonder if this should be implemented in RosettaSciIO, because the reader doesn't return data as list of events.

I think an eXSpy signal class with for this would be a useful addition for the community. Scope-wise, I think it fits naturally to include in eXSpy, and since we don't have a ton of SIMS applications at this point, maintaining a whole separate package would likely be an unnecessary burden (though we could always split it off in the future if there's more development to do).

Yes, exactly.

[CSSFrancis]

@jat255 seems like a good idea :) It might be worth discussing this a bit further.

On a side note, one thing I've thought about is:

1. We should be better at saving average pattern/spectrum and multiple virtual images
2. We need a better way to share data
3. Can we have interactive images in the browser.

Starting from Rosettasciio I think we should start defining guide image/navigation images as well as average spectra/ images.

Maybe just a generic field where you can add as many as you'd like.

Then something like NexusLIMS could easily access it. Or for online datasets you can visualize parts of them on the web before downloading.

[jat255]

@ericpre if you happen to have any example files for this type of data, that would be much appreciated! I have a couple examples from my client, but they all come from the same instrument, so I'm not certain if there's much (or any) variability in the structure, metadata, etc.

@CSSFrancis I think this dovetails nicely with the idea of virtual images on the 4D-STEM side as you mention. Storing such data in a zarr data structure probably allows a nice way of doing the online/sharing mode of only pulling the data you actually need for a given operation (or none, if all you're after is the metadata like NexusLIMS)

I could also potentially envision a "preview" image (which depends on the type of signal of course) being stored alongside the actual data. For a lot of data types this probably isn't necessary, but for others it's almost critical. This is not so different than how a lot of TIFF images store a JPEG thumbnail in their EXIF data, or other strategies. For the SIMS data, this could look something like:

[jat255]

I've opened #169 and hyperspy/rosettasciio#491 for some comments!