Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
One pixel line length

Subject: One pixel line length

From: Lars-Göran Nord

Date: 30 Jul, 2010 17:07:04

Message: 1 of 47

I have an binary image with several one pixel lines crossing each other (crack pattern) whose total length I'm trying to find.
I'm stuck! Any help would be greatly appreciated!
Lars

Subject: One pixel line length

From: Sean

Date: 30 Jul, 2010 17:15:07

Message: 2 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2v0ro$ln1$1@fred.mathworks.com>...
> I have an binary image with several one pixel lines crossing each other (crack pattern) whose total length I'm trying to find.
> I'm stuck! Any help would be greatly appreciated!
> Lars

Well, if they're one pixel wide couldn't you just sum them?
If this isn't what you meant, could you post a picture somewhere so we can have a better idea of what you meant?

Subject: One pixel line length

From: Lars-Göran Nord

Date: 30 Jul, 2010 17:38:04

Message: 3 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2v1ar$ljj$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2v0ro$ln1$1@fred.mathworks.com>...
> > I have an binary image with several one pixel lines crossing each other (crack pattern) whose total length I'm trying to find.
> > I'm stuck! Any help would be greatly appreciated!
> > Lars
>
> Well, if they're one pixel wide couldn't you just sum them?
> If this isn't what you meant, could you post a picture somewhere so we can have a better idea of what you meant?

Well I'm not sure it's that easy, the lines are not straight. I'm new to this so please tell me where to post my image.
Thanks,
Lars

Subject: One pixel line length

From: Sean

Date: 30 Jul, 2010 17:47:05

Message: 4 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2v2ls$i6v$1@fred.mathworks.com>...
> "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2v1ar$ljj$1@fred.mathworks.com>...
> > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2v0ro$ln1$1@fred.mathworks.com>...
> > > I have an binary image with several one pixel lines crossing each other (crack pattern) whose total length I'm trying to find.
> > > I'm stuck! Any help would be greatly appreciated!
> > > Lars
> >
> > Well, if they're one pixel wide couldn't you just sum them?
> > If this isn't what you meant, could you post a picture somewhere so we can have a better idea of what you meant?
>
> Well I'm not sure it's that easy, the lines are not straight. I'm new to this so please tell me where to post my image.
> Thanks,
> Lars

http://drop.io/
Is a good site for images.

Do you have image processing toolbox?

Subject: One pixel line length

From: Lars-Göran Nord

Date: 30 Jul, 2010 17:54:04

Message: 5 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2v36p$lvu$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2v2ls$i6v$1@fred.mathworks.com>...
> > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2v1ar$ljj$1@fred.mathworks.com>...
> > > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2v0ro$ln1$1@fred.mathworks.com>...
> > > > I have an binary image with several one pixel lines crossing each other (crack pattern) whose total length I'm trying to find.
> > > > I'm stuck! Any help would be greatly appreciated!
> > > > Lars
> > >
> > > Well, if they're one pixel wide couldn't you just sum them?
> > > If this isn't what you meant, could you post a picture somewhere so we can have a better idea of what you meant?
> >
> > Well I'm not sure it's that easy, the lines are not straight. I'm new to this so please tell me where to post my image.
> > Thanks,
> > Lars
>
> http://drop.io/
> Is a good site for images.
>
> Do you have image processing toolbox?

Yes I have the toolbox, and will drop the image in 30 min.

thanks again.

Subject: One pixel line length

From: Lars-Göran Nord

Date: 30 Jul, 2010 18:50:09

Message: 6 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2v3js$ija$1@fred.mathworks.com>...
> "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2v36p$lvu$1@fred.mathworks.com>...
> > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2v2ls$i6v$1@fred.mathworks.com>...
> > > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2v1ar$ljj$1@fred.mathworks.com>...
> > > > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2v0ro$ln1$1@fred.mathworks.com>...
> > > > > I have an binary image with several one pixel lines crossing each other (crack pattern) whose total length I'm trying to find.
> > > > > I'm stuck! Any help would be greatly appreciated!
> > > > > Lars
> > > >
> > > > Well, if they're one pixel wide couldn't you just sum them?
> > > > If this isn't what you meant, could you post a picture somewhere so we can have a better idea of what you meant?
> > >
> > > Well I'm not sure it's that easy, the lines are not straight. I'm new to this so please tell me where to post my image.
> > > Thanks,
> > > Lars
> >
> > http://drop.io/
> > Is a good site for images.
> >
> > Do you have image processing toolbox?
>
> Yes I have the toolbox, and will drop the image in 30 min.
>
> thanks again.

The image is now on drop, onepixelline@drop.io
This picture was made in photoshop and then processed in matlab, bwmorph(bw2, 'thin', inf);

Lars

Subject: One pixel line length

From: Sean

Date: 30 Jul, 2010 19:30:23

Message: 7 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2v6t1$kq1$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2v3js$ija$1@fred.mathworks.com>...
> > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2v36p$lvu$1@fred.mathworks.com>...
> > > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2v2ls$i6v$1@fred.mathworks.com>...
> > > > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2v1ar$ljj$1@fred.mathworks.com>...
> > > > > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2v0ro$ln1$1@fred.mathworks.com>...
> > > > > > I have an binary image with several one pixel lines crossing each other (crack pattern) whose total length I'm trying to find.
> > > > > > I'm stuck! Any help would be greatly appreciated!
> > > > > > Lars
> > > > >
> > > > > Well, if they're one pixel wide couldn't you just sum them?
> > > > > If this isn't what you meant, could you post a picture somewhere so we can have a better idea of what you meant?
> > > >
> > > > Well I'm not sure it's that easy, the lines are not straight. I'm new to this so please tell me where to post my image.
> > > > Thanks,
> > > > Lars
> > >
> > > http://drop.io/
> > > Is a good site for images.
> > >
> > > Do you have image processing toolbox?
> >
> > Yes I have the toolbox, and will drop the image in 30 min.
> >
> > thanks again.
>
> The image is now on drop, onepixelline@drop.io
> This picture was made in photoshop and then processed in matlab, bwmorph(bw2, 'thin', inf);
>
> Lars


Well you have to decide what exactly you want to do with this. How do you want to measure pixel line length?
Here's a few ideas to wrap your head around:
Should each individual pixel count as one unit? I.e. from opposing face to opposing face? Or should it be 3*sqrt(2) i.e. corner to corner?

If two pixels share a face should it be 2 units? I.e. opposite face to opposite face? Or should it be 1 unit center to center and the other units dependent on the next pixels off each end?
What I'm hinting at is some sort of Marching Cubes-esque algorithm.

If you just use as I mentioned above it will give you an over estimate but depending on your application that may not be a bad thing. What are these lines measuring and what are you doing with the results?

-Sean

Subject: One pixel line length

From: Sean

Date: 30 Jul, 2010 19:52:04

Message: 8 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message =
> If you just use
sum()
 as I mentioned above it will give you an over estimate but depending on your application that may not be a bad thing. What are these lines measuring and what are you doing with the results?
>
> -Sean
Typo, that sum() was kind of important to that sentence meaning anything.

Subject: One pixel line length

From: ImageAnalyst

Date: 30 Jul, 2010 21:13:49

Message: 9 of 47

On Jul 30, 2:50 pm, "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se>
wrote:
> The image is now on drop, onepixelline@drop.io
> This picture was made in photoshop and then processed in matlab, bwmorph(bw2, 'thin', inf);
>
> Lars-
------------------------------------------------------------------------------------------------------------------------------
Correction: Your image is at http://drop.io/onepixelline

You can use bwarea() if you want a different way of calculating area
than sum(). sum() sums up all the "set" pixels. bwarea() applies
weighting factors to adjust for the fact that pixels, in a triangle
say, may be considered to have partial areas in each pixel depending
on whether neighboring pixels are set. For example
0 1
1 1
Is the area of this 3? Or is it sqrt(2)? Or something different?

Subject: One pixel line length

From: Lars-Göran Nord

Date: 30 Jul, 2010 21:21:04

Message: 10 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2vah4$gtb$1@fred.mathworks.com>...
> "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message =
> > If you just use
> sum()
> as I mentioned above it will give you an over estimate but depending on your application that may not be a bad thing. What are these lines measuring and what are you doing with the results?
> >
> > -Sean
> Typo, that sum() was kind of important to that sentence meaning anything.

Very good comments, first of all the lines are measuring crack lengt (thermal fatigue of steel) and when I have the length of the one pixel lines (cracks) I will calculate an average crack width by dividing the total crack area from the original image with the length of cracks.
From the start I had an idea of finding pixels connected corner by corner and giving them the value sqrt(2) and all others connected face to face 1. I don't follow your 3*sqrt(2).

Subject: One pixel line length

From: Lars-Göran Nord

Date: 30 Jul, 2010 21:29:04

Message: 11 of 47

ImageAnalyst <imageanalyst@mailinator.com> wrote in message <dcc648d5-1c79-4c4f-b1de-53919ded9e61@g35g2000yqa.googlegroups.com>...
> On Jul 30, 2:50 pm, "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se>
> wrote:
> > The image is now on drop, onepixelline@drop.io
> > This picture was made in photoshop and then processed in matlab, bwmorph(bw2, 'thin', inf);
> >
> > Lars-
> ------------------------------------------------------------------------------------------------------------------------------
> Correction: Your image is at http://drop.io/onepixelline
>
> You can use bwarea() if you want a different way of calculating area
> than sum(). sum() sums up all the "set" pixels. bwarea() applies
> weighting factors to adjust for the fact that pixels, in a triangle
> say, may be considered to have partial areas in each pixel depending
> on whether neighboring pixels are set. For example
> 0 1
> 1 1
> Is the area of this 3? Or is it sqrt(2)? Or something different?

I think it's 2+sqrt(2), but I have to think it over one more time:-)

Thanks

Subject: One pixel line length

From: Lars-Göran Nord

Date: 30 Jul, 2010 21:42:04

Message: 12 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2vg70$mm4$1@fred.mathworks.com>...
> ImageAnalyst <imageanalyst@mailinator.com> wrote in message <dcc648d5-1c79-4c4f-b1de-53919ded9e61@g35g2000yqa.googlegroups.com>...
> > On Jul 30, 2:50 pm, "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se>
> > wrote:
> > > The image is now on drop, onepixelline@drop.io
> > > This picture was made in photoshop and then processed in matlab, bwmorph(bw2, 'thin', inf);
> > >
> > > Lars-
> > ------------------------------------------------------------------------------------------------------------------------------
> > Correction: Your image is at http://drop.io/onepixelline
> >
> > You can use bwarea() if you want a different way of calculating area
> > than sum(). sum() sums up all the "set" pixels. bwarea() applies
> > weighting factors to adjust for the fact that pixels, in a triangle
> > say, may be considered to have partial areas in each pixel depending
> > on whether neighboring pixels are set. For example
> > 0 1
> > 1 1
> > Is the area of this 3? Or is it sqrt(2)? Or something different?
>
> I think it's 2+sqrt(2), but I have to think it over one more time:-)
>
> Thanks

