用 BufferedImage 读取图片后怎么安全获取像素值
直接调用 getRGB() 拿到的是 ARGB 整数，不是 R/G/B 单独的 0–255 值，新手常误以为返回的就是灰度或红通道。必须手动拆解：高位是 alpha（可能为 0），接着是 red、green、blue 各占 8 位。
- 正确做法是用位运算：
(rgb >> 16) & 0xFF取 red，(rgb >> 8) & 0xFF取 green，rgb & 0xFF取 blue - 如果图片是索引色（
TYPE_BYTE_INDEXED）或二值（TYPE_BYTE_BINARY），getRGB()仍能工作，但内部会做颜色表映射——不推荐直接处理，先用new BufferedImage(..., TYPE_INT_ARGB)转一次更稳 - 避免在循环里反复调用
getWidth()/getHeight()，提前存成变量；否则 HotSpot 未必能完全内联，小图不明显，大图（如 4K）下 GC 压力会上升
ColorConvertOp 看似简单但实际不适用于自定义灰度公式
它默认按 ITU-R BT.709 标准加权（0.2126*R + 0.7152*G + 0.0722*B），不能改系数。如果你要实现老式 NTSC（0.299/0.587/0.114）或纯平均法（(R+G+B)/3），这条路走不通。
-
ColorConvertOp适合快速预览或对精度无要求的批量转换，比如 UI 缩略图生成 - 它内部用 native 实现，比纯 Java 循环快，但只支持固定色彩空间转换（如 RGB → GRAY），不暴露像素级控制权
- 若强行绕过——比如先转成
TYPE_BYTE_GRAY再读回像素——会触发隐式重采样，且某些 JDK 版本（如 OpenJDK 8u292）在非标准 DPI 屏幕上可能出偏色
手动灰度计算时权重选哪个？别硬背，看用途
灰度不是数学问题，是视觉感知问题。人眼对绿色最敏感，红色次之，蓝色最弱——所以等权平均（(R+G+B)/3）看起来发灰、发闷，实际很少用。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 印刷/文档扫描常用
0.299*R + 0.587*G + 0.114*B（NTSC），兼容性好，旧设备显示也稳 - 高清视频/现代 UI 推荐
0.2126*R + 0.7152*G + 0.0722*B（BT.709），绿色权重更高，细节保留更好 - 想省 CPU？用查表法：预生成长度 256 的 int 数组
grayLut[r] = (int)(0.299*r)，再叠加 g/b 查表结果，避免浮点乘法（尤其在嵌入式 JVM 上明显）
写回图片前必须注意 setRGB() 的坐标系和类型匹配
setRGB(x, y, rgb) 的 x 是列（水平）、y 是行（垂直），和数组下标 [y][x] 一致，但和数学坐标系相反——错一位就整张图斜着花。
立即学习“Java免费学习笔记（深入）”；
- 目标
BufferedImage类型必须是TYPE_INT_ARGB或TYPE_INT_RGB；如果是TYPE_BYTE_GRAY，setRGB()会静默忽略 alpha 位，且 G 值被截断到 0–255，但传入的rgb若含非零 alpha，结果不可控 - 批量设像素用
setRGB(int[], offset, scanline, ...)比单点调用快 5–10 倍，尤其 >1MP 图片；但要注意scanline必须等于图片宽度，否则内存越界写（JVM 不报错，图像错位） - 保存为 JPEG 时，
ImageIO.write(img, "jpg", out)中的格式名必须是"jpg"或"jpeg"，写成"JPEG"在部分 JDK（如 Amazon Corretto 11.0.15）上会返回 false 且无异常
