Cloud Function从存储桶下载图片时返回未知张量形状的异常问题

核心根因 #

• 执行模式差异：本地运行时默认开启纯Eager执行流，tf.io.decode_image被调用时会立即触发图片解码计算，所有维度信息都会被静态记录，可输出完整形状。Cloud Function运行时会对入口函数做图追踪预处理，在未触发实际计算的阶段，通用图片解码接口无法完全从图片字节头推导全量静态形状，就会输出带<unknown>的部分形状信息。
• 返回值序列化差异：直接将TensorShape自定义对象作为返回值，不同运行环境的序列化逻辑对该对象的解析规则不一致，会直接输出<unknown>字符串。
• 接口特性差异：通用解码接口tf.io.decode_image默认动态适配图片通道数，静态形状推导阶段不会强制锁定通道维度，进一步放大了两种环境下的结果偏差。

定位排查思路 #

• 在云函数入口添加日志，打印tf.executing_eagerly()的返回值，确认当前运行时的执行模式
• 打印云存储下载得到的图片字节流长度，确认下载的图片字节完整、无损坏
• 打印解码后张量调用.numpy()得到的实际数组形状，确认解码流程本身运行正常
• 核对本地开发环境与云函数运行时安装的TensorFlow版本，排除版本差异导致的接口行为变化

可落地的解决方法 #

• 替换为对应图片格式的专用解码接口，强制锁定解码参数：由于从存储桶下载的是PNG格式图片，可将通用tf.io.decode_image替换为tf.image.decode_png，显式指定通道数，降低静态形状推导的不确定性
  调整前的代码：

  image = tf.io.decode_image(img, dtype = tf.dtypes.float32)
  

  调整后的代码：

  image = tf.image.decode_png(img, dtype=tf.dtypes.float32, channels=3)
  

• 强制触发实际计算，规避静态形状推导的不确定性：拿到解码后的张量后，通过调用.numpy()强制触发图计算执行完成，此时读取到的形状为解码后的实际值
• 转换返回值类型，规避自定义对象的序列化问题：不要直接返回TensorShape对象，将其转为普通Python元组/列表再作为返回值
  调整前的代码：

  shape = image.shape
  return {"1":shape}
  

  调整后的代码：

  # 强制触发计算，拿到全量实际形状
  actual_shape = tuple(image.numpy().shape)
  return {"1": actual_shape}
  

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