I have say I was wrong, 3 is right.

Subject: One pixel line length

From: Lars-Göran Nord

Date: 30 Jul, 2010 22:19:05

Message: 13 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2vgvc$bkb$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2vg70$mm4$1@fred.mathworks.com>...
> > ImageAnalyst <imageanalyst@mailinator.com> wrote in message <dcc648d5-1c79-4c4f-b1de-53919ded9e61@g35g2000yqa.googlegroups.com>...
> > > On Jul 30, 2:50 pm, "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se>
> > > wrote:
> > > > The image is now on drop, onepixelline@drop.io
> > > > This picture was made in photoshop and then processed in matlab, bwmorph(bw2, 'thin', inf);
> > > >
> > > > Lars-
> > > ------------------------------------------------------------------------------------------------------------------------------
> > > Correction: Your image is at http://drop.io/onepixelline
> > >
> > > You can use bwarea() if you want a different way of calculating area
> > > than sum(). sum() sums up all the "set" pixels. bwarea() applies
> > > weighting factors to adjust for the fact that pixels, in a triangle
> > > say, may be considered to have partial areas in each pixel depending
> > > on whether neighboring pixels are set. For example
> > > 0 1
> > > 1 1
> > > Is the area of this 3? Or is it sqrt(2)? Or something different?
> >
> > I think it's 2+sqrt(2), but I have to think it over one more time:-)
> >
> > Thanks
>
I have to ask if your example is at the crossing of the lines, this part is quite small and might be treated in different ways if it helps to simplifie things.
Lars
> I have say I was wrong, 3 is right.

Subject: One pixel line length

From: Sean

Date: 30 Jul, 2010 22:38:04

Message: 14 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2vfo0$mtp$1@fred.mathworks.com>...
> "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2vah4$gtb$1@fred.mathworks.com>...
> > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message =
> > > If you just use
> > sum()
> > as I mentioned above it will give you an over estimate but depending on your application that may not be a bad thing. What are these lines measuring and what are you doing with the results?
> > >
> > > -Sean
> > Typo, that sum() was kind of important to that sentence meaning anything.
>
> Very good comments, first of all the lines are measuring crack lengt (thermal fatigue of steel) and when I have the length of the one pixel lines (cracks) I will calculate an average crack width by dividing the total crack area from the original image with the length of cracks.
> From the start I had an idea of finding pixels connected corner by corner and giving them the value sqrt(2) and all others connected face to face 1. I don't follow your 3*sqrt(2).

First off, the 3*sqrt(2) was a typo; I meant just sqrt(2). (My typing has been failing me today, fortunately weekend is here!)

For calculating the area of the crack just summing the pixels of the skeleton will probably give you an accurate enough length. The crack isn't a geometric surface and thus trying to fit a triangulated surface is probably no more accurate than a pixel face one. Also, since you're using total area in pixels as your area it would make sense to me to not triangulate the line and then pollute that measurement with pixel area. I.e. you would want triangulated perimeter of the outside of the crack to stay consistent.

Those are just a few thoughts. We do a lot of work with crack propagation in concrete x-cmt images and that's usually what we use.

Have a great weekend; hopefully you can get away from this!

Subject: One pixel line length

From: ImageAnalyst

Date: 30 Jul, 2010 22:51:53

Message: 15 of 47

The image you uploaded looks pretty well binarized and skeletonized.
It also has many breaks in the skeleton. If it were me, I'd just sum
up all the pixels. I'd probably first try to get better lines with no
breaks in them. Looks like the original image was maybe like metallic
crystals and you then tried an edge detection and then thresholded and
skeletonized. You might get a better skeleton with a better pre-
process. Maybe the edges are weak in some areas due to noise or
whatever. Maybe you could try a bilateral filter (http://
homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/MANDUCHI1/
Bilateral_Filtering.html), or the mean shift algorithm to clean up the
image before running the edge filter.

If you share more information you'll get better suggestions.

Subject: One pixel line length

From: Walter Roberson

Date: 30 Jul, 2010 22:52:15

Message: 16 of 47

Lars-Göran Nord wrote:
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> <i2vg70$mm4$1@fred.mathworks.com>...
>> ImageAnalyst <imageanalyst@mailinator.com> wrote in message
>> For example
>> > 0 1
>> > 1 1
>> > Is the area of this 3? Or is it sqrt(2)? Or something different?

> I have say I was wrong, 3 is right.

Area of a triangle is 1/2 * base * height.

If we interpret the base and height here to each be 2, then we would have
1/2 * 2 * 2 which would be an area of 2.

If we interpret the 1's as marking pixel centers, then the base and height
would each be 1, leading to an area of 1/2 .


With regard to the length of the lines:

Unfortunately at that resolution I cannot see how "smooth" the lines are.
Would it be acceptable to approximate the length as if each line segment is
convex when viewed from one of its sides? If you do not have to deal with
zig-zags and figuring out the micro-level length, then I think it would likely
be _relatively_ easy to find piecewise straight-line approximations based upon
tangents to the curve that are extended to some tolerance from the actual line.

Subject: One pixel line length

From: Lars-Göran Nord

Date: 31 Jul, 2010 10:13:05

Message: 17 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2vk8c$7vp$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2vfo0$mtp$1@fred.mathworks.com>...
> > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2vah4$gtb$1@fred.mathworks.com>...
> > > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message =
> > > > If you just use
> > > sum()
> > > as I mentioned above it will give you an over estimate but depending on your application that may not be a bad thing. What are these lines measuring and what are you doing with the results?
> > > >
> > > > -Sean
> > > Typo, that sum() was kind of important to that sentence meaning anything.
> >
> > Very good comments, first of all the lines are measuring crack lengt (thermal fatigue of steel) and when I have the length of the one pixel lines (cracks) I will calculate an average crack width by dividing the total crack area from the original image with the length of cracks.
> > From the start I had an idea of finding pixels connected corner by corner and giving them the value sqrt(2) and all others connected face to face 1. I don't follow your 3*sqrt(2).
>
> First off, the 3*sqrt(2) was a typo; I meant just sqrt(2). (My typing has been failing me today, fortunately weekend is here!)
>
> For calculating the area of the crack just summing the pixels of the skeleton will probably give you an accurate enough length. The crack isn't a geometric surface and thus trying to fit a triangulated surface is probably no more accurate than a pixel face one. Also, since you're using total area in pixels as your area it would make sense to me to not triangulate the line and then pollute that measurement with pixel area. I.e. you would want triangulated perimeter of the outside of the crack to stay consistent.
>
> Those are just a few thoughts. We do a lot of work with crack propagation in concrete x-cmt images and that's usually what we use.
>
> Have a great weekend; hopefully you can get away from this!

>Thank you Sean,
>Interesting to hear you also have been hit with crack analysis problems. I can follow your area talk that I will use on the original image (none one pixel image) were the cracks have a width.
>Just summing the pixels to get the length from my one pixel line is not sinking in, if I have a 45 deg. line i.e. all pixels connected corner by corner then this will be a quite incorrect method to me?????
> Am I blinded by my method to use the one pixel line for getting my length, is there something in this perimeter I have missed?
>Tiff image and a crop of .fig is now on drop.

Lars

Subject: One pixel line length

From: Lars-Göran Nord

Date: 31 Jul, 2010 10:26:05

Message: 18 of 47

ImageAnalyst <imageanalyst@mailinator.com> wrote in message <fd388927-5180-480e-aedb-0f7efdc47061@d17g2000yqb.googlegroups.com>...
> The image you uploaded looks pretty well binarized and skeletonized.
> It also has many breaks in the skeleton. If it were me, I'd just sum
> up all the pixels. I'd probably first try to get better lines with no
> breaks in them. Looks like the original image was maybe like metallic
> crystals and you then tried an edge detection and then thresholded and
> skeletonized. You might get a better skeleton with a better pre-
> process. Maybe the edges are weak in some areas due to noise or
> whatever. Maybe you could try a bilateral filter (http://
> homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/MANDUCHI1/
> Bilateral_Filtering.html), or the mean shift algorithm to clean up the
> image before running the edge filter.
>
> If you share more information you'll get better suggestions.

> I have more images no one tiff and one crop of .fig

>There are no brakes in the lines but if this will happen I will try your hint, thanks.

> What I need in the end of all this is crack length, mean crack width and numbers of 3 and 4 crack intersections.

Thanks again.
Lars

Subject: One pixel line length

From: Lars-Göran Nord

Date: 31 Jul, 2010 12:29:07

Message: 19 of 47

Walter Roberson <roberson@hushmail.com> wrote in message <i2vlar$2g2$1@canopus.cc.umanitoba.ca>...
> Lars-Göran Nord wrote:
> > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> > <i2vg70$mm4$1@fred.mathworks.com>...
> >> ImageAnalyst <imageanalyst@mailinator.com> wrote in message
> >> For example
> >> > 0 1
> >> > 1 1
> >> > Is the area of this 3? Or is it sqrt(2)? Or something different?
>
> > I have say I was wrong, 3 is right.
>
> Area of a triangle is 1/2 * base * height.
>
> If we interpret the base and height here to each be 2, then we would have
> 1/2 * 2 * 2 which would be an area of 2.
>
> If we interpret the 1's as marking pixel centers, then the base and height
> would each be 1, leading to an area of 1/2 .
>
>
> With regard to the length of the lines:
>
> Unfortunately at that resolution I cannot see how "smooth" the lines are.
> Would it be acceptable to approximate the length as if each line segment is
> convex when viewed from one of its sides? If you do not have to deal with
> zig-zags and figuring out the micro-level length, then I think it would likely
> be _relatively_ easy to find piecewise straight-line approximations based upon
> tangents to the curve that are extended to some tolerance from the actual line.

>Thanks for your answer Walter
>I have uploaded more images now
> There are 3 things I need, crack (line) length, mean crack width and numbers of 3 and 4 "way crossings"
>Right now I'm looking into the perimeter use (as Sean meantioned) and might be able to use perimeter/2 as the total crack length and then area/length to get mean crack width.
  Lars

Subject: One pixel line length

From: Image Analyst

Date: 31 Jul, 2010 17:53:04

Message: 20 of 47

Lars:
Well we're getting a little more info, bit by bit. It seems you are looking at cracks in something (rather than metal grains). Maybe Sean can help you, expecially if you're also dealing with cracks in concrete.

The image you posted does have breaks. But it also has background so it looks like you saved the figure and uploaded it rather than saved the actual image - hence the background padding and breaks.

Perhaps the next bit of information you could supply would be the actual binary image (not the saved image of it displayed in a figure), the original grayscale image from which you derived the binary image, and the code you used to derive the binary image.

There is an option in bwmorph() that can find branchpoints in the skeleton. You will want to use that to count the number of crack intersections.

To get crack width, you will not want to skeletonize the cracks, which of course just reduces all binary cracks down to a single pixel width. You'll want to measure the original, un-skeletonized binary image.

