Error thrown when using Ellipsoid Factor


I am using the Ellipsoid Factor a lot, and had no problem up until now. I have updated Fiji yesterday and suddenly Ellipsoid Factor doesn’t work anymore, I am able to select my parameters but then I get an Exception message:

(Fiji Is Just) ImageJ 2.0.0-rc-69/1.52p; Java 1.8.0_172 [64-bit]; Windows 10 10.0; 64MB of 5991MB (1%)
java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.NoSuchMethodError: net.imglib2.view.Views.translateInverse(Lnet/imglib2/RandomAccessibleInterval;[J)Lnet/imglib2/view/IntervalView;

	at net.imagej.legacy.LegacyService.runLegacyCompatibleCommand(
	at net.imagej.legacy.DefaultLegacyHooks.interceptRunPlugIn(
	at ij.IJ.runPlugIn(
	at ij.Executer.runCommand(

Caused by: java.util.concurrent.ExecutionException: java.lang.NoSuchMethodError: net.imglib2.view.Views.translateInverse(Lnet/imglib2/RandomAccessibleInterval;[J)Lnet/imglib2/view/IntervalView;
	at java.util.concurrent.FutureTask.get(
	at net.imagej.legacy.LegacyService.runLegacyCompatibleCommand(
	... 5 more

Caused by: java.lang.NoSuchMethodError: net.imglib2.view.Views.translateInverse(Lnet/imglib2/RandomAccessibleInterval;[J)Lnet/imglib2/view/IntervalView;
	at org.bonej.ops.skeletonize.FindRidgePoints.createRidge(
	at org.bonej.ops.skeletonize.FindRidgePoints.calculate(
	at org.bonej.ops.skeletonize.FindRidgePoints.calculate(
	at org.bonej.wrapperPlugins.EllipsoidFactorWrapper.getDistanceRidgePoints(
	at org.bonej.wrapperPlugins.EllipsoidFactorWrapper.runEllipsoidOptimisation(
	at org.scijava.thread.DefaultThreadService.lambda$wrap$2(
	at java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.util.concurrent.ThreadPoolExecutor$
	... 1 more

Exception.txt (2.7 KB)
Do you know what is wrong and how to fix it?

Thank you!

Thanks for the report.
Could you please send us the parameters you use (a screenshot of the dialog box would be OK), and some sample data so we can try to reproduce this exception?
Any ideas @alessandrofelder?

I tried using it with the three images from the BoneJ website (the Shrew, Emu and Synthetic images) which I had no problem with before yesterday. I tried running the Ellipsoid Factor on those 3 images with these parameters:

Thank you for your help


Thanks for flagging this - I can reproduce the problem on my laptop.

I think I know why the problem happens: BoneJ requires imglib with a version >5.8 to have the translateInverse method, but the Fiji updater decides to downgrade that to 5.6.3 for some reason. Not sure what the best way to fix this is.
We could revert to using imglib's Views.offset (which has been deprecated in favour of translateInverse for now?

Me too, on my workstation. I note that there were a few concurrent updates just now:

A polite message to the Fiji / imglib team informing them that their update downgrading stuff broke our stuff is probably the best way to go. @ctrueden @StephanPreibisch

Do/can we specify this in a pom.xml, and would it make a difference if we did?
Can we catch this kind of stuff in a test that can alert developers of other projects?

We don’t specify it, I am guessing there is a straight-forward way to do it, but would have to look it up.

I don’t have an answer to your second question. I don’t know.

I have narrowed down the problem to:

  • the Java-8 update site (i.e. where ImageJ updates itself from) has imglib2-5.6.3 as the latest version
  •;quick~imglib2 on the other hand (where I think BoneJ and other projects look for their dependencies) has versions up to imglib2-5.9.2 (that’s why we knew that Views.offset was deprecated and introduced the switch to Views.translateInverse in this commit.

that means that even if we specified it in the BoneJ POM, it might still get changed by updating from other sites, right?

That is about as far as my understanding goes - maybe someone else can help further (would be much appreciated):
In particular, I wonder:

  • why when installing BoneJ from source, we install imglib2-5.8.0 and not the latest on the maven.scijava, imglib2-5.9.2?
  • why there is a discrepancy between the update site and (I am sure there is a good reason for this, I just don’t know it!)
  • what the best practice for us BoneJ developers is to avoid these issues in the future?

Edit: There is no downgrading going on from the core sites. The issue is that BoneJ2 now extends pom-scijava 28, whereas Fiji still extends pom-scijava 27.0.1. And what’s served from the Java-8 update site is (mostly) congruent with the state of the Fiji master branch.

The immediate solution is to upload (i.e. shadow) the newer imglib2 version (and any other needed newer libraries!) to the BoneJ update site. I am doing this now for imglib2.


Thanks a lot @ctrueden!
Yes, that explains it.

So, I guess that means we should avoid BoneJ depending on newer versions of scijava than the latest Fiji in the future :thinking: if we want to keep BoneJ compatible with the latest Fiji.

I have now uploaded imglib2 5.8.0 to the BoneJ update site. Please update your Fiji, test it and report back how it goes.

Yes, the safest way forward is to keep the version of pom-scijava you extend the same as the one from Fiji. I am sorry I did not update Fiji to pom-scijava 28 yet. I have been working on pom-scijava 29, which includes many component updates, and plan to update Fiji to that ASAP after it’s released.

However, there are times when adopting a newer pom-scijava is really important, and I’d hate for the delays with Fiji to hold you back. You can always shadow newer versions of core libraries in this way, if you need—it’s just that it might conflict with other update sites in some scenarios.

Which leads me to my last suggestion: add the bonej artifacts to pom-scijava, so their versions are managed in the combined “mega-melt” melting-pot I’m developing. I have developed new tooling to validate that all versions of all components managed by pom-scijava do in fact work together at runtime. I’d love to include bonej in this mix. The benefit to you is that these sorts of skews would be caught much earlier, by Travis whenever pom-scijava’s master branch is updated. Let me know if you’re interested, and I can explain in more detail (in a new topic here, or on GitHub).


Thanks again @ctrueden - I have tested and that solves it for me.

@JPeladeau Hopefully the latest fix works for you too - would you mind updating your Fiji, checking and letting us know, please?

1 Like

Just checked and its fixed for me too. Thanks!

1 Like

Sounds good. We are in, please show us how. Thanks for your help @ctrueden.

1 Like

I am working toward pom-scijava 29.0.0 on a topic branch. I added a commit managing the bonej components:

I tried running a melting-pot with bonej included, but realized that the multi-module structure of the bonej repository currently confuses the script. I will work on enhancing the script to support it. Will keep you posted. But the TL;DR is: you don’t have to do anything. :smile:

Thanks for sorting it. If it helps, all the BoneJ modules have the same version number.

What are the implications for us in the future? We are doing quite rapid releases at the moment, so the user version is likely to change often - will we need to update the current release version somewhere?

In general, we will want to keep the property bonej.version declared in pom-scijava up-to-date with your releases. There are a couple of ways we can achieve that:

  1. You can file PRs against pom-scijava whenever you release a new version, which just bumps the number. This is what the Bio-Formats team does, as well as some others—e.g., here is a PR bumping the version of Sholl_Analysis.

  2. You can do nothing, and I will notice that a new version has come out, and do it myself every so often. The way I notice is via the page, which I built to let me see at a glance which of the SciJava component collection (i.e. the components managed in pom-scijava) have new versions, which have changes on master since last release, and other useful details.

The advantage of (1) is that your new version will get added into the mega-melt Travis check sooner.

The advantage of (2) is that you don’t have to do anything. :smile: But then we may not catch version skew between libraries quite so quickly, depending on the scenario.

The eventual deployment goal is for the core ImageJ and Fiji update sites to always match what’s on the master branches, with Travis uploading the code to the update sites automatically. This will help. But even with that happening, I don’t see a way around the fact that extensions of ImageJ and Fiji should extend the same version of pom-scijava that imagej and fiji themselves extend. But it’s late here and I’m tired, so I may have more thoughts tomorrow or in near future. In the meantime, hopefully the above makes some semblance of sense! :clown_face:

1 Like

We will do that, and add it to our release protocol. @rimadoma, please describe the effect of this integration in the BoneJ paper.

Noted. It seems dangerous to have multiple versions of the same jar floating around the repositories.


I’m running into this same issue now even though everything is up to date. imglib2 version is > 5.8 and all packages up-to-date. I even installed onto a computer I have never used FIJI & BoneJ on to determine if manual installs were causing issues and am running into the same issue with a fresh install.

Any recommendations?