Bioformats Issue with .mrxs file

Usage & Issues
, ,
#1

Hi Bio-Formats people!

We received some lovely Masson-Trichrome images from @Judit that are in the controversial .mrxs format.

However BioFormats does not see the higher resolution pyramids. I know that this can be caused by the compression algorithm or by the image type (Fluorescence).

My question is more: What can we do to get a compatible format, ideally pyramidal?
I can share the file and folder pair (~600MB) if there is a kind soul that can help by assisting in creating a protocol. Ideally someone who has suffered similar issues.

Best

Oli

#2

Hi Oli,
Have you tried the Glencoe tools? See: https://www.glencoesoftware.com/blog/2019/12/09/converting-whole-slide-images-to-OME-TIFF.html
Cheers,
Damir

3 Likes
Qu Path only opens previews of mrxs files
#3

Yep, I would say that or load it into QuPath with OpenSlide (unless it is JPEGXR, in which case that wonā€™t work) and export it that way. I figure you have probably already tried that one though, so the above might be it.

1 Like
#4

Hi @dsudar,

Thanks for the link. I will definitely try that! Next week.

And @Research_Associate I tried with OpenSlide as you suggested but to no avail. Guess itā€™s the compression scheme, as these are supposed to be RGB images.

However I have received some interesting information : apparently loading this dataset into QuPath from Linux actually worksā€¦ I havenā€™t verified it myself but could this be linked to some difference in the OpenSlide library?

1 Like
#5

Could be ā€“ QuPath + OpenSlide on Linux can end up using system-wide (sub)dependencies. Mostly this manifests itself in a bad way but I guess sometimes it can work out.

3 Likes
#6

Thanks all for the valuable feedback!

I installed everything and ran it successfully. Compared to using the bfconvert command line tool, this saves about 2h of processing at least and the final ome.tiff file seems much better optimized in QuPath.

I documented the whole process here:
https://c4science.ch/w/bioimaging_and_optics_platform_biop/image-processing/qupath/ome-tiff-conversion/

6 Likes
#7

They are also available as conda packages here: https://anaconda.org/ome/repo if thatā€™s your thing.

4 Likes
#8

@oburri Nice write-up. And thanks for the tip about the --rgb flag. I had missed that flag entirely.
Cheers, Damir

1 Like
#9

Hi !
@oburri thanks a lot for helping and for documenting the process. Thanks all for valuable sugestions- good to know that there is a place where I can get some help. Cheers, Judit

1 Like
#10

Hi Oli!

I am a collegue of @Judit and I just tried your mrxs->ometiff conversion protocol with bfconverter (not on these masson images but same format) and I got some issues.
I recieved an ometiff file at the and, but Qupath barely opened it, and it seemed that resolution deteriorated a bit. Maybe the problem is that the metadata contains a label image as well? (my final ometiff also contains 2 tiff files, the section and the label)
Unfortunatelly I am absolutely a noob in the field so I donā€™t know any parameters to adjust and no idea how to start solving my problem. So sorry for stupid questions.

Cheers
Tamas

#11

Dear @tamaslkt,

What do you mean with ā€œbarely opened itā€?

In the case of files with multiple series, you cannot select which ones get converted. You get the same structure out as you had inā€¦

If the resolution deteriorated, it could be the compression scheme. Perhaps the best would be if you shared the raw file somewhere so people can have a look?

Best

Oli

#12

Hi @tamaslkt, before running the bfconvert tool it might be worth running the following command to confirm that the dimensions and metadata look correct:

showinf -nopix -omexml path/to/myFile.mrxs

#13

Dear @oburri and @dgault,

thanks for your reply! I uploaded the raw files and the product here:

https://drive.google.com/drive/folders/1xvpSdkHmnkqbRH_C1esPbqcEwqzt9wW3?usp=sharing

Itā€™s not impossible that I missed something during the conversion, though finally there was no error in the process. Thanks for your assistance I keep trying my best.

Cheers

#14

Thanks for the file. One interesting and frustrating thing is that this is the file as opened by QuPath

image
image376Ɨ551 15.2 KB

so even though there does not seem to be data in the lower part of the image, the bioformats conversion has created a huge area with pure black which is not particularly usefulā€¦ Is there a way to avoid this? And only save the area with non-zero pixels? @dgault I guess this is a common issue with formats that allow for non-rectangular imagesā€¦

1 Like
#15

Bio-Formats wont try to do anything such as automatically discard areas without data, and instead they will be displayed with zeroā€™s. If the dimensions are indeed correct for that image then what I would probably suggest is cropping the image during conversion to a more reasonable size to work with.

So you can add the crop option as below:

`-crop` ` X,Y,WIDTH,HEIGHT` 
bfconvert -crop 0,0,512,512 /path/to/file output-512x512-crop.tiff
1 Like
#16

When OpenSlide reads an .mrxs file, it generally includes cropping information in the ā€˜boundsā€™ properties: https://openslide.org/docs/properties/

QuPath v0.1.2 ignored this (and there was often a huge bit of space around the image), while v0.2.0 applies it.

It does something similar with other formats; in particular, .scn images sometimes had the padding if opened in QuPath v0.1.2 with OpenSlide ā€“ but they didnā€™t if opened with Bio-Formats (since Bio-Formats must handle these bounds internally). In that case, the cropping suggested by OpenSlide needs to be applied to get an image the same size as the one Bio-Formats provides automatically.

From a quick look at an .mrxs file, I see there is an .ini. file associated with it that contains entries like this:

COMPRESSED_STITCHING_ORIG_SLIDE_SCANNED_AREA_IN_PIXELS__LEFT = 100
COMPRESSED_STITCHING_ORIG_SLIDE_SCANNED_AREA_IN_PIXELS__TOP = 11232
COMPRESSED_STITCHING_ORIG_SLIDE_SCANNED_AREA_IN_PIXELS__RIGHT = 38400
COMPRESSED_STITCHING_ORIG_SLIDE_SCANNED_AREA_IN_PIXELS__BOTTOM = 194000

These differ for each image and seem match with OpenSlideā€™s bounds properties ā€“ I suspect at some point the image should be cropped using these.

1 Like