Please don't start replying right after a > symbol of the prior post - that will just end up adding your message onto the prior one, so for example, Google will collapse all your text into the prior message since it thinks it's part of the same message, and I don't see it unless I expand it.

Subject: One pixel line length

From: Lars-Göran Nord

Date: 31 Jul, 2010 21:55:23

Message: 21 of 47

"Image Analyst" <imageanalyst@mailinator.com> wrote in message <i31nu0$b2l$1@fred.mathworks.com>...
> Lars:
> Well we're getting a little more info, bit by bit. It seems you are looking at cracks in something (rather than metal grains). Maybe Sean can help you, expecially if you're also dealing with cracks in concrete.
>
> The image you posted does have breaks. But it also has background so it looks like you saved the figure and uploaded it rather than saved the actual image - hence the background padding and breaks.
>
> Perhaps the next bit of information you could supply would be the actual binary image (not the saved image of it displayed in a figure), the original grayscale image from which you derived the binary image, and the code you used to derive the binary image.
>
> There is an option in bwmorph() that can find branchpoints in the skeleton. You will want to use that to count the number of crack intersections.
>
> To get crack width, you will not want to skeletonize the cracks, which of course just reduces all binary cracks down to a single pixel width. You'll want to measure the original, un-skeletonized binary image.
>
> Please don't start replying right after a > symbol of the prior post - that will just end up adding your message onto the prior one, so for example, Google will collapse all your text into the prior message since it thinks it's part of the same message, and I don't see it unless I expand it.


>well all very good comments I will try to shape up.
and my lines are a crack patter from thermal fatigue in steel.
Sorry about the fatal mistake regarding the images, I was in PhotoShop "world" when saving them.
I will also supply the original image, this image is a fake one made in PhotoShop at 9 pixels width. I still don't have any good real one for testing.
I made the skeleton just to try to get the length, area will be taken from original image, but I might be wrong in this way of treating the image.
images will be uploaded tomorrow.

Subject: One pixel line length

From: Lars-Göran Nord

Date: 1 Aug, 2010 20:58:05

Message: 22 of 47

"Image Analyst" <imageanalyst@mailinator.com> wrote in message <i31nu0$b2l$1@fred.mathworks.com>...
> Lars:
> Well we're getting a little more info, bit by bit. It seems you are looking at cracks in something (rather than metal grains). Maybe Sean can help you, expecially if you're also dealing with cracks in concrete.
>
> The image you posted does have breaks. But it also has background so it looks like you saved the figure and uploaded it rather than saved the actual image - hence the background padding and breaks.
>
> Perhaps the next bit of information you could supply would be the actual binary image (not the saved image of it displayed in a figure), the original grayscale image from which you derived the binary image, and the code you used to derive the binary image.
>
> There is an option in bwmorph() that can find branchpoints in the skeleton. You will want to use that to count the number of crack intersections.
>
> To get crack width, you will not want to skeletonize the cracks, which of course just reduces all binary cracks down to a single pixel width. You'll want to measure the original, un-skeletonized binary image.
>
> Please don't start replying right after a > symbol of the prior post - that will just end up adding your message onto the prior one, so for example, Google will collapse all your text into the prior message since it thinks it's part of the same message, and I don't see it unless I expand it.


>Is this way OK to answer?
>
>Images are now uploaded one tif that I did in photoshop so its not a real image of the cracks but quite close. For the skeletton I used bw3 = bwmorph(bw2, 'thin', inf);
>
>I hope this will help us both:-)
>
>Thanks for your interest.

Subject: One pixel line length

From: Lars-Göran Nord

Date: 1 Aug, 2010 21:34:05

Message: 23 of 47

Walter Roberson <roberson@hushmail.com> wrote in message <i2vlar$2g2$1@canopus.cc.umanitoba.ca>...
> Lars-Göran Nord wrote:
> > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> > <i2vg70$mm4$1@fred.mathworks.com>...
> >> ImageAnalyst <imageanalyst@mailinator.com> wrote in message
> >> For example
> >> > 0 1
> >> > 1 1
> >> > Is the area of this 3? Or is it sqrt(2)? Or something different?
>
> > I have say I was wrong, 3 is right.
>
> Area of a triangle is 1/2 * base * height.
>
> If we interpret the base and height here to each be 2, then we would have
> 1/2 * 2 * 2 which would be an area of 2.
>
> If we interpret the 1's as marking pixel centers, then the base and height
> would each be 1, leading to an area of 1/2 .
>
>
> With regard to the length of the lines:
>
> Unfortunately at that resolution I cannot see how "smooth" the lines are.
> Would it be acceptable to approximate the length as if each line segment is
> convex when viewed from one of its sides? If you do not have to deal with
> zig-zags and figuring out the micro-level length, then I think it would likely

>Hi Walter,

> Finally some "good" pictures are uploaded

>Thanks
Lars
> be _relatively_ easy to find piecewise straight-line approximations based upon
> tangents to the curve that are extended to some tolerance from the actual line.

Subject: One pixel line length

From: Lars-Göran Nord

Date: 1 Aug, 2010 21:55:05

Message: 24 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2vk8c$7vp$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i2vfo0$mtp$1@fred.mathworks.com>...
> > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2vah4$gtb$1@fred.mathworks.com>...
> > > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message =
> > > > If you just use
> > > sum()
> > > as I mentioned above it will give you an over estimate but depending on your application that may not be a bad thing. What are these lines measuring and what are you doing with the results?
> > > >
> > > > -Sean
> > > Typo, that sum() was kind of important to that sentence meaning anything.
> >
> > Very good comments, first of all the lines are measuring crack lengt (thermal fatigue of steel) and when I have the length of the one pixel lines (cracks) I will calculate an average crack width by dividing the total crack area from the original image with the length of cracks.
> > From the start I had an idea of finding pixels connected corner by corner and giving them the value sqrt(2) and all others connected face to face 1. I don't follow your 3*sqrt(2).
>
> First off, the 3*sqrt(2) was a typo; I meant just sqrt(2). (My typing has been failing me today, fortunately weekend is here!)
>
> For calculating the area of the crack just summing the pixels of the skeleton will probably give you an accurate enough length. The crack isn't a geometric surface and thus trying to fit a triangulated surface is probably no more accurate than a pixel face one. Also, since you're using total area in pixels as your area it would make sense to me to not triangulate the line and then pollute that measurement with pixel area. I.e. you would want triangulated perimeter of the outside of the crack to stay consistent.
>
> Those are just a few thoughts. We do a lot of work with crack propagation in concrete x-cmt images and that's usually what we use.
>
> Have a great weekend; hopefully you can get away from this!

>Had a great weekend at my summerhouse.

>I now have some good pictures uploaded. I made the skeletton just to try to find the crack length that way, a real image will look almost like the cr1.tif but that one is actually a fake made in photoshop (dont have any good real one yet) but thickness of cracks will be uneven in real life. Thats why I want to measure the length of that one pixel line and then get area from the "real" one and mean crack width like this (area/length).
>
>Your way might be a better one, but I dont quite follow you Sean!
>
>Thank you,
Lars

Subject: One pixel line length

From: ImageAnalyst

Date: 1 Aug, 2010 22:58:03

Message: 25 of 47

On Aug 1, 4:58 pm, "Lars-Göran Nord" <lars-goran.no...@uddeholm.se>
wrote:
> >Is this way OK to answer?
>
> >Images are now uploaded one tif that I did in photoshop so its not a real image of the cracks but quite close. For the skeletton I used  bw3 = bwmorph(bw2, 'thin', inf);
>
> >I hope this will help us both:-)
>
> >Thanks for your interest.
--------------------------------------------------------------------------
At least you're replying to the proper response so that's good, but
you're responses still have a > in front of them so they are being
considered part of the prior reply and don't show up - they're
collapsed.

Anyway, I did download your image and do a little bit. Your cracks
are pretty thin - 1.24 pixels wide. Here is the code I used:
IMPORTANT: YOU WILL HAVE TO JOIN ANY LINES THAT THE NEWS READER SPLITS
INTO TWO.
I summed the skeleton to get the total cracks length. Then I divided
the area by that to get the average width:


clc; % Clear the command window.
close all; % Close all figures (except those of imtool.)
imtool close all; % Close all imtool figures.
clear; % Erase all existing variables.
workspace; % Make sure the workspace panel is showing.
fontSize = 20;
% Change the current folder to the folder of this m-file.
% (The line of code below is from Brett Shoelson of The Mathworks.)
if(~isdeployed)
cd(fileparts(which(mfilename)));
end

% Read in a standard MATLAB gray scale demo image.
folder = 'C:\Documents and Settings\username\My Documents\Temporary
stuff';
baseFileName = 'cr1.tif';
fullFileName = fullfile(folder, baseFileName);
grayImage = imread(fullFileName);
% Get the dimensions of the image. numberOfColorBands should be = 1.
[rows columns numberOfColorBands] = size(grayImage);
if numberOfColorBands > 1
    % Convert to gray scale
    grayImage = rgb2gray(grayImage);
end
% Display the original gray scale image.
subplot(2, 2, 1);
imshow(grayImage, []);
title('Original Grayscale Image', 'FontSize', fontSize);
set(gcf, 'Position', get(0,'Screensize')); % Enlarge figure to full
screen.

binaryImage = grayImage < 100;
% Display the binary image.
subplot(2, 2, 2);
imshow(binaryImage, []);
title('Binarized Image', 'FontSize', fontSize);
binaryArea = sum(binaryImage(:))

skel = bwmorph(binaryImage, 'skel');
% Display the skeletonized image.
subplot(2, 2, 3);
imshow(skel, []);
title('Skeletonized Image', 'FontSize', fontSize);

% Calculate the length of all the cracks.
skelArea = sum(skel(:))

% Divide the area by the length to get the average width.
crackWidth = binaryArea / skelArea;

message = sprintf('Done!\nThe area of the cracks is %d\nThe length of
the cracks is %d\nThe average width of the cracks is %.2f', ...
    binaryArea, skelArea, crackWidth);
uiwait(msgbox(message));

Subject: One pixel line length

From: Lars-Göran Nord

Date: 2 Aug, 2010 01:50:23

Message: 26 of 47

