SCientific Image Format Input & Output: a flexible, extensible framework for image I/O. *EXPERIMENTAL* All API is subject to change, so depend at your own risk! See also @openmicroscopy/bioformats.
@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 : )
If you find a minute to give me pointers how to solve it, that would be great : )
@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.
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.)
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.
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:
- SCIFIO's
BioFormatsFormatonly looks at the file contents if theSCIFIOConfig'scheckerIsOpenflag is set totrue, but it isfalseby default; and: - Bio-Formats does not consider the
.stkextension sufficient for theMetamorphReaderto returntruefromisThisType; whenopenisfalse, it simply returnsfalse.
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.
I opened a PR enabling Deflate (zlib) support for
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 : )
TIFFFormat.Writer: scifio/scifio#455See 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 : )
Let me know if you also need it uploaded to the Java-8 update site.
@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 moreIs 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 :-)
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?!
@ctrueden @hinerm concerning the
I pushed my work here: https://github.com/scifio/scifio-javacv/compare/wip
I get a NPE when trying to read, but all I found was that
Here I’m stuck and would need some input :-)
scifio-javacv update to the FileLocation API, I tried to update MovieFormat, but wasn’t able to fix the test (that was failing independently of the FileLocation API changes)…I pushed my work here: https://github.com/scifio/scifio-javacv/compare/wip
I get a NPE when trying to read, but all I found was that
openPlane is never called despite the format matches and setDest is called.Here I’m stuck and would need some input :-)
But feel free to focus on the ImageJ wiki first!
Hi everybody,
I am facing an issue with compressed DICOM files.
As a sample dataset I used DEMO 0002 from http://www.rubomedical.com/dicom_files/. I can’t open a plane for this file, as the process doesn’t come to an end. I tracked the issue back to line 1527 in the DICOMFormat.java file (https://github.com/scifio/scifio/blob/741ac2ac03ec4c566a6612c0f148fdd47bd47d9d/src/main/java/io/scif/formats/DICOMFormat.java#L1527), where the codec should be decompressed. And even more precisely: The while-loop in JPEGCodec.java doesn’t seem to come to an end (https://github.com/scifio/scifio/blob/741ac2ac03ec4c566a6612c0f148fdd47bd47d9d/src/main/java/io/scif/codec/JPEGCodec.java#L109). Can anyone help me with this?
I am facing an issue with compressed DICOM files.
As a sample dataset I used DEMO 0002 from http://www.rubomedical.com/dicom_files/. I can’t open a plane for this file, as the process doesn’t come to an end. I tracked the issue back to line 1527 in the DICOMFormat.java file (https://github.com/scifio/scifio/blob/741ac2ac03ec4c566a6612c0f148fdd47bd47d9d/src/main/java/io/scif/formats/DICOMFormat.java#L1527), where the codec should be decompressed. And even more precisely: The while-loop in JPEGCodec.java doesn’t seem to come to an end (https://github.com/scifio/scifio/blob/741ac2ac03ec4c566a6612c0f148fdd47bd47d9d/src/main/java/io/scif/codec/JPEGCodec.java#L109). Can anyone help me with this?
With SCIFIO (File > Import > Image...) I get a much weirder error:
[ERROR] java.io.IOException: io.scif.img.ImgIOException: java.io.FileNotFoundException: /home/curtis/Downloads/dicom_viewer_0002/0002.DCM (Permission denied)I've not seen this happen before.
OK, I add write permission to the file, which worked around that error. Certainly it's a bug in SCIFIO that the file is being opened read-write just to read it, though. And now, I can reproduce the error you're seeing, @EllaHir.
I'm looking at a reference to
io.scif.io.ByteArrayHandle. That seems a bit old to me?https://github.com/ilastik/ilastik4ij/blob/c3f2b21f094f3a66b537f26663fc5d6149a6cfb3/src/test/java/org/ilastik/ilastik4ij/ObjectClassificationDemo.java#L3
Any straightforward path to update it?
I'm thinking of doing some work with https://github.com/scifio/scifio-hdf5 and perhaps integrating the functionality of the Vibez HDF5 plugin. What's the status of those projects?
5 replies
Hello, I am trying to open a zipped tiff but I get a NullPointer at the 'getFormat' here https://github.com/scifio/scifio/blob/420046b51eec0c4b306b6eeaf84b7bd1132bdfa4/src/main/java/io/scif/services/DefaultInitializeService.java#L87
alternativly, i there a way to feed scifio a stream instead of a location? Then I could unpack the image myself.
@moreApi SCIFIO is built around the idea of random access, so streams present a challenge unless they can be reset or buffered. The work to support compressed random access handles was never completed; see (scijava/scijava-common#274). There is also a tangential issue at #334. (IIRC, that feature would work by clever buffering of streams, and then performance of access would depend on how large you are willing to let your buffers get, plus how random the access pattern of the format is.) Fundamentally, ZIP cannot work until the compressed handles support is completed.
You can feed SCIFIO a
Location that is not backed by a file, and as long as there is a DataHandle plugin for that location type, SCIFIO should be able to read it. For example, there is a BytesLocation for wrapping a byte[] of data. It works well because byte[] does allow for fast random access.