Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Deborah Schmidt
    @frauzufall
    image.png
    since the IOPlugin can't implement both HandlerPlugin types, we have to decide for one main one? Does this have more implications? The only difference I see is that boolean supports(final String descriptor) is then an Override method and boolean supports(final Location descriptor) would not be one
    Jan Eglinger
    @imagejan
    Can't we make a FileLocation for each String in IOService.open, and then only ask for HandlerPlugin<Location> at runtime?
    Deborah Schmidt
    @frauzufall
    yes, that sounds better
    Jan Eglinger
    @imagejan
    And probably fall back to using available HandlerPlugin<String>s for backwards compatibility...
    which would (temporarily) result in the open(String) method supporting more data types than the open(Location) method, until all IOPlugins have adapted to the new API.
    Deborah Schmidt
    @frauzufall
    If I create a FileLocation for String in IOService.open, that works, but it will not make use of the locationService.resolve method to support Strings which are not local file paths. In order to use this, the method would have to be able to throw an exception.. I think it would be great to add this and finally get a way to catch if saving or loading fails. This is all not backwards compatible though.
    Ok, that's not true, the exception could also be catched inside of IOService.open, but can someone remind me again why it is not throwing exceptions in general so far?
    Curtis Rueden
    @ctrueden
    @hinerm Was talking with @frauzufall on Friday about SCIFIO overwrite behavior changes. It would be good to have a short conversation between the three of us to settle once and for all how we want to handle SCIFIO writers when the destination already exists.
    @frauzufall Yes, that's why I didn't update IOPlugin to use the location API. I actually did do that work; it's on the sjc3 branch IIRC.
    But it can't be merged to sjc2 mainline without breaking backwards compatibility.
    We might be able to change it to implement HandlerPlugin<Location> instead, but then also leave the old String-based methods. It should be both source and binary backward compatible! But we'd need to test it.
    Deborah Schmidt
    @frauzufall
    @ctrueden ah cool that this already exists! what does sjc2 mainline mean?
    ah got it :sweat_smile:
    Curtis Rueden
    @ctrueden
    More than six years ago now... 🤯
    Deborah Schmidt
    @frauzufall
    wow
    Deborah Schmidt
    @frauzufall
    I tried to work with this commit, in case someone has time let me know what you think: scijava/scijava-common#395
    Ulrik Günther
    @skalarproduktraum
    hey everyone! we currently have a strange issue with scifio
    [ERROR] Module threw exception
    java.lang.NullPointerException
        at io.scif.services.DefaultInitializeService.initializeReader(DefaultInitializeService.java:87)
        at io.scif.img.ImgOpener.createReader(ImgOpener.java:483)
        at io.scif.img.ImgOpener.openImgs(ImgOpener.java:242)
        at io.scif.services.DefaultDatasetIOService.open(DefaultDatasetIOService.java:152)
        at io.scif.services.DefaultDatasetIOService.open(DefaultDatasetIOService.java:133)
        at io.scif.services.DefaultDatasetIOService.open(DefaultDatasetIOService.java:138)
        at io.scif.convert.FileToDatasetConverter.convert(FileToDatasetConverter.java:66)
        at org.scijava.convert.AbstractConvertService.convert(AbstractConvertService.java:125)
        at org.scijava.convert.AbstractDelegateConverter.convert(AbstractDelegateConverter.java:53)
        at org.scijava.convert.AbstractConvertService.convert(AbstractConvertService.java:125)
        at org.scijava.module.DefaultModuleService.load(DefaultModuleService.java:316)
        at org.scijava.module.DefaultModuleService.loadInput(DefaultModuleService.java:544)
        at org.scijava.module.DefaultModuleService.lambda$loadInputs$1(DefaultModuleService.java:346)
        at java.util.ArrayList.forEach(ArrayList.java:1257)
        at java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1080)
        at org.scijava.module.DefaultModuleService.loadInputs(DefaultModuleService.java:346)
        at org.scijava.module.process.LoadInputsPreprocessor.process(LoadInputsPreprocessor.java:58)
        at org.scijava.module.ModuleRunner.preProcess(ModuleRunner.java:102)
        at org.scijava.module.ModuleRunner.run(ModuleRunner.java:154)
        at org.scijava.module.ModuleRunner.call(ModuleRunner.java:124)
        at org.scijava.module.ModuleRunner.call(ModuleRunner.java:63)
        at org.scijava.thread.DefaultThreadService.lambda$wrap$2(DefaultThreadService.java:225)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
    this is triggered by using sciview's Isosurface command, https://github.com/scenerygraphics/sciview/blob/5a09273513df003b53457f99bb3b2a60d08b72c1/src/main/java/sc/iview/commands/process/Isosurface.java, with quite a large selection of TIFF files -- any ideas what could be the root cause there?
    Jan Eglinger
    @imagejan
    @skalarproduktraum it could be that SCIFIO/SciJava is too eagerly trying to convert a String into a Dataset with the new StringToDatasetConverter in SCIFIO. Can you try whether scifio/scifio#443 fixes your issue?
    (or FileToDatasetConverter actually, just read the stack trace in more detail)
    you might need to combine scifio/scifio#443 with scifio/scifio#444 and build yourself though...
    Deborah Schmidt
    @frauzufall
    @skalarproduktraum temporary workaround is to mark image parameters as persist = false in the command, then the preprocessor will skip them:
        @Parameter(persist = false)
        private IterableInterval<T> image;
    Ulrik Günther
    @skalarproduktraum
    @frauzufall sweet, i will try that right away, thank you!
    Ulrik Günther
    @skalarproduktraum
    okay that seems to work for me, time to let the users test :-D
    Jan Eglinger
    @imagejan
    @ctrueden @hinerm I’m stuck with a strange SCIFIO issue: scifio/scifio#453
    If you find a minute to give me pointers how to solve it, that would be great : )
    Curtis Rueden
    @ctrueden
    @imagejan I'll try to reproduce now.
    Curtis Rueden
    @ctrueden
    @imagejan Update so far: I was able to reproduce by running your Groovy script via --ij2 --headless --run. I was not yet able to reproduce using jgo to run the SCIFIO command line tool, not at the most recent release, nor the latest SCIFIO snapshot version. I think I'll start digging a bit in Eclipse. Once I have an idea what might be wrong, I'll update here again.
    Curtis Rueden
    @ctrueden
    Update 2: Problem happens when running with fiji 2.1.0 tag in Eclipse. This will make using the debugger simpler (no need for remote debugging).
    Curtis Rueden
    @ctrueden
    Update 3: In my local fiji/fiji working copy, I checked out tag fiji-2.1.0. Imported into Eclipse. Launched in debug mode. Loaded the MCVE script into the script editor. Back in Eclipse, navigated to FormatService, getFormat(Location) method. It's an interface, used ctrl+T to bring up implementations, navigated into DefaultFormatService, same method. Saw it delegates to another method, hit F3 to jump there, which led me to this code in scifio 0.41.0 (the version associated with fiji 2.1.0). Put a breakpoint there, ran the script in Fiji, and then back in Eclipse, I see that getFormatList returns null. Hit F8 to continue, then go back to Fiji and run the script again to trigger the breakpoint again. Rinse and repeat while stepping through the code with F5/F6/F7 to learn more about what's going wrong. I know this is a lot of detail, and that @imagejan probably doesn't need it, but I write it here for anyone wondering how we debug this stuff. The Script Editor + IDE combination is very powerful.
    It does help to have some prior knowledge—in this case I know that BioFormatsFormat is supposed to be the format handling STK files, so in the formats for loop, I'm digging in to that one first. Fortunately, it's the first one on the list right now. (If it weren't, you could use a conditional breakpoint to step straight to it by pressing F8.)
    Curtis Rueden
    @ctrueden
    Update 4: After working around some bugs in Eclipse's debugger (*sigh* I may bite the bullet and switch to IntelliJ soon; Eclipse seems to be getting buggier, at least for me), I reach the following surprising exception!
    java.io.FileNotFoundException: .../benchmark_v1_2018_x64y64z1c2s4t11_w1Laser4054BD4BP.stk (Permission denied)
    I think what's going on, at least for me, is that the file is read-only on my file system, but SCIFIO tries to wrap it in a read/write handle. I will see if other problems remain after addressing that.
    Curtis Rueden
    @ctrueden
    Update 5: I fixed the read-only file bug, which was a separate issue, with scijava/scijava-common@c4cb3a7. I then continued debugging, and indeed the NPE continues to happen. The problem is:
    1. SCIFIO's BioFormatsFormat only looks at the file contents if the SCIFIOConfig's checkerIsOpen flag is set to true, but it is false by default; and:
    2. Bio-Formats does not consider the .stk extension sufficient for the MetamorphReader to return true from isThisType; when open is false, it simply returns false.
    Curtis Rueden
    @ctrueden
    OK @imagejan, I'm done analyzing this issue. I responded on the GitHub issue with a workaround for you, along with a question about if we should change anything in SCIFIO.
    Jan Eglinger
    @imagejan
    Thanks a lot, @ctrueden, for the detailed debugging report! Much appreciated!
    Jan Eglinger
    @imagejan
    @ctrueden @hinerm what’s the status of scifio-javacv? As far as I can see, the unit test is failing with “data array too small”, and there’s no deployed maven artefact for it. Are there any plans to resurrect it? It would be awesome to have video codec support in SCIFIO.
    Jan Eglinger
    @imagejan
    I opened a PR enabling Deflate (zlib) support for TIFFFormat.Writer: scifio/scifio#455
    See also this forum topic.
    If you have time to have a look, I’d appreciate if this can be merged and released some time soon, as it will greatly simplify a workflow I’m currently working on : )
    Curtis Rueden
    @ctrueden
    @imagejan Reviewed, merged, and released with scifio 0.42.0. Cheers. :beers:
    Let me know if you also need it uploaded to the Java-8 update site.
    Jan Eglinger
    @imagejan
    @ctrueden thanks a lot! Uploading to the Java-8 site would be great, I can do it myself as well, I think. But I also wouldn’t mind waiting for another concerted pom-scijava update if that is planned.
    Curtis Rueden
    @ctrueden
    There will be another pom-scijava update, but probably not for at least 3-4 weeks. Uploading it in the meantime, as long as you do some light testing first of SCIFIO-related features, would be great.
    Jan Eglinger
    @imagejan
    :+1:
    Jan Eglinger
    @imagejan

    @ctrueden I tried to upload the new scifio-0.42.0.jar after having tested it a bit in Fiji, but I get the following error when uploading (with my account Eglinger):

    [ERROR] org.apache.http.conn.HttpHostConnectException: Connect to sites.imagej.net:443 [sites.imagej.net/144.92.48.186] failed: Connection refused: connect
        at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:156)
        at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)
        at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
        at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
        at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
        at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
        at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
        at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
        at net.imagej.plugins.uploaders.webdav.WebDAVUploader.runMethodOnClient(WebDAVUploader.java:525)
        at net.imagej.plugins.uploaders.webdav.WebDAVUploader.runMethodOnClient(WebDAVUploader.java:514)
        at net.imagej.plugins.uploaders.webdav.WebDAVUploader.lock(WebDAVUploader.java:314)
        at net.imagej.plugins.uploaders.webdav.WebDAVUploader.upload(WebDAVUploader.java:202)
        at net.imagej.updater.FilesUploader.upload(FilesUploader.java:260)
        at net.imagej.ui.swing.updater.UpdaterFrame.upload(UpdaterFrame.java:803)
        at net.imagej.ui.swing.updater.UpdaterFrame$5$1.run(UpdaterFrame.java:309)
    Caused by: java.net.ConnectException: Connection refused: connect
        at java.net.DualStackPlainSocketImpl.connect0(Native Method)
        at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
        at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
        at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
        at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
        at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
        at java.net.Socket.connect(Socket.java:589)
        at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:368)
        at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
        ... 16 more

    Is that expected, i.e. wrong account, wrong password? I would have expected a bit informative error message, so I’m unsure if the issue is on my side now, or on the server side :-)

    Jan Eglinger
    @imagejan
    Update: it seems it’s our institute’s restrictive firewall/proxy. From my home network, uploading worked fine. At our institute we have to use a proxy for http and https. The proxy settings in ImageJ work for subscribing to update sites, but apparently not for (webdav) uploading?!
    Curtis Rueden
    @ctrueden
    @imagejan I was going to upload it from here, but it looks like someone (you?) already uploaded it?
    Jan Eglinger
    @imagejan
    Yes, it worked from outside my institute network, see my last comment. Sorry for the buzz :-/
    Curtis Rueden
    @ctrueden
    No worries. I am not sure how to improve the error message, but it's a little surprising that the HTTP proxy settings weren't effective for uploading. Not the first time people haven't been able to upload from behind firewalls, though.
    Jean-Yves Tinevez
    @tinevez
    Indeed, we had the same issue in Janelia Farm back in 2016.