ImageBorderOperation + IMAQ Convolute

[b.ploetzeneder]

I am using IMAQ Convolute on a binary image as part of a perimeter edge counting algorithm. 

For this, I noticed some curious behaviour of IMAQ Convolute: It seems to ignore my Border Clear (which sets the border to 0) and convolutes as if the value was 1.

Only if I artificially pad the image (aka create my own border), I get the expected result.

What's the deal with this? Do I misunderstand the border concept?

[AmitShachaf]

Yes - you misunderstand the border concept.

1. border in IMAQ Create - LabVIEW is allocating a larger buffer then the image for enabeling correct convolution (kernal) operation. This border is not part of the image and shouldn't be cleaned by Bordr clear operation.

2. Clear border should clear blobs that are tuching the border of the image. Not the border of the memory buffer. 

[b.ploetzeneder]

a) But a convolution is a kernel operation, and it is NOT correct.

b) Reject Border is for removing particles, not clear border. If it would reject border particles, it would have emptied my first image.

Edit: To give the image as values..

[AmitShachaf]

I see your point.

But the border operation doesn't do anything in this case.

You will get the same result without it.

You are setting the border to zero while it is allready zero after the image create.

[b.ploetzeneder]

But the result it gives me is as if the border is NOT zero.

It gives me a result as if it is

0 0 1 0 0 

0 . . . .  0

1 . . . .  1

0 . . . .  0

0 0 1 0 0

[jozef.liptak]

Dear b.ploetzeneder,

thanks for pointing this out. In IMAQ vision concepts manual, and also in Vision Help there is a explanation on how the ImageBorderOperation VI should work:

http://zone.ni.com/reference/en-XX/help/370281AC-01/nivisionconcepts/image_borders/

And how you can use it:

http://zone.ni.com/reference/en-XX/help/370281AC-01/imaqvision/imaq_imageborderoperation/

There is also written:

"In NI Vision, most image processing functions that use neighbors automatically set pixel values in the image border using neighborhoods."

That is actually that you are experiencing (result is as if the border was not just zeros). The problem actually can be:

• that this information (e.g. that Convolute VI, and other VI's, ignores the set borders and still uses own border definition) is not written in the Vision help.
• that VIs like Convolute should not ignore the borders set by ImageBorderOperation VI

Sorry for that. What from the above should be corrected in your opinion? According to that I will address the right team in US with a corrective action request and my colleagues will try to correct. Documentation issues are corrected usually sooner. Problems with VI behavior: it depends on what needs to be changed, if it would require a version dump, if also other customers need such a behavior, ...

I found also some interesting discussion here:

http://forums.ni.com/t5/LabVIEW/IMAQ-ImageBorderOperation-does-not-work/td-p/294319

Please let me know your opinion, or directly contact your local NI techsupport and ask for help there.

[b.ploetzeneder]

Hi,

the image border makes sense for me for exactly one use-case: For image operations that consider the neighbourhood (require some sort of kernel). Those are morphological operations, filters and generally, convolutions.  For these functions, I expect IMAQ Convolute definitely to take the border into account, and that is a bug for me.  

However, it is a bug with a trivial work-around  (padding/unpadding subvis).  But it puts me in a position where I consider the concept of "border" untrustworthy and have to verify it for all my algorithms. So I think at minimum the documentation should point out where I can trust it or where not.

B

[jozef.liptak]

I created Corrective Action Request #609653. Now my colleague's from US need to validate and evaluate, and most probably they will forward to RnD, that needs to decide what can be done. If it will be fixed, it will appear in VDM readme under bug fixes with this number. This can take from until the next version release till even 3 years, if it will require version dump. Or RnD can decide, that this is not an high imporance CAR, and can decline it, or just include it in known issues, or change documentation of the Convolute VI.

[PShuttleworth]

Thanks for the info. I am having the same problem of not being able to change the border default values. I will try creating my own border.