Analysis with ImageJ and Visualization in the Jupyter Notebook

fiji
visualization
imagej
python
imagej-ops
jupyter

#41

First we need to ensure that it imglyb can be imported when run just from the command line. Just like you ran python -c "import jnius; print(jnius)" before, please run and print the output of

python -c "import imglyb; print(imglyb)"

If that does not work, we should try and isolate the problem even more, and create a new conda environment that contains only the required packages:

# pick different name if you already have an environment with this name
conda create -n imglyb-test
conda activate imglyb-test
conda install -c conda-forge pyjnius
conda install -c hanslovsky imglyb
python -c "import imglyb; print(imglyb)"

#42

@ctrueden Please change to

With the separation of java code and python code into two repositories I also updated the conda package name and imglib2-imglyb will not be updated on conda for future releases.


#43

I did that first, but then imglyb would not work on my system (“imglyb can not be found, it might not be correctly installed.”). This makes sense, since we need the imglib2-imglyb JAR file in order to function properly, and only the imglib2-imglyb package (not the imglyb package) installs that JAR into the environment.

So your idea is that the imglib2-imglyb JAR needs to be shipped with ImageJ2 from now on, then? I can do that, if that’s what you want. Let me know.


#44

Correct, the imglib2-imglyb jar will not be distributed through conda anymore. Instead, I use jrun to fetch the jar from maven now. The error message is actually thrown in imagej.py, however, so imglyb should still work on your system (just try python -c "import imglyb; print(imglyb)").

Probably not. Instead, imagej.py should be updated to use the most recent version of imglyb. My educated guess is that that just means that you can remove any code that tries to resolve and add the path to imglib2-imglyb.jar.

As a side note: Now that imglib2-imglyb is not a fat jar anymore, I think it could be shipped with ImageJ without introducing dependency skew. Then it would probably be best to import jnius before import imglyb in imagej.py, so the imglib2-imglyb jar from imagej would be used. Unfortunately, jrun would still try to resolve the imglib2-imglyb jar through maven (which takes a while the first time). That could probably be resolved by adding a switch to imglyb_config.py. In image.py, that would mean something like this:

# do your Fiji.app dir and jar discovery
# set up imglyb_config and jnius_config
import jnius
import imglyb

#45

I updated imagej.py, gutting all the path scanning logic. I guess we no longer need to set any environment variables (not JAVA_HOME nor IMGLYB_JAR nor PYJNIUS_JAR), right?

@hanslovsky Since you already use jrun to retrieve imglib2-imglyb… is there a way imagej.py could invoke jrun to download all of net.imagej:imagej, instead of relying on a user installation of ImageJ or Fiji? If so, we should definitely add that as an alternate ij.init() call, no?

Anyone interested: please test the latest master branch of imagej.py and let me know if it works on your system! If so, I’ll release 0.3.0 on PyPI.


#46

Yes, there definitely is! You can have a look at what I am doing in imglyb:

    primary_endpoint, workspace = jrun.jrun.resolve_dependencies(
        '+'.join([IMGLIB2_IMGLYB_ENDPOINT] + imglyb_config.get_endpoints()),
        cache_dir=IMGLYB_JAR_CACHE_DIR,
        m2_repo=LOCAL_MAVEN_REPO,
        repositories=imglyb_config.get_repositories(),
        verbose=2
    )
    jnius_config.add_classpath(os.path.join(workspace, '*'))

Replace imglyb_config.get_endpoints() with [endpoint1, endpoint2, ...], endpointN in the sense of jrun endpoints. In some sense, jrun is now what scijava/scyjava was supposed to be (without adding new jars at runtime, though), cf scijava/scyjava#3.

The reason why I did not suggest that earlier is that I thought it was by design that users were to specify the Fiji.app dir so they can use the exact same jars they would have in their ImageJ (e.g. update sites, different modules, etc). Maybe this could be added as a switch.

Anyone interested: please test the latest master branch of imagej.py and let me know if it works on your system! If so, I’ll release 0.3.0 on PyPI.

I ran the example from the readme on the latest master and saw no errors, so I figure it worked!


#47

There are users in both camps. My idea is to keep imagej.init(ij_dir) but also add a jrun-based way of creating a net.imagej.ImageJ instance. I filed an issue for it:

Great, I released imagej 0.3.0 on PyPI. :beers:


#48

Here is my output. It seems like I can import imglyb just fine

C:\WINDOWS\system32>python -c "import imglyb; print(imglyb)"
<module 'imglyb' from 'C:\\ProgramData\\Anaconda3\\lib\\site-packages\\imglyb\\__init__.py'>

#49

I guess that means it is an issue with spyder. I recommend running the relevant code from the command line, then. Maybe there is also a way to set environment variables manually in spyder.


#50

Great, thanks for all of your help. I’m disappointed this can’t be resolved. Even when I specify the environment variables manually, the code doesn’t compile from command line. I will try running this in Ubuntu instead, but I hope this becomes more Windows friendly in the future!

ie.

os.environ['JDK_HOME'] = "C:\\Program Files\\Java\\jdk1.8.0_181"
os.environ['JAVA_HOME'] = "C:\\Program Files\\Java\\jdk1.8.0_181"
os.environ['PYJNIUS_JAR'] = "C:\\ProgramData\\Anaconda3\\pkgs\\pyjnius-1.1.1.post54-py36h6538335_0\\share\\pyjnius\\pyjnius.jar"
os.environ['IMGLYB_JAR'] =  "C:\\ProgramData\\Anaconda3\\pkgs\\imglib2-imglyb-0.0.0.post135-py36_0\\share\\imglyb\\imglib2-imglyb-0.1.0-SNAPSHOT.jar"

#51

What exactly does not work? You said imglyb works from the command line, right? Is it imagej.py?
If it is imagej.py, please try the branch that @ctrueden suggested in this imagej.py issue