Cannot open SVS file

[suminwei]

Operating system

Linux

Platform

64-bit x86

OpenSlide Python version

1.1.2

OpenSlide version

3.4.1

Slide format

SVS

Issue details

Hi I'm running into the following error when trying to use Openslide to open svs files:

python $DAB_quant --folder=$FILES --ext=.svs --include_full processing /path/to/FILE.svs TIFFReadDirectory: Warning, Unknown field with tag 347 (0x15b) encountered. /path/to/FILEccc.svs: JPEG compression support is not configured. Traceback (most recent call last): File "quantify.py", line 280, in slide = openslide.OpenSlide(filename) File "/path/to/anaconda3/envs/py38dabquant/lib/python3.8/site-packages/openslide/init.py", line 160, in init self._osr = lowlevel.open(filename) File "/path/to/anaconda3/envs/py38dabquant/lib/python3.8/site-packages/openslide/lowlevel.py", line 133, in _check_open raise OpenSlideError(err) openslide.lowlevel.OpenSlideError: Unsupported TIFF compression: 7

[bgilbert]

Are you using libtiff installed from Anaconda? It looks like your copy of libtiff was compiled without JPEG support.

[suminwei]

Sorry - how may I check this? I'm not sure which libtiff is being used by the Python script (which is part of an open source software).

[bgilbert]

If you start the same Python interpreter you're using to run the script, you can do something like:

import os, openslide
print(os.getpid())

With Python still running, run grep tiff /proc/<process ID>/maps in a shell (substituting the process ID you found) to find the path to the copy of libtiff you're using. Post that here. In addition, you can run ldd /the/path/to/libtiff.so | grep jpeg to see if it's linked with libjpeg.

[suminwei]

Hi @bgilbert - thank you! I'm running on a cluster, so I suspended Python with Ctrl+z after running the commands you suggested, and then ran grep tiff /proc/2410/maps; not sure if this is entirely appropriate. The following is the output (why does there seem to be multiple paths?):

7fbddd0d2000-7fbddd12a000 r-xp 00000000 00:27 10402823390485434616 /n/app/tiff/4.0.7/lib/libtiff.so.5.2.5 7fbddd12a000-7fbddd329000 ---p 00058000 00:27 10402823390485434616 /n/app/tiff/4.0.7/lib/libtiff.so.5.2.5 7fbddd329000-7fbddd32c000 r--p 00057000 00:27 10402823390485434616 /n/app/tiff/4.0.7/lib/libtiff.so.5.2.5 7fbddd32c000-7fbddd32d000 rw-p 0005a000 00:27 10402823390485434616 /n/app/tiff/4.0.7/lib/libtiff.so.5.2.5 7fbde0659000-7fbde06f2000 r-xp 00000000 00:30 83403284314 /path/to/anaconda3/envs/py38dabquant/lib/python3.8/site-packages/Pillow.libs/libtiff-d147fec3.so.5.6.0 7fbde06f2000-7fbde08f1000 ---p 00099000 00:30 83403284314 /path/to/anaconda3/envs/py38dabquant/lib/python3.8/site-packages/Pillow.libs/libtiff-d147fec3.so.5.6.0 7fbde08f1000-7fbde08f6000 rw-p 00098000 00:30 83403284314 /path/to/anaconda3/envs/py38dabquant/lib/python3.8/site-packages/Pillow.libs/libtiff-d147fec3.so.5.6.0 7fbde08f6000-7fbde0901000 rw-p 0009e000 00:30 83403284314 /path/to/anaconda3/envs/py38dabquant/lib/python3.8/site-packages/Pillow.libs/libtiff-d147fec3.so.5.6.0

[suminwei]

I also checked if either of the two paths above were linked with jpeg. When I run ldd /the/path/to/libtiff.so | grep jpeg, there was no output. When I run ldd /path/to/anaconda3/envs/py38dabquant/lib/python3.8/site-packages/Pillow.libs/libtiff-d147fec3.so.5.6.0 | grep jpeg, the output was libjpeg-ba7bf5af.so.9.4.0 => not found.

[bgilbert]

Okay, your process has two copies of libtiff loaded. The second one appears to be a private copy for Pillow and shouldn't be relevant here. That one does use libjpeg, though. The not found isn't important; it's because ldd isn't using the same directory search path that Pillow does when it loads the library.

When I run ldd /the/path/to/libtiff.so | grep jpeg, there was no output.

To be clear, this was ldd /n/app/tiff/4.0.7/lib/libtiff.so.5.2.5? If so, then indeed there's no JPEG support in that libtiff. What is /n/app? How did you install that copy of libtiff?

[suminwei]

Hi @bgilbert, thank you for the explanation!

Yes sorry, I meant to write ldd /n/app/tiff/4.0.7/lib/libtiff.so.5.2.5 | grep jpeg. I think /n/app is a directory that contains all the modules that are available to be loaded in when working on the cluster, these were installed by someone else presumably? Before I ran the Python script, I loaded in a few modules:

module purge
module load gcc/6.2.0 openslide/3.4.1

I guess libtiffwas loaded as part of this?

[bgilbert]

Yes, libtiff and libjpeg (or libjpeg-turbo) are both mandatory dependencies of OpenSlide, so both would have been installed. libjpeg (or libjpeg-turbo) is an optional dependency of libtiff, but OpenSlide requires it to be enabled there. If libtiff was built locally by someone at your site, the fix is to rebuild it, making sure it detects and uses libjpeg or libjpeg-turbo. If libtiff was installed from a package maintained by a third party, I'd advise following up with that package's maintainer.

Since this isn't an OpenSlide issue, I'll close. Good luck!