Crack Analysis in 3D CT results with Fiji

I am recently starting a project of analyzing the cracks in 3D CT scans, but has completely no idea of how. My scanning result is a stack of tiff files. If possible, could anyone share me some of your experience with such analysis? Thanks a lot.

In general, what you are trying to do is known as segmentation: finding objects (in your case, cracks) in your image.

For a basic overview, check out the Segmentation page of the ImageJ wiki. It is worth trying @iarganda’s Trainable Weka Segmentation plugin in particular, since it is quite convenient to use, and often works very well.

Note that most segmentation routines in ImageJ are geared toward 2D, and most operate slicewise. One popular option for 3D segmentation is the 3D ImageJ Suite written by @ThomasBoudier.

1 Like


if you can provide some example images, potentially we can help you better.



1 Like

My sample is a cylindrical stone, and this image is a slice of the cross section. I want to quantify the cracks shown in the image in 3D, like the length, volume, etc. The full stack of the images are in this google drive link:
Thank you all for your help.

Good day,

in the provided JEPG-image I’m able to see a branching crack starting at the border at about 1 ‘o clock and branching not far from the center. The branches’ thickness is near the image resolution which might give rise to problems with their analysis.

I tried to download the stack but it is password protected.

I hope that the stack is not JEPG-compressed because the JEPG-artifacts in the provided image are severe.



1 Like

Thanks Herbie. I have updated the link to google drive.
The files are in .tif. Do you need it to be converted to jpeg?

1 Like


that link works and I found that what I previously judged as possible JPEG-artifacts is present in the TIF-image as well. I very much hope that the original data was not JPEG-compressed. Will say, I hope that you didn’t convert the TIF-images from JPEG-compressed ones. JPEG-images are not suited for scientific analyses and to simply change those to whatever other format doesn’t make them better …

In this sense I don’t understand: “Do you need it to be converted to jpeg?”

For example, for image cy_0615_B1_1051 there appears to be a chance to isolate the cracks by more or less simple means. Preprocessing by Median-filtering may help.




as respond to Trl request in older topic(Opening *.rec file) I must say that I have received images of my scanned sample (core drill of cracked concrete beam) just few days ago.
I have followed the advise by Ctrueden of using Trainable Weka Segmentation plugin, however I have run into some troubles:

  • First of all the images are very large which causes memory problems (I use 8gb ram, W7 64bit and increasing ImageJ memory limit doesn’t help),
    -The crack in the images is not that visible as in Trl sample.

To overcome memory problem I have run segmentation on a single image. To stop plugin from crashing I have used only one “Training feature” for segmentation (as was advised here: But the best I could segment was the sample and the surrounding air, which is a bit strange, because this can be achieved by simple Threshold.

I found that adjusting contrast and sharpening is cumbersome due to intensity differences between center of the sample and outer layers. Overall I feel that more sophisticated steps should be done before running segmentation, so that cracks in concrete would be more visible.

Here are the sample images (since they are large I have uploaded just 160 images out of 1200):

After some time of thinking I have made the following routine:

  1. Maybe this is not very scientific approach and it is not within open source idea, but I used Lightroom 6 to develop all tiff images for better contrast, sharpness, gradient exposure filters. I guess this is also possible with ImageJ, but with my skills this approach was much faster.

  2. I used ROI manager (Edit/Selection/Add to manager or CTR+t) to select 8 regions with Freehand selection tool on crack, each representing most common crack width and intensity section.

  3. After opening single image (not image sequence) I did:

  • Image/Dublicate (Ctrl+Shift+D)

  • selection of ROI from Manager table

    <img src="//" width="561" height="499">
  • Edit/Clear outside

    <img src="//" width="552" height="500">
  • Image/Adjust/Color Threshold

  • Process/Binary/Make binary (after this Analise particles with Show Mask option can be run to reduce noise)

    <img src="//" width="558" height="500">
  1. After getting thresholded images from all of ROI I did Image addition (Process/Image Calculator) to form one single image

Now the main problem in my case is that this has to be done at least 600 times, since I would like to make 3D view of the crack.

To make this process faster I did macro. It basically repeats same steps described above. To make it more robust I rename open image to “10” (so it would not interfere with Color Threshold macro automatically generated by pressing “Macro” button in “Threshold Color window”).
Also you can notice that I make dummy rectangle selection. I use this after finding out, that “Deselect” function in macro does’t work, which leaves yellow selection line on image. When applying Threshold in this state, whole image is being selected by red color (even if it is not visible after applying “Clear outside”). Only after click on white space, or by making selection in other place, the “Color Threshold” works where it is needed, on cropped ROI.

I would appreciate any comments and suggestions how to simplify or improve the crack detection for these thin crack and low contrast images as in my case.

Here is the macro:

open("C:\\Users\\your path here\\Image_xx.tif");

/////////////////////////////////                  ROI No.0
run("Duplicate...", "title=10-0");
roiManager("Select", 0);
setBackgroundColor(255, 255, 255);
run("Clear Outside");
makeRectangle(1428, 1458, 84, 130); /// Dummy selection

// Color Thresholder 2.0.0-rc-49/1.51d
// Autogenerated macro, single images only!
run("HSB Stack");
run("Convert Stack to Images");
for (i=0;i<3;i++){
  setThreshold(min[i], max[i]);
  run("Convert to Mask");
  if (filter[i]=="stop")  run("Invert");
imageCalculator("AND create", "0","1");
imageCalculator("AND create", "Result of 0","2");
for (i=0;i<3;i++){
selectWindow("Result of 0");
selectWindow("Result of Result of 0");
// Colour Thresholding-------------
//setThreshold(255, 255);
setOption("BlackBackground", false);

run("Make Binary");

/////////////////////////////////    similar for  ROI No.1,2,3,4,5,6 and 7

////////////////////////////  Summing all images into one

imageCalculator("Add create", "10-0","10-1");
imageCalculator("Add create", "10-2","10-3");
imageCalculator("Add create", "10-4","10-5");
imageCalculator("Add create", "10-6","10-7");

imageCalculator("Add create", "Result of 10-0","Result of 10-2");
selectWindow("Result of 10-0");
selectWindow("Result of 10-2");
imageCalculator("Add create", "Result of 10-4","Result of 10-6");
selectWindow("Result of 10-4");
selectWindow("Result of 10-6");
imageCalculator("Add create", "Result of Result of 10-0","Result of Result of 10-4");
selectWindow("Result of Result of 10-0");
selectWindow("Result of Result of 10-4");
1 Like


Currently i am also facing the same problem of crack length estimation in 3D using CT images. I like to know did you get some way out to solve this issue?

Don’t know if this topic is still alive but I could propose some solutions like this :

or this :

Let me know if you are still interested.



It seems that this data was generated by an XTek / Nikon ST225 instrument. If that is the case, the data was not post-processed correctly when the images were exported from the instrument software. The main problem with this dataset as far as I can see, is that it has not been corrected for the centre of rotation the proper way. That is the main reason your image quality is so poor. With better image quality it would be a lot easier to analyse the data. You can get a factor 100 better resolution if you know how to do the processing and export properly from the instrument software. The default parameters do not work well at all.

Hello @ENO. I would be interested in what you have done there.

Hey, How did you do that? this is so interesting


This is a quite old post and work for me :slight_smile:
I start computing binarization for crack area using a simple method (sorry I don’t remember exact used method)

I then compute a homemade distance map algorithm which allows to define some exclusion area (plug exterior)
A this step you can use ImageJ to get following rendering :

The following rendering :

is then obtained using blender and cgal shortest path algorithm.

Let me now if you are still interested by these results, I can try to find more information about all this…