ImageAnalyst <imageanalyst@mailinator.com> wrote in message <77b15315-fe1a-49a4-bec4-450751f27c09@l25g2000prn.googlegroups.com>...
> On Aug 1, 4:58 pm, "Lars-Göran Nord" <lars-goran.no...@uddeholm.se>
> wrote:
> > >Is this way OK to answer?
> >
> > >Images are now uploaded one tif that I did in photoshop so its not a real image of the cracks but quite close. For the skeletton I used  bw3 = bwmorph(bw2, 'thin', inf);
> >
> > >I hope this will help us both:-)
> >
> > >Thanks for your interest.
> --------------------------------------------------------------------------
> At least you're replying to the proper response so that's good, but
> you're responses still have a > in front of them so they are being
> considered part of the prior reply and don't show up - they're
> collapsed.
>
> Anyway, I did download your image and do a little bit. Your cracks
> are pretty thin - 1.24 pixels wide. Here is the code I used:
> IMPORTANT: YOU WILL HAVE TO JOIN ANY LINES THAT THE NEWS READER SPLITS
> INTO TWO.
> I summed the skeleton to get the total cracks length. Then I divided
> the area by that to get the average width:
>
>
> clc; % Clear the command window.
> close all; % Close all figures (except those of imtool.)
> imtool close all; % Close all imtool figures.
> clear; % Erase all existing variables.
> workspace; % Make sure the workspace panel is showing.
> fontSize = 20;
> % Change the current folder to the folder of this m-file.
> % (The line of code below is from Brett Shoelson of The Mathworks.)
> if(~isdeployed)
> cd(fileparts(which(mfilename)));
> end
>
> % Read in a standard MATLAB gray scale demo image.
> folder = 'C:\Documents and Settings\username\My Documents\Temporary
> stuff';
> baseFileName = 'cr1.tif';
> fullFileName = fullfile(folder, baseFileName);
> grayImage = imread(fullFileName);
> % Get the dimensions of the image. numberOfColorBands should be = 1.
> [rows columns numberOfColorBands] = size(grayImage);
> if numberOfColorBands > 1
> % Convert to gray scale
> grayImage = rgb2gray(grayImage);
> end
> % Display the original gray scale image.
> subplot(2, 2, 1);
> imshow(grayImage, []);
> title('Original Grayscale Image', 'FontSize', fontSize);
> set(gcf, 'Position', get(0,'Screensize')); % Enlarge figure to full
> screen.
>
> binaryImage = grayImage < 100;
> % Display the binary image.
> subplot(2, 2, 2);
> imshow(binaryImage, []);
> title('Binarized Image', 'FontSize', fontSize);
> binaryArea = sum(binaryImage(:))
>
> skel = bwmorph(binaryImage, 'skel');
> % Display the skeletonized image.
> subplot(2, 2, 3);
> imshow(skel, []);
> title('Skeletonized Image', 'FontSize', fontSize);
>
> % Calculate the length of all the cracks.
> skelArea = sum(skel(:))
>
> % Divide the area by the length to get the average width.
> crackWidth = binaryArea / skelArea;
>
> message = sprintf('Done!\nThe area of the cracks is %d\nThe length of
> the cracks is %d\nThe average width of the cracks is %.2f', ...
> binaryArea, skelArea, crackWidth);
> uiwait(msgbox(message));
>
>



Thanks a lot,

I have run the code and get the same answer as you, the lines should be 9 pixels wide as I used that in photoshop when I made this test image (cr1.tif)
Bedtime now will check more tomorrow.

Best regards,
Lars

Subject: One pixel line length

From: ImageAnalyst

Date: 2 Aug, 2010 02:06:06

Message: 27 of 47

On Aug 1, 9:50 pm, "Lars-Göran Nord" <lars-goran.no...@uddeholm.se>
wrote:
> Thanks a lot,
>
> I have run the code and get the same answer as you, the lines should be 9 pixels wide as I used that in photoshop when I made this test image (cr1.tif)
> Bedtime now will check more tomorrow.
>
> Best regards,
> Lars
-----------------------------------------------------------------------
Lars:
You're right - I forgot that the skel option of bwmorph doesn't
produce the full skeleton unless you add the 'inf' argument:
skel = bwmorph(binaryImage, 'skel', 'inf');

Now it will say 10.17 pixels as the average crack width.
Sorry about that, but it's correct now.
ImageAnalyst

Subject: One pixel line length

From: Sean

Date: 2 Aug, 2010 12:55:25

Message: 28 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i3588v$j5j$1@fred.mathworks.com>...
> ImageAnalyst <imageanalyst@mailinator.com> wrote in message <77b15315-fe1a-49a4-bec4-450751f27c09@l25g2000prn.googlegroups.com>...
> > On Aug 1, 4:58 pm, "Lars-Göran Nord" <lars-goran.no...@uddeholm.se>
> > wrote:
> > > >Is this way OK to answer?
> > >
> > > >Images are now uploaded one tif that I did in photoshop so its not a real image of the cracks but quite close. For the skeletton I used  bw3 = bwmorph(bw2, 'thin', inf);
> > >
> > > >I hope this will help us both:-)
> > >
> > > >Thanks for your interest.
> > --------------------------------------------------------------------------
> > At least you're replying to the proper response so that's good, but
> > you're responses still have a > in front of them so they are being
> > considered part of the prior reply and don't show up - they're
> > collapsed.
> >
> > Anyway, I did download your image and do a little bit. Your cracks
> > are pretty thin - 1.24 pixels wide. Here is the code I used:
> > IMPORTANT: YOU WILL HAVE TO JOIN ANY LINES THAT THE NEWS READER SPLITS
> > INTO TWO.
> > I summed the skeleton to get the total cracks length. Then I divided
> > the area by that to get the average width:
> >
> >
> > clc; % Clear the command window.
> > close all; % Close all figures (except those of imtool.)
> > imtool close all; % Close all imtool figures.
> > clear; % Erase all existing variables.
> > workspace; % Make sure the workspace panel is showing.
> > fontSize = 20;
> > % Change the current folder to the folder of this m-file.
> > % (The line of code below is from Brett Shoelson of The Mathworks.)
> > if(~isdeployed)
> > cd(fileparts(which(mfilename)));
> > end
> >
> > % Read in a standard MATLAB gray scale demo image.
> > folder = 'C:\Documents and Settings\username\My Documents\Temporary
> > stuff';
> > baseFileName = 'cr1.tif';
> > fullFileName = fullfile(folder, baseFileName);
> > grayImage = imread(fullFileName);
> > % Get the dimensions of the image. numberOfColorBands should be = 1.
> > [rows columns numberOfColorBands] = size(grayImage);
> > if numberOfColorBands > 1
> > % Convert to gray scale
> > grayImage = rgb2gray(grayImage);
> > end
> > % Display the original gray scale image.
> > subplot(2, 2, 1);
> > imshow(grayImage, []);
> > title('Original Grayscale Image', 'FontSize', fontSize);
> > set(gcf, 'Position', get(0,'Screensize')); % Enlarge figure to full
> > screen.
> >
> > binaryImage = grayImage < 100;
> > % Display the binary image.
> > subplot(2, 2, 2);
> > imshow(binaryImage, []);
> > title('Binarized Image', 'FontSize', fontSize);
> > binaryArea = sum(binaryImage(:))
> >
> > skel = bwmorph(binaryImage, 'skel');
> > % Display the skeletonized image.
> > subplot(2, 2, 3);
> > imshow(skel, []);
> > title('Skeletonized Image', 'FontSize', fontSize);
> >
> > % Calculate the length of all the cracks.
> > skelArea = sum(skel(:))
> >
> > % Divide the area by the length to get the average width.
> > crackWidth = binaryArea / skelArea;
> >
> > message = sprintf('Done!\nThe area of the cracks is %d\nThe length of
> > the cracks is %d\nThe average width of the cracks is %.2f', ...
> > binaryArea, skelArea, crackWidth);
> > uiwait(msgbox(message));
> >
> >
>
>
>
> Thanks a lot,
>
> I have run the code and get the same answer as you, the lines should be 9 pixels wide as I used that in photoshop when I made this test image (cr1.tif)
> Bedtime now will check more tomorrow.
>
> Best regards,
> Lars

Can you post the original non-binary crack image that you have? I think that will open up the options that you have.
Thanks

Subject: One pixel line length

From: Sean

Date: 2 Aug, 2010 13:01:06

Message: 29 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> >Just summing the pixels to get the length from my one pixel line is not sinking in, if I have a 45 deg. line i.e. all pixels connected corner by corner then this will be a quite incorrect method to me?????

It really depends on what your original image looks like. You could systematically calculate the line length finding: corner connected (45deg) pixels, face connected pixels, and boundary pixels (either edge of the image or end of a line). I think that we should look at your original images; however, and there is probably a better way to do it.

First and foremost, I don't know if you're just trying to set up a method for future use or strictly doing analysis on images you already have. Depending on how uniform your images are; if you change your acquisition protocol to get pre and post cracking images it would be a great tool in accurately identifying the cracks.

Subject: One pixel line length

From: Lars-Göran Nord

Date: 2 Aug, 2010 13:35:27

Message: 30 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i36fii$ktd$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> > >Just summing the pixels to get the length from my one pixel line is not sinking in, if I have a 45 deg. line i.e. all pixels connected corner by corner then this will be a quite incorrect method to me?????
>
> It really depends on what your original image looks like. You could systematically calculate the line length finding: corner connected (45deg) pixels, face connected pixels, and boundary pixels (either edge of the image or end of a line). I think that we should look at your original images; however, and there is probably a better way to do it.
>
> First and foremost, I don't know if you're just trying to set up a method for future use or strictly doing analysis on images you already have. Depending on how uniform your images are; if you change your acquisition protocol to get pre and post cracking images it would be a great tool in accurately identifying the cracks.


Sean

There is an tif image uploaded (cr1.tif) on drop this is the one I made in photoshop as a test image. The image is close to a real one, but its crack width is evan at 9 pixels normaly the width will vary. I check my sample at specific times and look at crack propagation, trying to compare length, mean width and number of branch points (3 and 4 "crossings").
Pictures will be taken in SEM and then analysed, I'm not sure if I'm allowed to have some other software at the computer running the SEM (scanning electron microscope). So it will probably be post processing of my images.
Not sure if that is what you ment??? At least you know my way of working now.

Regards,
Lars

Subject: One pixel line length

From: Sean

Date: 2 Aug, 2010 14:35:26

Message: 31 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message

> There is an tif image uploaded (cr1.tif) on drop this is the one I made in photoshop as a test image.
Oh sorry, I thought that 'binarized'

 The image is close to a real one, but its crack width is evan at 9 pixels normaly the width will vary. I check my sample at specific times and look at crack propagation, trying to compare length, mean width and number of branch points (3 and 4 "crossings").
> Pictures will be taken in SEM and then analysed, I'm not sure if I'm allowed to have some other software at the computer running the SEM (scanning electron microscope). So it will probably be post processing of my images.
> Not sure if that is what you ment??? At least you know my way of working now.

