pearcetm/GeoTIFFTileSource

Performance Issue Loading SVS Files

Opened this issue · 8 comments

ssims-nch commented

We currently use the Zoomify Turbo Command-Line Converter to convert SVS files to Zoomify Image Folders for our production environment. This approach allows us to load images in approximately 2 seconds (2MB transferred). However, we are considering using GeoTIFFTileSource to directly open SVS files and skip the conversion step.

Using GeoTIFFTileSource, the same SVS image takes about 15 seconds to load (100MB transferred), which is significantly slower than the Zoomify Image Folder method.

Do you have any suggestions to improve the load time?

pearcetm commented

A more detailed description of your current setup would probably be helpful. It sounds like you're using an image server - is that correct?

Local SVS files can be loaded without any further setup. However, viewing remote SVS files, like all remote files, relies on fetching the correct tiles for the current viewport by making HTTP range requests. If you're seeing hundreds of megabytes being transferred, my guess would be that the server needs to be configured to allow these range requests.

If you use the inspector tools in your browser you should be able to see what is being requested and returned. Also, are you able to paste link to an image on your server into the demo page, and is that having the same issues?

ssims-nch commented

Thank you for your response.

  1. Current Setup:

    • Our application is an ASP.NET MVC application hosted in IIS.
    • We use OpenSeadragon on the front end to display images.
    • Images are stored in a subdirectory of the app (e.g., /images/image.svs).
    • We don't use an Image Server.

  2. HTTP Range Requests:

    • We have confirmed that the server is correctly supporting HTTP range requests.
    • The server responses include the headers Accept-Ranges: bytes and Content-Range: bytes 1477771264-1484259328/1605933257.

  3. Demo Page:

    • We encountered a CORS policy error when trying to test the SVS file on the demo page (https://pearcetm.github.io).
    • We deployed the demo page as a separate application on the same server where the SVS files are hosted to avoid CORS issues. It performs about the same ~12 sec. load time (100 MB).
pearcetm commented
  • We deployed the demo page as a separate application on the same server where the SVS files are hosted to avoid CORS issues. It performs about the same ~12 sec. load time (100 MB).

If range requests are working correctly it is strange that you'd be seeing this much data transfer before rendering. Are you able to share a link to your demo page?

ssims-nch commented

Just to be clear, I assume you'd need access to the problematic SVS file too (it would need to be exposed as well)?

pearcetm commented

Just to be clear, I assume you'd need access to the problematic SVS file too (it would need to be exposed as well)?

Well, a URL pointing to an SVS file on your server would be helpful to try to reproduce the behavior. You could grab a file from https://openslide.cs.cmu.edu/download/openslide-testdata/Aperio/ to host on your server if you can't share a link to your actual file. Of course, if the demo file works and yours doesn't that opens up a whole new set of questions/issues...

pearcetm commented

@ssims-nch Any updates on this?

ssims-nch commented

I apologize for the lack of response. All of those demo files at https://openslide.cs.cmu.edu/download/openslide-testdata/Aperio/ were very fast with minimal data being transferred in our application. I'm working with our team to expose the problematic file in a way that's inline with our privacy policies.

pearcetm commented

Interesting that different SVS files would cause such different behavior. Perhaps the tiff info printed by the demo app could provide some insight. You might also look into which scanner models were used to create the files.