⚠

NOTICE! This is a static HTML version of a legacy Fiji BugZilla bug.

The Fiji project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Bug 1211 - Stack Rendering Slow
Stack Rendering Slow
Status: RESOLVED FIXED
Product: Fiji
Classification: Unclassified
Component: Plugins
unspecified
Macintosh Mac OS
: P4 normal
Assigned To: ImageJ Bugs Mailing List
Depends on:
Blocks:
 
Reported: 2016-01-06 23:47 CST by djrowland
Modified: 2016-02-18 15:49 CST
3 users (show)

See Also:
Description djrowland 2016-01-06 23:47:42 CST 
When loading a 10 Mb image of with about 44 z slices, the stack scrolling is pretty smooth when I first open FIJI and load an initial image. As soon as I perform certain functions the scrolling becomes very sluggish. 

I did notice something about Java. When I go to System Preferences and look at the installed Java version it is 1.8.0_66-b17. But in the information FIJI pulled it shows a Java version of 1.7.0_51-b13. Where does FIJI pull the java informatino and how do I get it to recognize the new Java version.

Information about your version of Java:

  os.arch => x86_64
  os.name => Mac OS X
  os.version => 10.11.2
  java.version => 1.7.0_51
  java.vendor => Oracle Corporation
  java.runtime.name => Java(TM) SE Runtime Environment
  java.runtime.version => 1.7.0_51-b13
  java.vm.name => Java HotSpot(TM) 64-Bit Server VM
  java.vm.version => 24.51-b03
  java.vm.vendor => Oracle Corporation
  java.vm.info => mixed mode
  java.awt.graphicsenv => sun.awt.CGraphicsEnvironment
  java.specification.name => Java Platform API Specification
  java.specification.version => 1.7
  sun.cpu.endian => little
  sun.desktop => null
  file.separator => /

The up-to-date check says: REMIND_LATER

Information relevant to JAVA_HOME related problems:

  JAVA_HOME is set to: /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home//jre
  imagej.dir => /Applications/Image Analysis/Fiji.app

Information about the version of each plugin:

Activated update sites:
ImageJ: http://update.imagej.net/ (last check:20151221181554)
Fiji: http://update.fiji.sc/ (last check:20151221202403)

Files not up-to-date:
  99410c2d (MODIFIED) 20151007153554 Contents/Info.plist
  80e5d193 (MODIFIED) 20160106213618 jars/ij-1.50e.jar
  45e57df6 (LOCAL_ONLY) 20110603193126 plugins/BrukerOpener.jar
  b060ccd8 (LOCAL_ONLY) 20020613170120 plugins/MRI_Analysis_Calculator.class
  f9404e8b (LOCAL_ONLY) 20110603193502 plugins/MRI_t2_Calculator.class
  3b062d6b (LOCAL_ONLY) 20020613170120 plugins/T1T2CurveFitter.class
  96d8a6be (LOCAL_ONLY) 20150902215048 plugins/mcib3d-suite/mcib3d-core.jar
  267bd203 (LOCAL_ONLY) 20150902215051 plugins/mcib3d-suite/mcib3d_plugins.jar
  9189a149 (LOCAL_ONLY) 20121115212418 plugins/nifti_io.jar
Comment 1 Mark Hiner 2016-01-07 09:03:14 CST 
Hello,

>Where does FIJI pull the java informatino and how do I get it to recognize the new Java version.

There is some (unfortunately complex) logic when Fiji starts up where it looks in various locations for Javas. 

The default behavior is to try to use the latest Java. There is a known issue on Macs where Java 8 isn't being chosen over Java 7. We actually have a pending fix for this right now.

If you would like to test it, download this experimental version of the launcher:

http://hinerm.imagej.net/ImageJ-macosx

and use it to replace the existing version in your Fiji.app/Conents/MacOS/ directory. If you do try this new launcher, it would be great to know if it works for you.

As an additional workaround you can see the FAQ for instructions on launching with different Java versions:

http://imagej.net/Frequently_Asked_Questions#How_do_I_launch_ImageJ_with_a_different_version_of_Java.3F

If you're interested in more technical details, let me know.
Comment 2 djrowland 2016-01-07 12:57:16 CST 
I downloaded the experimental launcher and replaced the file indicated in your response. This however resulted in FIJI no longer being able to open. 

I think I figured something else out based on your suggestion of forcing FIJI to select the version of Java. When I went to Library/Java/JavaVirtualMachines, I only see jdk1.7.0_51.jdk. The Java in system preferences that states 1.8.0_66 is not in the Library/Java folder. It is in the Library/INternet Plug-Ins/ and is a JavaAppletPluggin.plugin.

Doug
Comment 3 Mark Hiner 2016-01-07 14:13:11 CST 
>This however resulted in FIJI no longer being able to open.

Oh, I'm very sorry. I just tested on a co-worker's computer and it looks like that file is downloaded without execution permissions - despite being set on the server.

After replacing the file, you can fix these permissions by opening up a Terminal and running:

  chmod a+x /path/to/Fiji.app/Conents/MacOS/ImageJ-macosx

If you'd like, you can read more about chmod here: http://ss64.com/osx/chmod.html. Essentially you're just telling the computer that "yes, this file has permission to be executed."

>It is in the Library/INternet Plug-Ins/ and is a JavaAppletPluggin.plugin

Fiji is supposed to look for Java in that location. The problem comes from false negatives in Fiji's detection of Java, due to changes in file structure between Java 1.6 and 1.7+. That's precisely what is fixed in the experimental ImageJ-macosx file I had you download, so I'm hoping it will still work for you if you chmod the file.
Comment 4 djrowland 2016-01-07 14:36:25 CST 
Ok. I did a little bit of work on this. I had to download and install the latest JDK for java. That step is not so apparent. So it does not look like JDK auto updates itself and it seems as though FIJI and ImageJ depend on the latest JDK. Once I installed the latest JDK and pointed FIJI to this, FIJI responds as expected. 

So I have a few followups on this. 

1. Why does FIJI work on JDK and can FIJI alert a user as to the need to update the JDK?

2. Why does FIJI not point itself to the latest installation of JDK? I still needed to use the command line and now create an automator app to point to it. 

This seems to be a lot of work for an application to work. Is this kind of bug being worked on to make it easier for the user?

I have Windows machine and it seems unaffected by this.

Thanks

Doug
Comment 5 djrowland 2016-01-07 14:37:04 CST 
There was a mid air collision. I am going to try your chmod.

Doug
Comment 6 djrowland 2016-01-07 14:44:58 CST 
All is good now. I used the experimental version of the launcher with the permission change. It now loads the correct version of JDK and FIJI is working smoothly. So I guess that part is worked out.

I am still wondering about the JDK updates and how to automate that or to have FIJI alert a user to it being out of date. 

Thanks

Doug
Comment 7 Mark Hiner 2016-01-07 15:09:29 CST 
>I used the experimental version of the launcher with the
permission change.
> It now loads the correct version of JDK and FIJI is working
smoothly.
> So I guess that part is worked out.

That's great to hear. Thank you very much for testing and following up so quickly!

>Is this kind of bug being worked on to make it easier for the user?

Definitely. This is, in general, part of our work to migrate to Java 8 (http://imagej.net/2015-12-22_-_The_road_to_Java_8).

Java has an unfortunate history on the Mac, with Apple building its own version of Java and then stopping after Java 6. As a result, Fiji currently carries a lot of Apple Java 6-specific baggage - which is now causing problems with Java 7 and 8.

Our long term goal is to move to an industry standard way of interacting with Java (it looks as though JavaFX is becoming that standard) that will make transitions between Java versions easier.

In the short term, we are very close to having Fiji downloads with a bundled Java 8. Having you test the experimental launcher and confirm that it works is a big step in that direction.

>I am still wondering about the JDK updates and how to automate that or to have
FIJI alert a user to it being out of date

Moving to a JavaFX launcher could potentially help with this. There are some concerns with allowing arbitrary Java updates (e.g. preserving scientific reproducibility, plugins outright breaking with newer Java versions). We had specific experience with this recently with the 3D viewer (http://forum.imagej.net/t/java-3d-progress-and-next-steps/135) so part of our future plans include making it easier for ImageJ plugins to associate with a given Java version.

Anyway, the bottom line is that we agree that Java versioning needs to be more robust. If you'd like to share more observations or suggestions, it'd be great to continue the discussion on forum.imagej.net.

Thanks again for the help and feedback.
Comment 8 Curtis Rueden 2016-02-18 15:49:52 CST 
The new launcher was uploaded and released awhile back.