cv2.imread()读取图像默认返回uint8类型HWC数组，像素值范围为[0,255]，而非深度学习所需的float32和[0,1]或[-1,1]范围，需手动转astype(np.float32)并除以255.0或按模型要求归一化。
OpenCV cv2.imread() 读出的图为什么不是 [0,1] 范围？
因为 cv2.imread() 默认返回 uint8 类型的 HWC 数组，像素值在 [0, 255] 区间，不是深度学习模型通常期望的 float32 + [0, 1] 或 [-1, 1] 范围。直接喂给 PyTorch/TensorFlow 会报错或训练异常。
实操建议：
- 读图后立刻转
astype(np.float32)，再除以255.0（注意是浮点数，别用255） - 别用
cv2.cvtColor(img, cv2.COLOR_BGR2RGB)后再归一化——顺序不影响数值，但 BGR→RGB 必须在归一化前做，否则颜色错乱 - 如果后续要用
torchvision.transforms，它内部的ToTensor()会自动除 255 并换轴，此时你自己别重复归一化
标准化时该用 255.0 还是 127.5？
取决于模型训练时的预处理约定。不是“哪个更好”，而是“必须对齐”。比如 TensorFlow 的 tf.keras.applications 系列（如 ResNet50）默认要求输入范围 [-1, 1]，即 (img / 127.5) - 1；而大多数自定义 CNN 或 PyTorch torchvision 模型习惯 [0, 1]。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 模型输出全 NaN 或 loss 不下降 → 很可能归一化范围和模型权重预期不匹配
- 图像看起来发灰/过曝 → 可能用了
/ 127.5却没减 1，或者反过来 - PyTorch 加载 OpenCV 图后没调
.permute(2,0,1)→ shape 错成 (H,W,C)，导致广播归一化出错
cv2.imread() 返回 None 的真实原因和排查路径
不是文件不存在这么简单。cv2.imread() 对路径编码、空格、中文、相对路径非常敏感，且静默失败（不抛异常，只返回 None）。
实操建议：
- 先用
os.path.exists(path)和os.path.isfile(path)双重确认 - 路径里有中文？改用
cv2.imdecode(np.fromfile(path, np.uint8), cv2.IMREAD_COLOR) - 相对路径加载失败？打印
os.getcwd()看当前工作目录，别假设和脚本同目录 - Linux 下权限不足也可能返回
None，检查ls -l path
批量读图时内存爆掉，np.float32 真的比 uint8 多占 4 倍？
是的，但问题常被低估：一张 1080p RGB 图，uint8 占约 3.3MB，转 float32 就变成 ~13.2MB。1000 张图就超 13GB 内存。
性能与兼容性权衡：
- 训练时用
float32是必须的，但可延迟转换：先用uint8存在 list/queue 里，DataLoader的__getitem__中再转 - OpenCV 的
cv2.normalize()默认不改变 dtype，别指望它帮你省内存 - 如果只是可视化调试，用
plt.imshow(img.astype(np.uint8))即可，别全程 float32
最容易被忽略的一点：GPU 上做归一化（比如用 torch.tensor(img).float() / 255）看似省了 CPU 内存，但 tensor 创建时仍会先在 CPU 拷贝一份 float32 —— 批量加载阶段，CPU 内存仍是瓶颈。
