IMAQ LineProfile Problem/Bug?

[nollMarvin]

Hello,

i'm working on a Vision Project which requires to get line profiles which are patterned around a circle (see picture).

When i use 4 of this lines, everything is working smoothly. But when i decide to use lets say 6 lines things go crazy as some profiles have a lot of zeros at the end.

I presume it has something to do with the four lines move in the direction of the pixels and the six lines don't.

Is this a bug?

What can i do to avoid this issue?

Regards

Marvin

[Bob_Schor]

---

@nollMarvin wrote:

When i use 4 of this lines, everything is working smoothly. But when i decide to use lets say 6 lines things go crazy as some profiles have a lot of zeros at the end.

---

It would really help to attach the VI that is having this problem so we could take a closer look at it, and even try it out on our own computers.

One question I would have is what is the structure that you are showing in your picture?  Might it be an array?  Might you be filling this array with sub-arrays derived from your Line Profiles?  Might it be the case that when you go along a single dimension the arrays are of the same length, but when you go across two dimensions the arrays are a different length?  Might some arrays be end-packed with zeros to "enforce" a "same-length" requirement for a 2D array?  [Hmm -- this is hardly "one question" ...]

I can't tell, as I can't see your unposted code.

Bob Schor

[nollMarvin]

Thanks for your response.

I've attached the VI 'test.vi' which demonstrates the problem.

Could be that i've encountered an array dimension problem.

Regards

[Bob_Schor]

---

@nollMarvin wrote:

Thanks for your response.

I've attached the VI 'test.vi' which demonstrates the problem.

Could be that i've encountered an array dimension problem.

Regards

---

Yes, you have.  When you get the six Line Profiles, the first and fourth have 101 points, the rest have 88 points.  When you subsequently concatenate these six arrays (of different sizes) into a single 2D array, LabVIEW creates an array large enough to hold all of the points, using the default value (0) for the "missing" end points of the shorter arrays.  This Snippet illustrates the point -- the array size it returns is 2 by 101.

Bob Schor

[Bob_Schor]

I even have an explanation for the sizes of the Line Profiles (and, no, I'm not "peeking" inside the Vision Function that NI is using).

Let's assume that we want to go a radial distance of 100, starting from 0.  If we go along the X axis, we can generate 101 points, 0, 1, ... 100.  If we do the same thing, but now at a 30° angle from the X axis, we only need to step X from 0 to 100*sqrt(3)/2 = 87, and if we take unit steps, that results in 88 steps from 0 .. 87.

It is easy to test this prediction with your code (I'll do it in just a minute).  If we use 8 profiles, the lengths should be 101 (along the X and Y axes) and 72 (100*sqrt(2)/2 + 1).  Hold on, I'll modify your routine and check ...  Yep, I'm right, the lengths are 101 and 72.

Bob Schor

[nollMarvin]

Would it be an appropiate solution to just shift the array to center it along with the others? Or should i interploate the pixel values?

[Bob_Schor]

Depends on what you want to do, how accurate you need to be, etc.  Note that the problem arises because of the method (behind the scenes) that LabVIEW is using to track a line -- it makes unit steps along one of the X-Y coordinate axes rather than making unit steps along the radius you selected.

One solution would be to make your radii end not in a circle (so they all have equal lengths) but on the boundary of a square (so the ones on diagonal paths are longer).  By my analysis of IMAQ's algorithm, the arrays returned will all be the same length.

Another solution would be to rotate the image so that the path you are analyzing is always along a coordinate axis.  In the case of 6 radii, you'd need to do two rotations (of 30° and 60°), but for 8 radii, you'd only need one (45°).  Note that a rotation is likely to be computationally "expensive" (i.e. slow), and I have no idea how IMAQ handles pixel-rounding problems (it would be instructive to try it and see how well the images, when printed, superimpose).

Finally, you could use iterpolation methods to adjust the arrays to be of comensurate lengths.

Which method you like depends on what you want/need to do and what precision/accuracy you need.  You may want to try them all, experiment, and report back your results.

Bob Schor