The image analysis will always be post-processing but what I was hoping for is that you could have a series of images, exactly as you have said, where there are different levels of crack propagation. If the camera and beam (?) are fixed, you should be able to measure the difference by a simple subtraction. I.e. the first image has no cracks; the second one has a little bit (total area would be the sum, average area we're still working on; number of crack sprouts is a difficult problem but is doable if you want it.) Then the next (3rd image) would subtract the 2nd image to see where new cracks have spouted and where certain cracks have expanded (or contracted). As far as the average area; I think using perimeter/2 could be dangerous; especially if the cracks become wider. If you imagine a perfect rectangle of size 3x2 and do the math it, you'll see why.

ImageAnalyst's way with the skeleton and then predefined lengths for different pixel connectivities is probably best.

Another way you could get length, depending on how much time you want to devote to this, would be to calculate the orientation at each point and then figure out how long the line segment through that pixel would be at that orientation. (You might want to hear someone else reassure me on that! :)
The advantage of calculating the orientation at each point is that it would help you later with calculating number of cracks, since there is a major change in orientation where crack sprouts diverge from the bigger cracks.

Subject: One pixel line length

From: ImageAnalyst

Date: 2 Aug, 2010 14:36:30

Message: 32 of 47

Lars, did you see the fix I made to the code that will let it now
report the proper crack width?

Subject: One pixel line length

From: Lars-Göran Nord

Date: 2 Aug, 2010 15:43:05

Message: 33 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i36l3e$l15$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
>
> > There is an tif image uploaded (cr1.tif) on drop this is the one I made in photoshop as a test image.
> Oh sorry, I thought that 'binarized'
>
> The image is close to a real one, but its crack width is evan at 9 pixels normaly the width will vary. I check my sample at specific times and look at crack propagation, trying to compare length, mean width and number of branch points (3 and 4 "crossings").
> > Pictures will be taken in SEM and then analysed, I'm not sure if I'm allowed to have some other software at the computer running the SEM (scanning electron microscope). So it will probably be post processing of my images.
> > Not sure if that is what you ment??? At least you know my way of working now.
>
> The image analysis will always be post-processing but what I was hoping for is that you could have a series of images, exactly as you have said, where there are different levels of crack propagation. If the camera and beam (?) are fixed, you should be able to measure the difference by a simple subtraction. I.e. the first image has no cracks; the second one has a little bit (total area would be the sum, average area we're still working on; number of crack sprouts is a difficult problem but is doable if you want it.) Then the next (3rd image) would subtract the 2nd image to see where new cracks have spouted and where certain cracks have expanded (or contracted). As far as the average area; I think using perimeter/2 could be dangerous; especially if the cracks become wider. If you imagine a perfect rectangle of size 3x2 and do the math it, you'll see why.
>
> ImageAnalyst's way with the skeleton and then predefined lengths for different pixel connectivities is probably best.
>
> Another way you could get length, depending on how much time you want to devote to this, would be to calculate the orientation at each point and then figure out how long the line segment through that pixel would be at that orientation. (You might want to hear someone else reassure me on that! :)
> The advantage of calculating the orientation at each point is that it would help you later with calculating number of cracks, since there is a major change in orientation where crack sprouts diverge from the bigger cracks.

I fully agree to your comments and analysing cracks as you mentioned is great.
Calculating the orientation looks like a great thing to do but your comment "(You might want to hear someone else reassure me on that! :) is that one regarding the very good function or about the loooong time involved:-)

Lars

Subject: One pixel line length

From: Lars-Göran Nord

Date: 2 Aug, 2010 15:49:09

Message: 34 of 47

ImageAnalyst <imageanalyst@mailinator.com> wrote in message <11aec9ea-536a-44c9-b3fd-7f5132cf773f@z34g2000pro.googlegroups.com>...
> Lars, did you see the fix I made to the code that will let it now
> report the proper crack width?

Yes I just tested itand got same as you, but I tested a single 45 deg. line made in photoshop and the line length calculated by bwarea get a smaller value the the pixel length fom photoshop.
As you mentioned before I think we have to put some weight on pixels connected corner by corner!

Thank you,
Lars

Subject: One pixel line length

From: Sean

Date: 2 Aug, 2010 16:15:29

Message: 35 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i36p29$e2f$1@fred.mathworks.com>...
> "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i36l3e$l15$1@fred.mathworks.com>...
> > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> >
> > > There is an tif image uploaded (cr1.tif) on drop this is the one I made in photoshop as a test image.
> > Oh sorry, I thought that 'binarized'
> >
> > The image is close to a real one, but its crack width is evan at 9 pixels normaly the width will vary. I check my sample at specific times and look at crack propagation, trying to compare length, mean width and number of branch points (3 and 4 "crossings").
> > > Pictures will be taken in SEM and then analysed, I'm not sure if I'm allowed to have some other software at the computer running the SEM (scanning electron microscope). So it will probably be post processing of my images.
> > > Not sure if that is what you ment??? At least you know my way of working now.
> >
> > The image analysis will always be post-processing but what I was hoping for is that you could have a series of images, exactly as you have said, where there are different levels of crack propagation. If the camera and beam (?) are fixed, you should be able to measure the difference by a simple subtraction. I.e. the first image has no cracks; the second one has a little bit (total area would be the sum, average area we're still working on; number of crack sprouts is a difficult problem but is doable if you want it.) Then the next (3rd image) would subtract the 2nd image to see where new cracks have spouted and where certain cracks have expanded (or contracted). As far as the average area; I think using perimeter/2 could be dangerous; especially if the cracks become wider. If you imagine a perfect rectangle of size 3x2 and do the math it, you'll see why.
> >
> > ImageAnalyst's way with the skeleton and then predefined lengths for different pixel connectivities is probably best.
> >
> > Another way you could get length, depending on how much time you want to devote to this, would be to calculate the orientation at each point and then figure out how long the line segment through that pixel would be at that orientation. (You might want to hear someone else reassure me on that! :)
> > The advantage of calculating the orientation at each point is that it would help you later with calculating number of cracks, since there is a major change in orientation where crack sprouts diverge from the bigger cracks.
>
> I fully agree to your comments and analysing cracks as you mentioned is great.
> Calculating the orientation looks like a great thing to do but your comment "(You might want to hear someone else reassure me on that! :) is that one regarding the very good function or about the loooong time involved:-)
>
> Lars

Hi Lars,

I just think that it would be good to hear a second opinion on the orientation as a means of finding length idea before you spend too much time on it. I've given it a little more thought and I think it would be accurate. Consider this: a pixel is a square with the origin in the bottom left corner and a pixel orientation i.e. the orientation, theta, that this pixel has relative to what's around it. A few examples:
-if theta is 45deg; distance = 1/cos(45)= sqrt(2)=1.414; diagonal
-if theta is 0deg from either the vertical or horizontal axis = 1/cos(0) = 1; one side length
-if theta is 35deg from either vertical or horizontal axis 1/cos(35);
So 1/cos(theta) with each theta being the smallest angle from _any_ horizontal or vertical axis (i.e. always <= 45deg) would give the traversal of a line across this pixel. Then the sum of these would be the length. These calculations would be run on your skeleton.

Using orientation to calculate sprouts (or to segment fibers, veins etc.) is pretty well documented. Though many "Number of crack" measurements are actually "Number of new objects" measurements. I.e. they calculate the number of objects created rather than the number of cracks. Thus a crack really only counts when it creates a new object. Just a few thoughts for you to toy with!

-Sean

Subject: One pixel line length

From: Lars-Göran Nord

Date: 2 Aug, 2010 22:29:05

Message: 36 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i36qv1$jm5$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i36p29$e2f$1@fred.mathworks.com>...
> > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i36l3e$l15$1@fred.mathworks.com>...
> > > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> > >
> > > > There is an tif image uploaded (cr1.tif) on drop this is the one I made in photoshop as a test image.
> > > Oh sorry, I thought that 'binarized'
> > >
> > > The image is close to a real one, but its crack width is evan at 9 pixels normaly the width will vary. I check my sample at specific times and look at crack propagation, trying to compare length, mean width and number of branch points (3 and 4 "crossings").
> > > > Pictures will be taken in SEM and then analysed, I'm not sure if I'm allowed to have some other software at the computer running the SEM (scanning electron microscope). So it will probably be post processing of my images.
> > > > Not sure if that is what you ment??? At least you know my way of working now.
> > >
> > > The image analysis will always be post-processing but what I was hoping for is that you could have a series of images, exactly as you have said, where there are different levels of crack propagation. If the camera and beam (?) are fixed, you should be able to measure the difference by a simple subtraction. I.e. the first image has no cracks; the second one has a little bit (total area would be the sum, average area we're still working on; number of crack sprouts is a difficult problem but is doable if you want it.) Then the next (3rd image) would subtract the 2nd image to see where new cracks have spouted and where certain cracks have expanded (or contracted). As far as the average area; I think using perimeter/2 could be dangerous; especially if the cracks become wider. If you imagine a perfect rectangle of size 3x2 and do the math it, you'll see why.
> > >
> > > ImageAnalyst's way with the skeleton and then predefined lengths for different pixel connectivities is probably best.
> > >
> > > Another way you could get length, depending on how much time you want to devote to this, would be to calculate the orientation at each point and then figure out how long the line segment through that pixel would be at that orientation. (You might want to hear someone else reassure me on that! :)
> > > The advantage of calculating the orientation at each point is that it would help you later with calculating number of cracks, since there is a major change in orientation where crack sprouts diverge from the bigger cracks.
> >
> > I fully agree to your comments and analysing cracks as you mentioned is great.
> > Calculating the orientation looks like a great thing to do but your comment "(You might want to hear someone else reassure me on that! :) is that one regarding the very good function or about the loooong time involved:-)
> >
> > Lars
>
> Hi Lars,
>
> I just think that it would be good to hear a second opinion on the orientation as a means of finding length idea before you spend too much time on it. I've given it a little more thought and I think it would be accurate. Consider this: a pixel is a square with the origin in the bottom left corner and a pixel orientation i.e. the orientation, theta, that this pixel has relative to what's around it. A few examples:
> -if theta is 45deg; distance = 1/cos(45)= sqrt(2)=1.414; diagonal
> -if theta is 0deg from either the vertical or horizontal axis = 1/cos(0) = 1; one side length
> -if theta is 35deg from either vertical or horizontal axis 1/cos(35);
> So 1/cos(theta) with each theta being the smallest angle from _any_ horizontal or vertical axis (i.e. always <= 45deg) would give the traversal of a line across this pixel. Then the sum of these would be the length. These calculations would be run on your skeleton.
>
> Using orientation to calculate sprouts (or to segment fibers, veins etc.) is pretty well documented. Though many "Number of crack" measurements are actually "Number of new objects" measurements. I.e. they calculate the number of objects created rather than the number of cracks. Thus a crack really only counts when it creates a new object. Just a few thoughts for you to toy with!
>
> -Sean

Hi Sean,
The "orientation" way is very tempting as it can be developed further as you mentioned, well to me it is the right way to go!
Well the crack talk is OK but to me crack width is also very important as its kind of a inderect measurement of crack depth in the steel. And at a specific crack depth you get total failure of the part.

Lars

Subject: One pixel line length

From: Lars-Göran Nord

Date: 2 Aug, 2010 22:42:04

Message: 37 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i36qv1$jm5$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i36p29$e2f$1@fred.mathworks.com>...
> > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i36l3e$l15$1@fred.mathworks.com>...
> > > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> > >
> > > > There is an tif image uploaded (cr1.tif) on drop this is the one I made in photoshop as a test image.
> > > Oh sorry, I thought that 'binarized'
> > >
> > > The image is close to a real one, but its crack width is evan at 9 pixels normaly the width will vary. I check my sample at specific times and look at crack propagation, trying to compare length, mean width and number of branch points (3 and 4 "crossings").
> > > > Pictures will be taken in SEM and then analysed, I'm not sure if I'm allowed to have some other software at the computer running the SEM (scanning electron microscope). So it will probably be post processing of my images.
> > > > Not sure if that is what you ment??? At least you know my way of working now.
> > >
> > > The image analysis will always be post-processing but what I was hoping for is that you could have a series of images, exactly as you have said, where there are different levels of crack propagation. If the camera and beam (?) are fixed, you should be able to measure the difference by a simple subtraction. I.e. the first image has no cracks; the second one has a little bit (total area would be the sum, average area we're still working on; number of crack sprouts is a difficult problem but is doable if you want it.) Then the next (3rd image) would subtract the 2nd image to see where new cracks have spouted and where certain cracks have expanded (or contracted). As far as the average area; I think using perimeter/2 could be dangerous; especially if the cracks become wider. If you imagine a perfect rectangle of size 3x2 and do the math it, you'll see why.
> > >
> > > ImageAnalyst's way with the skeleton and then predefined lengths for different pixel connectivities is probably best.
> > >
> > > Another way you could get length, depending on how much time you want to devote to this, would be to calculate the orientation at each point and then figure out how long the line segment through that pixel would be at that orientation. (You might want to hear someone else reassure me on that! :)
> > > The advantage of calculating the orientation at each point is that it would help you later with calculating number of cracks, since there is a major change in orientation where crack sprouts diverge from the bigger cracks.
> >
> > I fully agree to your comments and analysing cracks as you mentioned is great.
> > Calculating the orientation looks like a great thing to do but your comment "(You might want to hear someone else reassure me on that! :) is that one regarding the very good function or about the loooong time involved:-)
> >
> > Lars
>
> Hi Lars,
>
> I just think that it would be good to hear a second opinion on the orientation as a means of finding length idea before you spend too much time on it. I've given it a little more thought and I think it would be accurate. Consider this: a pixel is a square with the origin in the bottom left corner and a pixel orientation i.e. the orientation, theta, that this pixel has relative to what's around it. A few examples:
> -if theta is 45deg; distance = 1/cos(45)= sqrt(2)=1.414; diagonal
> -if theta is 0deg from either the vertical or horizontal axis = 1/cos(0) = 1; one side length
> -if theta is 35deg from either vertical or horizontal axis 1/cos(35);
> So 1/cos(theta) with each theta being the smallest angle from _any_ horizontal or vertical axis (i.e. always <= 45deg) would give the traversal of a line across this pixel. Then the sum of these would be the length. These calculations would be run on your skeleton.
>
> Using orientation to calculate sprouts (or to segment fibers, veins etc.) is pretty well documented. Though many "Number of crack" measurements are actually "Number of new objects" measurements. I.e. they calculate the number of objects created rather than the number of cracks. Thus a crack really only counts when it creates a new object. Just a few thoughts for you to toy with!
>
> -Sean

I have to ask one more thing, 35 deg ? then we must look at pixels further away then closest ones right!

Thanks,
Lars

Subject: One pixel line length

From: Sean

Date: 3 Aug, 2010 13:26:05

Message: 38 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i37hjs$nek$1@fred.mathworks.com>...
> "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i36qv1$jm5$1@fred.mathworks.com>...
> > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i36p29$e2f$1@fred.mathworks.com>...
> > > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i36l3e$l15$1@fred.mathworks.com>...
> > > > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> > > >
> > > > > There is an tif image uploaded (cr1.tif) on drop this is the one I made in photoshop as a test image.
> > > > Oh sorry, I thought that 'binarized'
> > > >
> > > > The image is close to a real one, but its crack width is evan at 9 pixels normaly the width will vary. I check my sample at specific times and look at crack propagation, trying to compare length, mean width and number of branch points (3 and 4 "crossings").
> > > > > Pictures will be taken in SEM and then analysed, I'm not sure if I'm allowed to have some other software at the computer running the SEM (scanning electron microscope). So it will probably be post processing of my images.
> > > > > Not sure if that is what you ment??? At least you know my way of working now.
> > > >
> > > > The image analysis will always be post-processing but what I was hoping for is that you could have a series of images, exactly as you have said, where there are different levels of crack propagation. If the camera and beam (?) are fixed, you should be able to measure the difference by a simple subtraction. I.e. the first image has no cracks; the second one has a little bit (total area would be the sum, average area we're still working on; number of crack sprouts is a difficult problem but is doable if you want it.) Then the next (3rd image) would subtract the 2nd image to see where new cracks have spouted and where certain cracks have expanded (or contracted). As far as the average area; I think using perimeter/2 could be dangerous; especially if the cracks become wider. If you imagine a perfect rectangle of size 3x2 and do the math it, you'll see why.
> > > >
> > > > ImageAnalyst's way with the skeleton and then predefined lengths for different pixel connectivities is probably best.
> > > >
> > > > Another way you could get length, depending on how much time you want to devote to this, would be to calculate the orientation at each point and then figure out how long the line segment through that pixel would be at that orientation. (You might want to hear someone else reassure me on that! :)
> > > > The advantage of calculating the orientation at each point is that it would help you later with calculating number of cracks, since there is a major change in orientation where crack sprouts diverge from the bigger cracks.
> > >
> > > I fully agree to your comments and analysing cracks as you mentioned is great.
> > > Calculating the orientation looks like a great thing to do but your comment "(You might want to hear someone else reassure me on that! :) is that one regarding the very good function or about the loooong time involved:-)
> > >
> > > Lars
> >
> > Hi Lars,
> >
> > I just think that it would be good to hear a second opinion on the orientation as a means of finding length idea before you spend too much time on it. I've given it a little more thought and I think it would be accurate. Consider this: a pixel is a square with the origin in the bottom left corner and a pixel orientation i.e. the orientation, theta, that this pixel has relative to what's around it. A few examples:
> > -if theta is 45deg; distance = 1/cos(45)= sqrt(2)=1.414; diagonal
> > -if theta is 0deg from either the vertical or horizontal axis = 1/cos(0) = 1; one side length
> > -if theta is 35deg from either vertical or horizontal axis 1/cos(35);
> > So 1/cos(theta) with each theta being the smallest angle from _any_ horizontal or vertical axis (i.e. always <= 45deg) would give the traversal of a line across this pixel. Then the sum of these would be the length. These calculations would be run on your skeleton.
> >
> > Using orientation to calculate sprouts (or to segment fibers, veins etc.) is pretty well documented. Though many "Number of crack" measurements are actually "Number of new objects" measurements. I.e. they calculate the number of objects created rather than the number of cracks. Thus a crack really only counts when it creates a new object. Just a few thoughts for you to toy with!
> >
> > -Sean
>
> I have to ask one more thing, 35 deg ? then we must look at pixels further away then closest ones right!
>
> Thanks,
> Lars

Yes. Consider this case:
%%% Philosophical Image
M = false(8); %Binary Image
M(5,4) = true;
M(4,4) = true;
M(3,5) = true;
M(2,5) = true;
M(6,3) = true;
M(7,3) = true;
imtool(M) %Look at image (zoom in)
%%%
Now, (I didn't realize this but it greatly simplifies your problem) since this is all 2-dimensional, you have the luxury of using the 'Orientation' option of regionprops(). I would, to start at least, use two pixels on each side. Here's a quick example of how that works:
%%%
CC = bwconncomp(M);
my_orientation = regionprops(CC,'Orientation');
%%%
%
%my_orientation = 1x1 struct
%my_orientation =
% Orientation: 65.0780
%Thus the angle you would use:
%90-my_orientation.Orientation
% ans = 24.9220
%length = 1/cosd(ans); %= 1.1027
%

Subject: One pixel line length

From: Lars-Göran Nord

Date: 3 Aug, 2010 13:54:05

Message: 39 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i395dd$a33$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i37hjs$nek$1@fred.mathworks.com>...
> > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i36qv1$jm5$1@fred.mathworks.com>...
> > > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i36p29$e2f$1@fred.mathworks.com>...
> > > > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i36l3e$l15$1@fred.mathworks.com>...
> > > > > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> > > > >
> > > > > > There is an tif image uploaded (cr1.tif) on drop this is the one I made in photoshop as a test image.
> > > > > Oh sorry, I thought that 'binarized'
> > > > >
> > > > > The image is close to a real one, but its crack width is evan at 9 pixels normaly the width will vary. I check my sample at specific times and look at crack propagation, trying to compare length, mean width and number of branch points (3 and 4 "crossings").
> > > > > > Pictures will be taken in SEM and then analysed, I'm not sure if I'm allowed to have some other software at the computer running the SEM (scanning electron microscope). So it will probably be post processing of my images.
> > > > > > Not sure if that is what you ment??? At least you know my way of working now.
> > > > >
> > > > > The image analysis will always be post-processing but what I was hoping for is that you could have a series of images, exactly as you have said, where there are different levels of crack propagation. If the camera and beam (?) are fixed, you should be able to measure the difference by a simple subtraction. I.e. the first image has no cracks; the second one has a little bit (total area would be the sum, average area we're still working on; number of crack sprouts is a difficult problem but is doable if you want it.) Then the next (3rd image) would subtract the 2nd image to see where new cracks have spouted and where certain cracks have expanded (or contracted). As far as the average area; I think using perimeter/2 could be dangerous; especially if the cracks become wider. If you imagine a perfect rectangle of size 3x2 and do the math it, you'll see why.
> > > > >
> > > > > ImageAnalyst's way with the skeleton and then predefined lengths for different pixel connectivities is probably best.
> > > > >
> > > > > Another way you could get length, depending on how much time you want to devote to this, would be to calculate the orientation at each point and then figure out how long the line segment through that pixel would be at that orientation. (You might want to hear someone else reassure me on that! :)
> > > > > The advantage of calculating the orientation at each point is that it would help you later with calculating number of cracks, since there is a major change in orientation where crack sprouts diverge from the bigger cracks.
> > > >
> > > > I fully agree to your comments and analysing cracks as you mentioned is great.
> > > > Calculating the orientation looks like a great thing to do but your comment "(You might want to hear someone else reassure me on that! :) is that one regarding the very good function or about the loooong time involved:-)
> > > >
> > > > Lars
> > >
> > > Hi Lars,
> > >
> > > I just think that it would be good to hear a second opinion on the orientation as a means of finding length idea before you spend too much time on it. I've given it a little more thought and I think it would be accurate. Consider this: a pixel is a square with the origin in the bottom left corner and a pixel orientation i.e. the orientation, theta, that this pixel has relative to what's around it. A few examples:
> > > -if theta is 45deg; distance = 1/cos(45)= sqrt(2)=1.414; diagonal
> > > -if theta is 0deg from either the vertical or horizontal axis = 1/cos(0) = 1; one side length
> > > -if theta is 35deg from either vertical or horizontal axis 1/cos(35);
> > > So 1/cos(theta) with each theta being the smallest angle from _any_ horizontal or vertical axis (i.e. always <= 45deg) would give the traversal of a line across this pixel. Then the sum of these would be the length. These calculations would be run on your skeleton.
> > >
> > > Using orientation to calculate sprouts (or to segment fibers, veins etc.) is pretty well documented. Though many "Number of crack" measurements are actually "Number of new objects" measurements. I.e. they calculate the number of objects created rather than the number of cracks. Thus a crack really only counts when it creates a new object. Just a few thoughts for you to toy with!
> > >
> > > -Sean
> >
> > I have to ask one more thing, 35 deg ? then we must look at pixels further away then closest ones right!
> >
> > Thanks,
> > Lars
>
> Yes. Consider this case:
> %%% Philosophical Image
> M = false(8); %Binary Image
> M(5,4) = true;
> M(4,4) = true;
> M(3,5) = true;
> M(2,5) = true;
> M(6,3) = true;
> M(7,3) = true;
> imtool(M) %Look at image (zoom in)
> %%%
> Now, (I didn't realize this but it greatly simplifies your problem) since this is all 2-dimensional, you have the luxury of using the 'Orientation' option of regionprops(). I would, to start at least, use two pixels on each side. Here's a quick example of how that works:
> %%%
> CC = bwconncomp(M);
> my_orientation = regionprops(CC,'Orientation');
> %%%
> %
> %my_orientation = 1x1 struct
> %my_orientation =
> % Orientation: 65.0780
> %Thus the angle you would use:
> %90-my_orientation.Orientation
> % ans = 24.9220
> %length = 1/cosd(ans); %= 1.1027
> %


Thank you Sean,

I will look deeper into this this evening, as I'm not an expert in this it takes some time for me to figure it all out:-)
Do you think I can solve all this with some help:-) I have to tell my boss this monday if its possible or not. Othervise they will outsorce the whole thing, and I really dont like that at all. And the pleasure of success is aalso very sweet:-)

Thanks again,
Lars

Subject: One pixel line length

From: Sean

Date: 3 Aug, 2010 17:44:05

Message: 40 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> Thank you Sean,
>
> I will look deeper into this this evening, as I'm not an expert in this it takes some time for me to figure it all out:-)
> Do you think I can solve all this with some help:-) I have to tell my boss this monday if its possible or not. Othervise they will outsorce the whole thing, and I really dont like that at all. And the pleasure of success is aalso very sweet:-)
>
> Thanks again,
> Lars

You're welcome!

It's definitely doable and I think you're close to the solution. The programming aspects of this shouldn't be too hard as you have the aid of the Image Processing Toolbox.

Global approach:
-Create the skeleton with the aid of Image Analyst's example
-Calculate the orientation at each point on the skeleton using the bwconncomp, regionprops functions.
-To get length across pixel use the approach I gave you from above (total line length).
-To get max crack width: at each skeleton point calculate the angle orthogonal to that point's orientation. Using this orientation figure out how many point lie along a line drawn at this angle. Use the cos()^-1 formula to get this width too. The only time this would falter would be at intersections.

%%%
%Here is the code to do the first 3 steps in one shot. I think you'll like the results!
%%%
%
%SCd 08/03/2010
%% Load and Binarize
I = imread('/Users/Userx/Downloads/cr1.tif');
I = I(:,:,1) < 52; %Binarize
I = padarray(I,[2 2],false,'both'); %Pad the array for later use
%% ImageAnalyst's Skeleton
 
skel = bwmorph(I, 'skel',inf);
% Display the skeletonized image.
imtool(skel);
 
% Calculate total crask
binaryArea = sum(I(:));
 
% Calculate the length of all the cracks.
skelArea = sum(skel(:));
 
% Divide the area by the length to get the average width.
mean_crackWidth1 = binaryArea / skelArea
 
%% Get Orientation at each point
 
my_orientations = zeros(size(I)); %Preallocate
[r c] = find(skel); %[row col] indices of points on skel
%Note: This is why we padded earlier:
% all r,c are greater>=3 and <= size(dim) -2
 
%Go to each point and calculate orientation
for ii = 1:length(r)
    %Extract all pixels within the 5x5 window surrounding our point
    SKpart = skel((r(ii)-2):(r(ii)+2),(c(ii)-2):(c(ii)+2));
    
    %Connected components analysis, 8 connectivity (we care about corners!)
    CC =bwconncomp(SKpart,8);
    
    %Get orientation.
    RP = regionprops(CC,'Orientation');
    
    %Save the orientation. This may need modified if there are multiple
    %Orientations returned in the even of more than one object
    my_orientations(r(ii),c(ii)) = RP.Orientation;
end
 
%Sign doesn't matter
length_orientations = abs(my_orientations);
 
%Get angle closest to any axis
length_orientations(length_orientations>45) = 90 - length_orientations(length_orientations>45);
 
%Get length, preserving only those in the skeleton
eachLength = 1./cosd(length_orientations).*double(skel);
skelLength = sum(eachLength(:));
 
%Crack area divided by length
mean_crackWidth2 = binaryArea/skelLength
 
%Compare to Image Analyst's:
mean_crackWidth1/mean_crackWidth2

Subject: One pixel line length

From: Lars-Göran Nord

Date: 3 Aug, 2010 20:08:19

Message: 41 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i39kh5$fbv$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> > Thank you Sean,
> >
> > I will look deeper into this this evening, as I'm not an expert in this it takes some time for me to figure it all out:-)
> > Do you think I can solve all this with some help:-) I have to tell my boss this monday if its possible or not. Othervise they will outsorce the whole thing, and I really dont like that at all. And the pleasure of success is aalso very sweet:-)
> >
> > Thanks again,
> > Lars
>
> You're welcome!
>
> It's definitely doable and I think you're close to the solution. The programming aspects of this shouldn't be too hard as you have the aid of the Image Processing Toolbox.
>
> Global approach:
> -Create the skeleton with the aid of Image Analyst's example
> -Calculate the orientation at each point on the skeleton using the bwconncomp, regionprops functions.
> -To get length across pixel use the approach I gave you from above (total line length).
> -To get max crack width: at each skeleton point calculate the angle orthogonal to that point's orientation. Using this orientation figure out how many point lie along a line drawn at this angle. Use the cos()^-1 formula to get this width too. The only time this would falter would be at intersections.
>
> %%%
> %Here is the code to do the first 3 steps in one shot. I think you'll like the results!
> %%%
> %
> %SCd 08/03/2010
> %% Load and Binarize
> I = imread('/Users/Userx/Downloads/cr1.tif');
> I = I(:,:,1) < 52; %Binarize
> I = padarray(I,[2 2],false,'both'); %Pad the array for later use
> %% ImageAnalyst's Skeleton
>
> skel = bwmorph(I, 'skel',inf);
> % Display the skeletonized image.
> imtool(skel);
>
> % Calculate total crask
> binaryArea = sum(I(:));
>
> % Calculate the length of all the cracks.
> skelArea = sum(skel(:));
>
> % Divide the area by the length to get the average width.
> mean_crackWidth1 = binaryArea / skelArea
>
> %% Get Orientation at each point
>
> my_orientations = zeros(size(I)); %Preallocate
> [r c] = find(skel); %[row col] indices of points on skel
> %Note: This is why we padded earlier:
> % all r,c are greater>=3 and <= size(dim) -2
>
> %Go to each point and calculate orientation
> for ii = 1:length(r)
> %Extract all pixels within the 5x5 window surrounding our point
> SKpart = skel((r(ii)-2):(r(ii)+2),(c(ii)-2):(c(ii)+2));
>
> %Connected components analysis, 8 connectivity (we care about corners!)
> CC =bwconncomp(SKpart,8);
>
> %Get orientation.
> RP = regionprops(CC,'Orientation');
>
> %Save the orientation. This may need modified if there are multiple
> %Orientations returned in the even of more than one object
> my_orientations(r(ii),c(ii)) = RP.Orientation;
> end
>
> %Sign doesn't matter
> length_orientations = abs(my_orientations);
>
> %Get angle closest to any axis
> length_orientations(length_orientations>45) = 90 - length_orientations(length_orientations>45);
>
> %Get length, preserving only those in the skeleton
> eachLength = 1./cosd(length_orientations).*double(skel);
> skelLength = sum(eachLength(:));
>
> %Crack area divided by length
> mean_crackWidth2 = binaryArea/skelLength
>
> %Compare to Image Analyst's:
> mean_crackWidth1/mean_crackWidth2

Sean,

This looks fantastic, fighting with my old car right now 1966 Impala conv. but will check later.

Don't know how to thank you.........

I'm very happy.

Be back later.

Thank you so much Sean,

Lars

Subject: One pixel line length

From: Lars-Göran Nord

Date: 3 Aug, 2010 23:21:05

Message: 42 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i39svj$q8s$1@fred.mathworks.com>...
> "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i39kh5$fbv$1@fred.mathworks.com>...
> > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> > > Thank you Sean,
> > >
> > > I will look deeper into this this evening, as I'm not an expert in this it takes some time for me to figure it all out:-)
> > > Do you think I can solve all this with some help:-) I have to tell my boss this monday if its possible or not. Othervise they will outsorce the whole thing, and I really dont like that at all. And the pleasure of success is aalso very sweet:-)
> > >
> > > Thanks again,
> > > Lars
> >
> > You're welcome!
> >
> > It's definitely doable and I think you're close to the solution. The programming aspects of this shouldn't be too hard as you have the aid of the Image Processing Toolbox.
> >
> > Global approach:
> > -Create the skeleton with the aid of Image Analyst's example
> > -Calculate the orientation at each point on the skeleton using the bwconncomp, regionprops functions.
> > -To get length across pixel use the approach I gave you from above (total line length).
> > -To get max crack width: at each skeleton point calculate the angle orthogonal to that point's orientation. Using this orientation figure out how many point lie along a line drawn at this angle. Use the cos()^-1 formula to get this width too. The only time this would falter would be at intersections.
> >
> > %%%
> > %Here is the code to do the first 3 steps in one shot. I think you'll like the results!
> > %%%
> > %
> > %SCd 08/03/2010
> > %% Load and Binarize
> > I = imread('/Users/Userx/Downloads/cr1.tif');
> > I = I(:,:,1) < 52; %Binarize
> > I = padarray(I,[2 2],false,'both'); %Pad the array for later use
> > %% ImageAnalyst's Skeleton
> >
> > skel = bwmorph(I, 'skel',inf);
> > % Display the skeletonized image.
> > imtool(skel);
> >
> > % Calculate total crask
> > binaryArea = sum(I(:));
> >
> > % Calculate the length of all the cracks.
> > skelArea = sum(skel(:));
> >
> > % Divide the area by the length to get the average width.
> > mean_crackWidth1 = binaryArea / skelArea
> >
> > %% Get Orientation at each point
> >
> > my_orientations = zeros(size(I)); %Preallocate
> > [r c] = find(skel); %[row col] indices of points on skel
> > %Note: This is why we padded earlier:
> > % all r,c are greater>=3 and <= size(dim) -2
> >
> > %Go to each point and calculate orientation
> > for ii = 1:length(r)
> > %Extract all pixels within the 5x5 window surrounding our point
> > SKpart = skel((r(ii)-2):(r(ii)+2),(c(ii)-2):(c(ii)+2));
> >
> > %Connected components analysis, 8 connectivity (we care about corners!)
> > CC =bwconncomp(SKpart,8);
> >
> > %Get orientation.
> > RP = regionprops(CC,'Orientation');
> >
> > %Save the orientation. This may need modified if there are multiple
> > %Orientations returned in the even of more than one object
> > my_orientations(r(ii),c(ii)) = RP.Orientation;
> > end
> >
> > %Sign doesn't matter
> > length_orientations = abs(my_orientations);
> >
> > %Get angle closest to any axis
> > length_orientations(length_orientations>45) = 90 - length_orientations(length_orientations>45);
> >
> > %Get length, preserving only those in the skeleton
> > eachLength = 1./cosd(length_orientations).*double(skel);
> > skelLength = sum(eachLength(:));
> >
> > %Crack area divided by length
> > mean_crackWidth2 = binaryArea/skelLength
> >
> > %Compare to Image Analyst's:
> > mean_crackWidth1/mean_crackWidth2
>
> Sean,
>
> This looks fantastic, fighting with my old car right now 1966 Impala conv. but will check later.
>
> Don't know how to thank you.........
>
> I'm very happy.
>
> Be back later.
>
> Thank you so much Sean,
>
> Lars


Sean,

I don't like the result,

I love it:-)
works flawlesly and gets correct answers:-)
will check more tomorrow.

