BoneJ2 usage questions

Thanks a lot for your answer @mdoube, and more generally thank you for the great work you’re doing with BoneJ.

I did give BoneJ2 a try, but considered that it was preferable for now to wait before ‘committing’ completely based the (probably simplistic) observation that the BoneJ2 website describes several tools as ‘work in progress’. The first tool one uses is usually ‘Optimise threshold’ (as binary images are required for most calculations). But this tool does not seem to be included yet.

Furthermore, I also tried to the new Anisotropy tool of BoneJ2 on one of my test stacks anisoPPP.tif (30.0 KB), which is basically ‘five simple trabeculae perfectly aligned positively along x, y, and z’. While BoneJ1’s routine yields a degree of anisotropy of almost 1, BoneJ2’s value is roughly 0.6 (whether or not the ‘Recommended minimum’ option is used). Furthermore, I did not see how to retrieve the direction of anisotropy in BoneJ2 (given as Eigen matrices in BoneJ1), which is a parameter of great interest to me.

Again, I’d like to warmly thank you @mdoube for your continuous effort with BoneJ!

All the best,


This command has been left out of BoneJ2 intentionally. All it was doing for most users was making a stack histogram and applying ImageJ’s built-in autothreshold to the histogram data. It was needed because the old autothresholder in ImageJ worked only on slice histograms, making it hard to get a consistent autothreshold for 3D images. ImageJ now has a stack histogram option in the threshold tool so users should use that instead. The other functionality in Optimise Threshold tried to minimise connectivity, but I’m not sure whether people understood that or really used it.

I had a look at this image and it is poorly suited to an anisotropy analysis. Anisotropy assumes that the whole stack is filled with the texture of interest. In your case, most of the image has a very even (i.e. isotropic) texture, because there are no background/foreground boundaries (it’s mostly all background). What to do in the case where there are no boundaries is tricky: essentially most of the line probes never hit anything so you get a long intercept length in most directions. Should a line probe that doesn’t hit any boundary count as infinitely long, or the actual tested length, or be ignored? Both of the algorithms will give weird results (with different flavours of weirdness due to implementation choices) because the input image doesn’t satisfy the assumption that the image is basically full of texture. The other problem with this image is that it is very small: try a test image of 256³ pixels, completely filled with texture, and see how you get on. @rimadoma is working on some improvements to the BoneJ2 implementation of Anisotropy: your feedback is valuable. Richard: do you think we could provide a user warning in the case that lots of line probes don’t hit boundaries?

1 Like

Thanks again for your answer and for looking into it,@mdoube.

Understood, thanks for the tip!

Maybe we should move this discussion to another more appropriate section of the forum? Anyways, I used my second favourite test stack, that I reduced at 256³.Cabossous-256.tif (16.0 MB). It is a real VOI (centre of humeral head of an armadillo), filled with trabeculae.
With BoneJ1 I get a degree of anisotropy of ca. 0.78. BoneJ2 yields ca. 0.35. Looking at the trabeculae, my expectation would be for the DA to be quite high (and mostly directed along Z).
Again, I´d strongly encourage re-implementing the option to have access to the eigen matrices, to retrieve the direction of the ellipsoid axes.
Another thing I realized running this test is that I am not able to save the Results table as usual. I know that this has changed now with a dedicated table. But when one wants to save this table, it´s automatically the stack window that is selected (this both on PC and Mac). I did not try yet to save the results directly running a command.

All the best,

What settings are you using for each of the versions? We made some improvements to Anisotropy that will be included in the next release. That will address your issues I believe. @alessandrofelder Just one more reason to cut a new release soon! Unfortunately I’m unable to test the development version of Anisotropy right now due to this nasty crash.

1 Like

@Viktorkopp: you just need to go into System preferences>Security, and allow the app to be opened (you’ll have to do this only once).

@mdoube: First I wanted to add something to one of my previous posts:

The direction of the main axis of the ellipsoid (associated with this DA) made sense (i.e., directed positively along x, y, and z). So I considered that even for this ill-fitted stack, the Anisotropy routine worked quite well.

  • BoneJ1: Auto mode, Record Eigens
  • BoneJ2: Recommanded minimum, showing radii

But because it’s hard to judge ‘by eye’ the anisotropy of a stack, I just created new test stacks according to your recommendations (256^3 pixels, full of texture). One with one simple direction along z –p256.tif (16.0 MB), one with a direction along x and z p-p256.tif (16.0 MB). The results:

  • BoneJ1: DA=0.99-1 in both cases; Direction (of main axis of the ellipsoid) according to the expectations (z and x and z, respectively).
  • BoneJ2: DA=0.74 and 0.35, respectively (directions unknown).

I hope that helps.

All the best,

Some kind of warning is a good idea. It’s easy enough to count the number of MIL vectors that didn’t intercept anything, but some thought has to be given to what “too few hits” means in practical terms. Let’s discuss the details on GitHub.

I could also bring back eigen vectors to the results like @Eli suggested


When directly running the command, you can click the results, and then copy everything with ctrl+a, ctrl+c.

Ale, you know scripting better than I do, how do you grab results from a macro / python when running e.g. BoneJ2 Anisotropy?

Yes, it is possible to grab (main and secondary) results tables programmatically in Python - an example of where I have done this can be found here - it can be helpful to automate things, but does require some scripting knowledge. Hope this helps!

Ok, thanks @rimadoma and @alessandrofelder
…using an ImageJ macro, one use to be able to grab the results of the ‘Results’ table simply with the getResult() function…I understand that this is not possible any more?


BoneJ2 doesn’t use the ‘Results’ table from ImageJ1 anymore, so the macro getResult() doesn’t do anything. It uses new style tables, which admittedly aren’t quite as good yet. Also BoneJ2 is meant to be used with modern Python scripts instead of the old macro language. In a Python script all the results of Anisotropy and other BoneJ2 are easily accessible.

I understand the choice. But imo that this is going to restrict accessibility. As you understood, I’m personally not fluent in Python and would therefore find it highly useful to keep compatibility with the ImageJ macro language…maybe I should look into Python, at least just enough to make a user-defined function that can grab BoneJ2 results :wink:


1 Like

It’s in bonej2/master already, but needs to be released.

1 Like

Zero is the most problematic, because if you get zero hits for a direction, what do you do with that vector? Should you count its total length (in which case you get the same intercept length as if there was one hit), or just remove it from the calculation? Another approach is to keep trying, making more probes in that direction until you get one hit, and then stopping. It would be expensive to do that but more accurate for sparse, or highly aligned, textures where there is a high chance of some directions not hitting any boundaries. @rimadoma we can chat more about it elsewhere: for the users it’s helpful to know that these implementation decisions exist, which affect their results.

Please update us with your efforts - it would be useful for other users to see.

Agreed. Let’s make a point of documenting these decisions on the ImageJ wiki.