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…