Thanks Sean

Lars

Subject: One pixel line length

From: Sean

Date: 4 Aug, 2010 15:00:21

Message: 43 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> Sean,
>
> I don't like the result,
>
> I love it:-)
> works flawlesly and gets correct answers:-)
> will check more tomorrow.
>
> Thanks Sean
>
> Lars

Glad to hear, and you're welcome!
I hope the car is doing well also, that sounds like a much more interesting project overall.

Let me know if you need anything else. As far as the above code it should work all of the time, unless, as the comment hinted at two objects are returned. In this case you'll have to decide what to do. It would be 1 or 2 lines of code to keep only the orientation which contains the center pixel.
I think I may program the max crack width algorithm I described above. It's a good excuse for me to program as opposed to journal/thesis write, which is far more enjoyable :)

-Sean

Subject: One pixel line length

From: Lars-Göran Nord

Date: 5 Aug, 2010 10:02:06

Message: 44 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i3bva5$k78$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> > Sean,
> >
> > I don't like the result,
> >
> > I love it:-)
> > works flawlesly and gets correct answers:-)
> > will check more tomorrow.
> >
> > Thanks Sean
> >
> > Lars
>
> Glad to hear, and you're welcome!
> I hope the car is doing well also, that sounds like a much more interesting project overall.
>
> Let me know if you need anything else. As far as the above code it should work all of the time, unless, as the comment hinted at two objects are returned. In this case you'll have to decide what to do. It would be 1 or 2 lines of code to keep only the orientation which contains the center pixel.
> I think I may program the max crack width algorithm I described above. It's a good excuse for me to program as opposed to journal/thesis write, which is far more enjoyable :)
>
> -Sean



