3D geodesic distance transformation on MorphoLibJ


I am having a problem with the 3D version of the geodesic distance map of MorpholibJ. What I have is a 3D binary stack (~1600x1600x, 81 z levels) with a single white continuous mask on a black background and then another stack with similar dimensions where I have marked a single white dot as the marker. If this would work, I would import the 3D transformation to Imaris, where I could extract the distances of cells within the masked region to the marker position.

If I perform the 2D version of the transformation on one slice, it gives me exactly the result I want, but If I attempt the same with the whole stack using the 3D version, it just undergoes endless iterations. Things I have already tried are:

Thresholding both the marker and the mask image to make sure they are binary 8bit
Inverting the images (either produces a black stack with no map or endless iterations)
Making sure the continuous mask does not touch the edges of the image in xyz.
Resizing my stack (500x500px)
Test stack with a white cylinder in the middle (500x500x, 50 slices)
Independent versions of Fiji on separate computers

If on the other hand, I perform the 3D Chamfer distance map on my own stack on MorphoLibJ, it works with no problem. I am really starting to think, is there something wrong with the plugin. I tested 3D geodesic distance transformation half a year ago and I remember that it worked then. Does anyone have any ideas?



apparently there was no change in the plugin for many months, so there should be something with the image.
Can you provide access to a sampleimagesucha that we can reproduce?



I have uploaded smaller versions of the stacks (I never tried putting images here so I don´t know exactly how this works):


Original tif stack: download
Original tif file Marker: download

Thank you so much for your assistance.




I could not open your images…

I have just made a quick check with bat cochlea volume. Protocol:

  • open bat cochlea volume
  • create new image with same size as bat cochlea volume, filled with black, called ‘marker’
  • draw a single white point at x=100, y = 50, slice = 30
  • call 3D geodesic distance map using marker image as marker, and original mage as mask.
  • I obtained similar result to figure 7.6 page 65 of the MorphoLibJ manual (v1.4.0).

The bat cochlea volume is touching image edge, so this should not be a problem.
You may want to change the chamfer distance weights, but this should not change much the result.


I was able to open my images, but it was a bit strange… (right click->show information of the picture-> select -> save).

I also tested now with the cochlea volume that I found from https://imagej.nih.gov/ij/images/
It has now been running for about an hour on my laptop (the third computer I have now tested) and it´s going on iteration ~70 000 and this stack is very small! Do I need a “super computer” for this to work? You also mentioned I could change some parameters? Would this affect how long it iterates? Please could you give instructions for me to try?

Here is a screenshot of how it looks:

The real data I have is very large so if it takes ages to process these small test stacks, it really seems hopeless. Funny thing is, I remember testing this once on my data (~1500x1500px, ~80 slices) in the past and having it work.

Thank you so much for trying to help me.



I could download your images, and investigate a bit.

Actually, i could obtain a 3D geodesic distance map from your samples, in a rather shorttime (few seconds).
Some potential pitfalls:

  • it is necessary to have binary image -> the volume I have downloaded had some values different from 0 and 255, maybe due to downsampling
  • the images I have downloaded had 255 values for the background and 0 values for the foreground. The convention in MorphoLibJ is the contrary, so it was necessary to invert images.
  • I also changed the LUT to “gray”. This should not change result, but I am not totally sure about this…




I sort of figured out “the problem”… I had been always selecting the quasi-Euclidean and it turns out that´s the one that never produces a result. The others work with no problem… I guess this is exactly what you were explaining about the weights already earlier :joy: I have no idea how accurate these different methods are if I want to say something about real distances. I guess I have to test empirically (since I have no educated sense in this).

Here´s a nice map for your trouble, I truly am sorry for all the trouble! And a million thanks again!



OK, great you could obtain the result you wanted! Looks nice!

I’ll investigate why the Quasi-Euclidean metric does not work as expected…


I have a follow-up question regarding this topic. I have now the 3D Geodesic distance map of my structure relative to my reference point of interest. I figured out that the plugin does not consider the scale of the image (xy = 0.231µm/px and z = 1,041µm/px), but it calculates the distances directly based on pixels. So on the 32-bit map, one increment in intensity corresponds to one pixel distance in xy and z going directly to the right or down from the “origo” (where I place my marker).The distances would be straight forward to calculate just by multiplying the intensity value with the scale: intensity value 10 = 10 x 0.231µm, but this only holds true only for the xy, but not for the z. Can you see a solution for this? Of course, if there would be a way to factor the scale into the map (intensity would change differently in xy than z), that would be easiest?


yes, MorphoLibµJ does not takes into account spatial calibration when propating geodesic distances.

What I suggest is to perform a resampling of the original image (ideally before segmentation) to have same voxel size for the 3 directions. Then the result of the distance map can be converted to a physical distance.

Oh right, that would work! Thanks!


So just to report what happened with this project in case someone else attempts to do something similar in the future. I did not manage to figure out how to import the distance transformations from Fiji to Imaris (where I had the cells identified as spots) without screwing up the numbers in the map. Imaris did not accept the 32 bit map and I was only able to import if I converted it to 16-bit or 8-bit. Moreover, the map was imported directly how it looks on the display and not based on the real values (I don´t know how to explain this better). What I had to do instead was to export the coordinates of the cells to Fiji. I did this by exporting an image stack of the spots from Imaris to Fiji, then I binarized the stack using thresholding and identified the spots using 3D object counter. Then I used the 3D ROI manager to read the objects and place them on the distance map. I lost a small percentage of the cells by doing this and I do not currently know why, but I don´t think it will be a huge problem.


Hi, thanks for the feedback!

32-bits images are not always easy to manage depending on the software. It should be possible to perform geodesic distance transform using 16-bits integer (it is possible for the 2D version…). I’ll try to add an option for that in a future release.

Anyone know whether MorphoLibJ’s 3D transforms will at some point take spatial calibrations into consideration when calculating distance transforms?

I accept that the volume can be resliced to work around this problem, but that’s not ideal for large datasets. Thomas Boudier’s 3D Distance Map does take spatial resolution into consideration, but it also seems to set distances at the image boundaries to zero (and adjust the resultant distance map accordingly) and there doesn’t seem to be any way to modify this behaviour.