Opening Olympus VSI Files from virtual Slide Scanner

[Oli]

Dear Melissa,

We have an Olympus Virtual Slide Scanner here and have been able to read in the data rather easily using the great LOCI Bio-Formats plugin.
However we've come across a dataset that does not provide the largest resolution image when importing it with Bio-Formats.
I've looked at the builds from Olympus and it's the same one we had when opening the previous datasets. One difference I see here is that the software auto-detected the tissue and scanned only the detected regions, so that could have had an influence, though other datasets have worked.

The dataset is provided here
https://documents.epfl.ch/users/o/ob/oburri/www/OlyVIA/Undetected_VSI.rar

Best and thank you for your time,

Oli

[mlinkert]

Hi Oli,

Thank you for reporting this (and for making a file available!).

It looks like the issue is that the files that contain the full-resolution images are in a directory that isn't named the way that Bio-Formats is expecting. I see:

Code: Select all

$ ls -hl *
-rw-r--r-- 1 melissa melissa 942K 2012-07-04 10:22 7262 wt col.vsi
-rw-r--r-- 1 melissa melissa 279M 2012-07-12 14:44 Undetected_VSI.rar

7262 wt col:
total 8.0K
drwxr-xr-x 2 melissa melissa 4.0K 2012-07-11 09:45 stack1
drwxr-xr-x 2 melissa melissa 4.0K 2012-07-11 09:45 stack10001


...and what I expect is:

Code: Select all

$ ls -hl *
-rw-r--r-- 1 melissa melissa 942K 2012-07-04 10:22 7262 wt col.vsi
-rw-r--r-- 1 melissa melissa 279M 2012-07-12 14:44 Undetected_VSI.rar

_7262 wt col_:
total 8.0K
drwxr-xr-x 2 melissa melissa 4.0K 2012-07-11 09:45 stack1
drwxr-xr-x 2 melissa melissa 4.0K 2012-07-11 09:45 stack10001


i.e. the sub-directory name should start and end with "_". If I create that directory and move the stack* directories into it, then the dataset appears to open correctly. Can you confirm that this is the case? Did the directory names change at all after acquisition, or is this exactly how the original data was structured?

Regards,
-Melissa

[Oli]

Dear Melissa,

i.e. the sub-directory name should start and end with "_". If I create that directory and move the stack* directories into it, then the dataset appears to open correctly. Can you confirm that this is the case? Did the directory names change at all after acquisition, or is this exactly how the original data was structured?

This indeed solves the problem. This is what happens when users don't tell us that they renamed the folders and files when they come to see us. We've learned our lesson and thank you very much for your time!

[Oli]

Dear Melissa,

Again, thank you for the previous response. One new point that seems troubling is the following.
Series 1 is usually an overview image taken with the 2X objective of the entire slide.
This image is in the vicinity of 85'000 x 40'000 pixels (Calculated for a px sizse of 3.45um, 2X, c-mount of 1.0 on a slide that is 25x50mm without the label area)

Funny thing is that the image as read by BioFormats announces over 340'000 x 140'000pixels.
Second with crop on import, only crops in the range 85'000 x 40'000 show the image, anything beyond that imports only black.

You can see it in the dataset that was submitted before.

Thanks for any help you can provide!

Best

Oli

[mlinkert]

Hi Oli,

Again, thank you for the previous response. One new point that seems troubling is the following.
Series 1 is usually an overview image taken with the 2X objective of the entire slide.
This image is in the vicinity of 85'000 x 40'000 pixels (Calculated for a px sizse of 3.45um, 2X, c-mount of 1.0 on a slide that is 25x50mm without the label area)

Funny thing is that the image as read by BioFormats announces over 340'000 x 140'000pixels.
Second with crop on import, only crops in the range 85'000 x 40'000 show the image, anything beyond that imports only black.

I have a little trouble duplicating this; Bio-Formats does indeed report that the dimensions of the highest-resolution image are 338793 x 157849. If I open the dataset in cellSens Viewer and pick the "40x" layer, then zoom in to 300% and move to the lower-right corner, then I see that the pixel coordinate of the lower-right-most pixel is (338792, 157848). That, to me, suggests that Bio-Formats is reporting the size correctly. Can you confirm that you see the same thing?

I do definitely see that the tiles outside of ~85000 x 40000 are all black, so I have filed a ticket for that here:

http://trac.openmicroscopy.org.uk/ome/ticket/9376

...and you have been CC'd as usual.

Regards,
-Melissa

[Oli]

Dear Melissa,

I understand your doubts regarding this error, however there is a conceptual error to correct.

