search

qupath / qupath

QuPath - Bioimage analysis & digital pathology
https://qupath.github.io
GNU General Public License v3.0
1.03k stars 275 forks source link

Cannot open *.czi with multiple scenes #337

Closed arnmayer closed 4 years ago

arnmayer commented 5 years ago

Hello Pete, hello everyone on this forum!

Bug report

Describe the bug Today, I tried opening one of our multichannel, multi-scene (TMA) Zeiss .czi files on an installation of QuPath Version 0.2.0-m2 on a recently installed Windows 10 system. To my surprise, this failed. I tried other files of the same type and got the same result. I could not open any of the multi-scene .czi files I have tried.

Of note, I have been working with version 0.2.0-m2 for a while now and it worked very well with "normal" *.czi files, which are also multi-channel, but do not contain multiple scenes. It must have been by sheer coincidence that, so far, I just had not tried any multi-scene files.

We have another PC with a QuPath installation in our lab, which runs 0.2.0-m1. It shows the same behaviour: no problem opening "normal" multichannel (4-plex) *.czi files, not able to open multi-scene files.

To Reproduce Steps to reproduce the behavior:

  1. Go to File
  2. Click on open
  3. Choose a *.czi file which you know is multi-scene
  4. See error "Sorry, can't open ... path to file"

Expected behavior These files used to open in version 0.1.3. The scenes were read as individual images. In the Zeiss "ZEN blue" software, there is an option to show all the scenes at once. This had not been possible in QuPath in the past. I was hoping that with the new version of Bioformats it might now be possible, but it seems we have moved a step backwards.

Screenshots Not applicable.

Desktop (please complete the following information):

Additional context Multi-scene *.czi files have been giving trouble in the past, e.g. with memory use. However, apart from the inability to "stitch" the scenes and show them all at once, the prior versions of QuPath could open them. Some googleing led me to checking as to whether the Microsoft Visual C++ Runtime Redistributables are installed on my system. The answer is yes.

Thank you in advance,

Arnulf University Medical Center Mainz, Germany Dept. of Radiation Oncology

Svidro commented 5 years ago

If it is an image or BioFormats based issue, I doubt there is much that can be done on the QuPath end. Have you tried opening the file in FIJI using the BioFormats importer? If it works there and doesn't in QuPath, it might be a QuPath interpretation error, otherwise it would need to be handled on the BioFormats issues page/Image.sc forum.

Also, thank you for taking the time to fill out the whole form :)

Svidro commented 5 years ago

Potentially more useful... You can Split Scenes (write files) out of Zen. If you have labeled your scenes correctly (A1, A2, etc), that information is retained in the file name. You can then create a project from those images. The individual images should work the same way normal CZI files do. Which is to say, not at all if they are 14bit images, and with significant problems with 8bit brightfield images.

Edit: I just saw you mentioned 4 channel, so nevermind that brightfield bit. The split scenes write files should still work!

petebankhead commented 5 years ago

I can confirm this is a QuPath problem, not a Bio-Formats one.

It actually seems to already be fixed in my code (without realising it was ever broken...), so should work in the next milestone.

Thanks for reporting this, it helps to remind me I need to check this specifically before the next release.

arnmayer commented 5 years ago

Thank you very much for looking into this problem so quickly!

In the meantime, I was able to open the TMA (multi-scene) file in Fiji - at least partially.

The Bio-Formats import dialog asked "Please specify the image series you wish to import. Use commas ... There are 690 total series." I requested all 690 series to be imported. I indeed got the stitched (!) version of all the scenes in the *.czi file. So, finally, the Bio-Formats importer is able to do the stitching!

However, so far I have only imported one channel, because I did not check the "Open all series" option. When I do check "Open all series", the import dialogue tells me that I don't have enough memory. (I need around 80 GB, have 24). I tried it anyway and it failed.

image

