视觉模型输入图片尺寸的预处理方案

视觉模型输入图片尺寸预处理，优先保留长宽比，再根据任务决定是否裁剪。需要读小字或局部缺陷时，不应只把整张大图缩到很小；可以保留全图上下文，并另传明确位置的局部图。最终尺寸与切片规则必须服从具体模型的 processor 或接口要求，没有适用于所有视觉模型的统一像素值。

下面实现一个小函数：对可信 RGB 单帧照片按 EXIF 方向转正，可选裁剪，再等比缩小。它只负责业务侧图片准备，不实现推理服务，也不把示例的 1024 当成模型硬限制。

Pillow 官方地址：https://pillow.readthedocs.io/

先分清业务预处理与模型 processor

业务预处理决定上传哪部分内容、需要保留多少上下文；模型 processor 则负责与预训练输入约定匹配的变换。二者可能都包含缩放，不能因为名字相似就把默认配置全部关闭。

Hugging Face Transformers 的图像处理配置可以包含 resize、crop、rescale 和 normalize，具体行为与模型有关。动态分辨率模型也可能采用不同切片或像素预算。接入时应读取目标模型配置与文档，不从某篇通用教程推断支持上限。参见 官方图像 processor 说明。

把等比缩放、裁剪和补边作为不同选择

不要直接把宽图拉成正方形。若接口允许非正方形图片，保留比例通常更容易解释；如果模型要求固定输入，应遵从它的处理约定。裁剪也不是越紧越好，例如判断标识属于哪个设备时，完全去掉周围结构可能让问题失去参照。

实现只缩不放大的照片准备函数

在已经安装 Pillow 的 Python 环境中使用下面示例。ROI 是转正后图片上的 left、top、right、bottom；右边和下边作为裁剪区间的结束边界。未提供 ROI 就保留全图。函数拒绝非 RGB 和多帧输入，因此透明图片不能直接套用，需要另行约定透明背景如何合成。

from PIL import Image, ImageOps

def prepare_photo(path, max_edge=1024, roi=None):
    # 本例仅处理可信RGB单帧照片，尺寸上限是应用策略而非模型标准
    if type(max_edge) is not int or max_edge 

本例使用 ImageOps.exif_transpose 处理方向，并用 thumbnail 保持比例、限制最大尺寸；相关操作见 Pillow 官方 ImageOps 文档。输入打开失败或格式不支持会抛出异常，调用层应返回明确失败，不能用空白占位图冒充成功。

这是读者可运行的示例，本文未执行图片处理或模型推理。生产上传还需另行处理文件大小、解码资源限制、颜色管理等问题，不要把这个函数直接当成完整上传安全组件。

用尺寸算例定位细节丢失的位置

若转正后的原图是 4000×2000，把最长边限制为 1000，等比尺寸应为 1000×500。这是比例计算，不是运行测量。原图里高 20 像素的字，在该比例下只剩约 5 像素高；即便传输格式无损，也不能保证模型读清。

对局部读字任务，可在允许多图输入的模型中同时提供全图与目标局部图，并明确指出局部图来自全图哪个区域。局部坐标必须对应同一张转正后的原图，不可把缩小后的坐标直接传给原图裁剪。

建议读者用三类自有样本检查：包含画面边缘目标的宽图、纵向照片，以及只比尺寸上限略大的图片。观察目标是否保留、比例是否变化、字是否缩得过小，而不是只看生成文件有没有超过指定宽度。

接入模型时避免重复缩放和盲目放大

将函数返回的 metadata 与本次输入关联保存，至少能说明原始尺寸、ROI、裁剪尺寸和输出尺寸。模型端还会做什么处理，单独记录；不要只保留文件名却无法说明内容经过了几次裁剪。

不建议对不清晰的小图做大倍率插值后宣称“细节恢复”。放大改变像素网格，不等于增加原始信息。若任务必须依赖微小文本，应优先获取更清楚的原始图片，或在模型允许的条件下重新规划局部输入。

所有图片都缩到1024就行吗？不行，1024仅是示例的应用上限，最终要结合任务细节与模型要求。

裁剪后是否还需要全图？取决于问题。只读局部内容与判断局部在全局的位置，需要的信息不同。

补边会不会总比裁剪好？不会。补边保留画面但增加无效区域，裁剪保留局部却丢上下文，应按模型约定和任务目标选择。