OpenImageIO中ImageInput::open()失败主因是路径/权限/插件缺失，非格式不支持；需调用OIIO::geterror()查真实错误，如“No appropriate input plugin found”。
OpenImageIO 读取图像时 ImageInput::open() 失败的常见原因
直接失败通常不是格式不支持，而是路径、权限或插件缺失。OpenImageIO 默认不自动加载所有解码器，尤其对 HEIC、WebP、JPEG2000 等需显式启用插件或编译时开启支持。
-
ImageInput::open()返回false且无错误信息？调用OIIO::geterror()看真实报错，比如"No appropriate input plugin found" - Linux/macOS 下检查
libOpenImageIO.so是否链接了libwebp或libjpeg；Windows 下确认对应 DLL 在 PATH 或可执行目录中 - 路径含中文或空格？OpenImageIO 旧版本（std::filesystem::absolute() 转成规范路径再传入
用 ImageInput 读取像素数据时内存布局和通道顺序怎么对上
OpenImageIO 默认返回的是“原始”通道排列（如 JPEG 是 RGB，PNG 可能是 RGBA，EXR 是 R G B A 分离），但不保证与你预期的 uint8_t* 布局一致——它取决于文件元数据 + 你指定的 format 参数。
- 别直接假设
spec.nchannels == 3就是 RGB：EXR 可能有"R","G","B","A"以外的通道名（如"Y","Z"），用spec.channelnames检查实际名称 - 读取时务必指定目标格式，例如：
input->read_image(TypeDesc::UINT8, pixels)；若不指定，可能返回 float 数据（尤其 EXR），导致越界或全黑 - 想强制转成 RGBA uint8？用
ImageBuf更稳：ImageBuf buf(filename); buf.convert(TypeDesc::UINT8); buf.write("out.png")
多帧图像（如 TIFF 序列、动画 GIF、DPX 序列）怎么逐帧读取
OpenImageIO 把“单个文件含多帧”和“多个文件组成序列”当成两类问题处理，API 行为差异大，容易混淆。
- TIFF/GIF 动画：用
input->seek_subimage(subimage, miplevel)遍历spec.nsubimages；注意 GIF 的subimage索引从 0 开始，但某些老 TIFF 可能跳帧 - 文件序列（
img.001.exr,img.002.exr）：不要手动拼路径！用ImageInput::open("img.*.exr")（支持 glob），然后靠spec.x/y/z和spec.full_x/y区分每帧裁剪区域 - DPX 文件时间码缺失？
spec.get_string_attribute("dpx:time_code")可能为空，得 fallback 到文件名解析
ImageBufAlgo::resize() 输出模糊或边缘撕裂怎么办
默认插值器是 "lanczos3"，听起来高级，但在小图缩放或整数倍缩放时反而引入振铃或偏移——这不是 bug，是设计如此。
立即学习“C++免费学习笔记（深入）”；
- 缩放后文字/线条发虚？换插值器：
ImageBufAlgo::resize(dst, src, "box")（下采样）或"bilinear"（上采样）更可控 - 输出尺寸非整数倍（如 1920x1080 → 500x281）？确保
dst.spec().full_x/y和.x/y对齐，否则 ROI 计算错位，边缘缺一行或重复 - Alpha 通道没参与重采样？默认
resize会处理所有通道，但若源图 alpha 名为"A"而你用了自定义通道名（如"alpha"），需手动设置roi.chbegin = 0; roi.chend = spec.nchannels
最麻烦的其实是跨平台浮点一致性：macOS 的 AVX 优化和 Linux 的 SSE 可能在 resize 中产生微小差异，做像素级比对前先确认是否真需要 bit-exact。
