search

DigitalSlideArchive / digital_slide_archive

The official deployment of the Digital Slide Archive and HistomicsTK.
https://digitalslidearchive.github.io
Apache License 2.0
110 stars 50 forks source link

How to resolve: The original tile source for the item is not working #219

Closed ghadjigeorghiou closed 2 years ago

ghadjigeorghiou commented 2 years ago

Hi,

We have been using a previous version of DSA for close to 2 years now and lately, some images started to throw errors when I was trying to view them. I had a look at the logs and for every image that was failing I found the same error message "The original tile source for the item is not working". At first, I thought that this might be an issue with the permissions on the storage server that's connected to DSA, but it seems like the permissions are fine. I am not sure, how to fix this issue since I don't know what the source of the problem is. Could anyone guide me on how to fix this? Thank you!

manthey commented 2 years ago

If it is only a few files, you can go to the item page via the Girder interface (where you navigate folders), and click the "Remove Large Image" icon ( image ), and then click the "Use this file for a large image" icon. This resets the internal choice of tile source.

If there are a lot of files where this has happened, it might be worth figuring out what occurred. For this, it would be useful to look at the database record for one such item. This can be done from the mongo database (or maybe from the Web API GET item/{id}/tiles/internal_metadata -- but I don't know if that will work if the item won't open because of the tile source). Specifically, we'd have to look at the item in mongo -- from the mongo shell this will be something like db.item.findOne({_id: Objectid(<item id>)}.

ghadjigeorghiou commented 2 years ago

Hi @manthey, thank you for getting back to me. Based on your comment, tile source refers to the internal tool that DSA is using to read these images. Is that correct? This has happened in hundreds of images, so I will follow your second suggestion and let you know how it goes. Thank you!

manthey commented 2 years ago

Yes. Under the hood, the DSA uses large_image to read a wide variety of images. Each reader is a "tile source", and DSA stores which one was used to open the image. The first time an image is opened, it tries the readers in an order based on some simple file characteristics until it finds one that opens the file. Subsequent times, it uses the same reader as was first used.

ghadjigeorghiou commented 2 years ago

That makes sense. Thanks!

ghadjigeorghiou commented 2 years ago

Hi @manthey, just wanted to update you on how I solved this.

tl;dr: The issue didn't have to do with the tile source, but rather the permissions on the storage location.

I followed your suggestion above and used the item/{id}/tiles/internal_metadata endpoint to check the tile source of a file that was failing. The message that I got was that Openslide was not able to read the image, which was true, but a bit misleading as to why it was failing. I logged into the database and had a look at the path for that file, and then checked its permissions on the storage location. I experimented with the permissions and in the end, I was able to fix it, by giving permissions to the correct user. From my understanding, DSA runs (and has the same permissions) as the user who deployed the docker containers. In our case, after importing a couple of collections in DSA we changed their permissions and the DSA user got locked out. By giving access to that user, everything started working fine. Thank you for your help!

manthey commented 2 years ago

I'm glad you figured it out. Clearly we need a better error message... I'll create an issue to track that: https://github.com/girder/large_image/issues/873