我这样简单的缩小图形的算法，为何有问题？

[lyzcom]

假如原图形中每一个像素是这样的：
a00 a01 a02 a03 a04 a05
a10 a11 a12 a13 a14 a15
a20 a21 a22 a23 a24 a25
a30 a31 a32 a33 a34 a35

上面一共是6*4个像素，我将他的宽度和高缩小一半，得到3*2个像素，于是：
(a00 + a01 + a10 + a11) / 4 是分别将R、G、B分量相加除以4之后再合成一个颜色。

这样计算应该是没有问题的吧？

但是，我发现如果这样一直递归计算下去，比如有一张256*256的图片，首先用上面的方法，邻近4个点采样平均，得到一张128*128的，再在这张128*128的图片上，邻近4个点采样缩成一张64*64的，如此一直缩到8*8。

我发现，当缩小越多的时候图像失真就越是严重，256*256的图缩到64*64的时候，整幅图像感觉除了色调、色温一样之外，图像都好象已经完全变了。


这是怎么回事呢？

[ablewindy]

看样子还是算法有问题！
没整过这方面的东西，帮你顶吧！

[jyc_nj]

1)你可以找找有没有相关的算法, 据我所知, 缩小失真的问题不是很好解决的(可能是没有一个能应对所有位图情况的算法).
2)StretchBlt之前用SetStretchBltMode指定不同参数,可能会对不同图片起效果. 你把结果GetDIBits出来, 看看和你的结果有什么差.(比较苦的一种推导算法方法)

[kill2001er]

不管什么算法，只要缩小或放大了图像，必然是有失真的，只是程度不同而已。不过你的算法好像也有问题，不应该直接在RGB空间做均值，在YUV空间做应该会好很多，你可以查查图像处理方面的书籍，邮电出版社的vc++数字图像处理就有这方面的问题。我也记不清了。你自己看看吧。
另外你可以试试不平均直接取其中的一个像素值作为缩小后的值。

[Fattest]

bmp文件的头部信息有没有处理过？