@Svidro Thank you very much! I am aware of the option to split the scenes and I have made extensive use of that possibility in projects with TMA specimens back when QuPath was not able to read multi-scene .czi at all. I have also tried hard to convince the guys at Zeiss to include a "merge all scenes" option in ZEN because for us the scenes offer no benefit. Unfortunately, this does not seem to be a priory for them although I have not checked for ZEN updates in a while. Also, if Bio-Formats can now stitch the scenes and the latest development version of QuPath already works with multi-scene .czi files, as Pete stated, the request is obsolete anyway.

So, thanks again. I'm looking forward to 0.2.0-m3!

Svidro commented 5 years ago

My thought was that with the addition of merging the data set (links below), you can still end up with a final sheet that represents the data points from your cores. It would be one project per TMA, but at least you could fairly easily get the results right now, rather than waiting for m3. Or I guess you could continue to use 1.3, that works as well :) https://forum.image.sc/t/h-score-by-object-class/27490/2?u=research_associate If you want the visualization of your cores, that wouldn't help at all, of course.

If you are in Zen (not sure which all versions), you can uncheck "show scenes individually" (I might not be remembering the exact wording, it is just below the image area, slightly to the left) to get an overview image. We have used that to create downsampled overviews of multiple wells on a 6 well plate, for example.

arnmayer commented 5 years ago

Since my multi-scene specimens are mostly tissue microarrays, the advantage would be that I could use all of QuPath's TMA functionality. I will have a look at those scripts. Thank you very much!

Regarding ZEN: Yes, I'm aware that ZEN can do that. But it cannot "commit" that change, i.e., save it to the file so that the scenes are gone. I had a lengthy discussion with some people at Zeiss about this. They see it in a way that getting rid of the scenes makes no sense to them. However, someone at Zeiss must have thought of that because in the TIFF export dialogue you actually do have the possibility to merge the scenes on export. I even tried exporting as a merged TIFF and then re-importing to the *.czi format. This works for smaller images (... and takes a lot of time ...) but fails for the image sizes we typically use in whole slide imaging.

petebankhead commented 5 years ago

I don't have an immediate solution, but I can think of three approaches to improve the situation...

  1. Improve QuPath's functions for handling TMAs based on dearrayed cores
  2. Find a way to merge the cores within QuPath
  3. Create a QuPath extension to use Zeiss' own open source CZI reader: https://github.com/zeiss-microscopy/libCZI

I think Option 1 has additional advantages and is probably needed in the longer term. Option 3 involves more work to support one particular format than I'm able to take on myself, but perhaps someone would like to try. It might give improvements over relying only on Bio-Formats... but it would definitely be a lot more work to develop and support cross-platform.

Option 2 (merging) is 'easiest' if that involves writing a new pyramidal OME-TIFF file... but that rather increases the amount of data involved, and requires knowing the coordinates where each core comes from.

A practical issue here is that I have seen a .czi TMA (I believe yours, @arnmayer :) ) that Bio-Formats has several problems with. This thwarts any plan we might develop to resolve this independently of Zeiss or the Bio-Formats team. Specifically:

If this image can be shared with the Bio-Formats team, they may be able to address these issues.

Finally, one of the delays to m3 is I've been doing the groundwork to make image servers smarter. The relevance here is that it means that an image server is able to dynamically crop and/or reposition parts of an image to generate 'pseudo' whole slide images in QuPath, which might be composed of different pieces. They can also do extra fancy things like apply color transforms or concatenate channels.

It will take some time to make this to become a fully-usable part of the software, but it relates to the problem as follows:

This has some limitations, e.g. if your cores aren't in a pyramidal format (but rather one 5000x5000 pixel image, for example) then combining these together dynamically won't end well. To get any kind of usable performance, it will be necessary to convert the files to make them pyramidal.

I hope that makes some kind of sense, describing what's possible now, what problematic, and what's coming...

Important PS. There's currently a post advertised to join me at work on QuPath here. With more than me working on it, things should be much faster - please pass on the link to anyone who might be interested!

petebankhead commented 4 years ago

Closing this because it has been quiet, and because the original issue should be fixed in the latest release.

Positioning scenes in 2D remains a possible future improvement, but is a little tricky/risky because of uncertainty in how exactly to interpret position information consistently across formats. See https://forum.image.sc/t/improve-bio-formats-image-position-metadata/30770