Moments of Inertia Issue

nwells · 2017-01-25 21:32:02 UTC

Hello, I have been working with CT scans from several skeletal populations and have recently run into a problem with the Moments of Inertia stage in the BoneJ plugin.

For some of the populations I have been working with, the following protocol has worked to attain cross sectional area measurements:

First a DICOM stack of the CT scans is imported into ImageJ and the scale of the image is recorded. The stack is then exported as a TIFF stack and opened in Avizo. As these scans contain multiple elements very close together, Avizo is used to crop each 3D model to just a singular bone of interest. This is done using the volume edit module and a padding value is added if necessary. The cropped element is then exported as a 2D TIFF stack and reopened in ImageJ. In ImageJ, the original scale from the DICOM file is entered and the image is made 8-bit. Then, using the BoneJ plugin, Moments of Inertia is run to properly orient the bone. The threshold is then adjusted, and slice geometry of the bone’s midslice is run to attain the cross sectional area.

For three out of approximately ten populations I have processed with this procedure it has worked without issue. However, for the remaining populations, the cropping of the image seems to be creating a problem. When I export the cropped image from Avizo and then open the image in ImageJ, the Moments of Inertia calculation produces a bone surrounded by a semi-opaque cloud, thus making CSA measurement impossible. I have tried multiple things to get rid of the ‘cloud,’ including adjusting the Brightness/Contrast settings of the original DICOM file in ImageJ before exporting it as a TIFF and cropping it in Avizo. This does get rid of the cloud around the bone, but when I run MOI on the cropped TIFF in ImageJ, the volume and mass outputs are about triple what would be expected. The same thing happens when I try the Subtract Background command in ImageJ.

Does anyone know how this could be fixed? I am told that the cloud surrounding the bone could be an issue stemming from the CT scanner’s original settings, thus making differentiation between the bone and the background poor. However, attempting to adjust the padding value has not fixed the issue. Is there a way to get rid of the cloud without interfering with the accuracy of the slice geometry output values?

Thanks!

mdoube · 2017-01-26 09:15:39 UTC

Would it be possible to attach some screenshots and ideally a bit of raw data to your post so we can help diagnose your problem?

It sounds like a thresholding issue, but hard to tell for sure without seeing the data.

nwells · 2017-01-26 16:25:35 UTC

Hi, unfortunately I cannot attach the raw data, but I have taken multiple screenshots of the entire process–let me know if there is any additional information that would be helpful!

In following this protocol I was able to get a slice geometry output, but I do not know if it is accurate since I do not know if moments of inertia is thrown off by the cloud. The lack of image contrast also made it difficult to estimate the midslice properly.

Thank you for your help!

Step 1. DICOM upload to ImageJ

Step 2. DICOM sequence options

Step 3. Checking DICOM scale

Step 4. Saving as TIFF from ImageJ

Step 5. Importing TIFFs to Avizo

Step 6. Avizo image read parameters

Step 7. TIFFs in Avizo

Step 8. Using volume edit to isolate humerus

Step 9. Cropped humerus exported as 2D TIFF

Step 10. Importing 2D TIFF stack into ImageJ

Step 11. Resetting scale in ImageJ

Step 12. Image adjusted from 16-bit to 8-bit

Step 13. Setup for moments of inertia command

Step 14. Resulting data

Step 15. Applying threshold

Step 16. Slice geometry with min gray made to match threshold

Step 17. Slice geometry output from approximate midslice

mdoube · 2017-01-26 17:17:58 UTC

Thanks for the images. You don’t need the Avizo steps. Are the medullary cavities filled on purpose?

I suggest the following:

At step 2 - drag 'n drop the whole DICOM directory onto ImageJ, which will ask you if it should open the whole stack. Click yes.

Instead of the rest of your process:

Draw a rectangular ROI around the bone you want to measure
Make sure that no other bones / other stuff are inside the ROI - if they are, delete them by setting their pixel value to -1000 HU (same pixel value as air). I do this by drawing a multi-point closed ROI and filling. It’s helpful to run Threshold while doing this (but don’t hit Apply), so you can see all the things that might get included by your threshold values. Sometimes I’ve had trouble getting ImageJ to fill with -1000 HU, in which case use this small macro which runs when you hit 9 on your keyboard:

