卷积理论与实现

发布于 2024-12-05 09:21:55 字数 814 浏览 0 评论 0原文

我研究图像处理中的卷积,因为它是课程的一部分,我了解理论和公式,但对其实现感到困惑。

公式为:


在此处输入图像描述


我的理解

卷积核水平翻转和翻转垂直方向然后将kernel中的值乘以对应的像素值,将结果相加,除以“行x列”得到平均值,最后这个结果就是该像素的值位于内核位置的中心。

实现中的混乱

当我运行课程材料中的示例卷积程序并插入 3x3 卷积核作为输入时,其中:

第一行:(0, 1, 0)

第二行:(0, 0, 0 )

第 3 行:(0, 0, 0)

处理后的图像向下移动一个像素,而我预计它会向上移动一个像素。这个结果表明在计算之前没有进行水平或垂直翻转(就好像在做相关一样)。

我认为程序可能有问题,所以我环顾四周,发现 Adobe Flex 3Gimp 也在这样做。

我不明白,是不是我忽略了什么?

感谢任何帮助或反馈。

I study convolution in image processing as it is a part of the curriculum, I understand the theory and the formula but I am confused about its implementation.

The formula is:


enter image description here


What I understand

The convolution kernel is flipped both horizontally and vertically then the values in the kernel are multiplied by the corresponding pixel values, the results are summed, divided by "row x column" to get the average, and then finally this result is the value of the pixel at the center of the kernel location.

Confusion in implementation

When I run the example convolution program from my course material and insert as input a 3x3 convolution kernel where:

1st row: (0, 1, 0)

2nd row: (0, 0, 0)

3rd row: (0, 0, 0)

The processed image is shifted down by one pixel, where I expected it to shift upwards by one pixel. This result indicates that no horizontal or vertical flipping is done before calculating (as if it is doing correlation).

I thought there might be a fault in the program so I looked around and found that Adobe Flex 3 and Gimp are doing this as well.

I don't understand, is there something that I missed to notice?

Appreciate any help or feedback.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

度的依靠╰つ 2024-12-12 09:21:55

我猜你尝试的程序实现的是相关而不是卷积。

我已经使用 ImageFilter 函数在 Mathematica 中尝试了您的过滤器,结果按预期向上移动:

在此处输入图像描述

结果:

在此处输入图像描述

我也在 Octave(一个开源 Matlab 克隆)中尝试过):

imfilter([1,1,1,1,1;
          2,2,2,2,2;
          3,3,3,3,3;
          4,4,4,4,4;
          5,5,5,5,5],
         [0,1,0;
          0,0,0;
          0,0,0],"conv")

(“conv”表示卷积 - imfilter 的默认值是相关)。结果:

   2   2   2   2   2
   3   3   3   3   3
   4   4   4   4   4
   5   5   5   5   5
   0   0   0   0   0

请注意最后一行是不同的。这是因为不同的实现使用不同的填充(默认情况下)。 Mathematica 对 ImageConvolve 使用恒定填充,对 ListConvolve 无填充。 Octave 的 imfilter 使用零填充。

另请注意(如贝利撒留提到的)卷积的结果可以比源图像更小、相同大小或更大。 (我在 Matlab 和 IPPI 文档中读过术语“有效”、“相同大小”和“完整”卷积,但我不确定这是否是标准术语)。这个想法是,求和可以

  • 仅在内核完全位于图像内部的源图像像素上执行。在这种情况下,结果小于源图像。
  • 在每个源像素上。在这种情况下,结果的大小与源图像相同。 边界处进行填充
  • 这需要在内核的任何部分位于源图像内部的每个像素的 。在这种情况下,结果图像比源图像大。这也需要在边界处填充。

I guess the programs you tried implement correlation instead of convolution.

I've tried your filter in Mathematica using the ImageFilter function, the result is shifted upwards as expected:

enter image description here

result:

enter image description here

I've also tried it in Octave (an open source Matlab clone):

imfilter([1,1,1,1,1;
          2,2,2,2,2;
          3,3,3,3,3;
          4,4,4,4,4;
          5,5,5,5,5],
         [0,1,0;
          0,0,0;
          0,0,0],"conv")

("conv" means convolution - imfilter's default is correlation). Result:

   2   2   2   2   2
   3   3   3   3   3
   4   4   4   4   4
   5   5   5   5   5
   0   0   0   0   0

Note that the last row is different. That's because different implementations use different padding (by default). Mathematica uses constant padding for ImageConvolve, no padding for ListConvolve. Octave's imfilter uses zero padding.

Also note that (as belisarius mentioned) the result of a convolution can be smaller, same size or larger than the source image. (I've read the terms "valid", "same size" and "full" convolution in the Matlab and IPPI documentation, but I'm not sure if that's standard terminology). The idea is that the summation can either be performed

  • only over the source image pixels where the kernel is completely inside the image. In that case, the result is smaller than the source image.
  • over every source pixel. In that case, the result has the same size as the source image. This requires padding at the borders
  • over every pixel where any part of the kernel is inside the source image. In that case, the result image is larger than the source image. This also requires padding at the borders.
内心荒芜 2024-12-12 09:21:55

请注意:

在此处输入图像描述

结果为:

在此处输入图像描述

因此,“移动”不是真实的,因为尺寸受到影响。

Please note that:

enter image description here

Results in:

enter image description here

So, the "shifting" is not real, as the dimensions are affected.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文