应直接操作像素内存而非getpixel/setpixel：先lockbits获取scan0指针和stride，按加权公式0.299r+0.587g+0.114b计算灰度，优先用format32bppargb格式，处理完调unlockbits；colormatrix适合ui预览但不灵活；保存jpeg需设quality≥95，跨dpi需指定分辨率防插值污染。
用 bitmap 和 getpixel/setpixel 做灰度？别这么干
性能差到没法用，尤其图片稍大（比如 1000×1000），每像素调一次 getpixel 会触发 gdi+ 锁、颜色空间转换、边界检查——实际速度可能比纯 c++ 慢 50 倍以上。
真正该走的路是直接操作像素内存。核心就两步：锁定位图数据 → 按字节改 RGB 值。
- 必须用
Bitmap.LockBits获取BitmapData，拿到Scan0指针和Stride - 灰度公式推荐用加权平均：
0.299 * R + 0.587 * G + 0.114 * B（人眼对绿色最敏感） -
Stride不等于宽度 × 字节，它按 4 字节对齐，比如 3 像素宽的 24 位图，Stride是 12 而不是 9 - 处理完务必调
UnlockBits，否则资源泄漏，多次调用后程序可能卡死或抛OutOfMemoryException
为什么 PixelFormat.Format32bppArgb 比 Format24bppRgb 更好处理
32 位格式每像素固定 4 字节（RGBA），地址计算简单：第 (y * Stride + x * 4) 字节是 B，+1 是 G，+2 是 R，+3 是 A。而 24 位格式每行字节数不整除 4，x 偏移得手动算对齐，容易越界。
- 创建新图时显式指定
PixelFormat.Format32bppArgb，避免隐式转换引入额外开销 - 即使原图是 24 位，也先用
new Bitmap(src, ...)转成 32 位再处理，比硬啃 24 位内存快且稳 - Alpha 通道保留原值（不设为 0 或 255），否则透明区域会变黑或白
用 ColorMatrix 做灰度？适合批量但不够灵活
ColorMatrix 是 GDI+ 提供的矩阵变换方案，适合 UI 层快速预览或动画滤镜，但控制粒度粗、不能条件处理（比如只灰度非透明区域）。
- 矩阵必须设成：
0.299, 0.587, 0.114, 0, 0这一行重复四次，最后一行保持0,0,0,1,0（保证 Alpha 不变） - 要用
ImageAttributes+Graphics.DrawImage才生效，不能直接改原图内存 - 每次绘制都走完整渲染管线，CPU 占用高，不适合后台批量处理千张图
- 如果图像带 ICC 配置文件，
ColorMatrix可能被忽略，结果偏色
灰度后保存为 JPEG 为什么发灰或对比度低？
不是算法问题，是 JPEG 编码器默认做了亮度/对比度补偿。原始灰度值 0–255 被压缩时，高频细节丢失更明显，尤其在暗部。
- 用
EncoderParameters显式设置Encoder.Quality为 95 以上，避免过度压缩 - 不要用
bitmap.Save("x.jpg")默认参数，它等价于 Quality=80，暗部容易糊成一片 - 如果需要精确控制，转成
Format8bppIndexed并自定义调色板（只含 256 级灰阶），再保存为 PNG - 注意：JPEG 不支持 Alpha，保存前确保背景已合成，否则透明区域会变成黑色
最麻烦的其实是跨 DPI 场景下 Bitmap 创建时没指定分辨率，导致缩放后灰度值被插值污染——这个点连很多老手都会漏。