macro "Fill with -1000 HU [9]" {
setColor(-1000);
fill();
}

Draw your rectangular ROI again, if you cleared it while deleting other bones
Run Slice Geometry
Set the min and max thresholds to sensible values - usually for bones in air something like 0 HU is fine, but you have to check for your images
Check to make sure the results make sense

nwells · 2017-01-26 19:51:36 UTC

Thank you so much! I do have a few more questions. So following your advice I was able to circumnavigate the issues introduced by Avizo. I did use the paintbrush at times to fill unwanted bone inclusions. The value for the resulting filled area was 0 (this was for an 8-bit image). Does this indicate that it will be counted as air? The measurements I arrived at seemed reasonable, but I wanted to doublecheck that previous analyses run on other elements using the protocol I originally outlined matched this new protocol. I chose an element and ran it first with my old protocol, then with the new. For the old protocol, the element was in a 2D TIFF stack format. The way you suggested it, I can just keep the file as a DICOM stack the whole time. I did find very slight differences in the moments of inertia and slice geometry calculations between the two protocols. I also saw that either the x or y centroid value increased quite a bit when just using the DICOM stack (it seems it increased by about 5 mm). Is this because they are different file formats? If so, which would you say is more reliable/accurate–the DICOM or the TIFF outputs?

mdoube · 2017-01-27 10:27:42 UTC

That’s what I’d recommend, unless you have to fill in bits to exclude them from your ROI, in which case it’s helpful to Save As… > TIFF. ImageJ saves DICOM series as TIFF stacks, with all the DICOM metadata in the TIFF header and the original pixel data and calibration intact.

Please don’t convert to 8-bit, you are losing data by doing that and it’s unnecessary.[quote=“nwells, post:5, topic:3892”]
The value for the resulting filled area was 0 (this was for an 8-bit image). Does this indicate that it will be counted as air?
[/quote]

That depends on what you set your min and max pixel values to in Slice Geometry, but typically, yes, 0 represents background (in your case air).

mdoube · 2017-01-27 10:38:25 UTC

I should add that the preprocessing for Slice Geometry and Moments of Inertia is the same: draw a rectangular ROI around your bone of interest, run the plugin and make sure you set the min and max pixel values to something sensible (like 0 HU).

For visualisation purposes it can be helpful to set the brightness & contrast so that your 16-bit pixel values are nicely displayed on screen. Quite often the default B&C is way too contrasty, so you can’t see the interesting contrast in your specimens.

One other reason to work on the DICOMs directly is that ImageJ is pretty good at getting the calibration right, so you don’t have to set pixel spacing or HU scaling. Sometimes (depending on the instrument), ImageJ struggles to get the slice spacing correct, so do check that.

nwells · 2017-01-30 15:25:31 UTC

Hi Michael, thanks again for your help. Unfortunately I must use 8 bit and the TIFF format in order to match a colleague’s protocol. I have now been doing the following:

I open the DICOM in ImageJ and save the stack as a TIFF image sequence. I then open the TIFF stack in ImageJ and set the image to 8 bit. I then use the rectangle tool to crop the central bone of interest. In most cases, there is some extraneous bone that is included after this. If I select the extraneous bone using an ROI and then fill it, this invariably leads to part of the bone of interest being filled as well. In order to avoid this I have been using the paintbrush tool and going slice by slice and filling in extraneous bone with a value of 0. Once all extraneous bone has been blacked out I run Moments of Inertia, find the midslice, and run slice geometry. I have done this several times to the same element, each time starting from scratch to see how well the trials agree with one another.

I have done three trials on one such bone and found that each time the output differs, especially in the case of the Moments of Inertia output. The cross sectional area values are fairly close (within 1 squared millimeter), but I am trying to figure out why this variability is occurring. Do you know what could be causing this? In addition, does variation in the Moments of Inertia output indicate that there may be an issue with the slice geometry output, even if all three cross sectional area values are quite close?