Export MSImageSet to imzML

[educh...@gmail.com]

Hi all Cardinalers!
I have one question. I didnt found how to do this: How can I export a MSImageSet to imzML? Is it possible?
I'm now doing some pre-processing steps using Cardinal and I have to give my users the preprocessed scans in imzML.
Thanks in advance!
Best regards,
Edu

[kbemis]

It is not possible yet. I hope to add that feature in the future.

-Kylie

[educh...@gmail.com]

Thank you so much Kylie! We will wait for it!
And of course, again thank you for this amazing package!
Regards!

Edu

[psh9...@gmail.com]

Hi Edu,

I am currently preprocessing the images in Cardinal and working with matlab exporting the images to .mat format. But instead of exporting MSImageSet, I only export the spectra and mz vectors. 

I belive that there is a package to build a imzML file from spectra and mz (or not, i haven´t looked into it still), but if you want, you can use functions imageData(MSImageSet)[] for spectra and mz(MSImageData) for mz.

I don´t know if this can help you but just to give you a little help,

-Suhyung

[educh...@gmail.com]

Hi Suhyung,
thanks for your help. I'll try it by this way and let's see if my users can use this.
Only one question. How do you obtain the x,y location? With this two procedures (exporting mz and spectra) you are losing this coordinates... or not?
Regards

Edu

[psh9...@gmail.com]

Hi Edu,

This is what Kylie told me to get coordinates/mz/spectra. Hope this helps you.

iData returns the spectral information where m/z is row, and each pixel is columns. You may want to transpose this.  

#get feature matrix from cardinal, feature x pixel
spectra <- iData(dataset)

#transposed, pixel x feature
spectra <- t(iData(dataset))


Getting x,y integer coordinates, if you have additional variables (like "sample") you may want to add more columns to the index, this returns only the xy coordinates

xy_coords =coord(dataset)[,1:2]

[kbemis]

Dear all,

I have added experimental support for writing imzML in Cardinal version  >= 1.11.2. It is currently available on Github (use package devtools and devtools::install_github to install from Github). It may take a couple days for the build to propagate on devel BioC.

I haven't yet tested it with other software, so I am not 100% sure of the validity of the imzML files, but it should include the most important metadata that other software would care about for importing. Let me know if you encounter problems.

Note that the conversion is lossy with regard to the metadata, because not all imzML tags are supported. The necessary intensity, m/z, and coordinate information will all be there, though.

The feature will be included with the next Bioconductor release.

-Kylie

[educh...@gmail.com]

Wow! Thanks Kylie!!!
I'll try to test it this week with my datasets and I'll give feedback.
Have a nice week!

[kbemis]

I forgot to mention it also requires package “matter” version >= 1.5.4:

http://bioconductor.org/packages/devel/bioc/html/matter.html
https://github.com/kuwisdelu/matter

-Kylie

[Melanie Föll]

Hi Kylie,

thanks for implementing the imzML export, this will be super useful!

Unfortunately the writeImzML does not work for me, it would be great if you have an idea what is going wrong here.

I downloaded the example 1 continuous imzML testfile from https://ms-imaging.org/wp/imzml/example-files-test/, and then only read and write in Cardinal:

small_file = readMSIData(file="Example_Continuous.imzML") #this works
writeImzML(small_file, "small_file")
# It returns: "Error: The specified file is not readable: V:\example_files\small_file.ibd"

I can find the written small_file.ibd in the folder and it has the same size as the input ibd file has, but apparently something went wrong.

I used R 3.5, Cardinal 1.12 and Matter 1.6

Best,

Melanie

[kbemis]

Hi Melanie,

I can't replicate your error on my Mac, and I don't currently have access to a Windows machine to test.

What happens if you read back in "small_file.imzML" with readMSIData() or readImzML()? Does it appear that the data is there?

Can you confirm that "V:\example_files\small_file.ibd" is the file path where the file should have ended up?

