Question before PR: expose aligned EIC traces / peak boundaries?

[Fraximov]

Hello MS-DIAL team,

I am building a small downstream QC dashboard around MS-DIAL console outputs, and I wanted to ask before opening a PR because I may be looking at an internal format that you do not want people to depend on.

The use case is simple: in the MS-DIAL GUI, it is possible to inspect the aligned EIC for a feature across samples and see which peak was integrated. This is very useful for QC, especially when one sample was integrated on a small neighboring peak instead of the expected peak.

For an external dashboard, I would prefer not to recompute EICs from raw data, because MS-DIAL already made the extraction/integration decisions. Recomputing outside MS-DIAL could show something slightly different from what was actually integrated.

Would you be open to exposing this information in a documented way?

For each aligned spot and sample, the useful information would be:

• the alignment ID or aligned spot index
• the sample/file ID
• the EIC points used by MS-DIAL
• the peak boundaries and apex position used for integration
• the x-axis type and values, for example RT, RI, drift time, or m/z

I have prototyped a small reader for AlignResult*.EIC.aef, enough to display these traces in a lightweight QC viewer. But since this looks like an internal binary format, I would rather ask what direction would be acceptable before preparing a PR.

Possible PR shapes could be:

• document or expose a reader for the existing .EIC.aef data
• add an optional export for aligned EIC traces
• add an export limited to selected or annotated features, to avoid large files
• use an existing internal MS-DIAL class/API if there is already a better access path

My main questions are:

• Is .EIC.aef meant to stay internal-only?
• Would you prefer an official export instead of documenting this binary file?
• Is there already an internal class that should be used for this?
• Would a small PR with tests and a tiny fixture be useful?

Thank you for your work on MS-DIAL. I would be happy to adapt the contribution to whatever format is easiest to maintain.