For those running 32-bit Windows: I was not able to test on that platform. Please let me know ASAP if you have any problems with a newly downloaded Fiji.
For those of you using JavaFX: it should now finally work on macOS without tweaks.
For anyone having issues with HTTPS Updater warnings: those should definitely be solved now. If you still see them, please start a topic here on the forum about it.
If you download it, and Fiji won’t start for you, please create a new topic and mention
@ctrueden
.
Do you think it would be worth offering a Fiji download for Mac M1 that bundles that JDK, with the caveat that plugins requiring native libraries won’t work out of the box at the moment?
Do you think it would be worth offering a Fiji download for Mac M1 that bundles that JDK, with the caveat that plugins requiring native libraries won’t work out of the box at the moment?
I think either that or perhaps suggesting M1 users download no-JRE plus a native system JRE would be a nice option—this is how I’ve been getting along.
Hi Curtis. I replaced the original folder “zulu8.60.0.21-ca-fx-jdk8.0.322-macosx_x64” with the unpacked folder “zulu8.60.0.21-ca-fx-jdk8.0.322-macosx_aarch64”, but it leads to crash of Fiji. Do I miss something?
Yup, I can confirm this. If you don’t have any system Java (which macs by default don’t) then that’s the behavior.
github.com/imagej/imagej-launcher
I've been using Fiji on an Apple Silicon M1 (arm64) MacBook Pro (Big Sur 11.4)
…
I've started a image.sc thread regarding getting things to work smoothly *native* rather than in Rosetta emulation.
https://forum.image.sc/t/fiji-clij-etc-native-on-apple-silicon-arm64-m1/53627/16
Everything works when architectures are matched, so everything emulated or everything native. Mixing architectures is a no go.
So for Fiji/imagej the key is native JRE. I have Azul 11, but native OpenJDK is also available via homebrew, and use of the "No JRE" Fiji. (The normal Mac OS install also works fine in Rosetta, but is markedly slower.)
The existing launcher actually works—despite being x86.
/Applications/Fiji.app/Contents/MacOS> lipo -info ImageJ-macosx
Non-fat file: ImageJ-macosx is architecture: x86_64
It does report an architecture mismatch error and does a fallback to system Java, which results in a 2nd Fiji icon in the dock—minor inconvenience.
As noted in the thread, Apple docs show you can build for a different architecture than you run (can't test obviously) and can build universal binaries. This is also supported by cmake, which I was pleased to see is used by the imagej-launcher.
I made a fork (https://github.com/psobolewskiPhD/imagej-launcher) and tweaked CMakeLists.txt to provide the two arch for cmake (to make a universal binary). I also had some Java path issues, which may be a Big Sur thing.
The project compiled with no issue and the binary is universal:
~/dev/imagej-launcher > lipo -info ImageJ-macosx
Architectures in the fat file: ImageJ-macosx are: x86_64 arm64`
I've tested this binary on my Apple Silicon M1 Mac. It works fine with the following behavior when launched from the command line to monitor errors (there's some warnings too regarding patcher/injector, but they seem of no issue):
1. current official imagej-macosx (x86), with current official JRE (x86):
Launches Fiji via Rosetta, no issues
2. current official imagej-macosx (x86), with no JRE and native system Java (Azul 11 in my case):
Launches Fiji after fallback to System Java. No issues. (~5s launch)
3. current official imagej-macosx (x86), with native JRE inside Fiji.app (Azul 11 in my case):
Wrong architecture error, system Java fallback, launches Fiji, No issues. (~5s launch)
4. my universal imagej-macosx (x86/arm64), with current official JRE (x86):
Wrong architecture error, system Java fallback, launches Fiji, No issues. (<4 s launch)
5. my universal imagej-macosx (x86/arm64), with no JRE:
System Java fallback, launches Fiji, No issues. (<4 s launch)
6. my universal imagej-macosx (x86/arm64), with native Azul 11 JRE inside Fiji.app:
Normal launch (<4 s), no issues, 1 Fiji in dock
(Also, if anyone is curious, if you put both an x86 and arm64 JRE in Fiji.app/java it's alphabetical. So adoptopen vs zulu results in wrong architecture error and system java. While adoptopen vs 1_zulu uses the included zulu.)
So from where I sit, a universal imagej-macosx for Fiji with native JRE inside is the best for Apple Silicon Macs, but all cases work fine, as long as a system Java exists.
The missing case is universal launcher on x86 Mac, which I might be able to try this weekend.
Here's a link to the binary if anyone wants to test it themselves, it belongs in:
Fiji.app/Contents/macos
https://www.dropbox.com/s/1ftxheyx85siko3/ImageJ-macosx.zip?dl=0
You can confirm by trying to run the executable
ImageJ-macosx
from the terminal that’s in
Fiji.app/Contents/MacOS
incompatible architecture errors
because of the incompatibility between the x86 binary launcher and the arm64 binary Java.
The solutions are to try my Universal2 (arm64/x86) launcher from the GitHub issue or install the arm64 Zulu java (
Java Download | Java 8, Java 11, Java 13 - Linux, Windows & macOS
) as system Java and use no-JRE Fiji.
Edit: Another option is to use vanilla ImageJ.
@Wayne
has a arm64 release with Zulu Java 13:
https://imagej.nih.gov/ij/download.html
Hi Peter. Thanks a lot. I’ve read nearly all of your comments on this forum and GitHub, but sorry that I am confused. I think the reason is that I do not know meanings of codes.
I tried ImageJ bundled with Zulu OpenJDK 13.0.6. It is native, but there is no bio-formats and other plugins, and there is no Update website, either. I have installed Oracle Java 18 for ARM64, but I do not know what to do.
When I tried Fiji, it shows that it is not native. I do download your “ImageJ-macosx” file and put it into folder Fiji.app/Contents/macOS, but when I double click Fiji, it seems that it is still Inter type app. I see you type something in the Mac terminal. I tried some, but failed.
I replaced the original folder “zulu8.60.0.21-ca-fx-jdk8.0.322-macosx_x64” with the unpacked folder “zulu8.60.0.21-ca-fx-jdk8.0.322-macosx_aarch64”, but it leads to crash of Fiji. Do I miss something?
No, I am sorry to hear that. I specifically made that
macos-arm64.tar.gz
hoping it would work in exactly the way you tried. What kind of crash do you get? Maybe I did something wrong preparing the bundle. I do not have an M1 Mac available to me for testing yet, so I only have limited ability to work on this.
If you could offer Fiji with that JDK for Mac M1, it will be very helpful.
We want to, but it is a lot of work (because Fiji ships native libraries that need to see recompilation + new releases for M1—or else things like the 3D Viewer will not work) and there are many other priorities competing for the LOCI Fiji team’s time. It is something we plan to look at over the summer, but I cannot promise when it will be available.
I have installed Oracle Java 18 for ARM64, but I do not know what to do.
Fiji does not work well yet with Java 17+. Use Java 11 or Java 8. I also advise against using Oracle JDK, for licensing reasons. Use OpenJDK. The Zulu 8 JDK+FX that
@psobolewskiPhD
linked (
this one: 8u332b09 / Azul Zulu: 8.62.0.19
) is a good choice.
@tangji0318
If you have Java arm64 installed in your system
then lets make sure that’s working.
/usr/libexec/java_home -V
arm64
somewhere, if it’s working correctly.
java -version
and you should see the active java being used, which should be the same.
no-JRE
Fiji, a Fiji.app without it’s own Java bundle inside. You can take the Fiji you have, right click on it to show contents and just delete the
java
folder. Then when you launch that Fiji it will fall back on your native Java.
image
1262×886 102 KB
I specifically made that
macos-arm64.tar.gz
hoping it would work in exactly the way you tried. What kind of crash do you get? Maybe I did something wrong preparing the bundle.
The bundle is fine, but the launcher being x86 means it clashes architectures. With x86 launcher only no-JRE installs will work.
Universal (x86/arm64) launcher for Mac OS · Issue #82 · imagej/imagej-launcher · GitHub
Fiji does not work well yet with Java 17+. Use Java 11 or Java 8. I also advise against using Oracle JDK, for licensing reasons. Use OpenJDK. The Zulu 8 JDK+FX that
@psobolewskiPhD
linked (
this one: 8u332b09 / Azul Zulu: 8.62.0.19
) is a good choice.
Your Oracle java may not be ideal, you may want to install Azul Java 8 or Java 11, this as your system java. The .dmg package should complete the install properly. And you can check using the same commands:
/usr/libexec/java_home -V
java -version
Hi Curtis. Thanks for your reply. What kind of crash? When I double click Fiji, the Fiji window does not show up. However, after I install OpenJDK, it works as a native app. I do not know what happens.
Hi Peter. Thanks a lot. Under your instructions, I succeed to run Fiji natively.
Tensorflow Plugin - Metal - Apple Developer
.
截屏2022-06-03 08.53.59
1074×852 82.5 KB
Unfortunately, I have bad news here.
is
available on arm64 thanks to Apple’s efforts. However, Apple has not supported porting the java component—Apple doesn’t ship Java with it’s machines/OS anymore, so I think they just don’t consider Java a priority.
github.com/tensorflow/java
<em>Please make sure that this is a bug. As per our [GitHub Policy](https://gith
…
ub.com/tensorflow/tensorflow/blob/master/ISSUES.md), we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:bug_template</em>
**System information**
- Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
- OS Platform and Distribution (e.g., Linux Ubuntu 16.04): **MacOs Big Sur ver11.0.1, M1 slices**
- Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
- TensorFlow installed from (source or binary): Maven
- TensorFlow version (use command below): Old tensorflow version(1.4.0/1.5.0), and new tensorflow Java Version 0.2.0
- JVM version: 1.8.0_162
- No GPU
**Describe the current behavior**
I just try to run tensorflow java offical example, and get tensorflow version for test. but It dosen't work.
I have test different versions of tensorflow java interface, and only ver 1.13.1 works well.
And all other versions can not work, for example old tensorflow version(1.4.0/1.5.0), and new tensorflow Java Version 0.2.0/0.3.0(tensorflow ver2.3.1/2.4.1) .
The Error shows below:
> A fatal error has been detected by the Java Runtime Environment:
> SIGILL (0x4) at pc=0x00000001290edc15, pid=6333, tid=0x0000000000001a03
> JRE version: Java(TM) SE Runtime Environment (8.0_162-b12) (build 1.8.0_162-b12)
> Java VM: Java HotSpot(TM) 64-Bit Server VM (25.162-b12 mixed mode bsd-amd64 compressed oops)
> Problematic frame:
> C [libtensorflow_framework.2.dylib+0x14c15] tensorflow::monitoring::MetricDef<(tensorflow::monitoring::MetricKind)1, long long, 2>::MetricDef<char [11], char [7]>(absl::lts_2020_02_25::string_view, absl::lts_2020_02_25::string_view, char const (&) [11], char const (&) [7])+0x125
> Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> An error report file with more information is saved as:
> /***/tf_test/hs_err_pid6333.log
> If you would like to submit a bug report, please visit:
> http://bugreport.java.com/bugreport/crash.jsp
> The crash happened outside the Java Virtual Machine in native code.
> See problematic frame for where to report the bug.
**Code to reproduce the issue**
Java code:
import org.tensorflow.TensorFlow;
public class HelloTensorFlow {
public static void main(String[] args) throws Exception {
System.out.println("Hello TensorFlow " +TensorFlow.version());
pom.xml
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.myorg</groupId>
<artifactId>hellotensorflow</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<exec.mainClass>HelloTensorFlow</exec.mainClass>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
<dependencies>
<dependency>
<groupId>org.tensorflow</groupId>
<artifactId>tensorflow-core-platform</artifactId>
<version>0.2.0</version>
</dependency>
</dependencies>
</project>
Alas, it’s not changed much over the past year.
On the flip side, tensorflow is such a complex and computation dependent machine learning library that it does not run emulated—it is tuned for the specific platform.
Your alternative for using StarDist is to use the scientific python ecosystem which has much better support by Apple. Stardist devs have made a very nice plugin for napari that I believe does everything the Fiji one does.
Stardist crashes Napari on M1 Mac
Usage & Issues
@dom3
It’s not hard to get a native conda env.
But it will be a bit annoying to have two different ones: anaconda and conda-forge miniforge.
If you’re not heavily invested in your Anaconda install, you could nuke it and just replace it with miniforge.
If you do want to keep your anaconda to have a separate emulated conda, then you will need to play some games in your shell initialization .zshrc file.
Anyhow.
My recommendation would be to setup your tensorflow environment native arm64 with G…
If something doesn’t work, then I suggest opening a new thread because we are quite out of the scope of this one.
Thank you very much, Peter. I have installed Stardist and Napari in terminal, and I will have a try.
Fiji does not work well yet with Java 17+. Use Java 11 or Java 8. I also advise against using Oracle JDK, for licensing reasons. Use OpenJDK.
I tried updating from the built-in version of Java 8 to the latest one available on
https://www.azul.com/downloads/
or even to upgrade to
Java 11
(always using the JDK FX), but it looks like there might be something missing. The easiest/quickest way to tell is that the Fiji About Box no longer says ImageJ2, but ImageJ 1.53t.
Is there something else that needs to be added? A folder needs to be renamed?? Is FIJI looking for some libraries at the wrong location because they’ve been moved? I can’t figure out what’s different and what I might be doing wrong
@Cortig
Which platform are you running? MacOS? And if so: M1 or Intel?
What are you trying to achieve? You want to run Fiji with a newer version of Java? Why?
Can you describe what goes wrong? Maybe share a screenshot of your presumably incomplete Fiji?
@ctrueden
Sorry, I should have specified. I’m on macOS Intel.
When I noticed the issues, I tried to play around with Java 8 to see whether things had changed location, etc. I then noticed that the bundled version of Java8 JDK FX is zulu8.60.0.21-ca-fx-jdk8.0.322, but zulu8.64.0.19-ca-fx-jdk8.0-2.345 is available. The improvements are minor, but I tried updating just in case, and that’s when I noticed that this version exhibited the same issues as when I played around with Java 11.
In a way, it’s not the end of the world. I can use FIJI with the bundled version of Java, but it really puzzles me and I was wondering what the difference was.
Here are the captures of the About box that illustrate the difference:
Screenshot 2022-09-28 at 12.34.31
1454×1166 881 KB
With Java 11 JDK FX or zulu8.64.0.19-ca-fx-jdk8.0-2.345
Screenshot 2022-09-28 at 12.33.47
1306×802 208 KB
@cortig
Interesting, thanks for the explanation.
ImageJ2 overrides the About dialog on macOS to display its About image instead of the original ImageJ’s. So something is different with OpenJDK 11, as well as Zulu OpenJDK 8.0.2-345, that seems to make ImageJ2’s override stop functioning.
Is there anything else not working as expected, besides the About dialog?
ctrueden: