imagej2
imagej2 copied to clipboard
imagej
Create a Windows installer for ImageJ2/Fiji
Right now, Fiji and ImageJ2 have the problem that if unpacked into the Program Files directory on Windows, the ImageJ Updater does not have full, unimpeded read/write access to its own directory. This is due to the Windows security model. It is in general very difficult to detect programmatically whether things will work; they might seem to work temporarily until the computer is rebooted, for example.
However, there is a potential solution: distribute the Windows version of ImageJ using an installer such as NSIS or Inno Setup, and have the installer flag the entire ImageJ/Fiji directory as globally writable by all users.
For details, see this SO answer and this Inno Setup FAQ entry.
Having a Windows installer will be good anyway because Windows users are most comfortable with them (just like OS X users are comfortable with DMG images which they mount and then copy the .app into /Applications themselves).
One wrinkle is that we still want to give a helpful error message if ImageJ/Fiji was manually unpacked into Program Files without using the installer. To do that, we can have the installer write a stub file into the installation directory, which is not present in the ImageJ/Fiji cross-platform zip distribution. And if the Updater does not see that stub file, it refuses to try to update an installation in Program Files.
Migrated-From: http://trac.imagej.net/ticket/2011
I really need help downloading fiji to view multiphoton microscopy pictures please someone help
I really need help downloading fiji to view multiphoton microscopy pictures please someone help
Additionally, I want to point you on http://forum.imagej.net if you have further questions.
I'm just curious, does anybody have made an installer yet ? I'm managing a small microscopy core facility and I try to push most of my users to use Fiji for their analysis on their personnal computer, but having no installer refrain some of them.
@alexandrebastien No installer yet, sorry. The switch of the ImageJ Launcher over to JavaFX is on my top 10 list of development priorities. But unfortunately probably just outside the top 5. So I expect it will be a few more months.
Please do not configure something that makes a program directory under a protected folder like C:\Program Files "globally writable by all users". That is a non-standard design and goes against all security recommendations. Users should only have modification rights within their own profile or (occasionally) in shared spaces (like some subdirectories of C:\ProgramData).
There is a better approach for installing ImageJ/Fiji as a system install that is available to run for all users. Install to C:\Program Files, keep those files protected from users (or malware) making any modifications, and create a service that will update ImageJ/Fiji as the SYSTEM account. It could be configured to auto-update, or be initiated from the menu as it is now.
Windows users sometimes complain about how weird/unintuitive it is that ImageJ cannot function properly out of Program Files like "normal" applications do—and I am inclined to agree. As long as users keep unpacking ImageJ and dumping it into C:\Program Files, we need to be as friendly/nice as possible. Right now, you at least get a warning about being unable to update from a "protected location", but no real guidance is given to users about how to fix this.
So, I think the best solution will be for ImageJ to be more flexible: by default, plugins should be installed into user space in standard locations—or failing that, at least something relatively platform-neutral like $HOME/.imagej. And only if you configure ImageJ to be a "portable app" does it try to manage its plugins within its own installation prefix. This latter option is useful e.g. for thumb drives which migrate across machines, when the user does own the ImageJ installation folder.
Does that sound like an OK plan to you, @teknowledgist?
@teknowledgist wrote:
create a service that will update ImageJ/Fiji as the SYSTEM account.
How would you suggest we run a Java-based Windows service? The Java Service Wrapper? Have you used it? My explicit goal for the future of ImageJ is no native code; I do not want to ship anything platform-specific or native, because the maintenance and testing burden is too high. I am very reticent to invest lots of effort into Windows-specific (or macOS-specific, or Linux-specific) layers of ImageJ, unless doing so creates a huge boost in usability somehow.
P.S. @teknowledgist since it looks like you are a Windows/Chocolatey enthusiast: any interest in helping with https://github.com/imagej/chocolatey-packages ? I would love to update/expand it to include ImageJ2, but have no bandwidth currently!
Does that sound like an OK plan to you, @teknowledgist?
Absolutely! I didn't know this was an option.
I'm going to expose my ignorance here... My understanding (based on trying to find what version I would be downloading) is/was that ImageJ/Fiji was so much a collection of smaller pieces that there was no base program to "versionize". Thus there was no real means of a machine installation and occasional "managed" upgrades by admins (i.e. deployment) and allowing users to pick and upgrade their plugins on their schedule.
In my idealized world, system admins would be able to deploy an application and define the "required" plugins, the "default" plugins (that user's could disable), and then allow each user the ability to include their own library of plugins. Everything the admin pushed would update at the admin's discretion, and the user would update their pieces when they choose. In my experience, almost no software offers this, so I don't expect ImageJ to end up there either.
How would you suggest we run a Java-based Windows service?
I can't suggest it one way or another because I know nothing about it, sorry. I appreciate your no native code goal. I don't mean to be the guy that asks for difficult/impossible things without knowing what I am doing, but I guess I have here.
any interest in helping with https://github.com/imagej/chocolatey-packages ?
Actually, I am here posting issues (and questions on the forum) because I was investigating creating a Chocolatey package. :smile: I have been playing with Chocolatey and (attempting) making packages for software I am asked to include in a classroom/lab (hence all the science-y stuff). Fiji is the latest.
I am not a developer by training (nor terribly knowledable of developer-y things), but I would be happy to continue toward both ImageJ2 and Fiji Chocolatey packages. However, I am trying to be pretty strict about making my Chocolatey packages be system (i.e. alluser) installs. (Ugh! The hoops I jumped through to make POV-Ray a system install!) My thinking for Fiji was to use Chocolatey to morph the current unzip-and-go, per-user (or insecure) design into a system install by locking it in Program Files and creating a scheduled task to run the updater. That would effectively be very close to what I think the installer requested in this issue should do.
I don't know if you want to have this discussion here or separately though. Feel free to contact me at my username at gmail.
My understanding (based on trying to find what version I would be downloading) is/was that ImageJ/Fiji was so much a collection of smaller pieces that there was no base program to "versionize".
There is a base program: the one in this here repository. The artifact is net.imagej:imagej and its version is currently 2.0.0-rc-59. (Actually, it is ridiculous that we use "RC" here, and that we are on candidate 59, when really it should still be beta or even alpha. Or maybe we should just bite the bullet and call it 2.0.0 and start with the SemVer properly...) This version is the one reported when you click the status bar of ImageJ, and is a useful shorthand which encapsulates all the versions of all the underlying components. That is: 2.0.0-rc-59 implies this lovely collection of packages:
$ mvn dependency:list|grep '\[INFO\] [a-z]'|sort
[INFO] au.com.bytecode:opencsv:jar:2.4:compile
[INFO] com.fifesoft:autocomplete:jar:2.5.8:runtime
[INFO] com.fifesoft:languagesupport:jar:2.5.8:runtime
[INFO] com.fifesoft:rsyntaxtextarea:jar:2.5.8:runtime
[INFO] com.github.jnr:jffi:jar:1.2.7:runtime
[INFO] com.github.jnr:jffi:jar:native:1.2.7:runtime
[INFO] com.github.jnr:jnr-constants:jar:0.8.5:runtime
[INFO] com.github.jnr:jnr-enxio:jar:0.4:runtime
[INFO] com.github.jnr:jnr-ffi:jar:1.0.7:runtime
[INFO] com.github.jnr:jnr-netdb:jar:1.1.2:runtime
[INFO] com.github.jnr:jnr-posix:jar:3.0.1:runtime
[INFO] com.github.jnr:jnr-unixsocket:jar:0.3:runtime
[INFO] com.github.jnr:jnr-x86asm:jar:1.0.2:runtime
[INFO] com.github.sbridges.object-inspector:object-inspector:jar:0.1:runtime
[INFO] com.google.guava:guava:jar:19.0:runtime
[INFO] com.googlecode.efficient-java-matrix-library:ejml:jar:0.24:compile
[INFO] com.googlecode.gentyref:gentyref:jar:1.1.0:compile
[INFO] com.headius:invokebinder:jar:1.2:runtime
[INFO] com.headius:options:jar:1.1:runtime
[INFO] com.jcraft:jsch:jar:0.1.49:runtime
[INFO] com.jcraft:jzlib:jar:1.1.2:runtime
[INFO] com.martiansoftware:nailgun-server:jar:0.9.1:runtime
[INFO] com.miglayout:miglayout:jar:swing:3.7.4:runtime
[INFO] com.sun.codemodel:codemodel:jar:2.6:runtime
[INFO] commons-logging:commons-logging:jar:1.1.1:runtime
[INFO] edu.emory.mathcs:jtransforms:jar:2.4:runtime
[INFO] edu.mines:mines-jtk:jar:20151125:compile
[INFO] edu.ucar:udunits:jar:4.3.18:compile
[INFO] gov.nist.math:jama:jar:1.0.3:compile
[INFO] io.scif:scifio-jai-imageio:jar:1.1.0:compile
[INFO] io.scif:scifio:jar:0.31.1:compile
[INFO] jitk:jitk-tps:jar:2.1.0:compile
[INFO] joda-time:joda-time:jar:2.9.4:runtime
[INFO] junit:junit:jar:4.12:test
[INFO] log4j:log4j:jar:1.2.17:compile
[INFO] mpicbg:mpicbg:jar:1.1.1:compile
[INFO] net.iharder:base64:jar:2.3.8:runtime
[INFO] net.imagej:ij1-patcher:jar:0.12.5:runtime
[INFO] net.imagej:ij:jar:1.51h:compile
[INFO] net.imagej:imagej-common:jar:0.24.3:compile
[INFO] net.imagej:imagej-deprecated:jar:0.1.1:runtime
[INFO] net.imagej:imagej-legacy:jar:0.23.5:runtime (optional)
[INFO] net.imagej:imagej-notebook:jar:0.2.1:compile
[INFO] net.imagej:imagej-ops:jar:0.36.0:compile
[INFO] net.imagej:imagej-plugins-commands:jar:0.7.0:runtime
[INFO] net.imagej:imagej-plugins-tools:jar:0.3.0:runtime
[INFO] net.imagej:imagej-plugins-uploader-ssh:jar:0.3.1:runtime
[INFO] net.imagej:imagej-plugins-uploader-webdav:jar:0.2.1:runtime
[INFO] net.imagej:imagej-scripting:jar:0.5.1:runtime
[INFO] net.imagej:imagej-ui-awt:jar:0.3.0:runtime
[INFO] net.imagej:imagej-ui-swing:jar:0.21.1:runtime
[INFO] net.imagej:imagej-updater:jar:0.8.2:compile
[INFO] net.imglib2:imglib2-algorithm-fft:jar:0.1.2:compile
[INFO] net.imglib2:imglib2-algorithm:jar:0.6.2:compile
[INFO] net.imglib2:imglib2-ij:jar:2.0.0-beta-35:runtime
[INFO] net.imglib2:imglib2-realtransform:jar:2.0.0-beta-34:compile
[INFO] net.imglib2:imglib2-roi:jar:0.4.4:compile
[INFO] net.imglib2:imglib2:jar:3.2.1:compile
[INFO] net.sf.jung:jung-api:jar:2.0.1:runtime
[INFO] net.sf.jung:jung-graph-impl:jar:2.0.1:runtime
[INFO] net.sf.trove4j:trove4j:jar:3.0.3:compile
[INFO] net.sourceforge.collections:collections-generic:jar:4.01:runtime
[INFO] net.sourceforge.jdatepicker:jdatepicker:jar:1.3.2:runtime
[INFO] org.apache-extras.beanshell:bsh:jar:2.0b6:runtime
[INFO] org.apache.commons:commons-compress:jar:1.4.1:runtime
[INFO] org.apache.commons:commons-lang3:jar:3.1:runtime
[INFO] org.apache.commons:commons-math3:jar:3.6.1:compile
[INFO] org.apache.commons:commons-math:jar:2.2:runtime
[INFO] org.apache.commons:commons-vfs2:jar:2.0:runtime
[INFO] org.apache.maven.scm:maven-scm-api:jar:1.4:runtime
[INFO] org.apache.maven.scm:maven-scm-provider-svn-commons:jar:1.4:runtime
[INFO] org.apache.maven.scm:maven-scm-provider-svnexe:jar:1.4:runtime
[INFO] org.bushe:eventbus:jar:1.4:compile
[INFO] org.clojure:clojure:jar:1.8.0:runtime
[INFO] org.codehaus.groovy:groovy:jar:2.3.6:runtime
[INFO] org.codehaus.plexus:plexus-utils:jar:1.5.6:runtime
[INFO] org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] org.javassist:javassist:jar:3.20.0-GA:runtime
[INFO] org.jfree:jcommon:jar:1.0.23:runtime
[INFO] org.jfree:jfreechart:jar:1.0.19:runtime
[INFO] org.jhotdraw:jhotdraw:jar:7.6.0:runtime
[INFO] org.jruby.extras:bytelist:jar:1.0.11:runtime
[INFO] org.jruby.jcodings:jcodings:jar:1.0.10:runtime
[INFO] org.jruby.joni:joni:jar:2.1.1:runtime
[INFO] org.jruby:jruby-core:jar:1.7.12:runtime
[INFO] org.jruby:jruby-stdlib:jar:1.7.12:runtime
[INFO] org.jruby:yecht:jar:1.0:runtime
[INFO] org.mapdb:mapdb:jar:1.0.3:compile
[INFO] org.markdownj:markdownj:jar:0.3.0-1.0.2b4:runtime
[INFO] org.mozilla:rhino:jar:1.7.6:runtime
[INFO] org.netlib:blas:jar:0.8:runtime
[INFO] org.netlib:f2jutil:jar:0.8:runtime
[INFO] org.netlib:lapack:jar:0.8:runtime
[INFO] org.netlib:netlib-java:jar:0.9.3-renjin-patched-2:runtime
[INFO] org.netlib:xerbla:jar:0.8:runtime
[INFO] org.ow2.asm:asm-analysis:jar:4.0:runtime
[INFO] org.ow2.asm:asm-commons:jar:4.0:runtime
[INFO] org.ow2.asm:asm-tree:jar:4.0:runtime
[INFO] org.ow2.asm:asm-util:jar:4.0:runtime
[INFO] org.ow2.asm:asm:jar:4.0:runtime
[INFO] org.renjin:datasets:jar:0.8.1906:runtime
[INFO] org.renjin:gcc-runtime:jar:0.8.1906:runtime
[INFO] org.renjin:grDevices:jar:0.8.1906:runtime
[INFO] org.renjin:graphics:jar:0.8.1906:runtime
[INFO] org.renjin:methods:jar:0.8.1906:runtime
[INFO] org.renjin:renjin-appl:jar:0.8.1906:runtime
[INFO] org.renjin:renjin-core:jar:0.8.1906:runtime
[INFO] org.renjin:renjin-gnur-runtime:jar:0.8.1906:runtime
[INFO] org.renjin:renjin-script-engine:jar:0.8.1906:runtime
[INFO] org.renjin:stats:jar:0.8.1906:runtime
[INFO] org.renjin:utils:jar:0.8.1906:runtime
[INFO] org.scala-lang.modules:scala-xml_2.12:jar:1.0.6:runtime
[INFO] org.scala-lang:scala-compiler:jar:2.12.1:runtime
[INFO] org.scala-lang:scala-library:jar:2.12.1:runtime
[INFO] org.scala-lang:scala-reflect:jar:2.12.1:runtime
[INFO] org.scijava:jython-shaded:jar:2.7.0:runtime
[INFO] org.scijava:minimaven:jar:2.2.0:runtime
[INFO] org.scijava:parsington:jar:1.0.0:compile
[INFO] org.scijava:scijava-common:jar:2.62.1:compile
[INFO] org.scijava:scijava-plugins-commands:jar:0.2.2:runtime
[INFO] org.scijava:scijava-plugins-platforms:jar:0.2.1:runtime
[INFO] org.scijava:scijava-plugins-text-markdown:jar:0.1.2:runtime
[INFO] org.scijava:scijava-plugins-text-plain:jar:0.1.2:runtime
[INFO] org.scijava:scijava-ui-awt:jar:0.1.5:runtime
[INFO] org.scijava:scijava-ui-swing:jar:0.9.1:runtime
[INFO] org.scijava:script-editor:jar:0.1.2:runtime
[INFO] org.scijava:scripting-beanshell:jar:0.3.1:runtime
[INFO] org.scijava:scripting-clojure:jar:0.1.5:runtime
[INFO] org.scijava:scripting-groovy:jar:0.2.5:runtime
[INFO] org.scijava:scripting-java:jar:0.4.0:runtime
[INFO] org.scijava:scripting-javascript:jar:0.4.3:compile
[INFO] org.scijava:scripting-jruby:jar:0.2.4:runtime
[INFO] org.scijava:scripting-jython:jar:0.4.0:runtime
[INFO] org.scijava:scripting-renjin:jar:0.2.1:runtime
[INFO] org.scijava:scripting-scala:jar:0.2.0:runtime
[INFO] org.scijava:swing-checkbox-tree:jar:1.0.1:runtime
[INFO] org.tukaani:xz:jar:1.0:runtime
[INFO] org.yaml:snakeyaml:jar:1.13:runtime
[INFO] regexp:regexp:jar:1.3:runtime
In my idealized world, system admins would be able to deploy an application and define the "required" plugins, the "default" plugins (that user's could disable), and then allow each user the ability to include their own library of plugins. Everything the admin pushed would update at the admin's discretion, and the user would update their pieces when they choose. In my experience, almost no software offers this, so I don't expect ImageJ to end up there either.
You are certainly not the first sysadmin to want that. I have discussed similar things with @carandraug and others in the past as well. I share your vision, particularly about mixing the system-available plugins with user-chosen ones. The thing I am less clear on supporting would be the ability for users to remove default plugins they don't like—I am not sure how we would implement that, nor even whether it is really necessary for people to be happy. If those defaults were automagically unpacked into the userspace area, then it would work. But already, with ImageJ2 you can add whatever you want to the classpath, and plugins are picked up automatically from those entries. So achieving this vision is not, in principle, very difficult. We mainly just need to improve the ImageJ Updater to better support it. This could be as simple as using $IJ_HOME for plugin installation when that directory is writeable, and using $HOME/.imagej (or other configured user-space location) when it isn't.
I can't suggest it one way or another because I know nothing about it, sorry. I appreciate your no native code goal. I don't mean to be the guy that asks for difficult/impossible things without knowing what I am doing, but I guess I have here.
Not necessarily. You are posing requirements for your use case, and I am posing requirements as well. We discuss and find solutions which meet all requirements! Fun stuff.
I looked more closely at that Java service library I linked, but realized it is not open source, so we cannot use it. At the moment, I generally believe (but not very strongly) that a Windows service is probably not the way to go... happy to hear it argued otherwise though if you have a clear vision for how it would work, and how it might be achieved.
I am not a developer by training (nor terribly knowledable of developer-y things), but I would be happy to continue toward both ImageJ2 and Fiji Chocolatey packages. However, I am trying to be pretty strict about making my Chocolatey packages be system (i.e. alluser) installs.
Awesome. I honestly know next to nothing about Chocolatey, but I'm happy to help where I can, especially if you have questions about how ImageJ2 is structured, or about Maven, etc. I can also comment on the internals of the Updater (to an extent—I didn't write it, but I generally know how it works).
I'll poke at some things.
I would really like to make an automatic package. That would allow for very easy updates to the package as ImageJ2/Fiji is/are updated. As noted in your initial steps into a Chocolatey package, there are a couple things I would need though:
- a URL for a page that I can parse for the current version (and download link). I didn't even know what version I installed on my test VM until you told me to click on the status bar.
- a URL for current release notes
I will also need to figure out how to get around the cmd-line update issue to do some logging.
Finally, is there a need for an ImageJ2 AND a Fiji package?
Thanks.
I would really like to make an automatic package. That would allow for very easy updates to the package as ImageJ2/Fiji is/are updated.
Agreed 100%. We want the process to be fully automated.
As noted in your initial steps
Just want to clarify that it is @AnthonyMastrean who deserves the credit for what has been done so far. I have not had time to move things forward any further yet.
a URL for a page that I can parse for the current version
You can look in the remote Maven repository:
-
net/imagej/imagej/maven-metadata.xml:
<metadata>➡️<versioning>➡️<release>
Or you can ask Git:
git fetch --tags && git describe --tags $(git rev-list --tags --max-count=1)
a URL for current release notes
There are no release notes, sorry. I still haven't developed a reasonable process to assist with generating/maintaining them.
I will also need to figure out how to get around the cmd-line update issue to do some logging.
Hopefully the --dry-run trick I mentioned will work for now.
Ultimately, the standalone app package will be built by Maven, via mvn -Pdist from the imagej/imagej working copy. You can try it now if you like, but there are still kinks.
Finally, is there a need for an ImageJ2 AND a Fiji package?
Hmm, I dunno. Probably not. The vision is that any ImageJ installation can be turned into a Fiji one simply by enabling the Fiji update site. So a dedicated package is unnecessary. The main reason to have it would be social: some users, especially those in the EU, know the name "Fiji" better than "ImageJ" and might look for Fiji via a CLI search, and be disappointed when they don't find it.
You can look in the remote Maven repository:
I think it is friendlier to identify the currently downloading version on the front-end, "normal-user", Downloads page, but the Maven repository is suitable for automatic Chocolatey package update needs.
However, in testing, I'm a bit confused...
If I download what is offered on the download page, I would expect that to be the latest release. However, if I run ImageJ-win64.exe --update update, there is still a whole bunch that downloads (including the Fiji_Win64.exe file). Are those things that have changed since the release? According to the date in the XML, it's been less than a week since the version was released. Are the changes really that fast? Should updates after installation be done daily?
Also, even after the update, if I open Fiji/ImageJ and choose Help -> Update ImageJ..., I am offered to update that to 1.50k (from 1.5.0j). I thought the ImageJ-win64.exe --update update command was taking care of that? If I choose Help -> Update Fiji, I get a message that everything is up-to-date.
Hopefully the --dry-run trick I mentioned will work for now.
I haven't had much chance to play with it, but at first glance it looks confusing. :thinking:
The vision is that any ImageJ installation can be turned into a Fiji one simply by enabling the Fiji update site. So a dedicated package is unnecessary.
If ImageJ2 has a userbase of its own and if Fiji is considered a plugin, depending on how it can be installed (i.e. via command line), I can see an argument for a Fiji package with ImageJ2 as a dependency. A user/admin asking Chocolatey to install Fiji would get ImageJ2 installed as a pre-req followed by Fiji (as a plugin). A user asking for ImageJ2 would just get that. They could be updated independently too (although it could get tricky if ImageJ2 is updated and won't work with the installed version of Fiji).
Thanks. Sorry if I'm being a PITA.
I think it is friendlier to identify the currently downloading version on the front-end, "normal-user", Downloads page
I am not sure what you mean by "friendlier". That Downloads page will not be updated every time a new release is cut; it simply links to an auto-generated archive of the newest available version. Therefore, you cannot deduce what the current version is by scraping the Downloads page.
If I download what is offered on the download page, I would expect that to be the latest release.
It was. But not for the past 3 months. This job, which updates those archives, has been offline since we took down our Windows Jenkins node. And it cannot be brought back online until I find time to get the Windows part of the builds working with Appveyor, since we are not planning to redeploy our own Windows Jenkins node anymore.
According to the date in the XML, it's been less than a week since the version was released. Are the changes really that fast? Should updates after installation be done daily?
I would say ImageJ and/or Fiji components are, on average, updated in batches every 2-8 weeks. But it varies depending on various factors.
Also, even after the update, if I open Fiji/ImageJ and choose Help -> Update ImageJ..., I am offered to update that to 1.50k (from 1.5.0j).
The "Update ImageJ..." command updates ImageJ 1.x. The "Update..." command runs the ImageJ Updater which updates all components of ImageJ2, including ImageJ 1.x and its plugins. Very confusing, I know. Plans to change it, but no time—the usual story.
I haven't had much chance to play with it, but at first glance it looks confusing.
The flag --dry-run here causes the ImageJ launcher to print out the Java command line invocation which would most closely conform to what the launcher does internally to launch ImageJ. It gives you a more complex, but also more customizable, baseline from which you can customize your ImageJ executions. Please ask if you need additional help.
If ImageJ2 has a userbase of its own and if Fiji is considered a plugin, depending on how it can be installed (i.e. via command line), I can see an argument for a Fiji package with ImageJ2 as a dependency.
Fiji is an update site, meaning it is a suite of plugins for ImageJ. We also provide Fiji as a standalone distribution of ImageJ: it is just ImageJ plus all the plugins already installed.
My ultimate goal, probably still years away, is to get rid of the Fiji download and have only the base ImageJ download, which then asks the user what plugins they would like to install when it first starts. This will greatly simplify the Downloads, since all users will download and install the same thing initially.
Thanks. Sorry if I'm being a PITA.
No need to apologize. You are continuing the conversation, which is what needs to happen if we want to actually accomplish anything!
you cannot deduce what the current version is by scraping the Downloads page.
I know. I was suggesting that the average Joe might want to be able to see what the current release is, and it would be really helpful for them if the download page was updated each time there is a release. For example, the download table header could read "Download Fiji v2.0.0-rc-59 for your OS".
It was. But not for the past 3 months.
In testing, it looks like the NoJRE download is the most recent though. Is there a drawback to using the NoJRE version as long as I can ensure that the machine has JRE already? That would reduce bandwidth and storage needs.
The "Update..." command runs the ImageJ Updater which updates all components of ImageJ2, including ImageJ 1.x and its plugins.
That would be great, but that is not my experience. I downloaded/unzipped, ran the --update update command, started Fiji and when I choose the "Update ImageJ..." menu, I still am offered a newer version number.
Fiji is an update site
I assume you mean "update suite". How difficult is it currently to install (and uninstall) Fiji onto/into a basic install of ImageJ?
That would be great, but that is not my experience. I downloaded/unzipped, ran the --update update command, started Fiji and when I choose the "Update ImageJ..." menu, I still am offered a newer version number.
Argh. This Jenkins job is supposed to notice when the ImageJ 1.x release notes are updated. It then generates a commit in this clean ImageJ 1.x repository, which then triggers a deploy to the Maven repository via this job, which then uploads ImageJ 1.x to the ImageJ update site via this other job. In short: a lot of work happens under the hood when Wayne uploads a new release of IJ1 to his web site.
But it seems that the Jenkins URL polling is not working, since notes.html clearly changed but that Jenkins job did not fire. For now, I fired it manually, so net.imagej:ij:1.51k should soon exist and get uploaded to the ImageJ update site. But this will continue to be a problem with future releases... 😦
I assume you mean "update suite".
I mean Update Site.
How difficult is it currently to install (and uninstall) Fiji onto/into a basic install of ImageJ?
In theory:
- You have a vanilla ImageJ2 installation.
- You run Help ▶ Update..., click "Manage Update Sites", check the "Fiji" box, and click OK.
- You note that tons of stuff will be installed, and click OK.
- When it is done, you restart ImageJ, and it is now Fiji.
In practice, there is one snag: we are in the midst of transitioning to Java 8, and there is this third update site called "Java 8" which ships the latest versions of all core ImageJ2 and Fiji components. I want to separate them back out again, putting them back onto the respective ImageJ and Fiji update sites, but as soon as I do that, I will break all installations which are still using Java 6. I have a plan to fix that, but it requires some development time, which I have not yet had time to do. So for now, in practice, you must check the "Fiji" and "Java-8" boxes both, and make sure your installation is using Java 8, not Java 6, before doing so. Then your ImageJ will indeed transform into Fiji.
Ignorant question from a non-user: Why not offer a "clean" ImageJ2 that isn't bogged down with ImageJ1? What is the percentage of plugins/scripts that 1) rely on v1, 2) are used, 3) can't be rewritten/forked themselves, and 4) are on systems that also need v2 features?
Regarding the theoretical install of the Fiji update site: Is there any way to add/define a site when ImageJ isn't running so the install happens the next time ImageJ is started?
Why not offer a "clean" ImageJ2 that isn't bogged down with ImageJ1?
So, the net.imagej:imagej artifact actually declares net.imagej:imagej-legacy as optional, which means that if you add a dependency on net.imagej:imagej, you actually do not inherit ImageJ 1.x by default. You have to add it explicitly.
Alternately, you can also get a "clean" ImageJ2 by deleting/moving imagej-legacy, ij1-patcher and ij out of the jars folder of your installation.
That said, there are several reasons a "clean" ImageJ2 is not super useful to end users right now, such as:
-
The ImageJ2 data model is still incomplete. The support for ROIs in particular still needs work. We are actively doing this work, but it is not ready yet.
-
The ImageJ2 Swing user interface—which was modeled closely after the IJ1 interface—is only a prototype, and we do not have plans to continue developing it. ImageJ2 (as a library) already integrates with KNIME, OMERO and other tools. There is also an ImageJFX interface in development. It would be rather superfluous, and a lot of effort, for us to continue developing yet another UI at this time.
-
The documentation on how to do things the "ImageJ2 way" is still lacking. And ImageJ Ops is still under heavy development, not yet at a stable 1.0.0 release.
What is the percentage of plugins/scripts that 1) rely on v1, 2) are used, 3) can't be rewritten/forked themselves, and 4) are on systems that also need v2 features?
The best data I have right now to address those questions is this spreadsheet.
The vague hand-waving answers are:
- rely on v1
The vast majority.
- are used
Hundreds.
- can't be rewritten/forked themselves
Of course, most can be rewritten. And if you look at that spreadsheet above, you'll see that many have been. But it costs developer time. Our original goal was to rewrite everything and offer a new UI that looks like the old one, but is fully ImgLib2-driven under the hood. We got pretty far, but not far enough (yet) to satisfy the bulk of the existing use cases (e.g., Analyze Particles).
- are on systems that also need v2 features
Well, "need" is relative. We have been encouraging people to switch to parameterized scripts, for example, and that is a v2 feature. Users can mix in usage of IJ1 APIs to those scripts, creating a result that needs both.
Is there any way to add/define a site when ImageJ isn't running so the install happens the next time ImageJ is started?
You can perform all of the updater-related actions using the command line updater.
So, I'm toying with starting from vanilla ImageJ2 and adding the Fiji and Java-8 update sites after and seeing a few sticking points off the bat...
- The download for the "all platforms version of ImageJ" is apparently the 20160205 version.
- Unpacking and running with
--update updatedoesn't appear to do anything but replace the launchers and ImageJ1 jar. - Starting ImageJ gui, the version is 2.0.0-rc-43/1.51k
- Help ▶ Update... gives an "everything is up-to-date" message.
- I can add, list and edit, but I can't tell from the updater documentation how to enable a site from the existing sites list.
I'm starting to wonder if an automatic Chocolatey package for Fiji is going to be like a Jenga game with me as a vision-impaired player. :sunglasses:
I'll try to chime in with some answers on this one:
- The download for the "all platforms version of ImageJ" is apparently the 20160205 version.
- Help ▶ Update... gives an "everything is up-to-date" message.
This is because currently all new updates for ImageJ and Fiji are shipped via the Java-8 update site, as explained by @ctrueden above. It will change once the transition to Java 8 is completed.
- I can add, list and edit, but I can't tell from the updater documentation how to enable a site from the existing sites list.
As far as I can see, a newly added site should be active by default (see this line), but maybe that only happens when you also specify host and upload directory?!
This is because currently all new updates for ImageJ and Fiji are shipped via the Java-8 update site, as explained by @ctrueden above. It will change once the transition to Java 8 is completed.
Ah! Sorry, I didn't really understand. Does that mean that not only will ImageJ not update without the Java-8 site, but adding the Java-8 site will (partially?) install the Fiji components too? IOW, currently, there is no way to have a fully updated vanilla ImageJ2?
As far as I can see, a newly added site should be active by default
OK, but does a site need to be added when it already exists in the list but just isn't enabled? I think of adding as maybe telling ImageJ about a private site. That is distinct from telling ImageJ to start using a site that it already knows about like the Java-8 and Fiji sites that can be just selected in the GUI (and are visible in the XML).
Does that mean that not only will ImageJ not update without the Java-8 site, but adding the Java-8 site will (partially?) install the Fiji components too?
Yes, unfortunately.
IOW, currently, there is no way to have a fully updated vanilla ImageJ2?
Well, you can build a vanilla ImageJ2 from the latest version using Maven. It will not match what is on the update sites. The goal is to unify these two mechanisms in the future, such that the Maven dependencies declared for a given version of ImageJ match what is uploaded to the core ImageJ update site, always.
does a site need to be added when it already exists in the list but just isn't enabled?
IIRC, unfortunately, yes. There is no way via the CLI to simply say "turn on the Foo update site" when Foo is listed at https://imagej.net/List_of_update_sites. But you can simply give the URL explicitly. This allows for both of the use cases you stated, even if it is suboptimal.
A couple more questions about the updater... (I promise to stop soon.)
The <upload-directory> in the add-update-site option is the location of the local components, or a location on the remote site?
If it defines a local path for components, can it use variables to allow for a system-install with plugins going into user-space?
Edit: syntax error on my part hid an important part
The in the
add-update-siteoption is the location of the local components, or a location on the remote site?
First argument is the update site name, second is the update site URL. Here is an example of use.
You might also want to look at the bootstrap.js approach. While we will not continue to do things this way forever, it is currently how several automated processes work to build up ImageJ installations "from scratch" from the update sites, and it may be helpful for you here. You can see a couple of usage examples here and here.
If it defines a local path for components, can it use variables to allow for a system-install with plugins going into user-space?
The second argument is a path (typically a remote path, although I expect you could use file:///) to an ImageJ update site. This has a very particular structure, with db.xml.gz describing the contents, and the JAR files of all versions present and named by datestamp. It would not work to point to, say, another ImageJ installation locally.
Hopefully that makes sense?
I really want to make the automated tooling here better, and built on Maven (since we are 90+% of the way there already!). In the meantime, bootstrap.js is the most "official" solution we have for generating ImageJ installations.
I'm starting to wonder if an automatic Chocolatey package for Fiji is going to be like a Jenga game with me as a vision-impaired player. 😎
For now, I think we should focus on building a Chocolatey package for Fiji including the Java-8 site. In other words: a package that matches what you get currently when you download Fiji. However, we can make it work in a non-hardcoded way, such that when the Java-8 stuff gets untangled later, you can then start offering vanilla ImageJ2 super easily. Does that seem reasonable?
First argument is the update site name, second is the update site URL.
Doh! Part of my question disappeared. I edited the post to correct it. I was referring to one of the optional arguments.
I think we should focus on building a Chocolatey package for Fiji including the Java-8 site.
I just found this other issue, so I'm going to move this discussion over there.
Hi all, I have experience with NSIS installers having scripted builds that were then run on wine on a linux box. If we got a NSIS distro going, it would make windows users happy to have and installer that they are more familiar with. In the NSIS scripts you can check the permission level of the user doing the install, and therefore the not allow installation in c:\Programs if not an admin. The NSIS installer could be then distributed via Chocolatey where this is being used for wider distribution. This does not solve the issue of write permissions in C:\Programs (where institution wide installations would tend to end up). I think a valid approach is that suggested earlier in this discussions whereby the distro ships with a number of default plugins (which also get updated regularly as updates become available). Any additionally installed plugins could end up in a/the user's application support directory (${HOME}/.appName in Linux, ${HOME}/Library/Application Support/appName for MacOS and C:\Users\AppData\Roaming\appName in Windows) and thus would not be subject to write restrictions. This approach may also make it less likely to have to reinstall the app if plugin updates "screw up" the app. In V2 of the updater there is discussion of having an Eclipse like tracking of installation history to enable roll backs in case of updates gone wrong. With the approach outlined above one could always roll back to the default installation. Please let me know what you think of this approach. It is a pretty standard way of doing things and it may be worth considering.
This issue has been mentioned on Image.sc Forum. There might be relevant details there:
https://forum.image.sc/t/fiji-updater-problem-flimj-installation-error/47560/5
This issue has been mentioned on Image.sc Forum. There might be relevant details there:
https://forum.image.sc/t/fiji-update-error-fiji-app-db-xml-gz-tmp-access-is-denied/49008/2
Hi all, I have experience with NSIS installers having scripted builds that were then run on wine on a linux box. If we got a NSIS distro going, it would make windows users happy to have and installer that they are more familiar with. In the NSIS scripts you can check the permission level of the user doing the install, and therefore the not allow installation in c:\Programs if not an admin. The NSIS installer could be then distributed via Chocolatey where this is being used for wider distribution. This does not solve the issue of write permissions in C:\Programs (where institution wide installations would tend to end up). I think a valid approach is that suggested earlier in this discussions whereby the distro ships with a number of default plugins (which also get updated regularly as updates become available). Any additionally installed plugins could end up in a/the user's application support directory (${HOME}/.appName in Linux, ${HOME}/Library/Application Support/appName for MacOS and C:\Users\AppData\Roaming\appName in Windows) and thus would not be subject to write restrictions. This approach may also make it less likely to have to reinstall the app if plugin updates "screw up" the app. In V2 of the updater there is discussion of having an Eclipse like tracking of installation history to enable roll backs in case of updates gone wrong. With the approach outlined above one could always roll back to the default installation. Please let me know what you think of this approach. It is a pretty standard way of doing things and it may be worth considering.
I second this. Has there been any update on this? I only learnt about this discussion thread today. I've always wanted an installer and have been packaging my own using Inno Setup for Windows, because it's easier to deploy and manage software that way. It's pretty straightforward to script the installer to put different things into different directories, but I'm not sure if there are hard-coded relative links that may break things if we do that. I've always just put everything in the same directory even when installing into %ProgramFiles%. I don't have much experience with NSIS but I suppose it works in a similar way as Inno Setup. I would also be happy to help with packaging if there's demand for it.
I get a sense that there are different user requirements/preferences. Installing system-wide into "%ProgramFiles%" should be preferred in a managed environment. For instance, in a shared lab, my lab manager may not want any user to be able to change the installation on a shared PC, so updates will be scheduled/managed by the lab manager only. If you have the permission to install it into "%ProgramFiles%", you should also be able to update it; if you don't have the permission to update it, maybe you shouldn't mess with that installation anyway because it may impact other users. This is by design and for good reason. Users who want a more up-to-date copy could install it per-user into their own %AppData% directory, without impacting other users. Both requirements can be met with the same installer.