While at 40X the image size is indeed 338792 X 157848, the 40X images are only a part of the whole slide.

The first series corresponds to the slide imaged using a 2X objective, which is about 85'000 x 40'000 real pixels in size.
Therefore, even though it maps properly to the full size image, this is only true if each real pixel in series 1 maps to about 4 pixels in the reported 338792 X 157848 size.

I'm not sure I am clear, but it seems to me that BioFormats reports the size the image should have at "full magnification" if we had taken the entire slide at 40X, rather than the actual number of pixels that make up this image.

I would also like to point out that about 3 weeks ago, this size was reported properly in BioFormats.


Thank you for the ticket!

Kind regards,

Oli

[mlinkert]

Hi Oli,

I understand your doubts regarding this error, however there is a conceptual error to correct.

While at 40X the image size is indeed 338792 X 157848, the 40X images are only a part of the whole slide.

The first series corresponds to the slide imaged using a 2X objective, which is about 85'000 x 40'000 real pixels in size.
Therefore, even though it maps properly to the full size image, this is only true if each real pixel in series 1 maps to about 4 pixels in the reported 338792 X 157848 size.

I'm not sure I am clear, but it seems to me that BioFormats reports the size the image should have at "full magnification" if we had taken the entire slide at 40X, rather than the actual number of pixels that make up this image.

OK, that makes sense. Thank you for the explanation!

I have updated the ticket accordingly, and hopefully we'll be able to get this fixed soon.

Regards,
-Melissa

[Oli]

Dear Melissa,

Thanks again for the support your team has provided. I'd like to submit a troublesome dataset that yields the following error log using the latest trunk build of LOCI formats (Should we use the new SNAPSHOT versions that come with fiji or the loci-tools.jar at this point?)

Caused by: loci.common.enumeration.EnumException: Unable to find TiffCompresssion with code: 34712

I've included a more complete log in the linked zip file.
https://documents.epfl.ch/groups/p/pt/ptbiop-unit/www/svi_trouble_BIOP.zip
Odd thing is that Image01 works fine but Image07 seems to cause problems. They were taken the same way from a batch of slides, so maybe having a working image and a non-working one should help find the bug.

Let me know if you'd need more information!

Best,

Oli

[mlinkert]

Hi Oli,

Thanks again for the support your team has provided. I'd like to submit a troublesome dataset that yields the following error log using the latest trunk build of LOCI formats (Should we use the new SNAPSHOT versions that come with fiji or the loci-tools.jar at this point?)

It is best not to use loci_tools.jar in Fiji, assuming your installation is fully up to date - using loci_tools.jar will now severely confuse Fiji. With the upcoming 4.4.4 version of Bio-Formats, "Plugins > LOCI > Update LOCI Plugins" will be fixed to update the files that are in Fiji already instead of downloading a new loci_tools.jar, so you should be able to use that if you want to test the trunk builds.

I've included a more complete log in the linked zip file.
https://documents.epfl.ch/groups/p/pt/p ... e_BIOP.zip
Odd thing is that Image01 works fine but Image07 seems to cause problems. They were taken the same way from a batch of slides, so maybe having a working image and a non-working one should help find the bug.

Thank you for this. I haven't the faintest idea why this difference would occur, but I have filed a ticket to fix it here:

http://trac.openmicroscopy.org.uk/ome/ticket/9618

As in the past, you have been CC'd.

Regards,
-Melissa

[Oli]

Dear Melissa,

Thank you for the information and the CC on the ticket.

I've found this bug now when opening .vsi files since this morning

Caused by: java.lang.NoSuchMethodError: loci.formats.in.CellSensReader.hasFlattenedResolutions()Z
at loci.formats.in.CellSensReader.initFile(CellSensReader.java:397)
at loci.formats.FormatReader.setId(FormatReader.java:1105)
at loci.formats.ImageReader.setId(ImageReader.java:695)
at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:505)
at loci.formats.DimensionSwapper.setId(DimensionSwapper.java:292)
at loci.formats.FileStitcher$ExternalSeries.<init>(FileStitcher.java:1164)
at loci.formats.FileStitcher.initFile(FileStitcher.java:814)
at loci.formats.FileStitcher.setId(FileStitcher.java:765)
at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:505)
at loci.formats.ChannelSeparator.setId(ChannelSeparator.java:274)
at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:505)
at loci.plugins.macro.LociFunctions.setId(LociFunctions.java:398)
... 16 more

But now with the SNAPSHOTS I am not sure on how to proceed to go back to a version that did work.

Best

Oli