为什么 Bitmap.GetPixel
不适合直方图统计
直接遍历每个像素调用
GetPixel看似直观，但实际会严重拖慢速度——它每次调用都触发 GDI+ 锁、颜色空间转换和边界检查。一张 1024×768 的 24 位图，要调用近 80 万次，实测比内存直读慢 10 倍以上。
正确做法是用
Bitmap.LockBits获取原始字节数组，按像素格式（如
PixelFormat.Format24bppRgb）解析内存布局： RGB 各通道连续排列，每像素 3 字节：索引
i*3是 B，
i*3+1是 G，
i*3+2是 R 注意 Windows 位图行字节数必须是 4 的倍数，需按
(width * 3 + 3) & ~3计算步长 锁定后务必调用
UnlockBits，否则资源泄漏
灰度直方图的三种实现路径
多数分析场景只需灰度分布。关键在「如何转灰度」——不同公式影响直方图形态：
Y = (R + G + B) / 3：简单平均，速度快但人眼感知偏差大
Y = 0.299*R + 0.587*G + 0.114*B：ITU-R BT.601 标准，更符合亮度感知 用
ColorMatrix配合
ImageAttributes转灰度再统计：适合需要复用图像处理流水线的场景，但额外开销明显
推荐直接计算：申请一个长度为 256 的
int[] histogram = new int[256]，遍历字节数组时累加对应灰度值索引。
彩色直方图：按通道还是 HSV？
RGB 直方图（三个 256 元素数组）容易写，但无法反映人眼对色彩的敏感度差异；HSV 空间更适合分析色调分布：
H（色相）取值 0–360，建议分 32 或 64 桶（避免稀疏），S 和 V 可各分 8 桶，构成 32×8×8 的三维直方图 .NET 没有内置 RGB→HSV 转换，需手写或引用Color.GetHue()/
GetSaturation()/
GetBrightness()，但注意这三个方法返回的是 0–360、0–1、0–1 浮点值，需手动量化 若只关心主色调，可跳过 S/V 过滤，直接统计 H 分布；若要排除低饱和区域，先筛
s > 0.2再统计
性能与精度的权衡点
直方图本身不存图像，但桶数和采样方式影响后续分析可靠性：
256 桶对灰度足够，但对 HSV 的 H 维，360 度映射到 256 桶会导致相邻色相（如红与橙红）被合并，建议至少 360 桶或用环形直方图逻辑 大图可降采样（如取每 4×4 块中心像素）加速，但会丢失局部细节；医疗或工业图像慎用 若需多图对比，务必统一灰度转换公式和桶边界，否则CompareHistograms结果无意义
真正容易被忽略的是 Alpha 通道处理：加载 PNG 时若未明确指定
PixelFormat.Format32bppArgb，
LockBits可能读出错误的内存布局，导致 R/G/B 偏移——务必检查
bitmap.PixelFormat并按实际格式解析字节顺序。
