









 
 




 
 


> Well, the basic idea was to see if, using a simple photograph or scan of an
> existing gear, if the number of teeth could be determined automatically and
> accurately. Just like in the link.
I don't think their link is a very good way to do it, if there are
artefacts on the photo you could end up with missing teeth or additional
teeth in the count. It would only be accurate/reliable on superclean
photos.
I wonder if you could do some sort of polar>rectangular conversion of
the image, once the centre is found (so x in the new image represents
0360 degrees polar angle, y represents radius at that angle). You can
then do a fourier transform along x, and the frequency peak in the
result will correspond to the number of teeth, and be far more immune to
any artefacts/noise in the image.
This is exactly the technique I use to measure the pitch of regularly
spaced identical objects in an image, it's extremely robust.
Post a reply to this message


 
 




 
 


scott <sco### [at] scottcom> wrote:
> You can
> then do a fourier transform along x, and the frequency peak in the
> result will correspond to the number of teeth, and be far more immune to
> any artefacts/noise in the image.
I worked a little bit more on this, and plotted out the radius vs arclength to
get a triangle wave graph (3600 samples). Naturally, I thought that the
Fourier transform would be a great way to pluckout the frequency of the teeth,
I just haven't gotten to that point yet.
I'm glad to see that you actually do this, and know empirically that it's a
reliable and robust method. That validates spending the time to go that route.
Thanks! :)
Based on my graph, there does seem to be some "cruft" at some point on the gear
photo that distorts the data, but it's apparently still clean enough to give me
the correct number of teeth with the way I'm currently doing it, provided I
apply the correct frequency of sampling. (see binary thread)
I was also thinking that there ought to be way to determine a radial sampling
frequency based on the resolution of the image  since any higher than that
wouldn't gain me anything.
Until I work any of that out, I might just think about prescanning the
perimeter, estimating the tooth number and average size of a tooth, and then
filtering out any noise that disrupts my counting algorithm by ignoring any
change that's less than a certain fraction of a tooth height.
Post a reply to this message


 
 




 
 


>> You can
>> then do a fourier transform along x, and the frequency peak in the
>> result will correspond to the number of teeth, and be far more immune to
>> any artefacts/noise in the image.
>
> I worked a little bit more on this, and plotted out the radius vs arclength to
> get a triangle wave graph (3600 samples). Naturally, I thought that the
> Fourier transform would be a great way to pluckout the frequency of the teeth,
> I just haven't gotten to that point yet.
> I'm glad to see that you actually do this, and know empirically that it's a
> reliable and robust method. That validates spending the time to go that route.
> Thanks! :)
>
> Based on my graph, there does seem to be some "cruft" at some point on the gear
> photo that distorts the data, but it's apparently still clean enough to give me
> the correct number of teeth with the way I'm currently doing it, provided I
> apply the correct frequency of sampling. (see binary thread)
>
> I was also thinking that there ought to be way to determine a radial sampling
> frequency based on the resolution of the image  since any higher than that
> wouldn't gain me anything.
>
> Until I work any of that out, I might just think about prescanning the
> perimeter, estimating the tooth number and average size of a tooth, and then
> filtering out any noise that disrupts my counting algorithm by ignoring any
> change that's less than a certain fraction of a tooth height.
Another thing I did, which allows you to get a much more accurate value
of wavelength/frequency than Fourier allows, is to use some form of
autocorrelation. It might work out quite well here... I do this step
after Fourier has given me a rough idea of the spacing, but you might be
able to just skip the Fourier step and do this...
You find the centre point of the gear. Then create a 2nd copy of the
image rotated by some angle A about this centre point. You then do a
difference of all the pixels in the original and rotated version and sum
up the errors (maybe ignore the centre part of the gear).
As you increase angle A from zero you will get a different total error,
the angle that gives the minimum error will be your tooth angle. You can
use whatever algorithm you want to search for the A with the minimum error.
Post a reply to this message


 
 




 
 


scott <sco### [at] scottcom> wrote:
> You find the centre point of the gear.
That's something I still need to improve  I'm working with only the roughest
estimate at the moment.
I think the usual method of using where 2 angle bisectors intersect to find the
center of a circle ought to straightforward enough to implement.
> Then create a 2nd copy of the
> image rotated by some angle A about this centre point. You then do a
> difference of all the pixels in the original and rotated version
A difference of all the pixels... a difference of  the rgb/gray values?
The vector length from the center of the circle?
Part of the challenge with this is differentiating "picture" and "object" and
separating and extracting one from the other for analysis.
> and sum
> up the errors (maybe ignore the centre part of the gear).
Sum up the differences in the above step to get a measure of the absolute change
as a function of the angle.
> As you increase angle A from zero you will get a different total error,
> the angle that gives the minimum error will be your tooth angle. You can
> use whatever algorithm you want to search for the A with the minimum error.
Or, I suppose the maximum would yield essentially the same result, if I
correctly understand how this all works.
With regard to the Fourier transform and its inverse  what are you using to
implement that? Is it part of a proprietary software package? A C library? I
think I've been able to get the 1D version working fairly well, but I haven't
been able to spend enough uninterrupted time with the 2D variation to match up
the output to what I see in online examples.
Thanks as always for your suggestions and guidance :)
Post a reply to this message


 
 




 
 


> A difference of all the pixels... a difference of  the rgb/gray values?
Yes, if you have a colour image then I'd probably do the pythagorean
distance between the two RGB values. It probably doesn't matter too much.
>> As you increase angle A from zero you will get a different total error,
>> the angle that gives the minimum error will be your tooth angle. You can
>> use whatever algorithm you want to search for the A with the minimum error.
>
> Or, I suppose the maximum would yield essentially the same result, if I
> correctly understand how this all works.
When you've found the correct angular spacing, the rotated image should
have all the teeth lining up with the original image, so the difference
between the two images (in terms of summing up the differences between
every pixel) should be very small. As you rotate the 2nd image so the
teeth are not quite lined up, you'll get bigger errors where there is
"gear" in one image and "background" in the other image.
The maximum total error might give you exactly half the angular spacing
of the teeth, as this would probably be where the "tooth" in the rotated
image exactly lined up with the "gap" in the original.
> With regard to the Fourier transform and its inverse  what are you using to
> implement that? Is it part of a proprietary software package? A C library? I
> think I've been able to get the 1D version working fairly well, but I haven't
> been able to spend enough uninterrupted time with the 2D variation to match up
> the output to what I see in online examples.
All of my stuff is in C#. As for the FFT I just found a library from
Google that seemed to work well. This is the one:
https://gerrybeauregard.wordpress.com/2011/04/01/anfftinc/
Post a reply to this message


 
 




 