Hi Sean,

Yes my Impala SS is performing like new now, I bought it from a guy in Ottumwa (Iowa) and he got it from his father. Makes me only third owner, not bad at all for a 50 (in some months)year old car. I had one 30 years ago, but this one is in better condition despite the 30 years differance:-) so I'm pleased.

I'm glad to hear you like helping out in a real world application, and I cant wait untill starting the tests and getting some info. I know this will develop into a fantastic analysing "tool".

Max crack width algorithm, greeeeeaaaat!!!!

Thank you,

Lars

Subject: One pixel line length

From: Lars-Göran Nord

Date: 6 Aug, 2010 16:15:21

Message: 45 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i3bva5$k78$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> > Sean,
> >
> > I don't like the result,
> >
> > I love it:-)
> > works flawlesly and gets correct answers:-)
> > will check more tomorrow.
> >
> > Thanks Sean
> >
> > Lars
>
> Glad to hear, and you're welcome!
> I hope the car is doing well also, that sounds like a much more interesting project overall.
>
> Let me know if you need anything else. As far as the above code it should work all of the time, unless, as the comment hinted at two objects are returned. In this case you'll have to decide what to do. It would be 1 or 2 lines of code to keep only the orientation which contains the center pixel.
> I think I may program the max crack width algorithm I described above. It's a good excuse for me to program as opposed to journal/thesis write, which is far more enjoyable :)
>
> -Sean



