Bayer-Group
Adding image on Windows network share fails: "java.lang.IllegalArgumentException: URI has an authority component"
Hello Paquo team,
First, thank you very much for your work on this piece of software!
When I use add_image with a new project, and the image is located on a Windows share, I am getting java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: URI has an authority component. This is the case when the file name is of any of the following forms:
-
//example/path/to subdirectory/image.png -
M:/path/to subdirectory/image.png(i.e., using a network drive mapping instead) -
file:/M:/path/to subdirectory/image.png
(If I use file:///example/path/to subdirectory/image.png), I get a different error, FileNotFoundError: image_provider can't provide URI for requested image_id.
To confirm, is this expected? Should I be using a different approach to adding images on a network share?
I am using Paquo v0.4.0 with QuPath v0.2.3, Python v3.8.12, and Windows 10.
with QuPathProject('//example/path/to project directory', mode="a") as project: # This works.
tile = project.add_image(
'//example/path/to subdirectory/image.png', # This raises the above error.
image_type=QuPathImageType.BRIGHTFIELD_H_E,
)
The full traceback:
Exception Traceback (most recent call last)
~\Miniconda3\envs\example\lib\site-packages\_jpype.cp38-win_amd64.pyd in qupath.lib.images.servers.ImageServerProvider.getPreferredUriImageSupport()
~\Miniconda3\envs\example\lib\site-packages\_jpype.cp38-win_amd64.pyd in qupath.lib.images.servers.ImageServerProvider.getServerBuilders()
~\Miniconda3\envs\example\lib\site-packages\_jpype.cp38-win_amd64.pyd in java.io.File.<init>()
Exception: Java Exception
The above exception was the direct cause of the following exception:
java.lang.IllegalArgumentException Traceback (most recent call last)
l:\home\path\to\qupath.py in <module>
----> 175 tile = project.add_image(
176 '//example/path/to subdirectory/image.png',
177 # image_type=QuPathImageType.BRIGHTFIELD_H_E,
178 )
179
~\Miniconda3\envs\example\lib\contextlib.py in inner(*args, **kwds)
73 def inner(*args, **kwds):
74 with self._recreate_cm():
---> 75 return func(*args, **kwds)
76 return inner
77
~\Miniconda3\envs\example\lib\site-packages\paquo\projects.py in add_image(self, image_id, image_type, allow_duplicates)
302 # first get a server builder
303 try:
--> 304 support = ImageServerProvider.getPreferredUriImageSupport(
305 BufferedImage,
306 String(str(img_uri))
java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: URI has an authority component
I would be grateful for any advice. Thank you again!
Hi @jglev
This seems to be an issue with the specific way a java URI expects a windows share to be encoded. I will try to create a test case for this on windows, and I will change the current implementation in paquo so that we don't expose the java Exception to the python world.
In the meantime, can you try providing your network path as one the following:
# doesn't work according to your report
//example/path/subdirectory/image.png
M:/path/subdirectory/image.png
file:/M:/path/subdirectory/image.png
# please try
file:////example/path/subdirectory/image.png
file://example/path/subdirectory/image.png
Cheers, Andreas 😃
I think that there are specific requirements for paths in windows.
See...
https://en.wikipedia.org/wiki/File_URI_scheme#Windows
So a proper URI for windows would be file:///M:/path/subdirectory/image.png
Notice 3 slashes.
Here is a simple example:
import jpype
import jpype.imports
jpype.startJVM()
import java
print(java.io.File(java.net.URI("file:C:/Windows")).exists()) # fails on URI is not hierarchical
print(java.io.File(java.net.URI("file:/C:/Windows")).exists()) # prints true
print(java.io.File(java.net.URI("file://C:/Windows")).exists()) # fails on URI has an authority component
print(java.io.File(java.net.URI("file:///C:/Windows")).exists()) # prints true
print(java.io.File(java.net.URI("file:////C:/Windows")).exists()) # prints true
Now here is where things get squirrely. What happens if you need to get a network drive through Java. There is a bug in java with regard to java.io.File which doesn't show up when you use java.nio.file.Paths. First notice that when you use $ rather than a :
print(java.nio.file.Paths.get(java.net.URI("file://localhost/c:/Windows")).toFile().exists()) # Fails Illegal character in path
print(java.nio.file.Paths.get(java.net.URI("file://localhost/c$/Windows")).toFile().exists()) # works
print(java.io.File(java.net.URI("file://localhost/c$/Windows")).exists()) # fails URI has an authority component (bug as this is completely valid path)
The problem is that Java fails to properly escape the drive letter when passing through a windows path. The newer nio has fixed the issue. Unfortunately this is an issue in the library not the python wrapper.
Not sure how much use this will be as this is way more complicated than I would have thought.
Thanks for helping out @Thrameos
Not sure how much use this will be as this is way more complicated than I would have thought.
It's super helpful! The URI handling already caused me quite some headaches because Python's pathlib.Path.as_uri() produces URIs that are incompatible with Java's in some edge-cases, see:
https://github.com/bayer-science-for-a-better-life/paquo/blob/a692c3cd5d91191c36811b318ead5cddca770765/paquo/images.py#L45-L64
https://github.com/bayer-science-for-a-better-life/paquo/blob/a692c3cd5d91191c36811b318ead5cddca770765/paquo/images.py#L89-L140
There's already a few tests in paquo, and I guess I'll just have to add more until all edge cases are handled, or just have better documentation with clear recommendations.
The newer nio has fixed the issue. Unfortunately this is an issue in the library not the python wrapper.
In that case, @jglev a super quick thing you could just try is to install QuPath v0.3.0 and configure paquo to use the newer QuPath which might include that fix and ships with a newer jvm.
Cheers, Andreas :smiley:
Thank you both, @ap-- and @Thrameos!
# please try file:////example/path/subdirectory/image.png file://example/path/subdirectory/image.png
To confirm, neither works (as above, using QuPath 0.2.3) -- both result in a FileNotFoundError: image_provider can't provide URI for requested image_id: message.
So a proper URI for windows would be
file:///M:/path/subdirectory/image.png
This also fails for me, alas, with a java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: URI has an authority component error.
My filename does have odd characters, though I'm not sure whether that's of use to know: 123456789 [x=135680,y=40960,w=640,h=640].png. I've tried it both in that format and as 123456789%20%5Bx=135680,y=40960,w=640,h=640%5D.png with all of the combinations above.
In that case, @jglev a super quick thing you could just try is to install QuPath v0.3.0 and configure paquo to use the newer QuPath which might include that fix and ships with a newer jvm.
I'll keep trying this! My initial try with QuPath 0.3.0 results in the following error when running from paquo.projects import QuPathProject:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000000, pid=12236, tid=26488
#
# JRE version: (16.0.2+7) (build )
# Java VM: OpenJDK 64-Bit Server VM (16.0.2+7, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# C 0x0000000000000000
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
(But I imagine that that's a separate issue.)
As I keep trying, I'd like to note how excited I am for your work on this project. QuPath is great software, and having a consistent Python wrapper opens so many doors for using it. Thank you again!
Unforrunately upgrading the vm isn't likely to address this. The jar is using an older API that has a bug based on the stacktrace. Unfortunately that bug remains. The newer API has the bug fixed, but someone would need to patch and release a new Jar file.
You can use JPype to test some of the patterns to see if the filename works though I suspect the given the soecial characters they may need some html style escape codes. Once you find a working pattern locate the offending call from the stacktrace and see if you can alter the java source to fix assuming it is not proprietary
@jglev
Just fyi the EXCEPTION_ACCESS_VIOLATION error you experienced is fixed in the newest version of paquo
Just ran into this issue myself.
Is there any update on whether we can load images with add_image() for images on a Windows mapped network drive? I can add_image() for local images, but for mapped network images I get the following error
---------------------------------------------------------------------------
FileNotFoundError Traceback (most recent call last)
Input In [35], in <cell line: 6>()
3 qupath_project = list(qupath_dir.glob("*.qpproj"))[0]
5 qp = QuPathProject(qupath_project, mode='a') # open project for appending
----> 6 qp.add_image(fn.as_uri())
File ~\Miniconda3\envs\RNAscope_analysis_v1\lib\contextlib.py:79, in ContextDecorator.__call__.<locals>.inner(*args, **kwds)
76 @wraps(func)
77 def inner(*args, **kwds):
78 with self._recreate_cm():
---> 79 return func(*args, **kwds)
File ~\Miniconda3\envs\RNAscope_analysis_v1\lib\site-packages\paquo\projects.py:302, in QuPathProject.add_image(self, image_id, image_type, allow_duplicates)
300 img_uri = self._image_provider.uri(image_id)
301 if img_uri is None:
--> 302 raise FileNotFoundError(f"image_provider can't provide URI for requested image_id: '{image_id}'")
303 img_id = self._image_provider.id(img_uri)
304 if not img_id == image_id: # pragma: no cover
FileNotFoundError: image_provider can't provide URI for requested image_id: 'file:///K:/data/projects/image%image.vsi'
Hi everyone, QuPath developer here, I think I might need to learn a lot more about URIs to understand this...
Anyhow, since my Windows laptop is old and unpleasant to use, I tried to replicate the core issue on my Mac - figuring that if the URI is valid it might not care about the operating system. Turns out that it does care, so that the following groovy script fails with URI has an authority component:
def uri = new URI("file://localhost/c\$/Windows")
def path = java.nio.file.Paths.get(uri)
println path
Therefore Paths seems to be doing something platform-specific. I dug around the OpenJDK code and found that the exception is thrown here.
So I then went hunting for what likely happens on Windows, and saw that a non-null raw authority could throw an exception in the Windows-specific code here. However presumably that code isn't what is being run in @Thrameos's examples at https://github.com/bayer-science-for-a-better-life/paquo/issues/65#issuecomment-970711915, but rather the more involved logic here.
The reason I explored is that QuPath uses new File(uri) in various places, and so I was reluctant to fix it in just one. The fact that the JDK contains seemingly different logic for assessing URI validity depending upon exactly how the code is run (not just the OS, but also precisely which methods are used on the OS) makes me worry a bit that any workaround that depends upon this will be pretty brittle.... particularly as we QuPath devs forget about this and introduce new File(uri) problems in the future.
Which led me to Wikipedia, and specifically this: https://en.wikipedia.org/wiki/File_URI_scheme#How_many_slashes?
Is use of the (also non-standard) '4-slash form'preferred by Java a potential workaround?
The more involved code I liked to above suggests that Java is internally 'fixing' the URI in this kind of way, adding extra slashes on Windows - but only if you get lucky by calling the right code path.
If this doesn't solve things then I can try to replace all instances of new File(uri) within QuPath and report back. But since I don't encounter the issue myself, I'll need someone else to tell me if it's solved.
Extra info - switched to the Windows laptop and can confirm that the following Groovy script fails in QuPath when using new File(uri):
def uri = new URI("file://localhost/c\$/Windows")
def path = java.nio.file.Paths.get(uri)
println("Path.get(uri): $path")
println("Path.toFile(): ${path.toFile()}")
println("Path.toFile().exists(): ${path.toFile().exists()}")
def file = new File(uri)
println("new File(uri): $file")
println("File.exists(): ${file.exists()}")
Output:
INFO: Path.get(uri): \\localhost\c$\Windows
INFO: Path.toFile(): \\localhost\c$\Windows
INFO: Path.toFile().exists(): true
ERROR: URI has an authority component in QuPathScript at line number 6
However if I add // I don't get any exceptions
def uri = new URI("file:////localhost/c\$/Windows")
def path = java.nio.file.Paths.get(uri)
println("Path.get(uri): $path")
println("Path.toFile(): ${path.toFile()}")
println("Path.toFile().exists(): ${path.toFile().exists()}")
def file = new File(uri)
println("new File(uri): $file")
println("File.exists(): ${file.exists()}")
Output:
INFO: Path.get(uri): \\localhost\c$\Windows
INFO: Path.toFile(): \\localhost\c$\Windows
INFO: Path.toFile().exists(): true
INFO: new File(uri): \\localhost\c$\Windows
INFO: File.exists(): true
Furthermore,, file.equals(path.toFile()) returns true - indicating that the files are the same (as the printing suggests).
Is it possible to use this info to resolve the issue, are are changes still required on the QuPath side?
Thank you so much for going down that rabbit hole @petebankhead :heart:
It looks like I should be able to fix this on the Python side then! I'll make a draft PR, and @mezwick I would ping you to test if it works.
Cheers, Andreas :smiley:
Hi @mezwick,
could you try installing paquo from the fix-windows-network-share branch and try adding your image via:
project.add_image("file:////localhost/K$/data/projects/image%image.vsi")
and via:
project.add_image("file:///K:/data/projects/image%image.vsi")
and report back.
Thank you!
Thanks for the efforts! I have installed the new branch and run some tests
For a local image (on C)
- I can
project.add_image()when passing apathlib.Pathto the local image - I cannot
project.add_image()when passing apathlib.Path.as_urito the local image which when printed looks likefile:///C:/data/projects/image%image.vsiI get the error
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
Cell In [78], line 1
----> 1 qp.add_image(local_image.as_uri(), allow_duplicates=True)
File ~\Miniconda3\envs\paquo_test\lib\contextlib.py:79, in ContextDecorator.__call__.<locals>.inner(*args, **kwds)
76 @wraps(func)
77 def inner(*args, **kwds):
78 with self._recreate_cm():
---> 79 return func(*args, **kwds)
File ~\Miniconda3\envs\paquo_test\lib\site-packages\paquo\projects.py:306, in QuPathProject.add_image(self, image_id, image_type, allow_duplicates)
304 if not img_id == image_id: # pragma: no cover
305 _log.warning(f"image_provider roundtrip error: '{image_id}' -> uri -> '{img_id}'")
--> 306 raise RuntimeError("the image provider failed to roundtrip the image id correctly")
308 if not allow_duplicates:
309 for entry in self.images:
RuntimeError: the image provider failed to roundtrip the image id correctly
- I cannot
project.add_image()when passing a modified uri path to the local image that looks likefile:////localhost/C$/data/projects/image%image.vsi, getting the following error
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
Cell In [92], line 1
----> 1 qp.add_image(local_image_uri_mod, allow_duplicates=True)
File ~\Miniconda3\envs\paquo_test\lib\contextlib.py:79, in ContextDecorator.__call__.<locals>.inner(*args, **kwds)
76 @wraps(func)
77 def inner(*args, **kwds):
78 with self._recreate_cm():
---> 79 return func(*args, **kwds)
File ~\Miniconda3\envs\paquo_test\lib\site-packages\paquo\projects.py:306, in QuPathProject.add_image(self, image_id, image_type, allow_duplicates)
304 if not img_id == image_id: # pragma: no cover
305 _log.warning(f"image_provider roundtrip error: '{image_id}' -> uri -> '{img_id}'")
--> 306 raise RuntimeError("the image provider failed to roundtrip the image id correctly")
308 if not allow_duplicates:
309 for entry in self.images:
RuntimeError: the image provider failed to roundtrip the image id correctly
For a network image
4. I cannot project.add_image() when passing a pathlib.Path to the network image. I get the following error
---------------------------------------------------------------------------
Exception Traceback (most recent call last)
File ImageServerProvider.java:224, in qupath.lib.images.servers.ImageServerProvider.getPreferredUriImageSupport()
Exception: Java Exception
The above exception was the direct cause of the following exception:
java.lang.IllegalArgumentException Traceback (most recent call last)
Cell In [75], line 1
----> 1 qp.add_image(network_image, allow_duplicates=True)
File ~\Miniconda3\envs\paquo_test\lib\contextlib.py:79, in ContextDecorator.__call__.<locals>.inner(*args, **kwds)
76 @wraps(func)
77 def inner(*args, **kwds):
78 with self._recreate_cm():
---> 79 return func(*args, **kwds)
File ~\Miniconda3\envs\paquo_test\lib\site-packages\paquo\projects.py:316, in QuPathProject.add_image(self, image_id, image_type, allow_duplicates)
314 # first get a server builder
315 try:
--> 316 support = ImageServerProvider.getPreferredUriImageSupport(
317 BufferedImage,
318 String(img_uri),
319 )
320 except IOException: # pragma: no cover
321 # it's possible that an image_provider returns an URI but that URI
322 # is not actually reachable. In that case catch the java IOException
323 # and raise a FileNotFoundError here
324 raise FileNotFoundError(image_id)
java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: URI has an authority component
- I cannot
project.add_image()when passing apathlib.Path.as_urito the network image which when printed looks likefile:///K:/data/projects/image%image.vsi. I get the error
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
Cell In [79], line 1
----> 1 qp.add_image(network_image_uri, allow_duplicates=True)
File ~\Miniconda3\envs\paquo_test\lib\contextlib.py:79, in ContextDecorator.__call__.<locals>.inner(*args, **kwds)
76 @wraps(func)
77 def inner(*args, **kwds):
78 with self._recreate_cm():
---> 79 return func(*args, **kwds)
File ~\Miniconda3\envs\paquo_test\lib\site-packages\paquo\projects.py:306, in QuPathProject.add_image(self, image_id, image_type, allow_duplicates)
304 if not img_id == image_id: # pragma: no cover
305 _log.warning(f"image_provider roundtrip error: '{image_id}' -> uri -> '{img_id}'")
--> 306 raise RuntimeError("the image provider failed to roundtrip the image id correctly")
308 if not allow_duplicates:
309 for entry in self.images:
RuntimeError: the image provider failed to roundtrip the image id correctly
- I cannot
project.add_image()when passing a modified uri path to the network image that looks likefile:////localhost/K$/data/projects/image%image.vsi, getting the following error
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
Cell In [96], line 1
----> 1 qp.add_image(network_image_uri_mod, allow_duplicates=True)
File ~\Miniconda3\envs\paquo_test\lib\contextlib.py:79, in ContextDecorator.__call__.<locals>.inner(*args, **kwds)
76 @wraps(func)
77 def inner(*args, **kwds):
78 with self._recreate_cm():
---> 79 return func(*args, **kwds)
File ~\Miniconda3\envs\paquo_test\lib\site-packages\paquo\projects.py:306, in QuPathProject.add_image(self, image_id, image_type, allow_duplicates)
304 if not img_id == image_id: # pragma: no cover
305 _log.warning(f"image_provider roundtrip error: '{image_id}' -> uri -> '{img_id}'")
--> 306 raise RuntimeError("the image provider failed to roundtrip the image id correctly")
308 if not allow_duplicates:
309 for entry in self.images:
RuntimeError: the image provider failed to roundtrip the image id correctly
Hope that helps! Let me know if i can do more.
Thank you so much for testing!
Okay so most of these errors seem to be on the paquo side. I'll update the tests and will ping you once I refactored the code causing the issues you reported.
Thanks @ap-- FYI, in case you missed it on image.sc forum, i can confirm that QuPath is fine loading images from a windows network mount via the GUI. So as you say, seems to be something on the Paquo side
Hey @mezwick, can you run your test again on the newest version of the https://github.com/bayer-science-for-a-better-life/paquo/tree/fix-windows-network-share branch?
Tests pass now. If you can confirm that it works for you I will prepare a new release.
@petebankhead I would certainly recommend removing new File(x) when dealing with URI. Java tends to fix stuff with new libraries and leaving the old path broken which then forces the developer to switch to nio library which forces code rewriting etc,. I understand the don't break backwards compatibility but this one was a blatant bug in Java. For all of my proprietary code that I work with I had to make that switch for largely the same reasons. (Broken io API which will never get fixed.)
As for how to prevent the code from reappearing that is tough. Most IDEs don't have a disable class X from usage button meaning one has to remember to use the alternative.
Installed the updated version of https://github.com/bayer-science-for-a-better-life/paquo/tree/fix-windows-network-share and can confirm that I can now add images for pathlib.Path files by converting them with pathlib.Path.as_uri() for both local and network images.
This works whether i pass as image_path.as_uri() or as the string str(image_path.as_uri()) in case others want to get their uri string some other way. (that is... file:///K:/data/projects/image%image.vsi)
For completeness (and not that you need it) passing the 'modded' 4 slash URI format (that is... file:////localhost/K$/data/projects/image%image.vsi) does not work.
So, seems to be all fixed! Fantastic. Thanks @ap--
@Thrameos fair enough, I've now submitted a PR that changes all instances of new File(uri) I could find in QuPath: https://github.com/qupath/qupath/pull/1134
Java's behavior seems at least consistent with the javadoc for new File(uri) and Path.of(uri) (i.e. the former specifies the authority is undefined, while the latter says behavior is platform-specific), so I guess it's working as intended in some sense. Although I agree it's not exactly ideal.
While fixing this, I saw that new File(uri) is used in a lot of places - including within the JDK its, and in core dependencies like Guava. So I think having the 'fix' in paquo to more Java-friendly representations is helpful anyway, to avoid this resurfacing somewhere else. But hopefully changes on both sides reduce the likelihood that this will cause anyone else a problem in the future.
QuPath does retain a slightly unhappy mix of File and nio, although this probably can't go away any time soon. For one thing, Groovy scripting is much easier with File (which is a default import with numerous enhancements). But we could be more consistent in using Path internally, where scripters are unlikely to visit.
For completeness (and not that you need it) passing the 'modded' 4 slash URI format (that is...
file:////localhost/K$/data/projects/image%image.vsi) does not work.
@mezwick could you provide the error with the traceback? I'm testing '4-slash'-URIs and don't see an error. My guess is the URI you're providing requires some urlencoding and that code path might still have problems.
General error warning
I should say for all approaches, i get a roundtrip error warning (even when the images are loading into the qp project). For local_image.as_uri() for instance
image_provider roundtrip error: 'file:///C:/Users/username/Desktop/scratch/data/image.vsi' -> uri -> 'C:\Users\username\Desktop\scratch\data\image.vsi'
URI approaches
LOCAL IMAGE (C drive)
local_image.as_uri() works
file:///C:/Users/username/Desktop/scratch/data/image.vsi
local_image with 4 slash works
file:////localhost/C$/Users/username/Desktop/scratch/data/image.vsi
NETWORK IMAGE (K mapped network drive)
network_image.as_uri() works
file:///K:/my_data/projects/project/data/raw_data/set1/image.vsi
network_image with 4 slash does not work
file:////localhost/K$/my_data/projects/project/data/raw_data/set1/image.vsi
the error is...
---------------------------------------------------------------------------
Exception Traceback (most recent call last)
File ImageServerProvider.java:224, in qupath.lib.images.servers.ImageServerProvider.getPreferredUriImageSupport()
Exception: Java Exception
The above exception was the direct cause of the following exception:
java.io.IOException Traceback (most recent call last)
File ~\Miniconda3\envs\paquo_test\lib\site-packages\paquo\projects.py:315, in QuPathProject.add_image(self, image_id, image_type, allow_duplicates)
314 try:
--> 315 support = ImageServerProvider.getPreferredUriImageSupport(
316 BufferedImage,
317 String(img_uri),
318 )
319 except IOException: # pragma: no cover
320 # it's possible that an image_provider returns an URI but that URI
321 # is not actually reachable. In that case catch the java IOException
322 # and raise a FileNotFoundError here
java.io.IOException: java.io.IOException: file:////localhost/K$/my_data/projects/project/data/raw_data/set1/image.vsi
does not exist!
During handling of the above exception, another exception occurred:
FileNotFoundError Traceback (most recent call last)
Cell In [17], line 1
----> 1 qp.add_image(network_image_uri_mod, allow_duplicates=True)
File ~\Miniconda3\envs\paquo_test\lib\contextlib.py:79, in ContextDecorator.__call__.<locals>.inner(*args, **kwds)
76 @wraps(func)
77 def inner(*args, **kwds):
78 with self._recreate_cm():
---> 79 return func(*args, **kwds)
File ~\Miniconda3\envs\paquo_test\lib\site-packages\paquo\projects.py:323, in QuPathProject.add_image(self, image_id, image_type, allow_duplicates)
315 support = ImageServerProvider.getPreferredUriImageSupport(
316 BufferedImage,
317 String(img_uri),
318 )
319 except IOException: # pragma: no cover
320 # it's possible that an image_provider returns an URI but that URI
321 # is not actually reachable. In that case catch the java IOException
322 # and raise a FileNotFoundError here
--> 323 raise FileNotFoundError(img_uri)
324 except ExceptionInInitializerError:
325 raise OSError("no preferred support found")
FileNotFoundError: file:////localhost/K$/my_data/projects/project/data/raw_data/set1/image.vsi
Can you try using the server and path you used to map K?
so file:////server_used_for_K/share_path/path/to/image.vsi
Maybe a mapped network drive X is just not accessible via //localhost/X$/
Or even simpler: please just open an explorer window and type \\localhost\K$\ in the address bar. If this doesn't access your network drive it means that K is just not reachable via localhost on windows.
Or even simpler: please just open an explorer window and type
\\localhost\K$\in the address bar. If this doesn't access your network drive it means thatKis just not reachable via localhost on windows.
cannot access network drive in windows explorer with \\localhost\K$ (does work for \\localhost\C$)
i will just stick to path.as_uri() format :)