Resaving xlef file creates non-functional lif/tif file

Hi,

our facility users record H&E tile scans on a Leica system, generating .xlef and .lof files. They stitch the files using LASX, creating a merged image within the same Leica file (project).
Following Opening .lof Leica files it is best to open the .xlef/.lof files with LASX and resave them.
Following BioFormats - Lifext: pyramid support for Leica LIF file : status? .lifext files containing pyramids and are read easily.

I encounter the following problems when handling the stitched file (~3GB). Resaving the stitched file as .lif or exporting as .tif creates a file with unexpected behavior:

  1. in QuPath: QuPath works best with pyramidial files; when clicking yes or no: Java.lang.NullPointerException
  2. in Fiji: open the file as a 3-channel (R, G, B in separate channels) that look normal. When switching to composite view the image as attached becomes visible.
  3. In LASX I cannot choose to generate a .lifext file. Some of the users’ tile scans come with a lifext file (maybe dependent on the size of the lif-file?). I can handle the lifext-file without problems in both Fiji and QuPath.

How do I obtain a (pyramid) file that I can handle properly with Fiji/QuPath?

1 Like

hi @aklemm ,

Which Leica system is it?

My two cents. We have an inverted Thunder system, used mostly for acquiring really large mosaics (>4 GB). Exporting them as TIFF does not help (to load them in QuPath) since exported TIFF is not pyramidal. Our work around is to invoke VIPS, that with a simple line of code

vips tiffsave “name-of-your-file”.tif --pyramid “new-name-of-your-file”.tif

re-saves your file now as a pyramidal TIFF, which can be easily imported in QuPath. It is not the best solution for everyone but it does the job.

Alvaro

4 Likes

Quick note, you can likely do the same thing with just QuPath, though maybe vips would be faster, I am not sure. I do not know if the original file will work, but I have definitely batch processed TIFF files->pyramidal TIFFs this way (via python script >.>). Maybe @petebankhead would know if there is a way to target a folder for ome.tif conversion.

2 Likes

Could you include some more lines from the error please? If nothing more appears, it should be under View → Show log. This might be a bug in QuPath we can easily fix, but I’m not sure.

(Alternatively, if you’re able to share an image with me then that would be even better.)

1 Like

Hi All,

thanks for the help!

@acrevenna - vips indeed worked fine and vips-generated pyramid files open in QuPath.

@petebankhead I have asked the user whether I can share the data with you. Error log: log.txt (52.6 KB)

The vips-generated file opened in Fiji still displays as the screenshot above. I now realized that this is “only” the LUT, the pixel values seem to be fine.
Using QuPath to export an OME-TIFF (following @Research_Associate thread) I find that this problem occurs only with the series of the highest resolution.

1 Like

So the problem is only with FIJI in that case? Since I assume the QuPath exported image works within QuPath. Or are there still problems there as well?

1 Like

Thanks Anna, this is very helpful – it does look like the problem is a bit deeper than I was hoping, and it might not be fixable from QuPath. The key bit is

Caused by Array size too large: 27688 x 35757 x 3 x 1        at loci.common.DataTools.safeMultiply32(DataTools.java:1286)
        at loci.common.DataTools.allocate(DataTools.java:1259)
        at loci.formats.FormatReader.openBytes(FormatReader.java:869)
        at loci.formats.ImageReader.openBytes(ImageReader.java:449)
        at loci.formats.ReaderWrapper.openBytes(ReaderWrapper.java:334)
        at qupath.lib.images.servers.bioformats.BioFormatsImageServer.readTile(BioFormatsImageServer.java:859)

which is the familiar error when trying to read the entire image in one go. But if the same image does open in Fiji, it suggests QuPath could be doing better.

1 Like

Yeah I would expect to see that error when trying to read a large image in one go. Normally reading the lower resolution, tiled reading or cropping a region would be the solutions. However I would expect the behaviour to be the same for QuPath and Fiji, so it would probably be best to see and test the image itself.

1 Like

Thanks for pointing to this thread.

I am sharing the full data with @petebankhead for further testing. However, it looks solved for me now: in Fiji I will use a lower resolution image which should work in this project and for QuPath I can use the VIPS conversion.

Thank you for the help!

1 Like

Thanks @aklemm the problem is that the ‘optimal’ tile size provided by Bio-Formats is 27688 x 12 pixels. This would be ok, except QuPath ignores tile sizes if any dimension is less than 32 pixels – with the result that QuPath assumes the entire image is just one big tile and attempts to read in one go… unsuccessfully.

Knowing that, I can improve QuPath’s logic for handling extreme tile sizes. This is enough to get the image to open, even if it is a bit slow since it still requires everything to be read into RAM.

1 Like

Here’s the fix, which will be in the next QuPath release Improve default tile sizes when using BioFormats · petebankhead/qupath@21d6cf8 · GitHub

3 Likes

Fantastic - thank you!