Optimising Ellipsoid Factor parameters and pre-processing for >90% fill percentage

I have been working through various combinations of parameter values and pre-processing for Ellipsoid Factor, in an attempt to achieve a fill percentage above 90%. This is on the advice I have read in this forum. Fill percentage >90% is stated to be an adequate representation of the bone in the sample.

I have altered the following values through the ranges at appropriate increments for each:
Skeleton points / ellipsoid from 1 to 5
Vectors from 100 to 300
Threshold lower value 50, 65, 70, 75, 80 and 89 (89 is the auto value). Upper threshold value always 255
Maximum drift 3 to 4
Iterations 100 to 300
Sampling increment 0.25 to 0.435 (the default value is 0.435)

The dataset I am working with is a 140 slice rat tibia trabecular VOI created in CTan. I use file>import>image sequence, and set it to 8-bit greyscale. I then threshold the dataset and select black background, b&w, prior to running the ellipsoid factor from the bonej menu.

My optimum parameters have been:
threshold 80
skeleton points / ellipse 1
vectors 200
drift 4
iterations 200
sampling increment 0.21
fill percentage = 83.2%

Another combination:
threshold 50
Skeleton points / ellipse 1
vectors 100
drift 4
iterations 100
sampling increment 0.3
fill percentage = 90.26%

  1. Surely lowering the threshold is not the way to go about this? Doesn’t that mean that I am including way too much soft tissue in the binarization, and so the sample isn’t representing the bone adequately?
  2. If I decide the reasoning in 1) is good and I need to keep the threshold around 89, how can I improve the fill percentage past ~83%? Is it by running pre-processing like despeckle, or an erosion then a dilation? I don’t know how much pre-processing is an acceptable amount to keep the sample adequately representing the bone.

Thanks for taking the time to read all this.

Flynn

1 Like

Hi Flynn,

  1. I would agree, you should decide on what is a good threshold to distinguish bone from non-bone before you do any analysis to it, be it EF, volume fraction, thickness or something else.
  2. In my experience, reducing the sampling increment even further (I have used ~0.03, but this is data dependent, and smaller sampling increments mean longer running times) could help, so I would try that if I were you - I would be interested to know how you get on. (Pre-processing is also a bit dependent on your data, I think a small amount of noise reduction is generally accepted, but can be a matter of contention - not sure - maybe you need some validation)

Hope this helps,
Alessandro

What is your pixel spacing : Tb.Th ratio? (how many pixels across an ‘average’ trabecula?)

Hi Michael,

I have just drawn a few straight lines on the binarized trabeculae (at threshold of 80) and pressed ctrl+m, with the units set to pixels. Average widths are around 6 pixels for Tb.Th.

Is this the correct way to measure it so I can answer your question?

Brilliant Alessandro thanks very much. I’ll try out the smaller sampling increment.

Hi @mdoube,

I have just drawn a few straight lines on the binarized trabeculae (at threshold of 80) and pressed ctrl+m, with the units set to pixels. Average widths are around 6 pixels for Tb.Th.

Is this the correct way to measure it so I can answer your question?

That’s a fair eyeballing method. You could also report the results of running Thickness (just Tb.Th, not Tb.Sp), and the pixel spacing from Image>Properties, for a more precise measurement.

Six pixels across a trabecula becomes a bit small for doing pixel-based estimates of size and shape, because your partial volume artefact (whether a pixel is counted as bone or marrow after segmentation) can lead to ± 1 pixel on either side. In practice that means that if 6 pixels Tb.Th occurs at a reasonable threshold, thresholding a bit low could give you 8 pixels and thresholding a bit high could give you 4 pixels. So you have a 33% uncertainty built in. It’s also harder to approximate smooth real surfaces with sparse dots (pixels), when the grid of dots becomes big relative to the changes in the real surface. EF is likely to struggle to fill the smaller features in your structure, so you might have to crank the settings a bit as @alessandrofelder has advised, to get a high filling %.

Ok @mdoube I’ll keep that in mind, thanks so much.

Is it possible / viable to reduce the skeleton points per ellipsoid below 1? My thinking is that if it was 0.5, there would be twice as many ellipsoids to fit, which would all but likely just reduce the fill percentage. Is this correct?

No, I don’t think that is possible, I am afraid.

I think I understand your thinking: It would result in two ellipsoids starting to grow at the centre of the same skeleton pixel. Not sure it would make much difference to the final EF result, but we haven’t planned or tested for this possibility I think.

Ok @alessandrofelder, thanks very much. I will get to work!

@mdoube @alessandrofelder my Tb.Th reading is higher than the 6 that I previously told you. It is actually ~10 pixels. Does this mean that I should set my maximum drift to 5 pixels so that an ellipse can be attempted across the full diameter of each trabeculae?

Interesting suggestion. The skip ratio is locked to being an integer, but you raise an interesting point, which is that the code will break if a fraction less than 0.5 is entered, because it will get rounded to 0. @alessandrofelder this is a bug and bad user input should be caught and handled: skipRatio has to be forced to be a positive integer >= 1.

In the new version soon to be released you will have the option to do multiple runs and average the results, which has a similar effect to what you describe. Several ellipsoids get seeded on the same point and the end result is averaged, so there are more chances for ellipsoids to fill small features. Not sure if it will dramatically increase your filling % in practice however.

OK, that’s much healthier than 6 pixels.

You can have a go with the drift setting. I haven’t played with it much. It’s mostly there to allow ellipsoids that exist in continuous space to jitter away from being centred strictly on the discrete, integer, pixel grid, to give a bit more latitude for optimisation. My worry with increasing drift to more than one pixel is that the main target which is to get bigger will override the requirement to estimate local geometry, and all the ellipsoids will drift towards larger features, meaning that smaller features will not contribute so much to the overall estimation of geometry.

Yes, the constraining of skeleton points/ellipsoid to integers >=1 is already handled in EF2.

1 Like

I haven’t seen much difference in mouse trabeculae at a similar resolution for settings of maxDrift=1 and maxDrift=5, but I agree that it is worth playing more with.

1 Like

Ok @mdoube @alessandrofelder, all of this is so helpful, thanks very much. Looking forward to trying out ellipsoid averaging (or whatever its going to be called) and I’ll try to keep the drift down at a reasonable level.

Flynn

1 Like

Hello @mdoube @alessandrofelder, I have my parameters nicely optimised now, and a fill percentage above 90%. Thanks again for all your help on this.

My last question is about the 3D viewer of the EF stack. To get this 3D model, I simply select the EF image stack once EF analysis has run, and then click plugins>3D viewer.

This 3D model is colour coded according to the EF of the biggest ellipse fitted at each point. I would like to have a colour gradient bar showing which colours represent which value of EF. For example, I think it would go from white (EF~1) to dark purple (EF~-1), I just can’t find the button to click to include a gradient bar like this.

Is this possible? How do I add this in to my coloured 3D model?

Flynn

1 Like

Cool, I am glad our advice helped!

I don’t know enough about the 3D Viewer to gauge whether it is possible to add a colour scale into it directly…

I think that @mdoube used ~the following for the EF publications:

  • in ImageJ, click File > New > Image
  • select something like these parameters and click OK:
    image
  • click Image > Lookup tables > Fire
  • save the image as a png and stick in next to a snapshot of your 3d render, with 1, -1 labels

Another way to go is to save your EF image stack and render it using e.g. ParaView

1 Like

Hi @alessandrofelder, that method works perfectly, thanks very much!

Flynn

1 Like