It isn't? A single white pixel creates a single kernel shape of white, when dilating, and goes away when eroding.
bitwise_and and _or are exactly what you would expect. 255 = 0b11111111, and 0 = 0b00000000. So bitwise_or with 255 always gives you white, and bitwise_and with 0 always gives you black.
I can see the confusion with morphology, but the bitwise is exactly correct.
I would like to add some additional information even if mathematical morphology in general is out of my scope.
In image processing, the erosion operation can be defined for grayscale image and with a flat structuring element as:
The destination image is set for each location to the minimum value of the pixels that lie in the structuring element chosen.
In a same way, the dilatation operation can be defined for grayscale image and with a flat structuring element as:
This time, the destination image is set for a particular position with the maximum value of the pixels of the source image that lie in the structuring element.
We have the same definition in the OpenCV documentation (e.g. cv::erode) or in the Matlab documentation (imerode).
This "general" definition can be applied for grayscale images and for binary images as well.
More specifically, the binary erosion of A by B is:
And the binary dilatation of A by B is:
Asked: 2016-08-21 20:15:50 -0600
Seen: 2,255 times
Last updated: Oct 09 '16
it just depends, what you define as "foreground". (opencv prefers white here). if you swap black and white there, dilate and erode swap their meaning.
@berak I know that, but this is not intuitive. Why does opencv prefer white as foreground?
probably because white==255==on, and black==0==off.
but yea, if you come more from "paper world", you'd think: black==print==on, white==bg==off.
Because OpenCV is a computer vision library. It is common sense to mark background pixels as black, while white pixels are the moving blobs in the video. This is done throughout the whole community and thus thats the main reason why OpenCV decided to follow that!