augly的PadSquare后接单值Resize触发张量尺寸不匹配RuntimeError求助

问题原因分析 #

1. torchvision.transforms.Resize的参数逻辑差异

这是最核心的直接原因，Resize的输出尺寸完全由传入的参数格式决定：

• 当传入单个整数/长度为1的序列（比如你的第一种写法[384]）时，Resize会保持输入图片的宽高比不变，仅把图片的短边缩放到你指定的数值，长边则按照宽高比计算后取整（不同版本torchvision的取整策略不同，旧版用四舍五入，新版用向下取整）。如果输入不是严格的正方形，输出必然也是非正方形。
• 当传入长度为2的序列（比如你修改后的写法(384,384)）时，Resize会忽略原始宽高比，直接强制把所有图片缩放到指定的(高度, 宽度)尺寸，输出的所有图片尺寸完全一致，自然可以正常堆叠成batch。

2. 为什么PadSquare处理后还会出现非正方形输入

你在单独测试时没有复现，是因为测试样本都是常规样本，而全量数据中存在边界特殊样本，导致augly.image.PadSquare实际输出不是严格正方形，常见触发场景如下：

• 样本携带EXIF方向信息：PIL默认读取图片时不会应用EXIF中存储的旋转、翻转参数，而augly的PadSquare内部会自动处理EXIF方向，导致宽高计算逻辑不匹配，补边后最终宽高差1像素。
• 低版本augly的PadSquare存在边界bug：当原图宽高的差值为奇数时，上下/左右的补边像素分配逻辑异常，最终输出的宽高差1像素。
• 部分样本通道数不统一：如果你的数据集里存在单通道灰度图、四通道RGBA图，读取时没有统一转成3通道RGB，PadSquare对不同通道数的图片处理逻辑有差异，也会导致尺寸偏差。

推荐解决方案 #

• 优先使用你修改后的写法，直接给Resize传入(384, 384)强制固定输出尺寸，这是最稳妥的方案，不受上游变换输出的影响。
• 如果需要排查PadSquare的问题，可以在PadSquare之后增加尺寸校验逻辑，打印出宽高不一致的样本路径，定位具体的异常样本。
• 图片读取时统一转成3通道RGB：Image.open(img_path).convert("RGB")，避免通道数差异导致的异常。
• 提前处理EXIF方向：用PIL.ImageOps.exif_transpose()将图片转成实际显示的尺寸后再做后续变换。

内容的提问来源于stack exchange，提问作者JohnJ