Also, try running:

file.access("V:\example_files\small_file.ibd", mode=4)

and let me know if it returns 0 or -1.

Thanks!

-Kylie

[Melanie Föll]

Hi Kylie,

thanks for your fast answer :)

"V:\example_files\small_file.ibd" is the windows path where the file should be and also physically it is there when navigating to the example_files folder and it has the same size as the original .ibd file. What is missing is the small_file.imzML, it seems like this file has never been written.

When I remove the original ibd input Example_Continuous.ibd and rename the small_file.ibd into Example_Continuous.ibd then I can read in the file normally. It seems like the ibd file is ok but due to the given error the imzML file never gets written.

The funny thing is that the paths which are used for the error messages have the windows backslash \ instead of the / slash usually used in R. Therefore if I copy the path from the error message into the file.access the file.access doesn't work of course. If I change the slashes by hand it returns -1.

> file.access("V:\example_files\small_file.ibd", mode=4)

#Error: '\e' is an unrecognized escape in character string starting ""V:\e"
> file.access("V:/example_files/small_file.ibd", mode=4)
V:/example_files/small_file.ibd
                             -1

Despite giving -1, when I rename the small_file.ibd and read it in again with the original imzML the reading works. Furthermore, when I try file.access on the original input files, they also give -1, despite I was able to read them:

> file.access("V:/example_files/Example_Continuous.ibd", mode=4)
V:/example_files/Example_Continuous.ibd
                                     -1
> file.access("V:/example_files/Example_Continuous.imzML", mode=4)
V:/example_files/Example_Continuous.imzML
                                       -1

Best,

Melanie




[kbemis]

Hi Melanie,

For the Windows path slash, you need to use "\\" instead of "\". This is because "\" is interpreted as an escape for a special character (e.g., "\n" is a newline and "\t" is a tab). Using "\\" will correctly be interpreted as the character "\", and it should find the file correctly.

The "file isn't readable" issue originates from the digest::digest() function which is used to calculate the sha1 checksum of the binary file. The digest::digest() function checks with file.access() whether the file is readable (which it clearly should be since it can be read) and gives that error if it's not. The sha1 checksum of the binary data is required to write the imzML file, which is why the ibd file is there, but you get an error before the imzML file can be written.

Can you try:

digest::digest(file="V:\\example_files\\small_file.ibd", algo="sha1")

and see if it succeeds in giving you a hash? If not, maybe try it on some other files, to see if the V: drive is somehow the issue?

-Kylie

[Melanie Föll]

Hi Kylie,

the digest returns the same error as before. The writing did also not work for other files.

When I change the drive I can write the files :)

Thank you very much for your help!

Best,

Melanie

[kbemis]

So it works with other drives? I am not sure why it would not work for the one you tried earlier.

In any case, it seems like the digest() function calculating the hash is the issue rather than the actual writing of the file. I will consider writing a blank hash with a warning to handle this in the future. (The metadata would technically be incorrect but most software should not care.)

Thanks!
-Kylie

[Melanie Föll]

Thanks to you! On the other drive everything is ok :)

[Melanie Föll]

Hi again,

is there a trick to keep pixel annotations such as msidata$diagnosis?

Thanks,

Melanie

[kbemis]

Not currently. Custom metadata and annotations would have to be handled with custom <userParam/> tags in the imzML file. Technically this is possible but not with the current Cardinal implementation. I will consider adding it in the future, but it might be a bit difficult to do it in a generalizable way, and other software probably wouldn’t be aware of it. I will think about ways it could be supported within Cardinal at least...

Currently the easiest way to store the annotations in a compatible way would just be to write the pixelData to a CSV file (e.g. with write.csv()) and store it alongside the imzML. Most other software currently resort to something like this (e.g. for regions of interest) rather than write it into the imzML.

-Kylie

[Melanie Föll]

No worries, I was just wondering ;) Thanks again for adding the writeimzml function!