Finding the centroid of a parabloid

[SegmentationFault]

Hm. Well maybe I have a fundamental misunderstanding then. When it is displayed on the 3D graph, it looks roughly like a 3d paraboloid. Why is the center you provided so far off from where I said the centroid should be?

Anyways, what is the best way of doing what I want? Is there something wrong with my algorithm? Is there a stock algorithm in LabVIEW that will do this? All I want to do is essentially get a 3d average..

[johnsold]

Your algorithm should always be based on the underlying physics of what you are trying to model.  When you mentioned a beam profile in message 8 that makes the Gaussian a more likely model.  This is the information I was trying to get with some of the questiosn in my first reply.

altenbach is very knowledgeable about fitting, both the mathematical models and the match between the physics and the data.  I suspect that his results are probably closer to what is actually happening than your guesses which seem to based on what looks easy to do rather than what your devices and data actually represent.

Can you put a screen or your measurement system about 10 times farther away from the emitter than it was when you collected the data you posted?  Then look at where the image appears.  I suspect that you will find the beam 20 degrees from vertical as altenbach suggested.  By moving the detector farther away from the  emitter, the beam tilt, if any, should be readily apparent.

Lynn

[KyleTTU]

---

@SegmentationFault wrote:

Hm. Well maybe I have a fundamental misunderstanding then. When it is displayed on the 3D graph, it looks roughly like a 3d paraboloid. Why is the center you provided so far off from where I said the centroid should be?

Anyways, what is the best way of doing what I want? Is there something wrong with my algorithm? Is there a stock algorithm in LabVIEW that will do this? All I want to do is essentially get a 3d average..

---

There is a basic function I found here for taking the average of a 3D array if that is all you're needing. However, I'm fairly certain it isn't going to meet all of your needs for this project.  Do you happen to have the NI Vision Development Module?  

Kyle Smith

Applications Engineer

National Instruments

[SegmentationFault]

I am sorry, but I am not very familiar with different models. I looked at altenbach's thread and at his VIs, but I didn't really understand them. It could very well be the best approach, I am just not experienced enough with fitting to be able to identify the best approach in the first place. 

Anyways, for more information, here is one of the graphs generated by the program: 

The cyan line represents where my algorithm is telling me the centroid is (I just mad a cursor line through that point so that it was easier to visualize). The black line represents where it seems like that center should actually be. I realize that it is hard to tell from just that picture, so here is another one from the top down:

Would an alternative approach be to take those contour lines, treat them as circles somehow, find the center of them, and then average each of those centers? 

[johnsold]

From looking at the images you posted, it appears that your algorithm is weighting the low intensity profiles more heavily than the higher intensity ones.  It would seem that that opposite is what you would want.  Think of the cyan point in the top view as the center of the 4e-6 profile and the black one as representing the 1.5e-5 profile.  Since they are not at the same point the beam axis is tilted.

Given the shapes of your profiles, circles would not be a very good fit.

Someone there must have some idea of how these things are supposed to behave.  The ideal or theoretical behavior should be the basis for selecting a model.  If you do not have any theory, you are just randomly manipulating numbers.  The calculations may be correct but the results have no meaning which correlates with the behavior of your devices.

Lynn

[SegmentationFault]

I really don't understand why it matters what model is used, as long as the appropriate results are achieved. And I'm not entirely sure what you mean by ideal or theoretical behaviour, but the ideal behaviour is that the beam generates a nice elongated dome beam profile. How could the results have no meaning? If we can get the centroid, we can test whether or not the beam is regular or irregular. 

As far as the algorithm I wrote, all it does is this:

First, it adds up every single power measurement to get the total power. 

Then, it goes through the power readings, multiplying them by the x-coordinate at that reading. Once all of those have been added together, the result is divided by the total power.

Then it goes through the power readings again, this time multiplying each one by the y-coordinate at that reading. Once all of these have been added together, the result is divided by the total power. 

How could it be weighting the low intensity profiles more?

[altenbach]

Part of your problem is the fact that your data seems to have an offset from zero, thus your math in the original post skews the resut towards the corner furthest from the peak.

Maybe all you need is some thresholding, e.g. ingore all values that are <30% of the max.

(Another option would be to subtract a constant value corresponding to the background, not shown)

Here's a quick draft, see if it make sense...

(I also think that your data file has a problem. I think the value in the lower left corner cell should be "+6" and not "-6")

[SegmentationFault]

It works! Ok so, from what I understand you are basically just doing the same thing as me but with some thresholding? Why does thresholding fix it? All the noise is constant so wouldn't that just sort of get "absorbed" in the calculations? 

And you were right about that last point. There was a bug in the code that I wasn't aware of, so I fixed that. Unfortunately, that didn't really solve the problem, so it must have been the thresholding.