Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

It seems like a mix of bugs (although they may come from single source).

1) Online documentation states that (3,3,-1,-1,CV_SHAPE_RECT) should be used, but in experiments I just did, I saw that (3,3,1,1,CV_SHAPE_RECT) gives correct result, and (3,3,-1,-1,CV_SHAPE_RECT) causes run time error. Sorry for my previous answer about this issue.

2) I receive even weirder results when I use C++ interface (i.e. getStructuringElement function). Anchor point I provide to it is ignored, i.e. changing anchor point has no influence on result. And when I provide anchor points to dilate function, I receive same results for both (1,1) and (-1,-1) anchor points... But when I use (0,0) as anchor the result is indeed shifted...

3) It seems that you meet an old bug that was present in OpenCV 1.0. When morphological function (like dilate or erode) is used, and the value of 'iterations' argument is bigger than 1, some shift of structuring element happens. I was sure that this issue was resolved years ago. And it indeed was resolved for default structuring element. But as I see now the problem still persist when user defined SE is used. I checked it both in C and C++ interfaces, just in case.

I am using OpenCV 2.4.2 while you are using 2.2.0, but if the problem exist in my version I guess it should be the same problem in yours.

As a temporary workaround for this bug until it will be fixed, you can run dilate function inside 'for loop', with 'iterations' argument set to 1. Reduces speed, but at least the result is correct.

Please report this issue in bug tracker.

On a side note, it is good to use last version of OpenCV, because each release had considerable amount of bug fixes (although not all the bugs are found and fixed yet, as you just experienced). And it is good to use C++ interface if possible (code is cleaner, automatic resource management, and so on).

It seems like a mix of bugs (although they may come from single source).

1) Online documentation states that (3,3,-1,-1,CV_SHAPE_RECT) should be used, but in experiments I just did, I saw that (3,3,1,1,CV_SHAPE_RECT) gives correct result, and (3,3,-1,-1,CV_SHAPE_RECT) causes run time error. Sorry for my previous answer about this issue.

2) I receive even weirder results when I use C++ interface (i.e. getStructuringElement function). Anchor point I provide to it is ignored, i.e. changing anchor point has no influence on result. And when I provide anchor points to dilate function, I receive same results for both (1,1) and (-1,-1) anchor points... But when I use (0,0) as anchor the result is indeed shifted...

3) It seems that you meet an old bug that was present in OpenCV 1.0. When morphological function (like dilate or erode) is used, and the value of 'iterations' argument is bigger than 1, some shift of structuring element happens. I was sure that this issue was resolved years ago. And it indeed was resolved for default structuring element. But as I see now the problem still persist persists when user defined SE is used. I checked it both in C and C++ interfaces, just in case.

I am using OpenCV 2.4.2 while you are using 2.2.0, but if the problem exist exists in my version I guess it should be the same problem in yours.

As a temporary workaround for this bug until it will be fixed, you can run dilate function inside 'for loop', with 'iterations' argument set to 1. Reduces speed, but at least the result is correct.

Please report this issue in bug tracker.

On a side note, it is good to use last version of OpenCV, because each release had considerable amount of bug fixes (although not all the bugs are found and fixed yet, as you just experienced). And it is good to use C++ interface if possible (code is cleaner, automatic resource management, and so on).