Hi Sean,

I have tryed the script on a lot of "fake" cracks and it works all the times:-)

Now to finding and counting the intersections (3 and 4 crossings) I have looked at my_orientations and can see that every intersection contains both + and - values in the columns, there is also like 4 values in the column at intersections (high angle) and 5 or maybe more values in columns at low angle intersections.
Can this be used in some way???
Or is the connectivity tool with "high connectivity" the right way to go?

Lars

Subject: One pixel line length

From: Sean

Date: 6 Aug, 2010 17:32:05

Message: 46 of 47

"Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i3hcep$kks$1@fred.mathworks.com>...
> "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i3bva5$k78$1@fred.mathworks.com>...
> > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> > > Sean,
> > >
> > > I don't like the result,
> > >
> > > I love it:-)
> > > works flawlesly and gets correct answers:-)
> > > will check more tomorrow.
> > >
> > > Thanks Sean
> > >
> > > Lars
> >
> > Glad to hear, and you're welcome!
> > I hope the car is doing well also, that sounds like a much more interesting project overall.
> >
> > Let me know if you need anything else. As far as the above code it should work all of the time, unless, as the comment hinted at two objects are returned. In this case you'll have to decide what to do. It would be 1 or 2 lines of code to keep only the orientation which contains the center pixel.
> > I think I may program the max crack width algorithm I described above. It's a good excuse for me to program as opposed to journal/thesis write, which is far more enjoyable :)
> >
> > -Sean
>
>
>
> Hi Sean,
>
> I have tryed the script on a lot of "fake" cracks and it works all the times:-)
>
> Now to finding and counting the intersections (3 and 4 crossings) I have looked at my_orientations and can see that every intersection contains both + and - values in the columns, there is also like 4 values in the column at intersections (high angle) and 5 or maybe more values in columns at low angle intersections.
> Can this be used in some way???
> Or is the connectivity tool with "high connectivity" the right way to go?
>
> Lars

If I understand you correctly: you're trying to identify crack intersection points and how many intersections at these points?

Instead of using orientation for this, you might be able to use the 'BranchPoints' option in bwmorph() on the skeleton that's already been created. Each branch point returned will mean either 3 or 4 cracks coming in to it. You could find out how many by summing the neighbors it has that are on. In the event of two branch points touching you'd have to sum the points on this new object's perimeter. Here's an example of that occurring:

%%%%
%Test Skeleton
I = false(5);
I(2,2) = true;
I(:,3) = true;
I(1,1) = true;
I(3,4) = true;

%Get Branch Points
bpts = bwmorph(I,'branchpoints');

%Plot stuff
subplot(1,2,1);
imshow(I);
title('Original')
subplot(1,2,2);
imshow(bpts);
title('Branch Points')

%Sum Stuff
nbranch = sum(I(find(imdilate(bpts,strel('disk',1)) - bpts))==1); %#ok<FNDSB>

%Algorithm:
%Find the perimeter pixels by subtracting the original branch points image
%from the one pixel dilated branch points image. Sum these values that are
%true in the skeleton image.
%%%

Subject: One pixel line length

From: Lars-Göran Nord

Date: 6 Aug, 2010 19:11:05

Message: 47 of 47

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i3hgul$8gc$1@fred.mathworks.com>...
> "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message <i3hcep$kks$1@fred.mathworks.com>...
> > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i3bva5$k78$1@fred.mathworks.com>...
> > > "Lars-Göran Nord" <lars-goran.nordh@uddeholm.se> wrote in message
> > > > Sean,
> > > >
> > > > I don't like the result,
> > > >
> > > > I love it:-)
> > > > works flawlesly and gets correct answers:-)
> > > > will check more tomorrow.
> > > >
> > > > Thanks Sean
> > > >
> > > > Lars
> > >
> > > Glad to hear, and you're welcome!
> > > I hope the car is doing well also, that sounds like a much more interesting project overall.
> > >
> > > Let me know if you need anything else. As far as the above code it should work all of the time, unless, as the comment hinted at two objects are returned. In this case you'll have to decide what to do. It would be 1 or 2 lines of code to keep only the orientation which contains the center pixel.
> > > I think I may program the max crack width algorithm I described above. It's a good excuse for me to program as opposed to journal/thesis write, which is far more enjoyable :)
> > >
> > > -Sean
> >
> >
> >
> > Hi Sean,
> >
> > I have tryed the script on a lot of "fake" cracks and it works all the times:-)
> >
> > Now to finding and counting the intersections (3 and 4 crossings) I have looked at my_orientations and can see that every intersection contains both + and - values in the columns, there is also like 4 values in the column at intersections (high angle) and 5 or maybe more values in columns at low angle intersections.
> > Can this be used in some way???
> > Or is the connectivity tool with "high connectivity" the right way to go?
> >
> > Lars
>
> If I understand you correctly: you're trying to identify crack intersection points and how many intersections at these points?
>
> Instead of using orientation for this, you might be able to use the 'BranchPoints' option in bwmorph() on the skeleton that's already been created. Each branch point returned will mean either 3 or 4 cracks coming in to it. You could find out how many by summing the neighbors it has that are on. In the event of two branch points touching you'd have to sum the points on this new object's perimeter. Here's an example of that occurring:
>
> %%%%
> %Test Skeleton
> I = false(5);
> I(2,2) = true;
> I(:,3) = true;
> I(1,1) = true;
> I(3,4) = true;
>
> %Get Branch Points
> bpts = bwmorph(I,'branchpoints');
>
> %Plot stuff
> subplot(1,2,1);
> imshow(I);
> title('Original')
> subplot(1,2,2);
> imshow(bpts);
> title('Branch Points')
>
> %Sum Stuff
> nbranch = sum(I(find(imdilate(bpts,strel('disk',1)) - bpts))==1); %#ok<FNDSB>
>
> %Algorithm:
> %Find the perimeter pixels by subtracting the original branch points image
> %from the one pixel dilated branch points image. Sum these values that are
> %true in the skeleton image.
> %%%

Sean,

Thank you, I will start testing at once and will try to get this together for monday. I think I can dig out some "real" images of cracks then.
You are correct as a sniper:-) a hit every time:-)

Thank you Sean,

Lars

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us